#2421 closed defect (fixed)
SetColorTable() not supported for existing TIFF files
Reported by: | yanchen | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.6.1 |
Component: | GDAL_Raster | Version: | 1.5.2 |
Severity: | normal | Keywords: | gtiff colortable |
Cc: | pgao@… |
Description
We have many cases that colormap has to be changed (added or deleted) for existing files, but SetColorTable() not supported for existing TIFF files.
Change History (8)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | gtiff added |
Milestone: | 1.5.3 → 1.6.0 |
Owner: | changed from | to
Status: | new → assigned |
I can confirm that by the nature of the libtiff API it is not really practical to alter color tables on existing files. There may be some possibility to use the new TIFFRewriteField() function in libtiff 4 to update color tables in place.
I will investigate in the near future.
comment:3 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have implemented the ability to modify the color table of a TIFF file which is PHOTOMETRIC_PALETTE and already has a color table.
I have also added the ability to specify PHOTOMETRIC=PALETTE at create time to force an image to be paletted even if no color table is written.
However, you cannot just write a palette to a greyscale image after the file has been crystalized (after the first image write) and have it magically convert from greyscale to paletted.
The changes seem to high risk to back port into 1.5.x. They are only in trunk (r15671). I have also implemented brief testing of this functionality as part of the autotest (r15670).
comment:4 by , 15 years ago
Milestone: | 1.6.0 → 1.6.1 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
It has become clear it is also necessary to be able to delete palettes from GeoTIFF files. I have decided to implement this when SetColorTable() is called with a color table with zero entries (or NULL, but the C interface will not allow passing a null color table now and many SetColorTable() implementations would crash).
I have a preliminary implementation of TIFFUnsetField() in libtiff4, and code in geotiff.cpp trunk using this (r15972). A test in the test suite tiff_write.py (r15793).
I am waiting for some feedback on the approach on the tiff mailing list before migrating these changes back into 1.6.
comment:5 by , 15 years ago
Keywords: | colortable added |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
comment:6 by , 15 years ago
A bunch more patches in trunk to make it safe to pass NULL to SetColorTable() for all drivers including proper delete color table implementation for HFA driver (r15980, r15981, r15982, r15983).
comment:8 by , 15 years ago
Some additional fixes for RemoveAndDestroy() method in the HFA driver needed for this in trunk (r16662) and 1.6 branch (r16663).
This is what I found in gtif\geotiff.cpp
// /* SetColorTable() */ //
CPLErr GTiffRasterBand::SetColorTable( GDALColorTable * poCT )
{ /* -------------------------------------------------------------------- */ /* Check if this is even a candidate for applying a PCT. */ /* -------------------------------------------------------------------- */