Date   

Re: Digest for oci...@googlegroups.com - 1 update in 1 topic

dbr/Ben <dbr....@...>
 

The reference role doesn't appear to be used anywhere inside OCIO itself. The choice of a reference space is just an choice when creating all your transforms. That said, it is a good idea to specify this role for people reading the config, and some applications "could" potentially use it (but setting it to something weird like "utility - raw" would work technically fine, it is only confusing)

The suggestions in that thread of "it's the first colorspace" is probably just because the example SPI config a happen to specify their "lnf" space first. However this is mistaken - there is nothing special about the first defined space.

I would suspect whoever created the ACES config misinterpreted the "reference" role as "what space to use for reference footage"

The meaning of the default roles are defined here:

http://opencolorio.org/userguide/config_syntax.html#roles

As you say, the reference role should be set to the main ACES space, as that is what the other spaces are defined relative to

These meanings should be a bit easier to find (e.g in the C++ API docs and Python bindings too) - made ticket for this,

On 17 Apr 2018, at 17:50, Abraham Schneider <abraham....@...> wrote:

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:
Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.

--
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: Digest for oci...@googlegroups.com - 1 update in 1 topic

Abraham Schneider <abraham....@...>
 

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:

Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.


Re: Digest for ocio...@googlegroups.com - 1 update in 1 topic

Blake Sloan <bsl...@...>
 

Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.


On Mon, Apr 16, 2018, 1:34 PM <ocio...@...> wrote:
Topic digest
View all topics
Abraham Schneider <abraham....@...>: Apr 16 12:38AM -0700

Hi there!
 
I just posted this question on the ACES
website: http://acescentral.com/t/why-utility-raw-as-reference-for-aces1-0-3-and-not-aces2065-1/1378
 
It seems like it's not just me that is unsure, how OCIO decides, which
colorspace in a config is used as the reference space, that all other
colorspaces are related to. And what excact purpose the 'reference' role
has.
 
Could you maybe have a look at this and shine some light on this topic?
 
 
Thanks, Abraham
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+u...@....


Which colorspace is used as the reference space for an OCIO config?

Abraham Schneider <abraham....@...>
 

Hi there!

I just posted this question on the ACES website: http://acescentral.com/t/why-utility-raw-as-reference-for-aces1-0-3-and-not-aces2065-1/1378

It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.

Could you maybe have a look at this and shine some light on this topic? 


Thanks, Abraham


Re: Converting Primaries

Breadbox <markel.j...@...>
 

Thank you all, after searching around I stumbled upon the site Sean mentioned and ended up using it. They were PCS-relative XYZ values for AdobeRGB in case anyone was wondering. Here's another site I also found that works for XY values. Not as sophisticated but it seems to work. 


On Monday, March 26, 2018 at 12:32:16 PM UTC-5, Sean Cooper wrote:

On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy...@...> wrote:
On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim....@...> wrote:

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Thanks so much for the check Jim!

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.


Re: Digest for ocio...@googlegroups.com - 6 updates in 2 topics

tony cole <ton...@...>
 

Hi,
This is likely a very old request.
I am charged with setting up a global config for a new startup.
I am basing the .ocio on aces1.0.3
I'm confused on how to customise profiles, looks etc ... I do not need half of the colourspaces, ie; dolby ...
Any advice from all of you would be greatly appreciated !
Thanks

On 27 March 2018 at 04:32, <ocio...@...> wrote:
Topic digest
View all topics
chris....@...: Mar 12 10:43AM -0700

Hi Sean,
 
Would you please add me as well?
 
chris....@...
 
Thanks!
-Chris Davies
Sean Cooper <se...@...>: Mar 26 06:34PM +0100

Luis, Chris added.
 
If someone could make a Slack invite bot that would be useful :)
 
Troy Sobotka <troy.s...@...>: Mar 26 02:23AM

Not sure if you got help here Markel.
 
I managed to craft up a spreadsheet that should work. Should being that it
hasn't been tested extensively and that you'll need to manually make your
OCIO stanzas from the provided entries. This isn't nearly as terrific as
Colour, but I realize not everyone has Python handy, and a sort of "online
calculator" probably couldn't hurt as I found myself doing the adaptation
frequently.
 
https://docs.google.com/spreadsheets/d/1qB1YVuQFTlAKeRLyQXtOJalbZQv3V1vRPXBywqIGV_o/edit?usp=sharing
 
I've input the values you gave along with ACES AP0 primaries. The chromatic
adaptation is the Bradford CAT. The OpenColorIO stanzas appear on the final
three lines. Those should be suitable to copypasta into a configuration as
part of a group transform. Note that your source buffer will need to be
linearized however appropriate for your encoded image.
 
Let me know if anyone spots a mistake.
 
With respect,
TJS
 
Jim Houston <jim.h...@...>: Mar 25 11:38PM -0700

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ. I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)
 
Jim
 
 
Troy Sobotka <troy.s...@...>: Mar 26 04:34PM

On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim.h...@...>
wrote:
 
> Transforms and they match conversion of the colorspace to XYZ. I did not
> check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include
> that.)
 
Thanks so much for the check Jim!
 
With respect,
TJS
Sean Cooper <se...@...>: Mar 26 06:32PM +0100

I'd also point you here:
http://colour-science.org/cgi-bin/rgb_colourspace_models_transformation_matrices.cgi
 
On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy.s...@...>
wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+unsubscribe@googlegroups.com.


Re: Slack invite

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

Luis, Chris added.

If someone could make a Slack invite bot that would be useful :)

On Mon, Mar 12, 2018 at 5:43 PM, <chris....@...> wrote:
Hi Sean,

Would you please add me as well?


Thanks!
-Chris Davies

--
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: Converting Primaries

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

On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim.h...@...> wrote:

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Thanks so much for the check Jim!

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: Converting Primaries

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

On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim.h...@...> wrote:

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Thanks so much for the check Jim!

With respect,
TJS


Re: Converting Primaries

Jim Houston <jim.h...@...>
 


I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Jim


On Mar 25, 2018, at 7:23 PM, Troy Sobotka <troy.s...@...> wrote:


Let me know if anyone spots a mistake.


Re: Converting Primaries

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

Not sure if you got help here Markel.

I managed to craft up a spreadsheet that should work. Should being that it hasn't been tested extensively and that you'll need to manually make your OCIO stanzas from the provided entries. This isn't nearly as terrific as Colour, but I realize not everyone has Python handy, and a sort of "online calculator" probably couldn't hurt as I found myself doing the adaptation frequently.


I've input the values you gave along with ACES AP0 primaries. The chromatic adaptation is the Bradford CAT. The OpenColorIO stanzas appear on the final three lines. Those should be suitable to copypasta into a configuration as part of a group transform. Note that your source buffer will need to be linearized however appropriate for your encoded image.

Let me know if anyone spots a mistake.

With respect,
TJS

On Wed, Mar 7, 2018 at 8:26 AM Troy Sobotka <troy.s...@...> wrote:
Convert the xy coordinates to XYZ, with red being the first column, then green, then blue. That forms a 3x3 matrix for taking linearized RGB to the XYZ domain.

From there you would need to perform a chromatic adaptation via Bradford or CAT02 to the AP1 or AP0 white point required.

The final matrix would be from XYZ, achromatic point aligned, to AP1 or AP0 RGB, which are well documented.

With respect,
TJS


On Wed, Mar 7, 2018, 8:20 AM Markel <markel.j...@...> wrote:
Hello,

I just wanted to know if you would be able to help me convert these primaries into the proper matrix for use with ACES? They would be for an input. 

r: 0.6484 0.3309

g: 0.2302 0.7016

b: 0.1559 0.0661

w: 0.3217 0.3291

Thank You

--
- Markel Gregory

--
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: Slack invite

chris....@...
 

Hi Sean,

Would you please add me as well?

 chris....@...

