Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPT issues related to hinges #2412

Closed
seisman opened this issue Jan 6, 2020 · 22 comments
Closed

CPT issues related to hinges #2412

seisman opened this issue Jan 6, 2020 · 22 comments

Comments

@seisman
Copy link
Member

seisman commented Jan 6, 2020

Script below gives different results after #2327 was merged:

gmt makecpt -Cpolar -T100/300/20 > mycpt1.cpt
gmt makecpt -Cpolar -T100/300/20 -Z > mycpt2.cpt
gmt psscale -Cmycpt1.cpt -Baf -Dx0/0+w10c+h -P -K > map.ps
gmt psscale -Cmycpt2.cpt -Baf -Dx0/0+w10c+h -Y2c -P -O >> map.ps
gmt psconvert -A -P -Tg map.ps

Before:

image

After:

image

Issues:

  1. There is no way to generate a "polar" CPT like before.
  2. The new continuous CPT looks weird.

For the first issue, possible solutions are:

  1. Add an option to allow ignoring hinge
  2. For master CPTs like polar, red2green, is the hinge really useful? Should we remove hinges from these CPTs?
@PaulWessel
Copy link
Member

I think those CPTs do have a hinge, but I agree that it being hardwired to 0 is not useful in all cases. The before/after effect is of course the fix to actually do what we said we were doing regarding resampling. Possible options:

  1. Reset the hinge if selected range does not contain the actual hinge. It is unlikely people want the all-red CPTs above, they probably want 200 to be the new hinge.
  2. Offer a modifier +h[z] to the cptfile that resets the hinge to z (if given) or removes the hinge if not given.

I guess option 2 is more flexible and also can handle option 1 without making that the default action.

@seisman
Copy link
Member Author

seisman commented Jan 6, 2020

If I understand it correctly, the old behavior is to ignore the hinge, and we declared it as a bug and fix it in #2334. However, it means the new behavior will break many old scripts.

@PaulWessel
Copy link
Member

Yes, but clearly the intent of the hinge was to honor it, so there was a but. However, we are free to define what should happen when the requested range does not include the hinge, and we could decide that the only sensible thing to do is to ignore the hinge in those cases. Unlike CPTs for bathymetry (where hinge = 0 is a good thing), we could also decide that hinge for polar etc does not make sense since 0 is not a universal value for hinges.

@joa-quim
Copy link
Member

joa-quim commented Jan 6, 2020

I don't see much point to have a hinge in the polar CPT. And I like +h[z] idea, which has another virtue to provide hinges to any CPT that were not defined with one.

I can also already see a new movie of the waterworld where we flood the Earth only by changing the z in -hz

@PaulWessel
Copy link
Member

Perhaps we should remove the HINGE setting from the non-bathymetry/topo CPTs first, then implement a +h[z] for removing/adding a hinge as a new feature then.

@joa-quim
Copy link
Member

joa-quim commented Jan 6, 2020

Hm, removing the hinges is actually a backward compat measure.

@PaulWessel
Copy link
Member

Testing my +h modifier. Adding +h to @seisman's -Cpolar now gives this:

map

I am not sure what will happen if the +hz does not match one of the boundaries in the cpt file. I don't think we want to interpolate and breat a slice just to put in an odd z value for hinge.

@joa-quim
Copy link
Member

joa-quim commented Jan 7, 2020 via email

@PaulWessel
Copy link
Member

Havent tested that yet but the assumption in my implementation is that the CPT hinge is one of the z-nodes in the cpt.

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

Here are my expectation:

gmt makecpt -Cpolar -T-100/200/20

image

The default behavior is ignoring the hinge, the same as GMT5 and GMT 6.0.0 does.


gmt makecpt -Cpolar+h -T-100/200/20

image

With +h modifier, the hinge is honored, and the default hinge is 0.

-Cpolar+h50 should set the hinge to 50. In this case, the output should be the same as -Cpolar only.


gmt makecpt -Cpolar+h100 -T-100/200/20

I don't have a figure for this, but I expect to see blue to white from -100 to 100, then white to red from 100 to 200.

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

The comments above apply to non-bathymetry/topo CPTs only. For bathymetry/topo CPTs, the hinge should be always honored, i.e. -Ctopo is equivalent to -Ctopo+h.

