NaN color by grdimage with Arctic Polar pojection

Hi, all
I use the GMT to plot the Sentinel-2 optical image data. The region is over the Arctic, so I choose some map projection suitable for there. -Q in grdimage could plot the NaN value as transparent. But in this projection (-JB), the transparent is not perfect.
gmt grdimage sub_low_byte.tif+b0,1,2, -Rsub_low_byte.tif  -J$J  -K -P -Q>$ps
gmt pscoast -J -R -Lx1c/0.5c+c114/22+w5k -N1 -Bxa30 -Bya -BWNes --FONT_TITLE=10p  -I1 -O >> $ps
gmt psconvert $ps -A -P -Tg


Map look as:

So, I guess there maybe some small problems for -Q in grdimage. Specially, when use such map projections.

Hi @yangleir, can you please check whether the result is the same when you put a space in between -Q and the redirect? Currently it looks like there is no space, which could cause problems.

No, the -Q>$ps construct poses no problem but something in recent grdimage revamp may be causing a problem. Using -Q is crashing for me.

Crashes for me too so we will figure this out - but we also need to wrap up a proposal so it may take a few days.

What does -Q mean if input is a r,g,b image? Nothing I think and should not apply, no?

Perhaps he means black (0,0,0) should be transparent? But that is not what -Q is set up to do. (0,0,0) is a color, not a NaN.

I use the GMT6.1.1. Not the latest version. Maybe that is why -Q crash for you.
Also, the tiff data maybe in chaos. The black is 0,0,0 and not NaN. I will check it.

After fixing the crash with -Q I just made a plot using a linear projection so that there is no reprojection: This will check if the black pixels are turned to transparent. It mostly work but there are patches in the image that has pixels set to (1,1,1) instead - these show up as black below. So nothing wrong with GMT it seems:

FYI, I opened the tif in PhotoShop to verify that those patches are 1,1,1.

Hi, @pwessel, Many thanks!
Yes, I try the -JM projection, too. The black pixels are also there. So, it is the data problem. Not the GMT.

Now the map is nice.
I use gdal to change the original tiff to Byte type.

gdal_translate -ot Byte -q -scale 0 1 0 255 sub_seaice.tif sub_low_byte.tif

The black pixels reason is that -scale 0 1 0 255 should be used instead of -scale 0 1 1 255.

There are still strange things in this case. See

gmt  grdimage  -R39.27833884/120.843316067767/77.3124277327767/88.19456263 -JD80.0608274538835/82.75349518138835/79.12611688231391/90.0082517795372/12c -Baf -BWSen -Q sub_low_byte.tif -P >

but when converted

gmt psconvert -Tg -A

the same plot with black areas like first plot shows up (???)

I am guessing that gmt_img_project does not necessarily treat the 0,0,0 pixels as NaNs and hence there must be some averaging of blue and black pixels.

I just try your code. It works no problem on GMT6.1.1. ( The small black jagged pixels may also due to the data resolution or something else. )
The data has been updated using gdal_translate :
Are you using the new data?

See the png by psconvert:

I’m using your original data. The one with (0,0,0) and (1,1,1) on no-data areas. And when I convert the PS I get

Please try the updated tiff file. I think it will be ok.
I think the key problem was basically raised because of the wrong usage of the scaling in gdal_translate.

yes, those black areas have rgb = 1,1,1 so of course psconvert will plot them as near-black.

You are missing my point. There are no blacks in the PS image. They show up only after conversion.

If you are using the original image that has a mix of 0,0,0 and 1,1,1 apart from the blue, then I am not sure how you get a white background PS. Surely those 1,1,1 pixels will remain and give almost black. There is nothing in grdimage that replaces 1,1,1 with NaN but there is for 0,0,0. So not sure what you are showing,

Didn’t I start with There are still strange things in this case.?

I am showing what I said. A screen-capture of the PS obtained with

gmt grdimage -R39.27833884/120.843316067767/77.3124277327767/88.19456263 -JD80.0608274538835/82.75349518138835/79.12611688231391/90.0082517795372/12c -Baf -BWSen -Q sub_low_byte.tif -P >

and where the sub_low_byte.tif is the file with the (0,0,0) and (1,1,1)