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
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
