grdinfo -E<nlevels> reads the range of a grid, splits it into <nlevels> intercals and builds a cpt. It allows a quick cpt suitable for a grid to be generated. Yet, there is no direct equivalent for table data. You can use gmt info -T<zinc> to return a -Tzmin/zmax/zinc string that can be used with makecpt to create the cpt file, but this result depends on <zinc> which would have to be selected carefully, knowing the data range in the first place. Experienced scripters can deal with this in a few lines, but it is certainly more tedious than for grids.

Proposal: Add a new -E<nlevels> option to makecpt. This would imply two things:

A filename(s) (or stdin) will be required so makecpt can compute the range of the data set.

Once range is known then the cpt file with <nlevels> slices can be computed.

Users would use the common -i<cols> option to select from which data column the range should be computed. If not given we default to the z column [-i2] or the last column, whichever is first.

History

You mean grd2cpt, right? I like your proposed makecpt feature. The resulting cpt file should ofc be histogram-equalized. So apart from determining the range, makecpt also has to fit the levels such that the number of records per level is equal.

Sorry, yes grd2cpt obviously. Histogram equalization is a different matter. -E<nlevels> in grd2cpt is just a simple stretching, there is no equalization there; that takes place via other options or no option.

Yes, I like the either of added the option -E also to makecpt.Can I ask for another feature to -E?It would be nice if -E without any argument would create the same amount of levels as the colour map contains. This would be similar to makecpt -T<zmin>/<zmax> without specifying the interval. Of course, both makecpt -E and grd2cpt -E should have this.

I have made the initial implementation of -E as discussed; in r12909. The last data column is used for the range determination and this can be changed via -i. For native binary data tables the -b option must be used.