[fdo-internals] RE: FDO raster image data model does not provide the actual number of bits used by certain image data formats (Re: FdoRfc1 & FdoRfc2)

[Greg Boone]

Hi Frank,

I took a second look at the possibility of implementing computational
functions on the FdoRasterDataModel. 

I finally 'clued in' that FdoRasterDataModel is not actually implemented
at the provider level. Since it is not an interface, it is implemented
only at the FDO API level and is meant to be an information type object
created by the provider OR a client of the provider and set through
FdoIRaster::SetDataModel. 

Such a mechanism allows the provider implementation to set the default
raster data model when the FdoIRaster instance is generated by the
provider. It also allows the client to manipulate the raster image by
changing its data model once it obtains access to FdoIRaster. By setting
the values in the data model, a client would affect the information
returned from FdoIRaster::GetStreamReader.

Once I remembered the details, I would now suggest that a computational
action such as GetMinMax would be better specified on the FdoIRaster
interface itself, and have it be separated from the definition of the
data model.

I would still argue that having both MinMax and BitsUsedPerPixel is a
more flexible system. It should be up to the client to determine what
information is relative to their needs and make the appropriate API
call.

As for obtaining MinMax from ATIL, I was mistaken. Jeff correctly
pointed out that it is available for certain formats.

Greg


-----Original Message-----
From: Frank Warmerdam (External) 
Sent: Thursday, March 22, 2007 11:21 AM
To: Greg Boone
Cc: Sarat Venugopal; Jeff Childers; Orest Halustchak; FDO Internals Mail
List
Subject: Re: FDO raster image data model does not provide the actual
number of bits used by certain image data formats (Re: FdoRfc1 &
FdoRfc2)

Greg Boone wrote:
> (NOTE: I am now adding the 'FDO Internals' email list to the thread)
>
> A couple of additional points,
> 
> 1) Regarding the 'bool force' option on the proposed GetMinMax() 
> function. I am not really in favor of offering this option, thus 
> requiring the FDO Provider to scan the image to determine the min/max 
> values. This is especially true when interfacing with the 
> FdoRasterDataModel Interface, which is meant for informational
purposes 
> only. If the underlying raster libraries do not offer the min/max
values 
> then I would rather leave their brute force calculation up to the
caller 
> rather than providing this logic in the provider.

Greg,

I must admit I have qualms about putting an action, like computing
min/max
on the FdoRasterDataModel interface which seems to be very property
oriented.  On the other hand, it isn't obvious where else to put an
operation like this.  Advice welcome.

I think there are benefits to letting the provider compute the min/max
values.  Both with regard to performance and since this gives the
provider
the opportunity to record the statistics in the dataset, as GDAL does.

I mentioned performance in particular because FDO provides no concept
of what the natural block size of an image is, nor what overviews are
available.  So it is very hard for FDO applications to efficiently and
generally sample an image on natural blocks, and/or utilize available
overview levels to quickly sample an image.

> 2) I would like to point out that not all of the raster libraries that

> our providers deal with offer up the min/max values. For example the 
> ATIL library only offers access to the bits and bitsUsed per pixel.

For images such as NITF formats with a corresponding ABPP flag, this
should be enough to return a useful approximate min/max value.

However, I don't think we should be hobbling the FDO data model due
to an incomplete feature set in ATIL.  And this would hopefully give
the ATIL folks some encouragement to consider a more robust model for
image scaling information.

> 3) If I read correctly, your proposal to add the GetMinMax function 
> would mean that GetBitsPerPixel and GetBitsUsedPerPixel will not be 
> supported.  Following up on Sarat's comments, what was your opinion on

> providing both sets of API functions? I think this may prove to be
more 
> flexible when implementing different raster providers such as the 
> Autodesk Raster provider and the GDAL Raster provider.

We definately need GetBitsPerPixel().  But you are correct that I am
proposing RFC2 as an alternative to adding the GetBitsUsedPerPixel()
which I find to be very specialized and of limited actual value to
applications.

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