Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#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 Changed 13 years ago by warmerdam

Keywords: HFA added
Status: newassigned

Hi,

Could you indicate the version of GDAL you are using? Efforts to support this ability are quite new.

comment:2 Changed 13 years ago by rprinceley

Version: unspecifiedsvn-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 Changed 13 years ago by Even Rouault

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 Changed 13 years ago by warmerdam

Milestone: 1.6.1
Resolution: fixed
Status: assignedclosed
Version: svn-trunk1.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 Changed 11 years ago by warmerdam

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.

Note: See TracTickets for help on using tickets.