Unfortunately, that would require the iterators to be polymorphic, i.e. having
virtual methods rather than being templated and inlined. That would surely
ruin performance of the iterators.
I suppose we could make a separate, slow "all type" iterator, and have two
versions (perhaps via templates) of each image processing operation: a fast
float-only and a slow-but-handles-all-types.
Still, I am haunted by a key question: does the support of all the types merely
seem nice and general to us idealists, or does anybody actually want and need
such functionality? As I said, the only way multi-type support would come into
play is if you are not using IB's backed by ImageCache (which itself
auto-converts to either one or two types, internally), and for some reason want
to hard-allocate non-float buffers (and not copy to float buffers to use IBA
functions), and also don't mind that the fact that the iterators themselves
convert from and to float would decrease performance (and give no precision
advantage) compared to having float buffers all along. With all those caveats,
what is the compelling real-world justification for the increased complexity?
The only reason I can think of is if you want to use the flavor of ImageBuf
that "wraps" an application buffer, and perhaps you are writing an app that
uses both OIIO and, say, OpenCV or some other 3rd party library that has
"images" in other formats that you want to wrap and make look like IB's, then
perform ImageBufAlgo functions on them. In such cases, it still seems to me
that float-uint8 or float-uint8-uint16-half (some small subset of our types
that covers everything you're truly likely to see) would more than do the trick.
-- lg
On Jun 29, 2012, at 12:07 PM, Stefan Stavrev wrote:
> It would be amazing if all types are supported.
>
> Analysis of the problem: The typical case is two input images A and B, and
> one output image R. Each can be one of 11 types. The problem with the current
> approach is that we have a cross product of the 11 types, resulting in 11^3
> madness. Can we get away with not using the cross product and still achieve
> our goal? Here is another approach that may or may not work, I am
> brainstorming. If it does not work at least it might provoke some ideas.
>
> First of all, notice this pattern:
>
> 1. Specialize type for input image A.
> 2. Specialize type for input image B.
> 3. Specialize type for input image C.
> 4. Create iterators for A, B and C based on their types.
>
> Step 4 is the key thing to notice. It is the ONE AND ONLY end goal of our
> types specialization!
>
> So why not have it like this:
>
> some_image_processing_function (R, A, B, ...) {
>
> switch (A.spec().format.basetype) {
> case TypeDesc::FLOAT: // create iterator for A of type <float, float>, on
> heap somehow?
> // same for the other types
> }
>
> switch (B.spec().format.basetype) {
> case TypeDesc::FLOAT: // create iterator for B of type <float, float>, on
> heap somehow?
> // same for the other types
> }
>
> switch (C.spec().format.basetype) {
> case TypeDesc::FLOAT: // create iterator for C of type <float, float>, on
> heap somehow?
> // same for the other types
> }
>
> }
>
> If we could do something like this the complexity is 3*11=33 compared to
> 11^3=1331.
>
> Again, I am just brainstorming, it might work or not but in worst case it
> will provoke some ideas. The main thing to notice is that the types of the
> images are independent of each other so there is no need to do cross
> products, we might be able to handle them separately somehow.
>
> Stefan
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
