Hi All, Personally, I think having some basic builtins when OCIO is enabled would be a good way to go - in the absence of an existant OCIO config, OIIO could have a set of basic internal transforms and spaces - anything built into OIIO could also be shipped in a OCIO config along with OIIO which would allow easy extension of an existing OCIO setup and provide precise compatibility with oiiotool etc. in other apps.
I think many users would appreciate not having to deploy an OCIO config and set environment variables etc. for very basic oiiotool-driven operations (e.g simple thumbnailing of DPX or EXR sources to PNG or JPG) - in our organisation, in some cases I have to deploy this stuff to users who will not have access to our central OCIO config stuff which does add a point of failure if the OCIO configs get forgotten. Currently, there are linear, sRGB and rec709 transforms available in OIIO if we don’t have OCIO at compile time, and it seems a little strange (for someone working with a VFX pipeline it is obvious OCIO expects a user-supplied config, but this may not be so for many of OIIO’s users ) not to have at least the same capability ‘out of the box’ when compiled with OCIO. >From my perspective, the basics should include linear, gamma2.2, SRGB, Cineon >support. None of this is a big deal for me, and the existing OIIO/OCIO combination really does work great as far as I am concerned. Thanks, -Pete On 6/08/2014, at 8:24 am, Mark Boorer <[email protected]> wrote: > The problem becomes knowing what color space your input files are in, and > having a transform to take them from that space to XYZ / Lab (Not to mention > any linearising that may need to be done). > As you mentioned, OCIO by default does not even ship with any defined > colorspaces, and transformations will not take gamut into account unless > explicitly coded into the OCIO Colorspace transforms. > > I do have all of the required code and matricies for transformations from > most common color spaces, and these could be added to OIIO (building up OCIO > transformations purely in code). But if you're hoping to have an automated > solution I don't think it's possible. > > For one, even just going off the metadata in the images often leads to > incorrect results. I'm yet to find a DPX with the correct Transfer > Characteristic metadata tag in the wild ;) > > Perhaps hard code some transfer functions (sRGB, gamma22, ploglin, linear), > and some colorspaces (sRGB, DCI-P3, ACES, XYZ) and let users pick them from > the command line? > Offering to fall back onto an OCIO colorspace if the OCIO env var is set > appropriately. > > I can look into this if it sounds appealing. > > -Mark > > > > > > On Tue, Aug 5, 2014 at 9:09 PM, Larry Gritz <[email protected]> wrote: > What's the difference between DE2000K and CIEDE2000? > > If there's consensus on which metric to use, it should be pretty easy to add, > and a welcome change. I'd happily do it myself if somebody isn't already > working on it. > > -- 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 > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
