> Except the infrastructure sort of already assumes the referece space > is fixed, as given by the luminance coefficients functions and > definition? Perhaps it makes sense to extend the luminance > coefficients into a more rounded (and obviously optional) set of > normalized primaries?
The luminance coefficients in OCIO are deprecated (as mentioned here: http://opencolorio.org/userguide/config_syntax.html#luma), and none of the internals take these values into account. > I do believe however, that by merely extending the OCIO luminance > coefficents for the reference space to be a referential > reference-to-XYZ standard, we are likely heading in a very sound > direction I'm hoping to explore proper RGB primaries and whitepoints in the future development of OCIO, but that could still be quite a while away (and after much discussion no doubt). By having colorspaces tagged with their explicit primaries, a transformation from one to another could calculate the gamut conversion matricies and add them to the op chain automagically, but could skip this step for colorspaces without primaries marked. Perhaps we should take these discussions to the OCIO-dev mailing list :) -Mark On Tue, Aug 5, 2014 at 10:08 PM, Troy Sobotka <[email protected]> wrote: > On Tue, Aug 5, 2014 at 1:24 PM, Mark Boorer <[email protected]> wrote: > > > > 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. > > Except the infrastructure sort of already assumes the referece space > is fixed, as given by the luminance coefficients functions and > definition? Perhaps it makes sense to extend the luminance > coefficients into a more rounded (and obviously optional) set of > normalized primaries? > > For example, the sRGB to XYZ matrix normalized for a D65 white point is > > 0.4124564 0.3575761 0.1804375 > 0.2126729 0.7151522 0.0721750 > 0.0193339 0.1191920 0.9503041 > > This is a wonderful matrix to have, because aside from giving us the > critical information we need for an XYZ transform (and as a result, > Lab, xyY, etc.) we also have in a way merely extended the luminance > coefficients functionality already present in OCIO, with the Y row > being the weights for any RGB triplet. > > > 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. > > I too agree that automation isn't likely to be a reasonable > expectation, and I also agree with your metadata concerns. > > I do believe however, that by merely extending the OCIO luminance > coefficents for the reference space to be a referential > reference-to-XYZ standard, we are likely heading in a very sound > direction. The function for getDefaultLumaCoefs can gracefully fall > back to the older config, as well as simply pulling the Y row from the > new configuration format. It doesn't seem too invasive as a first step > that would significantly augment both sets of tools. > > From there, it would seem deadly easy to generate a very good series > of dE versions that OIIO can leverage accordingly. > > With respect, > TJS > _______________________________________________ > 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
