Error recognizing .tif files from remote dataset

Q&A
1

I recently installed GMT with homebrew on a new mac, and am getting this error:

%  gmt grdcut @earth_day_30m -R-1.5/0/44.5/45.5 -Gdaytime.grd

grdcut [NOTICE]: Remote data courtesy of GMT data server oceania 
[http://oceania.generic-mapping-tools.org]

grdcut [NOTICE]: Blue Marble Earth Day View at 30x30 arc minutes reduced by 
Gaussian Cartesian r/g/b filtering (157.3 km fullwidth) [NASA].
grdcut [NOTICE]:   -> Download grid file [263K]: earth_day_30m_p.tif
grdcut [ERROR]: Unsupported image format. Supported formats are:
BMP,GIF,JPG,PNG & TIF
grdcut [ERROR]: Alternatively, append :<driver> for a valid GDAL driver
grdcut (gmtapi_export_image): Unknown Error [daytime.grd]
[Session gmt (0)]: Error returned from GMT API: GMT_IMAGE_WRITE_ERROR (23)
[Session gmt (0)]: Error returned from GMT API: GMT_IMAGE_WRITE_ERROR (23)
[Session gmt (0)]: Error returned from GMT API: GMT_IMAGE_WRITE_ERROR (23)

It seems it cannot recognize .tif files? I tried uninstalling / reinstalling gdal via homebrew with “–build-from-source” but this did not help. Is there something else I’m missing?

2 
grdcut [ERROR]: Unsupported image format. Supported formats are:
BMP,GIF,JPG,PNG & TIF

earth_day_... appears to be an RGB image, not data
grdcut works when specifying output as .tif

3

Yes, the error message is a bit misleading. Format of the saved image is picked from the extension and there is no image format with extension .grd

4

Does gdal also base the format by the extension? I thought it used a magic number.

5

just in case, omitting output file extension results in a segmentation fault:

...
grdcut [INFORMATION]: New:grdcut [INFORMATION]: 	-1.5	0	44.5	45.5	0.5	0.5	3	2
grdcut [DEBUG]: Object ID 1 : Registered Image File daytime as an Output resource with geometry Surface [n_objects = 2]
grdcut [DEBUG]: gmtapi_begin_io: Output resource access is now enabled [container]
grdcut [DEBUG]: gmtapi_export_image: Passed ID = 1 and mode = 0
grdcut [INFORMATION]: Writing image to file daytime
ERROR: Caught signal number 11 (Segmentation fault) at
/lib/x86_64-linux-gnu/libc.so.6(+0x19a397)[0x7fb1d4010397]
[0x0]
Stack backtrace:
/home/mkononets/mambaforge/envs/pygmt/bin/../lib/libgmt.so.6(gmt_sig_handler_unix+0xf0)[0x7fb1d42194e0]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7fb1d3eb8520]
/lib/x86_64-linux-gnu/libc.so.6(+0x19a397)[0x7fb1d4010397]
/home/mkononets/mambaforge/envs/pygmt/bin/../lib/libgmt.so.6(gmt_export_image+0xee)[0x7fb1d415478e]
/home/mkononets/mambaforge/envs/pygmt/bin/../lib/libgmt.so.6(GMT_Write_Data+0x2158)[0x7fb1d412ef28]
/home/mkononets/mambaforge/envs/pygmt/bin/../lib/libgmt.so.6(GMT_grdcut+0x3b8)[0x7fb1d438e3d8]
/home/mkononets/mambaforge/envs/pygmt/bin/../lib/libgmt.so.6(GMT_Call_Module+0x586)[0x7fb1d4118d06]
gmt(main+0x5d8)[0x5643c97a3618]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7fb1d3e9fd90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7fb1d3e9fe40]
gmt(+0x32fd)[0x5643c97a42fd]
6

Hi, hi. That’s for reading.

7

Aha, I understand. So this works fine:

gmt grdcut @earth_day_30m -R-1.5/0/44.5/45.5 -Gdaytime.tif

But this does not:

gmt grdcut @earth_day_30m -R-1.5/0/44.5/45.5 -Gdaytime.grd

Considering what the data represents, that makes sense! I wish the error was more informative (it should specify that the output image is the issue, not the input), but not sure if that’s possible. It had me thinking my gdal installation was broken.

8

I’m guessing this (and/or the error message) should be an easy one to fix. Anyone wants to take the chance on it?

Edit: I can provide some assistance.

9

Do you mean to fix the source code? I would like to try.

10

Yes, the source code.

11

I am actually interested too, but my experience developing code in C is limited to put it mildly (a couple of private Arduino projects, mostly modifying other people’s code). Seeing source codes on github, I never really used git either (well once around 10 years ago). Was not sure this project (gmt) is the best (first of all for the project) occasion to start learning by doing. Is there a lot of skills required to start work with gmt source code?

12

I open an issue

13

Nice to have volunteers and don’t forget we have many more issues to tackle. I will make my comments in the issue opened by Esteban.

14

Ah, ah. Probably not.

Honestly, yes. But it also depends on why we try to do. Many things are not complicated, diving in the alghorithms and the IO is complex.

15

long wrong stuff was here

16

Hmm, my grep suggestion was to find the location of the message “Unsupported image format.”, which leads to gmt_gdalwrite.c#L126

		else {
			GMT_Report (GMT->parent, GMT_MSG_ERROR, "Unsupported image format. Supported formats are:\nBMP,GIF,JPG,PNG & TIF\n");
			GMT_Report (GMT->parent, GMT_MSG_ERROR, "Alternatively, append :<driver> for a valid GDAL driver\n");
			return GMT_NOTSET;
		}

I never did try to find crashes with grep. I only hunt crashes with the debugger.

17

Anyway, the fix for this one (I guess) is to catch it right at the start and don’t let it go without a non selected driver. First case error because extension was wrong. Second case quite likely slipped the invalid extension test (because it was no extension), which lead to the … boom.

18

but there should be no “boom”? should it instead be something saved somewhere in some strange way?
Anyway, I’ve just had some fun digging in the code.

19

Yes, there should be no “booms”. Booms are bugs. Imagine you were doing this from PyGMT. The boom would have killed your entire session.

That’s how it starts.