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]
> <mailto:[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]
>> <mailto:[email protected]>> wrote:
>>
>>
>> Hi,
>>
>> In this commit:
>>
>> https://github.com/OpenImageIO/oiio/commit/cec86cd03230293bc9091e8c9a681115792bb6f3#diff-05487b27ae741be8268d20d7cdd48991
>>
>> <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] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <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
