#2842 closed defect (fixed)
Unable to delete colormap from HFA
Reported by: | rprinceley | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.6.1 |
Component: | GDAL_Raster | Version: | 1.6.0 |
Severity: | normal | Keywords: | HFA |
Cc: |
Description
Deleting color table using SetColorTable(0) does not work on HFARasterBand.
... band = dataset->GetRasterBand( 1 ); if ( band ) { band->SetColorTable( 0 ); } ::GDALClose( dataset );
Change History (5)
comment:1 by , 15 years ago
Keywords: | HFA added |
---|---|
Status: | new → assigned |
comment:2 by , 15 years ago
Version: | unspecified → svn-trunk |
---|
This issue was discovered in a 1.6.0 + patches build which is close to svn-trunk ( also tested on SVN snapshot from 2009-02-18 ).
comment:3 by , 15 years ago
I can reproduce it with latest trunk too on following test image :
gdal_translate -of HFA ../autotest/gcore/data/8bit_pal.bmp test.img
and then :
import gdal ds = gdal.Open('test.img', gdal.GA_Update) ds.GetRasterBand(1).SetColorTable(None) ds = None
The color table is still there afterwards.
But hfa_delete_colortable() in autotest/gdrivers/hfa.py passes with success.
comment:4 by , 15 years ago
Milestone: | → 1.6.1 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Version: | svn-trunk → 1.6.0 |
I have corrected this bug in trunk (r16420) and 1.6 branch (r16421). It turns out that hfa_delete_colortable() worked because there was a "next" column after the red/green/blue columns. The actual bug was that the nNextPos value was not getting reset to zero when poNext was NULL at the point of flushing the Bin_Function node.
comment:5 by , 13 years ago
It turns out that r16420 was the wrong fix and actually causes entries to be improperly truncated in some situations. The problem is that if nChildPos is non-zero but poChild is NULL that can just mean the application hasn't needed to access the child node(s).
The correct fix was incorporated in r16662, but the above changes needs to be removed as it has been in trunk (r21428) and 1.7 (r21429). Possibly this fix should be backported to 1.6 and 1.6-esri? If so, ensure that r16662 was applied there.
Hi,
Could you indicate the version of GDAL you are using? Efforts to support this ability are quite new.