Thanks for the quick and detailed response! We're reading in normal exrs (half or float) then using double typed image buffers to do computation on them. The eigen code we use does its thing with doubles, but we do also use things in OIIO::ImageBufAlgo for manipulating the raw pixel data in these image buffers, most often resize.
So, in this case, x -> x would be fine. We start in whatever format, do our computation as double, and then write out an exr half or float. It's the computation step where not offering any -> any or x -> x is biting us, but we can get to and from there just fine. To sum up: x->x would be perfect! On Thu, Apr 4, 2019 at 2:43 PM Larry Gritz <[email protected]> wrote: > Yeah, I was trying to combat extra long compile times by attempting to > avoid instantiating templates for EVERY possible cross-product of types, > when I strongly suspected that most of those types (let alone combinations) > were extremely rarely used and in those rare occasions would be fine with > translating to float. > > I guess double is the one type where that strategy would lose information, > I knew that at the time but thought "I never see double images in the > wild!" (At least not on purpose.) It can't be from openexr, which has no > double support. What are you doing, computationally generating "images" as > doubles and then doing ops on them? > > We can definitely fix something, I don't want you to have to maintain a > customized set of patches on your side, that's always a huge pain. > > Can I ask, is the only case you care about double->double? Or is it > double->any? Or other types that are not in the current "common" set > (which, to review, are float, uint8, uint16, half)? > > Because one thing I seriously considered when making these macros is > handling the x->x case (for all types x) in addition to the cross product > of {common}->{common}. That's more cases than only doing common->common, > but not nearly as many as any->any, if you see my point. It's O(n) vs the > O(n^2) that I really wanted to avoid, even though it's not quite as small > as the O(4), which perhaps was a little too restrictive. > > So if the x->x case doesn't cover you, then I can just make a build-time > option, like you suggest, that changes all of the DISPATCH_COMMON_TYPES > macros to instead be a full DISPATCH_TYPES, trading longer compile time for > native handling of all data types. > > > On Apr 4, 2019, at 1:36 PM, Alex Suter <[email protected]> wrote: > > > Hi, > > In this commit: > > > https://github.com/OpenImageIO/oiio/commit/cec86cd03230293bc9091e8c9a681115792bb6f3#diff-05487b27ae741be8268d20d7cdd48991 > > it looks like resize went from natively supporting type double to > converting it to float. We have some situations where we use double that > this change between 1.5 to 1.8 is causing an issue. > > I was wondering what you thought about going for the slower-to-compile, > more-templated-types way via an ifdef. Something like: > > #ifdef MORE_TEMPLATES_MORE_FUN > OIIO_DISPATCH_TYPES2 (... > #else > OIIO_DISPATCH_COMMON_TYPES2 (... > #endif > > We can also just modify it locally, but I thought it might be more > generally useful. (If this has been discussed to death, apologies, I > couldn't find it and am woefully behind the times). > > Thanks again for the wonderful library. > > -- Alex > > -- > |o| Alex Suter |o| R&D SF |o| x62368 |o| > _______________________________________________ > 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 > -- |o| Alex Suter |o| R&D SF |o| x62368 |o|
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
