Opened 16 years ago

Closed 15 years ago

#2149 closed enhancement (fixed)

gdaladdo overviews have strange colored artifact

Reported by: sroberts Owned by: Even Rouault
Priority: low Milestone:
Component: Utilities Version: 1.5.0
Severity: major Keywords: overview nodata
Cc: Even Rouault, antonio

Description

Starting with gdal version 1.5.0, gdaladdo generated overviews using "-r average" now have colored artifacts. The latest svn-trunk(version 1.6.0) as well as FWTools-linux-2.0.4.tar.gz exhibit the same problem. I do not have this problem with gdal 1.4.2. I've tried this on both Red Hat Enterprise Linux WS release 4 and Mandrakelinux 10.1. The attached GeoTIFF is an example of a very small section of DEM data of the Mississippi river delta. I created an overview via the command:

gdaladdo -r average example_dem.tiff 4

The full resolution image only has greens and whites but in the overview the boundaries between the greens and whites is filled in with bright blue. Also attached is a png dump of the overview.

-Steve

Attachments (2)

example_dem.tiff (191.1 KB ) - added by sroberts 16 years ago.
Example GeoTIFF with one overview.
example_dem_overview.png (23.5 KB ) - added by sroberts 16 years ago.
PNG dump of the overview

Download all attachments as: .zip

Change History (10)

by sroberts, 16 years ago

Attachment: example_dem.tiff added

Example GeoTIFF with one overview.

by sroberts, 16 years ago

Attachment: example_dem_overview.png added

PNG dump of the overview

comment:1 by warmerdam, 16 years ago

Keywords: overview nodata added
Resolution: invalid
Status: newclosed

Steve,

I have reviewed the situation and it appears you are suffering adverse effects from the recent incorporation of "nodata awareness" into the overview builder. The dataset has a nodata value of zero set for each of the bands. In the GDAL data model this sort of nodata is assumed to apply independently for each band. What this means is that band 3 (which has value 0 in areas that are meant to be valid data) is treated as having nodata values anywhere the pixel is zero. This causes the non-zero values (from the streams/valleys) to be "carried out" without mixing while in the other bands the stream (whitish) and non-stream (green) values are mixed in the border region. This results in bluish borders around the stream areas.

I was able to resolve this by removing the nodata metadata from the dataset, though this may not be desirable for your purposes. An alternate approach might be to preprocess the image to ensure that any pixel with red, green or blue set to zero but not all three set to zero, would have the zero values reset to 1.

I see this situation as technically correct operation by the overview builder, but the nature of the nodata model for GDAL is interfering with what you intended.

Note, the better nodata processing is now preventing inappropriate mixing on 0,0,0 nodata pixels with valid data around the edges of the valid data. So the nodata handling is mostly a good thing.

Please reopen if you think I'm wrong or if some improvement/change is required.

comment:2 by sroberts, 16 years ago

Resolution: invalid
Status: closedreopened

Thanks for the explanation. This is an RGB image (which I assume is a format used by many people?) and as such the three RGB values form a triplet that uniquely define a single color that is assigned to a pixel and IMHO the three values can not be treated separately at least for an RGB image. Treating these separately seems very counter intuitive to me. As an example, to define a transparent color using Mapserver requires you to list the RGB triplet. Due to the close ties between Mapserver and GDAL I had assumed they would use the same model. Also, removing the nodata metadata is not an option for me. The data I work with is full of null values and without the "nodata awareness" the overviews become very messy. So I was very pleased to see that the "nodata awareness" finally got fixed. Could there be a way to satisfy both camps? Maybe add an "-r average_rgb" option or something equivalent?

comment:3 by warmerdam, 16 years ago

Cc: Even Rouault added
Priority: normallow
Type: defectenhancement

I'm turning this into a feature enhancement request for multi-band tuple nodata values in the overview building. Multi-band nodata values can be specified as "NODATA_VALUES: n n n" on the dataset though relatively few GDAL tools currently honour this.

comment:4 by warmerdam, 16 years ago

I would add that this will likely be pretty hard to implement because overview building is done band by band so access to other bands for nodata tuple checking will be hard. It would also be nice if the masking code knew how to honour NODATA_VALUES tuples in which case it might be possible for the overview building to just request nodata masks for the band.

comment:5 by Even Rouault, 16 years ago

Owner: changed from warmerdam to Even Rouault
Status: reopenednew

comment:6 by Even Rouault, 16 years ago

Milestone: 1.6.0
Status: newassigned

I've implemented the 2 suggestions of Frank :

  • first step : Add a new class GDALNoDataValuesMaskBand to create a per-dataset nodata mask band (GMF_PER_DATASET | GMF_NODATA) when the metadata item NODATA_VALUES is found on the dataset (r15038)
  • second step : Use nodata masks when generating overviews (r15039)

Test added in r15040 and r15041.

Steve, you can test it by doing :

gdal_translate -mo "NODATA_VALUES=0 0 0" example_dem.tfif example_dem_nodatavalues.tiff
gdaladdo -r average example_dem_nodatavalues.tiff 4

This new capability should be probably documented somewhere.

comment:7 by antonio, 15 years ago

Cc: antonio added

comment:8 by Even Rouault, 15 years ago

Milestone: 1.6.1
Resolution: fixed
Status: assignedclosed

Docs added in r16558 / r16559.

Note: See TracTickets for help on using tickets.