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
>
> <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
