There are some questions about whether the growing (or for that matter, existing) collection of ImageBufAlgo image processing utilities ought to handle the full range of pixel data types OIIO supports when reading and writing files. Resolving this problem is especially important for "binary" image operations, where the full cross-product of (result type X image 1 type X image 2 type) could be a big compile time and executable size bottleneck.
ImageBufAlgo routines are, at present, inconsistent: some support all data types, including those never seen in the wild; some fail if it's anything but float; some support a limited number of common types (e.g., float, half, uint8, unint16) and fail otherwise. There is precedent in our existing code for all three approaches. But I think it would be better to settle on one and use it uniformly. Let's be clear about a few things: * ImageBuf still can hold any of the pixel data types, that's not up for debate. * The way the ImageBuf::Iterator works, there is already a conversion to or from float, when iterating through non-float buffers. So IBA routines that directly support non-float buffers offer NO speed or precision advantage -- the most they do is save an app the trouble of pre-copying to a float buffer (if it's not already using one) before making use of ImageBufAlgo functions. * We typically back read-only (i.e., anything read from disk) ImageBuf's by an ImageCache, which internally only supports float and uint8 and will convert everything else to one of those upon read, and in fact oiiotool and maketx instruct its ImageCache to use ONLY float. So this decision will have no effect on the functionality of oiiotool or anything that closely resembles it. So I put it to you, respected readers. Should we... (a) declare that henceforth, IBA functions are only designed to work on float ImageBuf's, which will greatly simplify the ImageBufAlgo source code and make them compile as quickly and compactly as possible? (b) support a commonly-used subset of types directly, as Stefan's "over" does (float, half, uint8, uint16)? This is not very expensive in runtime (thanks to template magic), but compared to solution (a) it is 16x more compile time and binary size, and at least 2x more source code complexity. (c) try to support all types? In which case we need an idea for a different method than using templates to fully specialize 11^3 versions, which leads to impractical compilation times, and the majority of the specializations will never, ever be used. I'm on the fence. On one hand, I like the idea of IBA functions being able to work on any type, or at least all of the common ones. On the other hand, going float-only with IBA would greatly simplify the code, and to the extent that IBA's canonical customer is oiiotool (or other programs somewhat like it), the extra functionality would be rarely if ever used and it would be hard to justify the extra complexity. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
