Adding new grdmix module

[PaulWessel]

Description of proposed changes

Experimental module to blend two grids or images using weights from a third, or to just add transparency to an existing single image. The immediate goal is to get this to work:

gmt grdmix @BlueMarble_06m.tif @BlackMarble_06m.tif [email protected] -Gnewmap.png

but it is still screwing. At least 2 hours from scratch got me pretty far. I added the dummy alpha.png to the cache for now - it will be removed once this all works. I expect to add all the usual resolutions for those images though up to 30s.

[seisman]

@PaulWessel I think it's a good opportunity to document what files should be added/updated when a new module is added.

[PaulWessel]

Yes, with the new cmake glue there was no need to touch CMakeFiles anymore. I have not touched the docs yet (other than adding grdmix.rst itself). But for the C side it seems no need - all is auto. Docs still need to be added into the website.
Still finding lots of bugs though in img stuff. I an reading a all-read 50x50 PNG which is stored as RGB 3 layers. However, when GMT_Read_Data returns, it says all the right thing but only the first 834 triplets are 255/0/0. SHould be 2500 triplets (50x50x3), so JL's GDAL reader is somehow dividing by 3 somewhere... So hard to test grdmix which I think is otherwise correct. I will implement import_ppm to go with export_ppm so I can test grdmix without relying on GDAL.

[PaulWessel]

Working strictly with PPM files I can show that this works as expected:

gmt grdmix BlueMarble_06m.ppm @BlackMarble_06m.ppm [email protected] -Gnewmap.ppm

Converting the latter to png yields this:

[PaulWessel]

After using Change_Layout everything runs fine but I get this image:

So supposedly that means bug in lines 12534-38. Can you see anything obvious, @joa-quim ?

[PaulWessel]

Will change grdmath call once #3319 is merged.

[seisman]

@PaulWessel These warnings are not directly related to OpenMP. I see a lot of warnings like this when OpenMP is disabled on macOS.

../src/geodesy/gpsgridder.c:744:3: warning: comparison of integers of different signs: 'uint64_t' (aka 'unsigned long long') and 'int' [-Wsign-compare]
                gmt_M_grd_loop (GMT, Out[GMT_X], row, col, k) if (gmt_M_is_fnan (Out[GMT_X]->data[k])) n_ok--;
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gmt_grd.h:165:40: note: expanded from macro 'gmt_M_grd_loop'
#define gmt_M_grd_loop(C,G,row,col,ij) gmt_M_row_loop(C,G,row) gmt_M_col_loop(C,G,row,col,ij)
                                       ^~~~~~~~~~~~~~~~~~~~~~~
../src/gmt_grd.h:163:51: note: expanded from macro 'gmt_M_row_loop'
#define gmt_M_row_loop(C,G,row) for (row = 0; row < (int)G->header->n_rows; row++)
                                              ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
../src/geodesy/gpsgridder.c:744:3: warning: comparison of integers of different signs: 'uint64_t' (aka 'unsigned long long') and 'int' [-Wsign-compare]
                gmt_M_grd_loop (GMT, Out[GMT_X], row, col, k) if (gmt_M_is_fnan (Out[GMT_X]->data[k])) n_ok--;
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gmt_grd.h:165:64: note: expanded from macro 'gmt_M_grd_loop'
#define gmt_M_grd_loop(C,G,row,col,ij) gmt_M_row_loop(C,G,row) gmt_M_col_loop(C,G,row,col,ij)
                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gmt_grd.h:164:94: note: expanded from macro 'gmt_M_col_loop'
#define gmt_M_col_loop(C,G,row,col,ij) for (col = 0, ij = gmt_M_ijp (G->header, row, 0); col < (int)G->header->n_columns; col++, ij++)

[PaulWessel]

They are related to OpenMP because Windows OpenMP forces us to switch to signed loop variables where we wish to use OpenMP. Since our GMT_* struct variables for positively definite quantities are unsigned (e.g., n_columns, n_rows), we get these stupid messages. We cannot change n_columns to be signed since it is an API definition. We suddenly cannot add casts (int) to those macros because Linux now suddenly has a hissy-fit. So not sure what we can do but swallow the warnings...

[joa-quim]

VS has #pragma macros to shut up specific warnings. Don't gcc & llvm have that?

[PaulWessel]

Yes we can do -Wno-*** I think, but we then basically loose the ability of the compiler to warn us. Can't you step on Bill Gate's balls and have him allow unsigned loop variables like the rest of the world?

[PaulWessel]

I mean, we could do things like

#ifdef WIN32
  int64_t row, col;
#else 
  uint64_t row, col;
#endif 

and then we may only get those warnings on Windows, which seems fair since it is Bill's fault.

[seisman]

We suddenly cannot add casts (int) to those macros because Linux now suddenly has a hissy-fit.

It puzzles me a lot, since we are doing the (int) casts in the master branch and everything works fine.

[PaulWessel]

yes, but the OpenMP pragmas creates new C code that is then compiled (all under the hood) and that is probably where the warnings are coming from. Not sure though.

[joa-quim]

Blame the OMPeers. Were them who imposed the signed ints at that version. And you know I never liked those unsigned that keep biting us with this.

[PaulWessel]

I think this one is now ready to be merged, guys?