I would be thrilled if OCIO contained all desired color-related logic and OIIO
could just rely on the right OCIO library calls for this kind of thing.
I'm not sure if this is on the OCIO roadmap, and historically OCIO has had (for
good reasons) a very rigid outlook on the world -- you buy into the whole OCIO
paradigm, or not, and need a full OCIO installation/configuration (LUTs and
color space names) like you'd have in a VFX studio, as a prerequisite to doing
anything useful at all. For example, just something simple like converting sRGB
in a JPEG to linear is something where OIIO would like to just do the obvious
linearizing transformation and hope for the best (which is fine in almost all
cases, though, if more is known about the exact color spaces expected, it could
be even smarter), whereas OCIO's reaction is "if you can't do it RIGHT (TM),
don't support it at all."
Jeremy will probably say I'm badly paraphrasing. :-) And I don't dispute that
there is a strong internal logic to OCIO. But that is partly why there's a bit
of a gap and why OIIO's color operations are a mishmash of OCIO and reliance on
OIIO-side shenanigans.
-- lg
On Aug 4, 2014, at 11:40 PM, Troy Sobotka <[email protected]> wrote:
>
> On Aug 4, 2014 10:11 PM, "Larry Gritz" <[email protected]> wrote:
>
> > All other things being equal, I think there's got to be some merit to using
> > an ISO standard color difference metric.
>
> DE2000K would be fine, but with it comes all of the baggage of correctly and
> accurately transforming FooColorspace to XYZ.
>
> Seems an unwieldy task for OIIO? A perfect fit for OCIO?
>
> With respect,
> TJS
>
>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
