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

Thu Mar 22 10:49:46 EDT 2007

(NOTE: I am now adding the 'FDO Internals' email list to the thread)

Hi Frank,

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. 

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. 

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.

Thanks,

Greg

-----Original Message-----
From: Frank Warmerdam (External) 
Sent: Thursday, March 22, 2007 1:00 AM
To: Sarat Venugopal
Cc: Greg Boone; Jeff Childers; Orest Halustchak

Sarat Venugopal wrote:

> Having looked at both proposals, RFC2 seems to be a superset of RFC1,
in 

> the sense that the number of bits in actual use could be deduced from 

> the minimum and maximum values. However, from an API perspective, I 

> believe combining both RFC's may be better in many ways. Here are some

> thoughts numbered to address each scenario.

Sarat,

Note, I was really offering RFC2 as a more general alternative to RFC1,

and based on my experience with other toolkits, and various application

requirements.

> 3. I don't really see a need for the boolean m_minMaxSet - minimum and

> maximum values will always exist for the given data model, which 

> defaults to those corresponding to the bit depth and data type, and 

> m_minMaxApproximate defaults to true. 

The purpose of m_minMaxSet was to mark whether the provided min/max

values were considered meaningful.  So if the file headers provide

no min/max information then m_minMaxSet would be false, even if

the min/max values were actually set to some absolute range values

for the data type.

But, it is important that we be able to distinguish between min/max

values that are just based on the data type, and ones that are based

on at least approximate sampling or header values.

BTW, I do really feel that RFC discussions should take place on the

fdo-internal list, in public view for more general feedback.

Best regards,

  _____  

From: Sarat Venugopal 
Sent: Thursday, March 22, 2007 12:18 AM
To: Greg Boone; Jeff Childers
Cc: Orest Halustchak; Frank Warmerdam (External)

Hi, Greg,

(Nice to e-meet you, Frank, I have found your GDAL tools very useful.)

Having looked at both proposals, RFC2 seems to be a superset of RFC1, in
the sense that the number of bits in actual use could be deduced from
the minimum and maximum values. However, from an API perspective, I
believe combining both RFC's may be better in many ways. Here are some
thoughts numbered to address each scenario.

1. If the format provides only the bits used information (such as 11 in
Ikonos data), it makes sense to use this *without* scanning the image
further. In the combined implementation, SetBitsUsedPerPixel() would set
m_minMaxApproximate to true, m_min to 0 and m_max to 2^11, for example.
The used bits (11) could be either stored in the data model or computed
when GetBitsUsedPerPixel() is called (say, std::max(minBits(m_min),
minBits(m_max))).

This will ensure that FDO does not scan the image unless the user is
specifically interested in the exact minimum and maximum.

2. If the format provides minimum and maximum values as part of the
header/metadata as Frank showed, then again no scanning is required and
we have exact values. Calling GetBitsUsedPerPixel() will return the
appropriate value as given above. SetBitsUsedPerPixel() should probably
throw an exception in this case (m_minMaxApproximate == false), as we
already have exact values.

3. I don't really see a need for the boolean m_minMaxSet - minimum and
maximum values will always exist for the given data model, which
defaults to those corresponding to the bit depth and data type, and
m_minMaxApproximate defaults to true. A subsequent call to
SetBitsUsedPerPixel() or SetMinMax() may modify these values, with the
latter setting m_minMaxApproximate to false.

To summarize, adding the public functions from RFC1 provides a great
deal of flexibility, without compromising the more general and accurate
approach outlined in RFC2. There is no need to add a separate variable
to store the bits used, which can be computed when asked for with inline
functions. An implementation detail is to eliminate m_minMaxSet, because
having these set always represents the object state accurately at all
times. Combining both approaches will eliminate the need to scan images
unless the user specifically requests for a full scan, by making use of
available metadata.

I hope it all makes sense.

Thanks for asking,

Sarat

  _____  

From: Greg Boone 
Sent: Thursday, March 22, 2007 5:06 AM
To: Sarat Venugopal; Jeff Childers
Cc: Orest Halustchak; Frank Warmerdam (External)

Hi Sarat, Jeff,

Now that Map 2008 is basically out the door, we are in a position to try
and come up with a resolution for Defect 868055 and hopefully have it
implemented for the upcoming release of MapGuide 2008 / FDO 3.2.2. FDO
3.2.2 will be binary compatible with Map 2008.

Our previous discussion on this topic has now resulted in several
proposals on how the FDO Raster interface could be modified to meet the
expected requirements. The pending proposals (and the discussions
leading up to the proposals) are outlined in the following links. 

FDO Open Source Community Discussion Links:

http://www.nabble.com/FDO-RFC-1---Support-Property-FdoIRaster%3A%3ABitsU
sedPerPixel-tf3398949s18162.html

http://www.nabble.com/RE%3A-FDO-RFC-1---Support-PropertyFdoIRaster%3A%3A
BitsUsedPerPixel-tf3414749s18162.html

http://www.nabble.com/RE%3A-FDO-RFC-1---SupportPropertyFdoIRaster%3A%3AB
itsUsedPerPixel-tf3415706s18162.html

FDO Open Source Community 'Request for Comments' (RFC) links 

http://trac.osgeo.org/fdo/wiki/FDORfc1

http://trac.osgeo.org/fdo/wiki/FDORfc2

Can you review the discussions and proposals? I would welcome your
feedback regarding:

1)       Which proposal would meet our client requirements?

2)       Can we implement the current proposal using existing ATIL
functionality?

Thanks in advance.

Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070322/742cdb26/attachment-0001.html