Date   

Re: OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 



On Tue, Oct 25, 2016, 11:54 AM Joseph Slomka <joseph...@...> wrote:

The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing.

Agree.

The question then is, how to specify the XYZ transform.

I added it in the above patch in a manner much like the luma tag.

Is this a workable step forward? It would seem that we could depreciate the luma tag and replace it with a mandatory XYZ tag with values.

Is this reasonable as a toe-in-water step?

With respect,
TJS


Re: OCIO Configuration Reference Values

Joseph Slomka <joseph...@...>
 

Troy,

The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing.


The next shortest is making it a requirement, and having it fail a sanity check and throw a flag if not implemented.

If it's agreed to then it should make it to the trunk. It sounds like OCIO needs more builds and more feedback to get user input and involvement. I am not a fan of a required role, but if it is a choice between that and dealing with dozens of VFX houses each with their own color management tools I'd much rather have required roles.

The slightly longer path is to make a metadata component to OCIO that provides some minimal API to manage color state of images.

Ideally OCIO would be the part of a project that manages color. It sounds like there is a need for a color management framework that track image state,executes logic and interacts with other color management systems.

-Joseph




On Mon, Oct 24, 2016 at 10:13 PM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Oct 24, 2016, 6:18 PM Joseph Slomka <joseph...@...> wrote:

The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created. 

My issue with best practices is that they will fail where not implemented, which means an entire user interface stack or potentially shaders, algorithms, and a whole slew of other things fall apart and suddenly break.

I am wondering:

1) What is the shortest path to a workable solution for OCIO in the near term that works.
2) Whether such a solution can make it into trunk and become reference.

Happy to see longer term goals here, but given that OCIO appeared to have been taken off of life support, only to resume critical condition weeks later, perhaps our goals should be modest at this juncture.

Implementing a mandatory XYZ set of values for reference, with applicable warnings or failure would at least be an entry point?

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 

On Mon, Oct 24, 2016, 6:18 PM Joseph Slomka <joseph...@...> wrote:

The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created. 

My issue with best practices is that they will fail where not implemented, which means an entire user interface stack or potentially shaders, algorithms, and a whole slew of other things fall apart and suddenly break.

I am wondering:

1) What is the shortest path to a workable solution for OCIO in the near term that works.
2) Whether such a solution can make it into trunk and become reference.

Happy to see longer term goals here, but given that OCIO appeared to have been taken off of life support, only to resume critical condition weeks later, perhaps our goals should be modest at this juncture.

Implementing a mandatory XYZ set of values for reference, with applicable warnings or failure would at least be an entry point?

With respect,
TJS


Re: OCIO Configuration Reference Values

Joseph Slomka <joseph...@...>
 

Andy,

The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created.

As for the second suggestion I think it is part of a bigger  problem. There needs to be metadata management to really address the issues that are popping up. OCIO describes color transformations, but not image states. OCIO can describe what to do with a Rec709 tagged image, but not tell you if an image is actually Rec709.  The idea would be that there should be some kind of mechanism to track and create the appropriate metadata for a given image state.

The idea of creating application specific keywords and application specific color data sounds like it could lead to situations where different applications could get mismatched information for the same image state. So perhaps and tone mapping,chromaticity and other metadata data could be added as tags to describe the inputs and outputs of each OCIO transform. That data can then be passed to the system that is used to track image state and metadata. That system  could then create application specific metadata from a more general image state description.

It's a lot more work but it could prevent issues down the line with inconsistent metadata. 

-Joseph


On Mon, Oct 24, 2016 at 8:27 AM, Andy Jones <andy....@...> wrote:
I'd like to see two things added, which I feel represent a conservative take on how to add chromaticity data without going "too far."

1) An XYZ role.  This won't solve all the problems, but it does provide a black-box way to get to a known colorspace, regardless of the transforms used, without creating an alternate pathway.  (It's also just a role, so it's hard to imagine it doing much harm, assuming care is taken to designate it in a reasonable way.)

2) User-specified key/value pairs, with some recommended "common" tags.  The recommendations would be to help achieve consistent names, but would not provide OOTB behavior.  In that sense, it would be similar to the role system.


