CPT ranges and hinges

Q&A
1

Hi all,

I’m updating my cptutils package to support the RANGE and HINGE directives in CPT files; I’m finding explicit documentation on the format difficult to source, so I’ve reverse-engineered an understanding from the behaviour of makecpt. I wonder if experts could confirm the following:

For a CPT with a RANGE, but without a HINGE:

If the CPT is correctly normalised, (so -1/1, or 0/1, or -1/0), then the colour stops are stretched to fill the RANGE, essentially overriding the makecpt -T option: the file

# RANGE = -1/100
-1 red 0 white
0 black 1 blue

gives

$ makecpt -Ctest -N
-1	red	49.5	white
49.5	black	100	blue
$ makecpt -T-1/100 -Ctest -N
-1	red	49.5	white
49.5	black	100	blue
$ makecpt -T-1/1 -Ctest -N
-1	red	0	white
0	black	1	blue

If a CPT is incorrectly normalised, say -1/3, then the effect is that the z-values are linearly scaled so that they are normalised, and then the RANGE or -T option is processed as usual, so

# RANGE = -1/100
-1 red 0 white
0 black 3 blue

gives

$ makecpt -Ctest -N
-1	red	24.25	white
24.25	black	100	blue
$ makecpt -T-1/100 -Ctest -N
-1	red	24.25	white
24.25	black	100	blue
$ makecpt -T-1/1 -Ctest -N
-1	red	-0.5	white
-0.5	black	1	blue

In particular, the absence of HINGE means there is no hinge, there is no default.

When there is an explicit HINGE, and the z-values are correctly normalised, then the same stretching takes place but separately for either side of the hinge: so

# HINGE = 0
# RANGE = -1/100
-1 red 0 white
0 black 1 blue

gives

$ makecpt -Ctest -N
-1	red	0	white
0	black	100	blue
$ makecpt -T-1/100 -Ctest -N
-1	red	0	white
0	black	100	blue
$ makecpt -T-1/1 -Ctest -N
-1	red	0	white
0	black	1	blue

When the CPT is incorrectly normalised, then again, normalisation is performed before processing the range directive/option, but performed separately on the two parts, so

# HINGE = 0
# RANGE = -1/100
-1 red 0 white
0 black 3 blue

so

$ makecpt -Ctest -N
-1	red	0	white
0	black	100	blue
$ makecpt -T-1/100 -Ctest -N
-1	red	0	white
0	black	100	blue
$ makecpt -T-1/1 -Ctest -N
-1	red	0	white
0	black	1	blue

So would I be right in thinking, at least morally, that normalisation is not a big deal, that it’s best to think of a CPT without a hinge as being a like a v4 CPT, the RANGE being a default for the -T option, and if there is a HINGE, then we essentially have 2 CPTs, one with range min/HINGE and the other HINGE/max? So there’s nothing special about the ranges -1/1, 0/1, -1/0, they’re really to keep things tidy, no semantics in there?

Thanks in advance!

Jim

2

Hi Jim, I think we did not add hard-core checks to ensure that the normalised CPTs actually have 0/1 or -1/1, and that HINGE requires -1/1 etc, etc., but perhaps we should add some extra checking to avoid surprises. Other that that I think you got things right. True that there is not much docs on this, but given that many experts definitively want to play around with CPTs for various purposes we should of course have some better instructions. As one of such experts, if you want to contribute a little section that might for instance go in to makecpt/grd2cpt docs under some NOTES section we would be very receptive to that and can do the stitching.

3

Thanks Paul, I’ll look at getting some detailed technical notes for cptutils and make a precis for makecpt.

One further query, I thought that perhaps the cpt COLOR_MODEL is redundant in GMT5+ since “each colour has its model embedded in its form”, r/g/b, h-s-v etc, but it is retained to specify “interpolation method”?

# COLOR_MODEL = RGB
0 0-0.5-0.5 1 180-0.5-0.5

and

# COLOR_MODEL = HSV
0 0-0.5-0.5 1 180-0.5-0.5

when passed to makecpt -Z -T0/1/0.5 -N -Fh produces

0	0-0.5-0.5	0.5	0-0-0.375
0.5	0-0-0.375	1	180-0.5-0.5

and

0	0-0.5-0.5	0.5	90-0.5-0.5
0.5	90-0.5-0.5	1	180-0.5-0.5

respectively, the latter seeming to be linear interpolation of the HSV channels. (That would seem a sensible technical choice to me.)

4

Yes I think that is right but cannot check at the moment