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]
>> <mailto:[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] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> [email protected] <mailto:[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