The reason I advocate for item 2 is that in order to interact with other color frameworks like ICC, color pickers, renderers, there is actually a wide variety of information that might be desirable.  For example, when tagging exported images, it may be preferable to provide a path to an existing icc profile, rather than generate a new one. And in a spectral renderer, one may want to define functions for converting from rgb to spd in the context of texturing.  When necessary, named eotfs could be provided, but these would be unofficial, and would correspond to individual applications, with no functionality provided by OCIO.  For example, a texture colorspace could specify a gamma function, or other named encoding curve.

In the case of an RGB renderer or an exported EXR, chromaticity values could be provided directly, without an expectation that those values will be used by OCIO to perform calculations.  I actually think this is preferable, as the transforms in the OCIO profile may not make sense as matrix/encoding type transforms.  For example, a colorspace that transitions from scene-referred to display-referred may benefit from a matrix for interoperability with other display-referred colorspaces.  However, this behavior is decidedly different from what the to_reference transform provides.

I would also advocate recommending that any applications always look for application-scoped keys before general keys in both roles, or this sort of per-colorspace metadata map.  For example, Maya should look for "maya_chromaticities" before falling back to "chromaticities."  By doing this, users can benefit from simple configs (no application scoping) whenever possible, but will never be faced with incompatible colorspace definitions due to varying application interpretations of the same keys.  This could be very important for things like specifying eotfs, as different applications could have slightly different names for the same curves, or slightly different curves that using the same name.

On Mon, Oct 24, 2016 at 7:39 AM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Oct 24, 2016, 6:55 AM Thomas Mansencal <thomas.m...@...> wrote:

Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I can see a danger of disconnection between the primaries / whitepoint fields and the MatrixTransform if both are present at same time, precision issues induced by the rounding would be enough to break that relationship for example.

I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc.

What *is* required is a method to query metadata about the reference, in an absolute colour encoding model / space such as XYZ, given that OCIO is blind to the hard data on a space.

So what *might* be a solution is to provide a "one way" set of data as per specification or particular reference setup. Of course this could lead to minor discrepancies between say, white point via specification and white point via mathematical matrix calculation, but I suspect in this case the specification would be ideal?

Consider the currently, *all* OCIO UI is broken in terms of pickers and like details given that no existing method to formally query the reference metadata exists. Also consider that all CGI with regards to shaders / algorithms that require Kelvin, wavelength, etc. cannot work correctly without bending OCIO.

It should be noted that while a huge chunk of applications fail miserably that are within an ICC system, the methods exist for developers to "do the right thing" and glean information from the ICCs.

This is also required in OCIO, and should be a much more pressing subject given that *every single new Apple product* is using alternate primaries in their displays. Sure, we can hack around this by providing a reference role that takes things to XYZ etc., but a more official method would be preferred.

You would also likely need to support a field for the chromatic adaptation transform being used to convert from the given colourspace to the reference colourspace.

Probably going to be handy to have at least WVK, VK, and B, indeed. Is there any data out there on CAT02 and such regarding suitability for CGI / VFx work?

Can we see some motion on this?

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO Configuration Reference Values

Andy Jones <andy....@...>
 

I'd like to see two things added, which I feel represent a conservative take on how to add chromaticity data without going "too far."

1) An XYZ role.  This won't solve all the problems, but it does provide a black-box way to get to a known colorspace, regardless of the transforms used, without creating an alternate pathway.  (It's also just a role, so it's hard to imagine it doing much harm, assuming care is taken to designate it in a reasonable way.)

2) User-specified key/value pairs, with some recommended "common" tags.  The recommendations would be to help achieve consistent names, but would not provide OOTB behavior.  In that sense, it would be similar to the role system.


The reason I advocate for item 2 is that in order to interact with other color frameworks like ICC, color pickers, renderers, there is actually a wide variety of information that might be desirable.  For example, when tagging exported images, it may be preferable to provide a path to an existing icc profile, rather than generate a new one. And in a spectral renderer, one may want to define functions for converting from rgb to spd in the context of texturing.  When necessary, named eotfs could be provided, but these would be unofficial, and would correspond to individual applications, with no functionality provided by OCIO.  For example, a texture colorspace could specify a gamma function, or other named encoding curve.

