Conversion of paletted PNG to ECW does not work

[jcrepetto]

When I convert a paletted PNG file to ECW, the resulting image is almost black, as if the compression was made using the indexes instead of the real colours.

Example:

gdal_translate -of ECW -co "TARGET=94%" -co "DATUM=NTF"  -co "PROJ=LM1FRA2D" -a_ullr 970000 1860000 980000 1850000 test.png test.ecw

There is no problem with a true colour PNG image.

Expected result

- Either GDAL should do the 8-bit to 24-bit conversion as part of the format translation (for convenience and to save on temporary disk space)
- Or at least produce an error message that paletted files are not supported, and stop. GDAL should not produce a wrong result, it would save a lot of time to users.

Note : This topic has been discussed on the GDAL-dev ML, on 19 Dec 2006 and 3 Jul 2007.

[warmerdam]

I concur, the ECWCreateCopy() function should error out if the source image is paletted and bStrict is set to TRUE. If bStrict is FALSE and the source image has a palette the function should issue a warning and proceed as it does now.

Mateusz, could you take care of this as time permits?

This pattern should be applied in a variety of other drivers too. It might make sense to bundle up the logic in a support function. We also really ought to have a way of declaring in the driver metadata whether the driver supports writing paletted images, but I think we will not try and address that at this time.

[rouault]

This is another duplicate of #1692 and #1796 (JPEG driver is affected too)

I think that expected result for most users would be proposal number 1 : 8bit --> 24bit implicit conversion. I don't really see why/when it would not be a good idea, from a user point of view, to do the implicit conversion when we have 1 source band and that its color interpretation is palette index or greylevel. For example, convert (from ImageMagick? tool suite) automatically converts 8bit GIF to 24bit JPG.

Now, from a developer point of view, it needs some work of course ;-) and there's still the workaround with an intermediate pct2rgb.

[warmerdam]

Even,

If we are going to have drivers CreateCopy?() functions do palette to RGB conversion on the fly, I think that should be proposed as an RFC for discussion and vote. For now, it is not the expected (or to my mind preferred) behavior of GDAL drivers.

[rouault]

Patch attached that checks for the presence color table on band 1 and warns/fails for ECW, MrSID, JPG and JPEG2000. Maybe some other drivers are missing. I didn't really see the added value of a support function for that, especially if we decide one day to do palette expansion on the fly. (Coudl't test if it compiles fine for MrSID and ECW drivers)

[warmerdam]

Even,

The patch looks good to me. Could you please attach it in trunk?

I don't see the need for this to go into 1.5.1.

[rouault]

Patch commited in trunk in r13715

[rouault]

In r14806, I've commited the final fix for this issue by providing a proxy dataset that does color table expansion. It also adds a -expand option to gdal_translate to take benefit of it.

[klokan]

I love this functionality and also the related palette expansion in VRT... Thanks a lot for it.

But I have found a bug. PNG Standard allows palette records with variable transparency. Such PNG is not expanded to RGBA correctly in GDAL (gdal_translate -expand RGBA), as the partly opaque colors does not correctly affect the alpha channel. It would be great to have this patched for 1.6, as GDAL2Tiles is partly dependent on this functionality.

The example PNG file which produce wrong results during rgba expansion is attached. If you run gdalinfo on it you will see the color table records with variable alpha.

[klokan]

PNG file with palette containing colors with variable transparency

[klokan]

I apologize. After closer testing and discussion with EvenR on IRC it seem GDAL implementation do everything correctly. The viewers I was using for displaying the results were not correctly interpreting alpha in the results. OpenEV shows everything correctly. I am sorry for the buzz.