Thanks!
-Chris Davies


Re: Slack invite

Luis Barrancos <luis.b.b...@...>
 

Hi
I'd like to have access to the ocio slack channel as well.
Regards


Re: Slack invite

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

Sorry for the delay, Chris, Simon, Espen, Sean, and Remi I've sent the invite

On Fri, Mar 9, 2018 at 8:53 AM, <remia...@...> wrote:
Hello,

I'd like to join too : remia...@...

Thanks !

On Monday, December 18, 2017 at 5:08:56 PM UTC+1, Sean Wallitsch wrote:
Shi...@... too if you don't mind :)

Thanks!

On Sat, Dec 16, 2017 at 6:49 PM Chris Offner <chri...@...> wrote:
May I also request an invite?
chri...@...

Thank you! :)

--
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: Slack invite

remia...@...
 

Hello,

I'd like to join too : remia...@...

Thanks !


On Monday, December 18, 2017 at 5:08:56 PM UTC+1, Sean Wallitsch wrote:
Shi...@... too if you don't mind :)

Thanks!

On Sat, Dec 16, 2017 at 6:49 PM Chris Offner <chri...@...> wrote:
May I also request an invite?
chri...@...

Thank you! :)

--
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: Converting Primaries

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

Convert the xy coordinates to XYZ, with red being the first column, then green, then blue. That forms a 3x3 matrix for taking linearized RGB to the XYZ domain.

From there you would need to perform a chromatic adaptation via Bradford or CAT02 to the AP1 or AP0 white point required.

The final matrix would be from XYZ, achromatic point aligned, to AP1 or AP0 RGB, which are well documented.

With respect,
TJS


On Wed, Mar 7, 2018, 8:20 AM Markel <markel.j...@...> wrote:
Hello,

I just wanted to know if you would be able to help me convert these primaries into the proper matrix for use with ACES? They would be for an input. 

r: 0.6484 0.3309

g: 0.2302 0.7016

b: 0.1559 0.0661

w: 0.3217 0.3291

Thank You

--
- Markel Gregory

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


"pure virtual method called" crash when developing nuke OP plugin with OCIO

Yanli Zhao <yanli...@...>
 

Hi All,
I'm a new to both Nuke and OCIO. For some reason, I need to develop a nuke OP similar to OCIOFileTransform.  But when I add just one simple line such as "OCIO::GetCurrentConfig()", I got a crash with the terrible "Pure Virtual method called" error. I was wondering that maybe I was linking the wrong version of OCIO. Has anyone met with similar issues? I'm developing plugin for Nuke 10.0v5 with OCIO 1.0.9.

Apple


Pure Virtual Function crash when developing a nuke OP with OCIO / OpenColorIO API

Yanli Zhao <yanli...@...>
 

Hi,
For some reason, I need to write a pixelOp similar to OCIOFileTransform with OCIO API. But when I add just one simple line such as "OCIO::GetCurrentConfig()", I got a crash with the terrible "Pure Virtual Function" error. I was wondering that maybe I was linking the wrong version of OCIO. Has anyone met with similar issues? I'm developing plugin for Nuke 10.0v5 with OCIO 1.0.9 on Linux.

Apple


Support of the Java interface

Patrick Hodoul <patric...@...>
 

Hi all,

I would like to know if OCIO java public interface is used? and should be maintained ?

OCIO currently supports three public interfaces: 1) The native C++, 2) The Python interface (built on top of the C++ one), and 3) the Java one (built on top of of the C++ one)
It seems that Java interface is not so much used by tools. My 2 cents...
Any feedbacks ?

Regards,
Patrick.


Re: 1.1.0 Release

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

Version 1.1.0 has just been released and is located on the "RB-1.1" branch for long-term support.

Please continue to evaluate and we will release patches as necessary.

Thanks!

On Fri, Jan 12, 2018 at 1:47 PM, Richard Shaw <hobbe...@...> wrote:
Crap, never mind again...

Richard

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

481 - 500 of 2155