[Gdal-dev] RE: Strange NoData value from a MrSID image (Peng Gao)

[Frank Warmerdam]

On 7/6/05, Michael P. Gerlek <mpg at lizardtech.com> wrote:
> > One solution could be not using native MrSID NoData color as
> > GDAL band specific NoData value (because it's not), and
> > adding a new call at Dataset level to get NoData color for
> > the entire dataset for apps that want to make use of the NoData color?
> >
> > What do you think?
> 
> That certainly would be okay - but this is really a question at the
> GDAL / MrSID driver level, though.  Frank?

Peng / Michael, 

Well, Peng and discussed this a bit already, and I suggest we take
it to the list to see if there are other opinions.  I am not in any big rush
to add a "dataset level" nodata method, so the short term "fix" would
be to ignore nodata values for mrsid alltogether - at least for multi-band
products.  Presumably the same rule would be applied to other formats
with similar issues as they are noticed. 

So, do other list members feel it would be better to ignore MrSID nodata
values because they don't really mean what GDAL means by nodata? 

For those who might have lost track of the distinction, in MrSID format
the pixel is considered "nodata" if the nodata values for all bands match.
In GDAL each band is treated distinctly, so one band could have a pixel
be nodata if it matches the nodata value for that band, while the same pixel
in other bands is not nodata. 

The GDAL approach really comes from thinking of raster files as a
stack of data layers.  For instance, one band might be elevation and
another some value computed by a model.  In this sort of situation bands
are quite independent (other than geospatial co-incidence).  But when 
looking at an RGB photo, you often want to consider the bands as a unit.

PS. If I did stop returning the band level nodata values for MrSID, I 
could still offer them as dataset level metadata with a standard name,
so apps could still look for it.  The benefit of handling as metadata instead
of having a custom API entry point is that the change is much easier and
more backward compatible.  The downside is that as images are copied
around and processed the metadata may (or may not) be carried along with
it and might well become inaccurate. 

For instance, if you do "gdal_translate -b 3 -b 2 -b 1 in.tif out.tif" then
gdal_translate would make no effort to re-map the band ordering in some
dataset level metadata related to nodata. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent