GenericMappingTools
Ability topping NaN nodes/pixels in grdview with the NaN color
See the forum post for background.
Apparently, grdview can only paint nodes with the NaN colour for -Qs (surface) and when the 3D vantage point -paz/el is not used. This seems unnecessarily restrictive for no good reason and probably hails back to the GMT4 days. My proposal to improve this involves a new modifier to -Q. New syntax (and improved layout for all):
-Qc|i|m[x|y][color]|s[m][+m][+n]
Select among the following directives c i m or s:
- Specify c. Same as -Qi but will make pixels with z = NaN transparent, using the colormasking feature in PostScript Level 3 (the PS device must support PS Level 3).
- Specify i for image plot, and optionally append the effective dots-per-unit resolution for the rasterization [Default is GMT_GRAPHICS_DPU].
- Specify m for mesh plot [Default], and optionally append color for a different mesh paint [white].
- Specify mx or my for waterfall plots (row or column profiles). Optionally, append color as for plain m.
- Specify s for surface plot coloured by the CPT, and optionally append m to have mesh lines drawn on top of surface (use -Wmpen to set specific mesh pen).
Note: If the CPT is categorical then only -Qm is available (but see -T).
Optional modifiers:
- +m - Force a monochrome image. Colors are then converted to shades of gray using the (monochrome television) YIQ transformation
- +n - Force colorisation of NaN nodes or pixels via the NaN CPT or default colour. PROPOSED.
One question is if we leave the NaN colour default for -Qs or if that also needs +n? Probably for backwards compatible reasons we should leave it?
Yes, but (as Yvonne said on the post) how GMT would know at what z value should paint the NaN? At the bottom of the 3D block? at the top? in the middle? So, the modifier must include a z value.
The NaN value is used, not some random z-value. Aren’t we talking NaNs?
Paul Wessel Professor Emeritus, Department of Earth Sciences (808) 956-4778 | @.*** http://www.soest.hawaii.edu/earthsciences
On 17 January 2024 at 12:50:33, Federico Esteban @.***) wrote:
Yes, but (as Yvonne said on the post) how GMT would know at what z value should paint the NaN? At the bottom of the 3D block? at the top? in the middle? So, the modifier must include a z value.
— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/GenericMappingTools/gmt/issues/8301*issuecomment-1895649416__;Iw!!PvDODwlR4mBZyAb0!T6N3-p0X4FsExxR39vvgorBE6akpqeMN7B9M2CuIE3BGHfWYJk2nU5481820m8vCfptas8lGEN4IvurZNKAE4Zc9aw$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AGJ7IX26QVKY7P32RVJSXJ3YO63INAVCNFSM6AAAAABB6KT2EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGY2DSNBRGY__;!!PvDODwlR4mBZyAb0!T6N3-p0X4FsExxR39vvgorBE6akpqeMN7B9M2CuIE3BGHfWYJk2nU5481820m8vCfptas8lGEN4IvurZNKDYMNAubg$ . You are receiving this because you were assigned.Message ID: @.***>
As I understand, grdview works with two grids: reliefgrid (sets the shape) and drapregrid (sets the colors).
We can set the color of NaN for the drapregrid. This is easy.
But we also need a value for the reliefgrid. I think this is why grdview can't paint the NaN nodes.
HM, OK there are several issues with grdview that we have addressed in grdview so now there are differences in syntax, docs, and maybe internal operations. Back from GMT4 we used to allow grdimage to accept three grids (red.grd, green.grd, blue.grd). We still do so under the hood but usage and documentation only discusses single grid and single image (grid | image). In fact, grdimage handles those 3 grids as three consecutive files given on input. This differs in grdview.
In grdview.c we list the single relief grid but under -G for drape grid we still list the option for three grids (-Gdrapegrid | -Gred.grd -Ggreen.grd -Bblue.grd). So here, -G is repeated 3 times. This all looks ugly to me. Apart from the NaN-color issue, I think grdview needs to modernise its documentation and usage and hide this ugliness but accept it via backwards compatibility. Our preferred way of images is passing an RGB image, not 3 grids from an era before @joa-quim worked to include images. We might even consider a GMT_Call_Module to grdmix if we get 3 color grids and return the image.
In the presence of draping, the relief grid just provides geometry/shape and there is nothing to paint. COlor is determined by the draping and that grid may have NaNs to be coloured or it is an image. grdimage image has many ways to handle NaN color - not sure if we want to replicate all that in grdview.
I think I may want to work on a PR that fixes the oldfashinoned -Gred -Ggreen -Gblue syntax first.
I think @joa-quim might recall we had a rgb2grd module a long time ago? So that is how people made those 3 grids. Better to expect -Ggrid|image and leave some stuff under the hood in case someone runs an old script with three -G drape grids.
Also @joa-quim you added this in the grdview parser:
case 'z': /* One image. This is an undocumented fake option but one that lets externals pass both images and grids for draping. */
We will see but perhaps there wont be a need for this once -Gimage works, but no biggie.
What do you think is grdview would work (under the hood) as my script? It creates a 2D image and then drop it over the relief. This is simpler to do (I suspect) and would have the advantage that we grdview won't plot things that should be hidden by the relief (that could happened in more complex figures).
Sorry, a bit early to know - I am in the middle of stuff. Not quite sure of what you are asking.
Also @joa-quim you added this in the grdview parser:
case 'z': /* One image. This is an undocumented fake option but one that lets externals pass both images and grids for draping. */We will see but perhaps there wont be a need for this once -Gimage works, but no biggie.
Hmm, I'm not finding any use of that hidden case z: in GMT.jl
Hmm, I'm not finding any use of that hidden
case z:in GMT.jl
Think we can remove it. We learn that one image is passed and that is all that is needed I think.