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)
Change History (10)
by , 16 years ago
Attachment: | example_dem.tiff added |
---|
comment:1 by , 16 years ago
Keywords: | overview nodata added |
---|---|
Resolution: | → invalid |
Status: | new → closed |
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 , 16 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 , 16 years ago
Cc: | added |
---|---|
Priority: | normal → low |
Type: | defect → enhancement |
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 , 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 , 16 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:6 by , 16 years ago
Milestone: | → 1.6.0 |
---|---|
Status: | new → assigned |
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 , 15 years ago
Cc: | added |
---|
comment:8 by , 15 years ago
Milestone: | 1.6.1 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Example GeoTIFF with one overview.