Date   

Re: OCIO - Path Forward

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

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Troy, would you be able to wrap this into an Issue on GH? With the coming addition of labels, this will be classified as a feature request.

On Wed, Jan 11, 2017 at 5:03 PM, Troy Sobotka <troy.s...@...> wrote:


On Wed, Jan 11, 2017, 5:42 PM Sean Cooper <se...@...> wrote:
  • Road to 2.0
    • What are the dream requests?

On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements.

Having spent plenty of time ramming into the problems, I believe that can be elegantly accomplished by:

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Many transforms are going to be of the transfer function variety, and it makes sense to tackle UI in the least invasive manner possible, hence limiting the metadata to the fewest possible areas makes sense? Per transform seems overkill unless a sane metadata structure can be arrived at that wraps up the needs.

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

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



On Wed, Jan 11, 2017, 5:42 PM Sean Cooper <se...@...> wrote:
  • Road to 2.0
    • What are the dream requests?

On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements.

Having spent plenty of time ramming into the problems, I believe that can be elegantly accomplished by:

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Many transforms are going to be of the transfer function variety, and it makes sense to tackle UI in the least invasive manner possible, hence limiting the metadata to the fewest possible areas makes sense? Per transform seems overkill unless a sane metadata structure can be arrived at that wraps up the needs.

With respect,
TJS


OCIO - Path Forward

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

Hello all, and happy new year!

I'd like to start a formal discussion around the steps we will take to give OCIO a breath of life. Hopefully we can work to make 2017 a year of progress. So in that spirit I'd like to layout a general game plan for comment and discussion.

General Notes:
  • Reading through our last discussion I found it troubling that due to the stalled public development, conversations and progress seemed to have moved behind closed doors. To facilitate openness I advise all contributors to relegate conversation to either the GitHub issues or this forum. I have created an OpenColorIO Slack channel if there needs to be quick group conversation among contributors, but the majority of conversation should be relegated to this forum.
  • I have been granted ownership to the GitHub repo, and can accomplish administrative tasks as necessary. I do not intend to accept Pull Requests in isolation, both due to the need for public discourse and my unfamiliarity with the codebase.
  • Development should continue in a "master-only" fashion, based on the previous branch/merge patterns and at the suggestion of Larry Gritz

Game Plan:

  • Organization
    • Project Owners
      • This is no slight to the current owners of OCIO, but would it be worth it to revisit the current owners and identify their level of involvement moving forward (based on interest and free time available)? It could be beneficial to add vocal / active developers to the helm of the project. Discussion welcomed.
    • Issues
      • Need to create a better issue labeling scheme, and need to maintain it's use. Suggestions welcome.
      • Are issues irrelevant / duplicates?
      • Do PRs solve specific issues?
      • Asses difficulty in solving
    • Pull Requests
      • Are they still relevant?
      • Rank in order of usefulness
      • Determine order of integration
  • Repository
    • Continuous Integration
      • In order to begin pulling a larger volume of Pull Requests, we need to update the CI system in use.
      • Alongside this is a reevaluation of the OCIO unit tests
    • Make private forks public
      • Address private forks with additional features (Dennis Adams, Mark Boorer, etc.)
      • Get them posted publicly, work into pull request
  • Road to 2.0
    • What are the dream requests?
    • How do we want to interact with OCIO in 5 years?
    • What movements on the horizon do we need to begin working towards?
    • What features would improve adoption in modern software?
Order of Attack:
  • Issue Labels
  • Easy PR with greatest image quality impact
  • Website + Documentation
    • Up to date? Documentation still relevant?
    • Website on version 1.0.8
  • Continuous Integration
  • PR review
  • Issue solving
  • Live, Long and Prosper

Please join me in conversation about the future of OCIO! All of the above is open to suggestion and critique.

Sean


Re: LUT for linear exr to rec709

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

Hi Meiwa,

It's a bit hard to remotely debug from the info you've provided, but the general answer is that you'd want to bring your Linear source (presumably in Arri Wide Gamut primaries) into a V3LogC space. Depending on the tools at your disposal you should be able to do this in most grading applications and in Nuke's native "colorspace" node, or uses OCIO's ACES 1.0.1 config. Then use the ARRI Lut Generator, but coming from LogC source instead of Sensor Linear.

If you give a little more info I could try to shape my answer a little better.

On Tue, Dec 13, 2016 at 4:21 AM, <mei...@...> wrote:
Dear Andrew,

I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome.
The output lut generate an over-expose image.
Is that because there is difference between "scene linear" and "normalized sensor linear"?

I have the situation here same with Matt, hope find out solution asap.

Thanks,
Meiwa

On Thursday, November 12, 2015 at 12:09:15 AM UTC+8, Andrew Britton wrote:
If it doesn't work, email me and I might be able help out. 


On Nov 11, 2015, at 5:40, Matt Keith <mtt...@...> wrote:

Thanks for the promt reply Andrew!

I'm out the office at the moment but I'll give this a go as soon as I'm back at my desk.

Matt.

On Wednesday, November 11, 2015 at 1:34:22 PM UTC, Andrew Britton wrote:
You should be able to create a LUT from that generator that performs both operations. Have you tried these settings?

Load preset - Advanced

"Camera Data"
Gamma - Normalized sensor linear
Range - Extended

"Conversion Parameters"
Scaling - Photometric

"Image Destination"
Gamma - video
Range - legal

"LUT Parameters"
3D - Forced
Bits - 16
File Format - Nuke (makes a .cube file if I remember right which maya/VRay can use)


image.jpeg



On Nov 11, 2015, at 5:07, Matt Keith <mtt...@...> wrote:

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt

--
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-d...@....
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-d...@....
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: LUT for linear exr to rec709

mei...@...
 

Dear Andrew,

I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome.
The output lut generate an over-expose image.
Is that because there is difference between "scene linear" and "normalized sensor linear"?

I have the situation here same with Matt, hope find out solution asap.

Thanks,
Meiwa

On Thursday, November 12, 2015 at 12:09:15 AM UTC+8, Andrew Britton wrote:
If it doesn't work, email me and I might be able help out. 


On Nov 11, 2015, at 5:40, Matt Keith <mtt...@...> wrote:

Thanks for the promt reply Andrew!

I'm out the office at the moment but I'll give this a go as soon as I'm back at my desk.

Matt.

On Wednesday, November 11, 2015 at 1:34:22 PM UTC, Andrew Britton wrote:
You should be able to create a LUT from that generator that performs both operations. Have you tried these settings?

Load preset - Advanced

"Camera Data"
Gamma - Normalized sensor linear
Range - Extended

"Conversion Parameters"
Scaling - Photometric

"Image Destination"
Gamma - video
Range - legal

"LUT Parameters"
3D - Forced
Bits - 16
File Format - Nuke (makes a .cube file if I remember right which maya/VRay can use)


image.jpeg



On Nov 11, 2015, at 5:07, Matt Keith <mtt...@...> wrote:

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt

--
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-d...@....
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: link problem with Visual Studio 2012

Paul Miller <pa...@...>
 

On 12/5/2016 4:12 PM, Dithermaster wrote:
Is this 32-bit or 64-bit? If 32-bit, did you change the default calling
convention in your project (__cdecl vs __stdcall)? Undecorated headers
with .lib files that use the default convention will fail if you've
changed the default convention. In 64-bit this is moot since it's
all __fastcall.
No, 64 bit only.

I used the default cmake settings, though I did run cmake and build with cygwin in my path (so "patch" would work when building tinyxml).

I'll look into the v0 vs v1 issue - that looks like it may be the culprit.


On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...
<mailto:jeremy...@...>> wrote:

Are you using the proper generated headers? Are you overriding so
version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to
be in v1 (corresponding to the major version).

See https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in
<https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in>

#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace
OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@


https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt
<https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt>
set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR}CACHESTRING "Set the SO version
in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...
<mailto:pa...@...>> wrote:

