Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#2855 closed defect (fixed)

RRD overviews do not preserve the NoData pixels in the base raster dataset

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.6.0
Severity: normal Keywords: overview, HFA


I have a dataset (a grid) with NoData? pixels. I build overviews in AUX (RRD) format. The AUX overviews show value 0 instead of NoData?.

The .ovr works fine for the same base dataset.

Change History (7)

comment:1 Changed 12 years ago by gaopeng

Milestone: 1.6.1
Version: unspecified1.6.0

Addition information:

BuildOverviews? generated two large file, an .ige (2,581,940K) and a .rrd file (865,082K). If I force it to generate ovr type of overviews (removing the .aux), the generated .ovr file is only 101,884K bytes.

comment:2 Changed 12 years ago by warmerdam

Keywords: overview added
Owner: changed from Frank Warmerdam to warmerdam


Are you suggesting that the overview raster bands should return a properly set nodata value when GetNoDataValue?() is called on the overview band object?

In general GDAL has taken the approach that applications should not depend on metadata such as color tables, nodata, RATs, and so forth existing on overviews, though in some cases they might. So, my preliminary thought is that the application should be careful to use the full resolution band for all metadata.

comment:3 Changed 12 years ago by gaopeng

In my test case, GetMaskFlags?() returns GMF ALL_VALID on the overview band object, and the actually pixel value in the overviews for the NoData? area is not the NoData? value returned from the base raster band. It's will be nice the flag indicates there are NoData? pixels in the overviews. The pixel value for NoData? area in the overview band should match the NoData? value.

comment:4 Changed 11 years ago by warmerdam

Status: newassigned

I have confirmed that nodata/mask information is propagated to .ovr style overviews but not to imagine format overviews (ie. rrd or built-in to .img overviews). I will correct this.

comment:5 Changed 11 years ago by warmerdam

Keywords: HFA added
Milestone: 1.6.4


I believe this has been corrected now in trunk (r18625), 1.7 (r18626) and 1.6-esri (r18627).

The solution was to ensure nodata values were propagated into the .img during CreateCopy?() (not just to the aux.xml file) and then to ensure they were carried into the overview in hfaopen.cpp:CreateOverview().

comment:6 Changed 11 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

I have extended the trunk autotest suite with verification of this new feature (r18628).

comment:7 Changed 11 years ago by warmerdam

part of the change was missed previously and has been committed in trunk (r18630), 1.7 (r18631) and 1.6-esri (r18632).

Note: See TracTickets for help on using tickets.