In the case of an RGB renderer or an exported EXR, chromaticity values could be provided directly, without an expectation that those values will be used by OCIO to perform calculations.  I actually think this is preferable, as the transforms in the OCIO profile may not make sense as matrix/encoding type transforms.  For example, a colorspace that transitions from scene-referred to display-referred may benefit from a matrix for interoperability with other display-referred colorspaces.  However, this behavior is decidedly different from what the to_reference transform provides.

I would also advocate recommending that any applications always look for application-scoped keys before general keys in both roles, or this sort of per-colorspace metadata map.  For example, Maya should look for "maya_chromaticities" before falling back to "chromaticities."  By doing this, users can benefit from simple configs (no application scoping) whenever possible, but will never be faced with incompatible colorspace definitions due to varying application interpretations of the same keys.  This could be very important for things like specifying eotfs, as different applications could have slightly different names for the same curves, or slightly different curves that using the same name.

On Mon, Oct 24, 2016 at 7:39 AM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Oct 24, 2016, 6:55 AM Thomas Mansencal <thomas.m...@...> wrote:

Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I can see a danger of disconnection between the primaries / whitepoint fields and the MatrixTransform if both are present at same time, precision issues induced by the rounding would be enough to break that relationship for example.

I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc.

What *is* required is a method to query metadata about the reference, in an absolute colour encoding model / space such as XYZ, given that OCIO is blind to the hard data on a space.

So what *might* be a solution is to provide a "one way" set of data as per specification or particular reference setup. Of course this could lead to minor discrepancies between say, white point via specification and white point via mathematical matrix calculation, but I suspect in this case the specification would be ideal?

Consider the currently, *all* OCIO UI is broken in terms of pickers and like details given that no existing method to formally query the reference metadata exists. Also consider that all CGI with regards to shaders / algorithms that require Kelvin, wavelength, etc. cannot work correctly without bending OCIO.

It should be noted that while a huge chunk of applications fail miserably that are within an ICC system, the methods exist for developers to "do the right thing" and glean information from the ICCs.

This is also required in OCIO, and should be a much more pressing subject given that *every single new Apple product* is using alternate primaries in their displays. Sure, we can hack around this by providing a reference role that takes things to XYZ etc., but a more official method would be preferred.

You would also likely need to support a field for the chromatic adaptation transform being used to convert from the given colourspace to the reference colourspace.

Probably going to be handy to have at least WVK, VK, and B, indeed. Is there any data out there on CAT02 and such regarding suitability for CGI / VFx work?

Can we see some motion on this?

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 

On Mon, Oct 24, 2016, 6:55 AM Thomas Mansencal <thomas.m...@...> wrote:

Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I can see a danger of disconnection between the primaries / whitepoint fields and the MatrixTransform if both are present at same time, precision issues induced by the rounding would be enough to break that relationship for example.

I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc.

What *is* required is a method to query metadata about the reference, in an absolute colour encoding model / space such as XYZ, given that OCIO is blind to the hard data on a space.

So what *might* be a solution is to provide a "one way" set of data as per specification or particular reference setup. Of course this could lead to minor discrepancies between say, white point via specification and white point via mathematical matrix calculation, but I suspect in this case the specification would be ideal?

Consider the currently, *all* OCIO UI is broken in terms of pickers and like details given that no existing method to formally query the reference metadata exists. Also consider that all CGI with regards to shaders / algorithms that require Kelvin, wavelength, etc. cannot work correctly without bending OCIO.

It should be noted that while a huge chunk of applications fail miserably that are within an ICC system, the methods exist for developers to "do the right thing" and glean information from the ICCs.

This is also required in OCIO, and should be a much more pressing subject given that *every single new Apple product* is using alternate primaries in their displays. Sure, we can hack around this by providing a reference role that takes things to XYZ etc., but a more official method would be preferred.

You would also likely need to support a field for the chromatic adaptation transform being used to convert from the given colourspace to the reference colourspace.

