On Jun 29, 2012, at 1:30 PM, Stefan Stavrev wrote:
> I can't think of other solution for supporting all types.
>
> I would vote for small subset of types, but after some years, what if there
> are 100 or 200 functions that will need type specialization. Even having 4
> types will be a problem I guess, 4^3 for 3 input images and 4 types, is still
> not small.
You could cut out another factor of 4 by making the rule that *results* have to
be float, inputs can be one of 3 or 4 common types.
Just saying.
It's worth repeating one more time: ImageCache is already {float,uint8} only
and oiiotool is already float-only (for internal computation; both support all
the data types for their file inputs and outputs). This is largely an academic
argument about library design for ImageBufAlgo, for which we do not yet have an
identified candidate customer that is demanding anything but float.
> So, at this point I vote for float-only. Aside question, is there any reason
> to go with double instead?
That would be a 2x memory and significant performance hit (because it doubles
require twice the memory bandwidth and take up twice the cache space, at the
very least), with no obvious benefit. I've never seen a double-precision image
file in the wild, so I can't see the point of computing with more precision
than we will ever encounter in the inputs or desired outputs.
I will prepare a pull request for "over" showing the kind of code
simplification this will bring, then people can comment in a more informed
manner about the benefit we'd get from the simplification.
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
