Opened 15 years ago

Closed 14 years ago

Last modified 14 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 by gaopeng, 15 years ago

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 by warmerdam, 15 years ago

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 by gaopeng, 15 years ago

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 by warmerdam, 14 years ago

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 by warmerdam, 14 years ago

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 by warmerdam, 14 years ago

Resolution: fixed
Status: assignedclosed

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

comment:7 by warmerdam, 14 years ago

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.