[gdal-dev] Troubleshooting palette management. Potential bug in palette for overviews?

[Even Rouault]

Daniele,

This is indeed an inconsistency I spotted a long time ago :
https://trac.osgeo.org/gdal/ticket/2213

Nobody was apparently sufficiently annoyed by this to fix it. Actually I see I proposed a patch. 
Was probably waiting for feedback. I'm not sure if there's a standardized way of converting 
between the [0,255] and [0,65535] ranges.

Even

> Hi List,
> I'm investigating on a issue I have with a paletted image with overviews,
> using java ImageIO tiff reader (wait... I know on this list we discuss
> about GDAL topics :) ).
> I'm trying to better understand palette interpretation and palette storing
> on tags and how they are handled by GDAL.
> 
> From TIFF specifications, colormap entries are stored as short values.
> I have a sample file with this color tab (as reported by gdalinfo).
> 
> Color Table (RGB with 256 entries)
>   0: *164*,164,164,255
>   1: *255*,255,255,255
>   2: 0,0,0,255
>   3: 0,0,0,255
> .... repeat 0,0,0,255 to the end.
> 
> Using an Hex editor or AsTiffTagViewer, I can see the byte values of the
> colormap as stored on the file.
> For the first 4 mappings of the colortable the Red components are:
> *A4 A4* *FF FF* 00 00 00 00
> (8 bytes = 4 shorts)
> 
> As far as I have understood, this is related to that part of the
> specification (quoting it, section 5):
> 
> 
> *In a TIFF ColorMap, all the Red values come first, followed by the Green
> values, then the Blue values. In the ColorMap, black is represented by
> 0,0,0 and white is represented by 65535, 65535, 65535*
> 
> So the second entry of the map, being white (255, 255, 255) has its red
> value stored as 65535 = *FF FF *whilst the first color (164,164,164) has
> its red value stored as 42148 = *A4 A4*
> 
> I see this behavior is confirmed by the way the geotiff.cpp create the
> colortable:
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/gtiff/geotiff.cpp#L5043
> 
> panTRed[iColor] = static_cast<unsigned short>(257 * sRGB.c1);
> panTGreen[iColor] = static_cast<unsigned short>(257 * sRGB.c2);
> panTBlue[iColor] = static_cast<unsigned short>(257 * sRGB.c3)
> 
> Applying a color*257 multiplication allows to have its 8 bits color
> representation stored into a short where intensity goes from 0 to 65535.
> 
> The issue I have is that when using gdaladdo, the overviews are generated
> with a different color table.
> So that the first 8 bytes of the red component stored in the colormap,as
> reported by AsTiffTagViewer are:
> *A4* 00 *FF* 00 00 00 00 00
> 
> When converting it back to a 0-255 color component with the formula
> R*255/65535 it become *163* instead of 164.
> 
> I see in the GDAL code that both the IBuildOverviews and
> CreateOverviewsFromSrcOverviews call the CreateTIFFColorTable function
> which multiplies the colorMapEntry by 256 instead of 257.
> 
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/gtiff/geotiff.cpp#L9137
> 
> This may explain the *A4* 00 *FF* 00 entries in the overview with respect
> to the *A4 A4 FF FF *entries in the main level.
> 
> Do you have any feedback on this?
> Please, let me know what do you think about it.
> 
> Best Regards,
> Daniele


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161124/b1d44328/attachment-0001.html>