ImageMagick's convert program changes PNG file format so that color/alpha info doesn't survive GDAL

Question

It appears that ImageMagick's convert program changes something in my PNG file that causes GDAL processing to mess up the color and/or transparency bands.

My original PNG file gets processed successfully by gdal_translate, gdalwarp and gdal2tiles.py to create web tiles. Call it original.png.

Here is the workflow that generates correct tiles:

original.png -> 'gdal_translate' -> tmp.gtif -> 'gdalwarp' -> final.gtif -> 'gdal2tiles.py' -> tiles

Here is the problematic workflow:

original.png -> 'convert -trim' -> trimmed.png -> 'gdal_translate' -> tmp.gtif -> 'gdalwarp' -> final.gtif -> 'gdal2tiles.py' -> tiles

Hence 'convert' changes something that GDAL can't handle (note that if I start with a PDF file format, original.pdf, and use 'convert' to change it to PNG, I have the same problem - so it's not just the trim (cropping) functionality of convert). Using gdalinfo, I see that 'convert' has changed the pixel data type from Byte to UInt16, as you see below.

Here's an excerpt from the gdalinfo printout for the original file:

> gdalinfo original.png 
Driver: PNG/Portable Network Graphics
Files: original.png
Size is 1000, 800
Band 1 Block=1000x1 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=1000x1 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=1000x1 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=1000x1 Type=Byte, ColorInterp=Alpha

Note that Type=Byte.

Here's the gdalinfo for the trimmed (problematic) file:

> gdalinfo trimmed.png 
Driver: PNG/Portable Network Graphics
Files: trimmed.png
Size is 746, 746
Band 1 Block=746x1 Type=UInt16, ColorInterp=Red
Band 2 Block=746x1 Type=UInt16, ColorInterp=Green
Band 3 Block=746x1 Type=UInt16, ColorInterp=Blue
Band 4 Block=746x1 Type=UInt16, ColorInterp=Alpha

Note the data type has changed from Byte to UInt16, and the Mask Flags are not longer there.

Then after running this file through 'gdal_translate' to get tmp.gtif, here is the gdalinfo:

> gdalinfo tmp.gtif 
Driver: GTiff/GeoTIFF
Files: tmp.gtif
       tmp.gtif.msk
       tmp.gtif.aux.xml
Size is 746, 746
... (coordinate info omitted ) ...
Band 1 Block=746x1 Type=UInt16, ColorInterp=Red
  Mask Flags: PER_DATASET 
Band 2 Block=746x1 Type=UInt16, ColorInterp=Green
  Mask Flags: PER_DATASET 
Band 3 Block=746x1 Type=UInt16, ColorInterp=Blue
  Mask Flags: PER_DATASET 
Band 4 Block=746x1 Type=UInt16, ColorInterp=Alpha
  Mask Flags: PER_DATASET

(PER_DATASET flag is back, and ColorInterp values are still rgba)

Finally, after running this output (tmp.gtif) through 'gdalwarp', the ColorInterp values don't survive (nor does the Mask Flag):

>gdalinfo final.gtif
Driver: GTiff/GeoTIFF
Files: final.gtif
Size is 758, 749
... (coordinate info omitted ) ...
Band 1 Block=758x1 Type=UInt16, ColorInterp=Gray
Band 2 Block=758x1 Type=UInt16, ColorInterp=Undefined
Band 3 Block=758x1 Type=UInt16, ColorInterp=Undefined
Band 4 Block=758x1 Type=UInt16, ColorInterp=Undefined

If I view this file, it's grayscale, but then the tiles generated by gdal2tiles.py from this file are a jumbled mix of colors.

Anyone have experience with ImageMagick's convert program and getting it to play nice with GDAL? Thanks ahead.

-Jeff

Answer 1

Just a wild guess for the 16 bit pixels issue: you can try forcing 8-bit or byte pixels in convert by using png8:trimmed.png as the output filename. If you are using precompiled Windows binaries, you can download the "Q8" releases, which uses byte computations only.

Answer 2

Further to Mike's answer, gdal_translate has the -ot switch to force a given datatype (-ot Byte in your case), and the -mask switch to select a band as a mask, e.g.: -mask 4

My ImageMagik-fu isn't strong, but an alternative is if you can get IM to just output the rectangle it would have used to trim the image, you could use the -srcwin option of gdal_translate.