@PaulWessel
Copy link
Member

OK, I can work on that.

@PaulWessel
Copy link
Member

I think this means we remove the HINGE keyword from the non-bathy/topo CPTs since otherwise I dont know when to honor hinges. So polar+h is needed to get the hinge as you indicate.

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

If we remove the HINGE from non-bathy/topo CPTs, how do we know if a CPT can have a hinge (i.e. polar can have a hinge, but seis cannot)?

@PaulWessel
Copy link
Member

I think any CPT can have a hinge but perhaps it makes little sense to push on on the seis cpt, but you could. We dont have to limit that I think.

@PaulWessel
Copy link
Member

Here is the list of all CPTs with hinges curently:

berlin.cpt:# HINGE = 0
broc.cpt:# HINGE = 0
cork.cpt:# HINGE = 0
earth.cpt:# HINGE = 0
etopo1.cpt:# HINGE = -0.001
geo.cpt:# HINGE = 0
globe.cpt:# HINGE = 0
lisbon.cpt:# HINGE = 0
mag.cpt:# HINGE = 0
no_green.cpt:# HINGE = 0
oleron.cpt:# HINGE = 0
polar.cpt:# HINGE = 0
red2green.cpt:# HINGE = 0
relief.cpt:# HINGE = 0
sealand.cpt:# HINGE = 0
split.cpt:# HINGE = 0
srtm.cpt:# HINGE = 1
terra.cpt:# HINGE = 0
tofino.cpt:# HINGE = 0
topo.cpt:# HINGE = 0
vik.cpt:# HINGE = 0
world.cpt:# HINGE = 0

I think the only one that should default to have a hinge are earth, etopo1, geo, globe, mag, relief, sealand, srtm, terra, topo, world.

@PaulWessel
Copy link
Member

Note taht some of the perceptually uniform colormaps are bimodal, such as vik, so they are kind of meant to have a hinge. But so is polar, and there is no rule it must be at zero, so best to remove those, too. I have to rescale the cpt masters to go from 0-1 instead of -1/1 as well for these.

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

I think the only one that should default to have a hinge are earth, etopo1, geo, globe, mag, relief, sealand, srtm, terra, topo, world.

I agree.

Note taht some of the perceptually uniform colormaps are bimodal, such as vik, so they are kind of meant to have a hinge. But so is polar, and there is no rule it must be at zero, so best to remove those, too. I have to rescale the cpt masters to go from 0-1 instead of -1/1 as well for these.

I'm a little confused. If there is no hinge in a master CPT, how do you resample the CPT? For example, if the master polar CPT is from 0 to 1, what does "gmt makecpt -T-10/50/5 -Cpolar+h10" mean?

@PaulWessel
Copy link
Member

Perhaps it is simplest to distinguish between a hard hinge and a soft hinge. We let the bathy/topo have a hard hinge at 0, but can let polar have a soft hinge at zero. Soft hinges are ignored unless +h is used while hard hinges are never ignored since they were designed with that feature in mind. So in your polar example the soft hinge of z' = 0 (normalized z' value at white) would be mapped to use data value z = 10. I think this is doable. Since the CPT language is not defined we can change the HINGE = 0 to HARD_HINGE = 0 and replace some with SOFT_HINGE = 0. I wonder if we even have to have a value for these since they are always at normalized z' = 0 except two case: srtm at 1 which I think is a special case where the hinge is in meter (we try to avoid painting the ocean) and etopo1.cpt which was made by Lester Anderson. Maybe I can redesign that one to use 0 as well.

@PaulWessel
Copy link
Member

In fact, all my hinged CPTs go from -1 to 1 with a hinge at 0, so I think they should all have hinge for z' = 0 and then that gets mapped to whatever you want (which normally is z = 0 but can be overridden).

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

That looks good to me.

@seisman
Copy link
Member Author

seisman commented Jan 7, 2020

So we should remove the HINGE keyword from non-bathy/topo CPTs. Then all the CPT can be divided into three groups:

  1. CPTs go from 0 to 1: no hinge, +h has no effects
  2. CPTs go from -1 to 1, but without the HINGE keyword: soft hinge, +h means honoring the hinge
  3. CPTs with the HINGE keyword: hard hinge, the hinge is always honored and

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants