#2213 closed defect (fixed)
GTiff : inconsistant [0-255] <--> [0-65535] colormap values translation
Reported by: | Even Rouault | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.2.4 |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | gtiff colormap |
Cc: |
Description
The conversion between the GDAL 8 bit color map space, ranging from 0 to 255, to the TIFF 16 bit color map space, ranging from 0 to 65535, is not done currently in a very consistent way in the code. Most places multiply or divide by 256, and one place multiplies by 257 (GTiffCreateCopy for a GDT_Byte band).
I think that the right factor is 257, in order to use the full dynamics of the 0-65535 range. I would propose too to use the following formula, (tiff_color_value + 127) / 257, that rounds to the nearest value.
However, there's maybe a good reason to do as it's actually done ? I could imagine it's done because some other software use 256 as the multiplication/division factor and we want to be consistent with them ? But if it is the case, then we should replace the 257 factor by 256.
Attachments (1)
Change History (7)
by , 16 years ago
Attachment: | gdal_svn_trunk_gtiff_colormap_translation.patch added |
---|
comment:1 by , 9 years ago
comment:2 by , 8 years ago
It may be that patch has been at least partly applied into https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/gtiff/geotiff.cpp but geotiff.cpp has grown quite a lot since 2008. Patch is not usable as is any more but Even can probably tell if the idea is still alive.
comment:3 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Let's close that. This is probably more a theoretical concern that somethings that surfaces in real world cases...
comment:5 by , 6 years ago
Milestone: | → 2.2.4 |
---|
Any news about this one?