Ticket #2842 (closed defect: fixed)

Opened 4 years ago

Last modified 2 years ago

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

Changed 4 years ago by warmerdam

  • keywords HFA added
  • status changed from new to assigned

Hi,

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

Changed 4 years ago by rprinceley

  • version changed from unspecified to 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 ).

Changed 4 years ago by 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.

Changed 4 years ago by warmerdam

  • status changed from assigned to closed
  • version changed from svn-trunk to 1.6.0
  • resolution set to fixed
  • milestone set to 1.6.1

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.

Changed 2 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.