Opened 8 years ago

Closed 7 years ago

#5111 closed defect (invalid)

gdalwarp doesn't copy TIF color interpretation for alpha band

Reported by: cdestigter Owned by: warmerdam
Priority: normal Milestone: 1.10.1
Component: GDAL_Raster Version: 1.10.0
Severity: normal Keywords:
Cc: Robert Coup, cdestigter

Description

In gdal 1.9.2, warping from an RGBA tif into a new file with the following command-line:

gdalwarp -te 0.0 -20037508.3428 20037508.3428 0.0 -of GTiff -ts 4096 4096 -co TILED=YES -co COMPRESS=DEFLATE -r bilinear in.tif out-1.9.tif

# then upgrade gdal to 1.10, then

gdalwarp -te 0.0 -20037508.3428 20037508.3428 0.0 -of GTiff -ts 4096 4096 -co TILED=YES -co COMPRESS=DEFLATE -r bilinear in.tif out-1.10.tif

Here's the diff of the gdalinfo output for the output files from 1.9.2 and 1.10: https://gist.github.com/craigds/872515177f92c04024e2

In summary the color interpretation is no longer copied to the target in 1.10.

Luckily 1.10 did add a workaround; if I add '-setci' to the command-line it fixes the problem.

In light of the existence of the new -setci flag, it's possible this is intended behaviour, but it's backwards incompatible and I couldn't find any docs on this, so I consider it a regression.

Change History (4)

comment:1 Changed 8 years ago by Even Rouault

I cannot reproduce this with rgba.tif from the GDAL autotest suite (http://svn.osgeo.org/gdal/trunk/autotest/gcore/data/rgba.tif)

gdalwarp ../autotest/gcore/data/rgba.tif out.tif -overwrite -ts 100 100 -r bilinear -co TILED=YES -co COMPRESS=DEFLATE

generates out.tif with ColorInterp?=Alpha on band 4.

comment:2 Changed 8 years ago by cdestigter

Thanks for the quick response, we'll do some more testing and get back to you.

comment:3 Changed 8 years ago by Even Rouault

Any news on this ?

comment:4 Changed 7 years ago by Jukka Rahkonen

Resolution: invalid
Status: newclosed

I consider that lack of feedback means that system works.

Note: See TracTickets for help on using tickets.