Gsconvert GMT 6.0.0 vs 5.4.5 png bits per pixel

Q&A
1

Hi,
Thank you for your work on this amazing software and for releasing and supporting it.
I’ve been using GMT 5.4.5 for some time to create maps which include red marker pixels in ps file and which is then converted it to a png version. I then use Image Magick on the png file in order to find the pixel location of the red marker pixels so I can further process different images which are png of the same dimensions. This is a way of finding a lat long location on another map image.
I tried GMT 6.0.0 and the scripts I wrote no longer work. I think I’ve tracked the issue down to psconvert using different settings and producing a 24 bit per pixel png file. The file is a larger size, Irfanview says its 24 bits per pixel, whereas from GMT 5.4.5 it was 4 bits per pixel. The resolution is the same.
I’ve used the -S option on the psconvert command and see what look like very different results, here with the paths anonymised and simplified:

gmt psconvert “C:\ANONPATH\KnownGoodOriginal.ps” -A -E96 -P -Tg -S

GMT 6.0.0 gives:
@“c:/programs/gmt6/bin/gswin64c.exe” -q -dNOPAUSE -dBATCH -dNOSAFER -dSCANCONVERTERTYPE=2 -dMaxBitmap=2147483647 -dUseFastColor=true -dGraphicsAlphaBits=2 -dTextAlphaBits=4 -sDEVICE=png16m -g690x747 -r96 -sOutputFile=“C:\ANONPATH\KnownGoodOriginal.png” “./psconvert_8800d.eps”

GMT 5.4.5 gives:
psconvert: @“C:\Program Files\gs\gs9.22\bin\gswin64c.exe” -q -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress -dDownsampleColorImages=false -dDownsampleGrayImages=false -dDownsampleMonoImages=false -dUseFlateCompression=true -dEmbedAllFonts=true -dSubsetFonts=true -dMonoImageFilter=/FlateEncode -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dSCANCONVERTERTYPE=2 -dMaxBitmap=2147483647 -dUseFastColor=true -sDEVICE=png16m -g690x747 -r96 -sOutputFile=“C:\KnownGoodOriginal.png” -f"./psconvert_12724d.eps"

Is gswin64c.exe a different implementation of gs, or effectively a link to it? How can the version of gs be determined?

I’ve looked at the documentation for psconvert, but nothing jumped out at me as being able to change this output png format in this way.

In Image Magick I produce a list of all the pixels in the png by colour, and none of these are of exact colour red (which appears as ‘red’ rather than decimals) when processing the GMT 6.0.0 png file, so the matching fails. Here is an example of the beginning of the file, showing some exactly white pixels:

ImageMagick pixel enumeration: 690,747,65535,srgb

0,0: (65535,65535,65535) #FFFFFF white
1,0: (65535,65535,65535) #FFFFFF white
2,0: (65535,65535,65535) #FFFFFF white

I’m looking to reproduce the original file format for the png file, with the smaller file size, then hopefully the scripts will start working again. It would be possible, but harder, to search for decimal colours close to red, but I’m also keen to keep the files small as I have a lot of images to process.

Any ideas?

Thank you.
A

2

The gs instruction run by psconvert has evolved along times, often to accommodate ghostscript changes. I don’t remember that it ever produced 4 bits images but seem to have looked into more detail into this.

GMT6 ships with a ghostscript built from source a little after 9.50 release and will proclaim to be 9.51 (but that’s not true). If the cause of your failures is the currently run ghostscript command, you can always convert the PS file manually (or script it) using the command that works for you. And, if necessary, the gs version that works for you.

You can also have a look at grdimage that let you create png images directly without passing trough ghostscript (but has its own limitations).

3

Hi Joaquim,
Thank you for the reply. I’ve had time to look at this a bit more now. I was mistaken about the bits per pixel being different, I’d looked at one of the indexed png files. The others are all 24bpp.

I’ve done various tests with different GS versions and the different command line options etc, and the key difference was that I need the GS option -dGraphicsAlphaBits=1 in order to maintain exactly ‘red’ pixels, not blend them with nearby ones. This is controlled by the gsconvert -Qg2 which is the default in GMT 6.x.x. So I was able to simply (after several hours work!) add -Qg1 to my gsconvert command in the scripts to change the default behaviour and everything is working again. I didn’t have to recode to issue a gs command directly, but can use gsconvert. An additional benefit in my case is that these files are ~60% of the size of those produced with -Qg2, probably because fewer colours are needed.

The difference isn’t with GS versions etc, or the previous (GMT5.4.5) use of dPDFSETTINGS=/prepress or -dAutoFilterColorImages=false or other options which differed which I also thought might make a difference.

Cheers,
A