Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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

share|improve this question

2 Answers 2

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.

share|improve this answer
    
Thanks, Mike. I ended up specifying '-depth 8' in 'convert' and that resolved the issues with GDAL. I tried your suggestion (including png8: before the output file name), but for some reason gdal_translate still interprets the data at UInt16. Good to know about the Q8 release - might avoid this disconnect. As to the reason GDAL doesn't interpret the data correctly (if that is indeed the case), it's still mysterious but at least we have a workaround. Thanks for the inputs! –  Jeffo Jan 6 '12 at 23:24

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.

share|improve this answer
    
Indeed -srcwin with gdal_translate would work, but I wanted to be able to remove extra white space around the plot so I can get the pixel size for the known area of interest before using the corners of the image as ground control points (gcps) in gdal_translate. And 'convert - trim' does that nicely. Thanks for the suggestions, though. –  Jeffo Jan 6 '12 at 23:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.