Hey! This change works great for us. Thanks so much. On Thu, Apr 4, 2019 at 9:16 PM Larry Gritz <[email protected]> wrote:
> Here is my stab at a solution: > https://github.com/OpenImageIO/oiio/pull/2203 > > Curiously, I must have thought of this at some point, because there was > already a OIIO_DISPATCH_COMMON_OR_SAME_TYPES2 macro. But I didn't use it > anywhere! So I got rid of it and just changed the COMMON_TYPES2 and > COMMON_TYPES3 macros to explicitly spell out the "all same type" cases. > > -- lg > > > On Apr 4, 2019, at 4:10 PM, Larry Gritz <[email protected]> wrote: > > OK, great. > > I think just adding the x->x cases is straightforward and will give you > what you need without reintroducing the compilation cost of the full cross > product of types. And I like that better than a build-time option because > it will give you uniform results that won't vary behavior in an explicable > way depending on the build flags. > > I'll whip that right up for you, stay tuned. > > -- lg > > > On Apr 4, 2019, at 3:11 PM, Alex Suter <[email protected]> wrote: > > 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 > > > -- > Larry Gritz > [email protected] > > > > > _______________________________________________ > 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