I'm in the twilight zone today. After a bad merge from
Mac->Windows, my application will no longer link against the
shared OpenColorIO.lib on Windows, using Visual Studio 2012.
This is the exact same set of headers and .lib I've been using
for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport)
public: static int __cdecl
OpenColorIO::v0::FileTransform::getNumFormats(void)"
(__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or
definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_DATA"
(__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_COLOR_PICKING"
(__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR"
(__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake
on it, and rebuilt. I did have to make one change to
OpenColorABI.h, and that is to get it to use <memory> and
std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like
nothing is being exported from it.

Has anyone else experienced anything like this?

--
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...@...
<mailto:ocio-dev%2B...@...>.
For more options, visit https://groups.google.com/d/optout
<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+u...@...
<mailto:ocio-dev+u...@...>.
For more options, visit https://groups.google.com/d/optout
<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+u...@...
<mailto:ocio-dev+u...@...>.
For more options, visit https://groups.google.com/d/optout.


Re: link problem with Visual Studio 2012

Dithermaster <dither...@...>
 

Is this 32-bit or 64-bit? If 32-bit, did you change the default calling convention in your project (__cdecl vs __stdcall)? Undecorated headers with .lib files that use the default convention will fail if you've changed the default convention. In 64-bit this is moot since it's all __fastcall.

On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...> wrote:
Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).


#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

--
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: link problem with Visual Studio 2012

Jeremy Selan <jeremy...@...>
 

Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).


#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

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


link problem with Visual Studio 2012

Paul Miller <pa...@...>
 

I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?


Re: OCIO Configuration Reference Values

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

On Tue, Oct 25, 2016 at 3:25 PM Malcolm Humphreys <malcolmh...@...> wrote:
The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2).


This strikes me as clean, sensible, and very viable in short term.

I also believe that this discussion could wander off into colour quackery and OCIO bloatification without keeping a guiding bit of design question in front of us. Namely:

Q: "What is the design problem we are seeking to solve?"

This is why I originally asked the question, and I can give a pretty clear answer:

A:"How to make user interface elements and algorithms perform and display colour correct and accurate output?"

If we take a simple HSV wheel, we can see that the values will not be aligned with the reference space without some problems. If we lay out the UI element, we could assume the values are in reference, scene referred, and roll it to the view chosen. The only problem with this is that the imager gets a particular transfer baked version of it, albeit properly transformed to the view from the reference in terms of chromaticities.

If an imager tries to flip to a linearized transfer version of HSV, or a log encoded transfer, or another particular transfer, etc., the problem becomes much more complex. I see the following problems:

*) How can we strip off the transfer function from a view and apply the image's desired transfer function to the UI element?
*) How can an application / OCIO deduce what is a transfer function versus any other transform so that an application can present a sane list of options for the transfer options?
*) How can an application apply a display correction to a view, after the above concerns? (IE Keep display corrections completely isolated from the view transform knot.)

Extending this to the views, or per set of views under a display, is a halfway solution to solving the UI element issue.

The transfer function problem isn't an easy one to solve, and as such I'd be interested to hear wise minds on how to tackle it with a shortest-path solution. I was thinking that the basis of the look modifiers on the views (+ and - to add or remove looks) could be useful to perhaps extend to transforms and get transfer function versus scene / display linear versions?

Malcolm's reference metadata certainly solves the algorithm-dependent problems immediately, and is not terribly invasive. It should likely also be *mandatory* that trunk forward versions of OCIO force this definition such that an application and lean on the metadata to be present. A *huge* plus one to see this land as soon as possible.

Thoughts?
TJS


Re: OCIO Configuration Reference Values

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

I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility.

Yes, this is exactly my concern and the reason why I joined the conversation. I quite like the minimalistic, almost agnostic approach of OCIO so far and if you introduce primaries, whitepoint, CAT support, the question of performing colour math is to be brought on the table. You might end up with some interesting issues to ensure consistency between your primaries, whitepoint, CAT specification and the matrices you define in the ColorMatrixTransform if no math is to be involved. We have been there with Colour and it has required a bit of work. Discrepancies might not be a big problem for OCIO, but it is something to be aware of.

Cheers,

Thomas


