For GMT master cpt files, the z-values are in the range 0/1, or -1/1 if there is a hinge. That carries some disadvantages: the non-normalised file
0 0/0/255 10 0/0/255
10 0/255/0 20 0/255/0
20 255/0/0 30 255/0/0
normalises to
# RANGE = 0/30
0.00000000 0/0/255 0.333333333 0/0/255
0.33333333 0/255/0 0.666666667 0/255/0
0.66666667 255/0/0 1.000000000 255/0/0
so the exact z values are converted to approximate values which need to be given to high precision to minimise loss of accuracy.
A further disadvantage is that 3rd party parsing of normalised cpt files needs to read and account for the RANGE directive, essentially reimplementing some of the functionality of makecpt.
Currently, GMT works with the non-normalised files as if it normalises the files on input, as discussed here. If that behaviour were to be permanent, then I think the idea of a “denormalised” cpt file would be useful. This is a non-normalised file with a RANGE that agrees with the actual z-values:
# RANGE = 0/30
0 0/0/255 10 0/0/255
10 0/255/0 20 0/255/0
20 255/0/0 30 255/0/0
z-values can be exact in common use-cases, the RANGE directive can be ignored by 3rd party parsers, GMT reads and processes these files “as you would expect”. Possibly this denormalsed form could be used on cpt-city?
Thoughts?
(Proposed changes to cptutils to support this here.)