Probably going to be handy to have at least WVK, VK, and B, indeed. Is there any data out there on CAT02 and such regarding suitability for CGI / VFx work?

Can we see some motion on this?

With respect,
TJS


Re: OCIO Configuration Reference Values

Thomas Mansencal <thomas.m...@...>
 

Hi,

I came across this thread.

Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I can see a danger of disconnection between the primaries / whitepoint fields and the MatrixTransform if both are present at same time, precision issues induced by the rounding would be enough to break that relationship for example.

You would also likely need to support a field for the chromatic adaptation transform being used to convert from the given colourspace to the reference colourspace.

Cheers,

Thomas

On Thursday, September 29, 2016 at 9:54:37 AM UTC+13, Malcolm Humphreys wrote:

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

Question would be would this just be metadata or actually used to create extra ops.

What do you think?

.malcolm


On 28 Sep 2016 20:35, "Troy Sobotka" <troy...@...> wrote:
Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.
* Greyscale conversions. Again, missing metadata on Y weights.
* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.
* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.


Feedback appreciated.

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


OCIO Windows build

tde <till.d...@...>
 

Hi,

I know it is an old question but I could not find a working solution.

Is there a walkthrough to build OCIO including PyOpenColorIO on Windows?

Or something precompiled that might work?

My current setup is Visual Studio Community 2015.

Thanks


Re: OCIO Configuration Reference Values

Sean Cooper <se...@...>
 

This is timely, I was going to raise the issue of whether it's appropriate for OCIO to be colorimetry intelligent or not. Where OCIO would define the chromaticites per colorspace, as Malcolm stated.

As an additional feature, here @SPI I've created a wrapper around the python api where I specify a colorspace's chromaticites (primaries and whitepoint) for the reference space and for all subsequent colorspaces. At config generation, the matrix transforms to and from the reference space are automatically generated for each colorspace. Additionally there is the option to perform chromatic adaptation for varying whitepoints or not. This is implemented as an OCIO Matrix transform.

This isn't 100% what you're talking about Troy, but I think it follows in the same line of discussion. Though I do see how even a simple chromaticity flag in the colorspace would prove useful.

On Wed, Sep 28, 2016 at 2:00 PM, Troy Sobotka <troy.s...@...> wrote:


On Wed, Sep 28, 2016 at 1:54 PM Malcolm Humphreys <malcolmh...@...> wrote:

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

I loved this idea when Mark originally hinted at it at SIGGRAPH, but frankly, it would probably require some deeper sculpting unless someone can figure out an elegant solution for the parser on each transform.

Part of the problem here though is that I'm pretty sure this begins to deviate quite a bit from the transform oriented nature of OCIO. It's also compounded by the fact that it isn't terribly clean as some transforms (say OETF / EOTF or other transfer curves) would not have definitions. So again, it feels deeper perhaps? 

Question would be would this just be metadata or actually used to create extra ops.

I am approaching this from the aspect of designing UIs that are properly colour managed, and it's darn tricky currently. It's also darn tricky to design say, shaders or algorithms that require XYZ in a colour agnostic way without such metadata (such as black body or Kelvin formulas).

This almost trivial solution would certainly repair all of those cases instantly, at a low cost of code overhead / change.

What do you think?

I'm very curious to hear what other folks with much larger brains than mine have to say?

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 



On Wed, Sep 28, 2016 at 1:54 PM Malcolm Humphreys <malcolmh...@...> wrote:

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

I loved this idea when Mark originally hinted at it at SIGGRAPH, but frankly, it would probably require some deeper sculpting unless someone can figure out an elegant solution for the parser on each transform.

Part of the problem here though is that I'm pretty sure this begins to deviate quite a bit from the transform oriented nature of OCIO. It's also compounded by the fact that it isn't terribly clean as some transforms (say OETF / EOTF or other transfer curves) would not have definitions. So again, it feels deeper perhaps? 

Question would be would this just be metadata or actually used to create extra ops.

I am approaching this from the aspect of designing UIs that are properly colour managed, and it's darn tricky currently. It's also darn tricky to design say, shaders or algorithms that require XYZ in a colour agnostic way without such metadata (such as black body or Kelvin formulas).