On Wed, Oct 26, 2016 at 3:15 PM Andy Jones <andy....@...> wrote:
(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now.
or instead
(b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields.

I like option A.

I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility.  Personally, I'd rather see OCIO remain an open-ended color transform framework that supports the kinds of metadata users need for interoperability with other color frameworks, but doesn't limit it to specific metadata tags, or specific interpretations of those tags.  That's not to say I'm against encouraging more robust color management, but I think OCIO should draw a line in the sand and stick to facilitating, rather than enforcing the use of colorimetric relationships, and only move that line forward very carefully--if at all.  Otherwise, it would be easy to end up simply duplicating the efforts of ICC and/or ACES.

I think the metadata structure in Malcolm's example is immediately useful in its own right, and that's pretty much what I was imagining.  I also think there is room for a global metadata structure, which could allow the config to define values like the "reference_chromaticities" in Malcolm's example, without having to add a new first class tag at the root.  The significance of a token being defined in a metadata map would simply be that OCIO itself will not interpret the data, but will make it available as-is.

Since the files are yaml-based, it might also be interesting to allow for the use of yaml anchors during parsing.  That would allow for explicit use of values defined as metadata elsewhere in the file. For example, you could de-reference the colorspace chromaticities, and the reference chromaticities in a "CATTransform" plugin without having to define them twice, and without relying on any behind-the-scenes metadata query, or brittle reliance on naming conventions for the metadata tags.

Lastly, although it wouldn't be required for adding arbitrary metadata tags, I do also support the idea of transform operator plugins and generalizing the API access for operator attributes as a longer term goal.  That seems like it just makes sense.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ocio-dev/1gAf2Xwlu1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: OCIO Configuration Reference Values

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

(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now.
or instead
(b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields.

I like option A.

I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility.  Personally, I'd rather see OCIO remain an open-ended color transform framework that supports the kinds of metadata users need for interoperability with other color frameworks, but doesn't limit it to specific metadata tags, or specific interpretations of those tags.  That's not to say I'm against encouraging more robust color management, but I think OCIO should draw a line in the sand and stick to facilitating, rather than enforcing the use of colorimetric relationships, and only move that line forward very carefully--if at all.  Otherwise, it would be easy to end up simply duplicating the efforts of ICC and/or ACES.

I think the metadata structure in Malcolm's example is immediately useful in its own right, and that's pretty much what I was imagining.  I also think there is room for a global metadata structure, which could allow the config to define values like the "reference_chromaticities" in Malcolm's example, without having to add a new first class tag at the root.  The significance of a token being defined in a metadata map would simply be that OCIO itself will not interpret the data, but will make it available as-is.

Since the files are yaml-based, it might also be interesting to allow for the use of yaml anchors during parsing.  That would allow for explicit use of values defined as metadata elsewhere in the file. For example, you could de-reference the colorspace chromaticities, and the reference chromaticities in a "CATTransform" plugin without having to define them twice, and without relying on any behind-the-scenes metadata query, or brittle reliance on naming conventions for the metadata tags.

Lastly, although it wouldn't be required for adding arbitrary metadata tags, I do also support the idea of transform operator plugins and generalizing the API access for operator attributes as a longer term goal.  That seems like it just makes sense.


Re: OCIO Configuration Reference Values

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

Hi,

Sorry I have been a bit busy getting up to speed with a job.

I have been musing some ideas with Robert Molholm about this separately and wanted to mention it to see what you think.

The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2).

Then add a CATTransform which can read this metadata.

I would also like to add a find colorspace by chromaticities to help support image files that have this metadata.

The main advantages to this are you have control on where chromaticities are used within the transform list per colorspace and it also allows you to have ColorSpaces with chromaticities metadata but are just extra descriptive data (so you don’t have to have messy flags to respect them or not).

For example it could look something like this in a profile:

reference_chromaticities:
red: [0.6400, 0.3300]
green: [0.2100, 0.7100]
blue: [0.1500, 0.0600]
white: [0.3127, 0.3290]

- !<ColorSpace>
name: AdobeRGB
bitdepth: 8ui
metadata:
chromaticties:
red: [0.6400, 0.3300]
green: [0.2100, 0.7100]
blue: [0.1500, 0.0600]
white: [0.3127, 0.3290]
luminance_max: [160]
luminance_min: [0.5557]
description: |
AdobeRGB blah
allocation: uniform
allocationvars: [-0.125, 1.125]
to_reference:
- !<ExponentTransform> {value: [2.2, 2.2, 2.2, 1]}
- !<CATTransform> {method: “bradford”}


Things I am still pondering are about the goal of having a plugin support in terms of what the api and format looks like. ie. to support plugins the Ops would need to be exposed and the Transform interface needs to be generalised so a plugin could expose it’s paramaters (ie. you wouldn’t have a explicit interface CDLTransform.setSlope(foo) vs Transform(“CDL”).set(“slope”, foo)).

If this was done to expose Op and Transform parameters it would make sense to do this for ColorSpace as well to make the api consistent.

That is not likely to happen anytime soon but it begs the question should chromaticties and luminance be either:

(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now.

or instead

(b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields.

.malcolm

On 25 Oct 2016, at 9:32 pm, Troy Sobotka <troy.s...@...> wrote:



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


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

701 - 720 of 2216