Opened 15 years ago

Closed 15 years ago

#2734 closed defect (invalid)

NODATA not correct in expand RGB

Reported by: klokan Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

I think NODATA is not correct when running:

gdal_translate -a_nodata 255 -expand rgb palette.tif rgb.tif

The result looks correct:

$ gdalinfo rgb.tif
...
Band 1 Block=400x6 Type=Byte, ColorInterp=Red
  NoData Value=255
Band 2 Block=400x6 Type=Byte, ColorInterp=Green
  NoData Value=255
Band 3 Block=400x6 Type=Byte, ColorInterp=Blue
  NoData Value=255

I expect to have only 255, 255, 255 (white) as NODATA set.

When I look at the rgb.tif in the OpenEV in the bottom left corner of the result it shows the correct 255r 255g 255b [NODATA] but top right corner shows also nodata color: 255r 180g 250b [NODATA]. Why NODATA is set to two different colors, I expected only white to be NODATA.

I am using this trought VRT driver, where the same result appears (I can attach the VRT file).

Attachments (1)

palette.tif (121.6 KB ) - added by klokan 15 years ago.

Download all attachments as: .zip

Change History (2)

by klokan, 15 years ago

Attachment: palette.tif added

comment:1 by Even Rouault, 15 years ago

Resolution: invalid
Status: newclosed

Petr,

This is related to OpenEV behaviour, and I think we can consider it as a feature, not a bug.

As I tried to explain a bit in #2724, the notion of NODATA is per-band. And that's how OpenEV interprates it apparently. You'd be more interested by the NODATA_VALUES metadata (on the dataset level) described in the GDAL Data model :

NODATA_VALUES: The value is a list of space separated pixel values matching the 
number of bands in the dataset that can be collectively used to identify pixels
that are nodata in the dataset. With this style of nodata a pixel is considered
nodata in all bands if and only if all bands match the corresponding value in the
NODATA_VALUES tuple. This metadata is not widely honoured by GDAL drivers, 
algorithms or utilities at this time.

I can confirm that it is not widely honoured in GDAL. To the extent of my knowledge, it is only understood by the PNG driver and I've added it support for it as an implicit band mask RFC15 and in overview building during 1.6 development. This is not directly honoured in warping code, but as Frank pointed out to us, there's the UNIFIED_SRC_NODATA warping options that achieves the same result.

And it's likely that OpenEV doesn't handle NODATA_VALUES at all.

Side node: you should also be aware that you could run it problems with NODATA and GTiff as the TIFFTAG_GDAL_NODATA tag is a single value shared by all bands. That is to say if you try to set 1 as the nodata value for band 1, 2 for band 2 and 3 for band 3. You'll get "1 1 1" (or "3 3 3" I don't remember). See ticket #2083 where there was some preliminary discussions about supporting a different value for each band.

Some examples with NODATA_VALUES:

gdal_translate -of VRT -expand rgb palette.tif rgb.vrt -mo NODATA_VALUES="255 255 255"
$ python
>>> import gdal
>>> ds = gdal.Open('rgb.vrt')
>>> print ds.GetRasterBand(1).GetMaskFlags() == gdal.GMF_NODATA | gdal.GMF_PER_DATASET
True

Note: See TracTickets for help on using tickets.