This almost trivial solution would certainly repair all of those cases instantly, at a low cost of code overhead / change.

What do you think?

I'm very curious to hear what other folks with much larger brains than mine have to say?

With respect,
TJS


Re: OCIO Configuration Reference Values

Malcolm Humphreys <malcolmh...@...>
 

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

Question would be would this just be metadata or actually used to create extra ops.

What do you think?

.malcolm


On 28 Sep 2016 20:35, "Troy Sobotka" <troy.s...@...> wrote:
Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.
* Greyscale conversions. Again, missing metadata on Y weights.
* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.
* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.


Feedback appreciated.

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 

Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.
* Greyscale conversions. Again, missing metadata on Y weights.
* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.
* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.


Feedback appreciated.

With respect,
TJS


NUKE CDL MatchGrade

kernelk...@...
 

I noticed that OCIO is used in Nuke for CDL exports. Are there any other programs apart from Nuke that create CDLs from matched grades? I was looking through the OCIO code and didn't see any code itself that does this. If any one has any repositories or pointers to available libraries, I would appreciate it.

K


Re: State of OCIO development re: CPU/GPU mismatches

Sean Cooper <se...@...>
 

I think it would be very interesting to take a look at an OpenCL OCIO implementation.

It seems like: #304, #396, + Kevin's CDL parse, would be easy first steps to get these creaky joints moving again.

I'll have more time next week to investigate the other pull requests, and catch up on the test suite.

@Malcolm: do know the status of the DNeg OCIO pull that has been referred to? And if there are still people there interested in pushing to the public repo? 

On Tue, Sep 13, 2016 at 9:37 AM, Dithermaster <dither...@...> wrote:
Nathan and others interested,

I've attached a PDF describing our OpenCL extensions to OpenColorIO. An accurate OpenGL path would do something very similar with multiple shader parameters, and would return GLSL instead of an OpenCL kernel. I am happy to work closely with anyone who wants to create the accurate OpenGL path starting from these changes, but I'm not an OpenGL expert so you'd need to handle the OpenGL side of things.

Sincerely,

///d@
Dennis Adams


On Tue, Sep 13, 2016 at 10:45 AM, Dithermaster <dither...@...> wrote:
Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

Dithermaster <dither...@...>
 

Nathan and others interested,

I've attached a PDF describing our OpenCL extensions to OpenColorIO. An accurate OpenGL path would do something very similar with multiple shader parameters, and would return GLSL instead of an OpenCL kernel. I am happy to work closely with anyone who wants to create the accurate OpenGL path starting from these changes, but I'm not an OpenGL expert so you'd need to handle the OpenGL side of things.

Sincerely,

///d@
Dennis Adams


On Tue, Sep 13, 2016 at 10:45 AM, Dithermaster <dither...@...> wrote:
Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Re: State of OCIO development re: CPU/GPU mismatches

Dithermaster <dither...@...>
 

Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

Mark Visser <mvi...@...>
 

+1 to Dennis's offer of fixed GPU path code, fixing the banding issue would be fantastic! I can pitch in with testing and code review if that helps.

I too would love to see what DNeg has been up to, but without a comprehensive test suite there's no easy way to see what changes a massive code dump introduces, and that's scary.

This PR is about as basic as it gets and has been in production at Mokko for years: https://github.com/imageworks/OpenColorIO/pull/396

cheers,
-Mark


On Tuesday, September 13, 2016 at 5:08:49 AM UTC-4, Malcolm Humphreys wrote:
I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <nath...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

Larry Gritz <l...@...>
 

Erlang, wow. That .travis.yml looks like it dates from when dinosaurs roamed the earth.

Having recently set it up for OIIO and OSL, perhaps I can take a stab at it. 



On Sep 13, 2016, at 2:08 AM, Malcolm Humphreys <malcolmh...@...> wrote:

I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <natha...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan



--
Larry Gritz
l...@...



Re: State of OCIO development re: CPU/GPU mismatches

Malcolm Humphreys <malcolmh...@...>
 

I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <natha...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

Nathan Rusch <natha...@...>
 

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan

741 - 760 of 2243