[fdo-internals] FDO RFC 1 - Support PropertyFdoIRaster::BitsUsedPerPixel

[Greg Boone]

Hi Frank,

The change request came from Ikonos. The following information was
extracted from an email exchange I had with them...

"Ikonos has images that are in 16 bit, unsigned integer format. In
reality, only 11 bits out of this 16 are used. When their application
renders it, if this information is not available, it will render it as
16 bit, which results in a totally black image, using the default color
map. Ikonos fully depends on the data model to completely describe the
properties of the image."

"Currently, Ikonos works around this issue by examining all pixels and
manually determining the used bits field by the number of bits actually
used, which needless to say is inefficient. Their example data set does
have this property set (number of data bits) but this information is not
exposed through FDO."

"The used bits are useful in the case of stylization if the code takes
advantage of it. This is true not only for 16 bit images with 11 bits
used like the Ikonos, but other formats as well. Both TIFF and PNG can
encode grayscales with less than 8 bits (2 and 4 bit). Some raster
engines will promote these to 8 bit automatically, but it will report
the lower bits used count so that applications can make use of it during
modification and UI presentation (like Histograms). "

[GB] See inline for an attempt to answer your questions...


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Thursday, March 15, 2007 1:30 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 1 - Support
PropertyFdoIRaster::BitsUsedPerPixel

Greg Boone wrote:
> Hi All,
> 
> I am submitting the following RFC for open discussion and comments:
> 
> http://trac.osgeo.org/fdo/wiki/FDORfc1
> 
> Please respond to the list with any feedback.

Greg,

I read the RFC over.

1) Is it assumed that if GetUsedBitsPerPixel() is less than
GetBitsPerPixel()
that the used bits will be the low order bits, and the high order bits
will
be zero?
[GB} Yes.

2) What are the applications using this information for?  To do a linear
contrast stretch?  If so, would it be better to supply min/max values
instead of a number of bits?  If an image has values from 0 to 300 and
GetUsedBitsPerPixel() returns 9 the application would still do a
0-511 linear stretch which isn't too great for 0-300 values.
[GB] I am not sure I can really answer his question. See referenced
email discussion above...

3) For many file formats there isn't any way to find out how many bits
are actually being used.  Is this going to be a problem?  Is there going
to be a way for providers to return an indicator that they don't
know how many bits are actually being used?
[GB] In this case bitsUsedPerPixel == bitsPerPixel

4) Is there going to be a default implementation provide that just
returns
GetBitsPerPixel()?
[GB] Yes, I believe we could arrange this.

5) In GDAL I have a concept of NBITS as metadata from some drivers.
This is
primarily just returned by drivers reading 1, 2, and 4 bit images and
returning
them as 8bit.  This can be mapped to the GetUsedBitsPerPixel() call.
[GB] Yes. That sounds appropriate. On a side note, does the GDAL
provider support data model conversion? I thought not. If so, it would
have to deal with this issue at that time. 

Overall, I'd like to understand the rationale better (is it just for
linear
stretches).
[GB] Well, I am not in the best position to explain the exact rationale
of the customer other than what is stated above. If you would like I can
start an external thread with that customer that may help answer your
questions. That being said, the bottom line is that the customer expects
to have access to the NBITS metadata that is published with the image
and does not wish to manually determine this information by examining
the data stream.

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    | President OSGeo,
http://osgeo.org

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals