Date   

Re: Review: DisplayTransform interface update

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

I think that's a perfect description of all the terminology. I'm
thinking a glossary section (front page of webpage?, inside the FAQ?)
would be appropriate.

I'm thinking of naming the class that handles looks,
LookModificationTransform (LMT). This is the terminology the Academy
/ IIF is using, and it would be a nice fit to use the same terminology
inside OpenColorIO.

-- Jeremy

On Wed, Jan 26, 2011 at 11:01 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
I would think looks would be something separate from views.
Terminology we currently have:
- Transform - functions that transform RGBA data
- ReferenceSpace - a space that connects ColorSpaces
- ColorSpace - a meaningful space that can be transferred to and from the
reference space
- Display - a virtual or physical display device
- View - a meaningful view of the reference space on a Display
- Role - abstract colorspace naming
I would say a Look is a meaningful group of Transforms that can be applied
between the reference space and other transformations to create consistent
creative styles.
.malcolm
On 26/01/2011, at 12:00 PM, Joseph Slomka wrote:

Would the 'view' terminology  be able to encompass your concept of looks? Id
it does then I'm onboard
-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf
Of Jeremy Selan
Sent: Tuesday, January 25, 2011 4:54 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Oh, and have we agreed to use 'View' rather than 'Alias'?  I'm cool with
that...

-- Jeremy

On Tue, Jan 25, 2011 at 4:51 PM, Jeremy Selan <jeremy...@...>
wrote:

Would this syntax preserve Display order?  I think that's important.

-- Jeremy

displays:

  sRGB:

     -!<View> {name: Raw, colorspace: nc10}

     -!<View> {name: Log, colorspace: lg10}

     -!<View> {name: Film, colorspace: srgb8}

  DCIP3:

     -!<View> {name: Raw, colorspace: nc10}

     -!<View> {name: Log, colorspace: lg10}

     -!<View> {name: Film, colorspace: p3dci8}





Re: Review: DisplayTransform interface update

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

I would think looks would be something separate from views.

Terminology we currently have:
- Transform - functions that transform RGBA data
- ReferenceSpace - a space that connects ColorSpaces
- ColorSpace - a meaningful space that can be transferred to and from the reference space
- Display - a virtual or physical display device
- View - a meaningful view of the reference space on a Display
- Role - abstract colorspace naming

I would say a Look is a meaningful group of Transforms that can be applied between the reference space and other transformations to create consistent creative styles.

.malcolm

On 26/01/2011, at 12:00 PM, Joseph Slomka wrote:

Would the 'view' terminology  be able to encompass your concept of looks? Id it does then I'm onboard
-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Jeremy Selan
Sent: Tuesday, January 25, 2011 4:54 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Oh, and have we agreed to use 'View' rather than 'Alias'?  I'm cool with that...

-- Jeremy

On Tue, Jan 25, 2011 at 4:51 PM, Jeremy Selan <jeremy...@...> wrote:
Would this syntax preserve Display order?  I think that's important.

-- Jeremy

displays:
  sRGB:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: srgb8}
  DCIP3:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: p3dci8}





Re: Review: Replaced config->getRoleNameByIndex

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

Replaced config->getRoleNameByIndex() with config->getRoleName()
- getRoleNameByIndex returned the colorspace name not the role name, also ..ByIndex seemed redundant in the signature.

Added hasRole(role) convenience function

Commit:
https://github.com/malcolmhumphreys/OpenColorIO/commit/4825ef1c7d105378ef5ebd41609f5d3b49c2a6ac

.malcolm

On 19/01/2011, at 11:12 AM, Malcolm Humphreys wrote:


Thanks!

I like the intent, but have two minor issues:

First, the trivial: I'd prefer to never allow NULL values as return
types from const char * functions. Please use an empty string ""
instead.

The reason being, OCIO expects the client to copy the returned string
value, if the client intends to hang onto it. So it's often convenient
in your code to do a directly assign the function result to a
std::string,

std::string rolename = config->getRoleNameByIndex(i);

If the API promises to never return a NULL value, this will work
great. However, if OCIO can return a null pointer than the above code
will crash. Thus for all char * return functions the user would be
required to explicitly add a null check. This is probably counter to
user expectations, and I expect that a few would slip through and
result in occasionally crashy client code. (This would be likely
because most of the time it *would* work fine. Only on invalid
configurations, or other corner cases, would this sharp corner be run
into. I'd like to keep OCIO as friendly as reasonable.)

(See http://github.com/imageworks/OpenColorIO/issues#issue/20 for more
thoughts on this topic).
Sure that sounds great, i'll fix that.

The second issue is that you've exposed two helper functions
(getRoleColorSpaceName), that are not quite as helpful as they appear.
Is the client supposed to use these at runtime to determine which
colorspace to use for a given role?

Allow me to answer... "No!"

:)

ConstColorSpaceRcPtr getColorSpace(const char * name) const;
already does this in the 'correct' way, and this should be the *only*
allowed mechanism for getting a ColorSpace from a name. It
encapsulates a bit of extra mojo your new function does not, such as
looking at the 'strictParsing', and if allowed returning the DEFAULT
colorspace role in fall-through situations. It also resolves the
ambiguity where a role name and colorspace name overlap, and having
this resolution only defined in a single place seems preferable.

What if we renamed your functions to make it super clear that they are
not intended for color-space resolution, but instead as configuration
setup/ui purposes?

I.e.
setRole(const char * role, const char * colorSpaceName);
const char * getRoleName(int index);
const char * getRoleValue(int index);
I don't remind removing them altogether.

I was really just adding them to match the old functionality of getRoleNameByIndex() which returned the colorspace name not the role name, I wasn't sure if you were needing the colorspace name.

Calling getColorSpace(getRoleName(0)) seems nice an clean to me.

.malcolm

Even though the role 'value' is a colorspace name, I think the
function would be far less tempting for the naive API user to
accidentally call.

If we'd like a convenience function to do the resolution, we could add
const char * getColorSpaceName(const char * name) const;

which would internally rely on config::getColorSpace.

-- Jeremy

On Sun, Jan 16, 2011 at 8:22 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
When building some UI menus, I wanted to get a list of defined roles. Config::getRoleNameByIndex() only returned the resolved colorspace name.

--snip--
Replaced config->getRoleNameByIndex (which returned the colorspace name, not the role name) with the following:

- getRoleName(int): get the role name at index, this will return values like 'scene_linear', 'compositing_log'. Returns NULL if index is out of range

- getRoleColorSpaceName(int): get the actual colorspace name at role index. Returns NULL when index is out of range

- getRoleColorSpaceName(char*): get the actual colorspace name from a role name. Returns NULL if roles is not defined
--snip--

https://github.com/malcolmhumphreys/OpenColorIO/commit/d7c8094f6aad57f980060e87d0f547ff36d844b7

.malcolm


Re: Review: Python build warning fix

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

LGTM

On 27/01/2011, at 2:36 PM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/d37b316cd8354216b4d89b85c06ab08108b5d1cc

A pretty trivial change, include python.h first when building pyglue.

Some linux installations are adamant about including python.h first,
or you get warnings about duplicate #DEFINES for _POSIX_C_SOURCE,
_XOPEN_SOURCE, etc. This cleans it up.

-- Jeremy


Review: Python build warning fix

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

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/d37b316cd8354216b4d89b85c06ab08108b5d1cc

A pretty trivial change, include python.h first when building pyglue.

Some linux installations are adamant about including python.h first,
or you get warnings about duplicate #DEFINES for _POSIX_C_SOURCE,
_XOPEN_SOURCE, etc. This cleans it up.

-- Jeremy


Re: Review: DisplayTransform interface update

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

Cool, no pressure just wanted to know if this was the direction we were thinking of going.

.malcolm

On 27/01/2011, at 11:21 AM, Jeremy Selan wrote:

Yes, I like it. Just haven't had a chance to update the code and
re-submit yet. Sorry...

-- Jeremy

On Wed, Jan 26, 2011 at 4:08 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Did you have any thoughts on this?

On 26/01/2011, at 12:12 PM, Malcolm Humphreys wrote:


I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to check to see if a display is supported by default and creating one if it is not.
Could this not be part of the API? the core could just keep around the list that was in the profile as the default list and then the active would either be a copy of this or what was ever dynamically set.

Looking a little more closely I don't understand the need to have multiple defaults in the active_views
active_views: [Film, Log, Raw]
Unless you want to explictly exclude a defined view as a default.
This might answer jeremy's questions as well.

I was thinking the order is important in active_displays and active_views.

I guess the use case for all this is:

Say we have 3 groups of machines.
group1: dual sRGB heads
group2: sRGB and one Dreamcolor (DCI-P3 emulation) heads
group3: sRGB and a DCI projector head

In the profile it would be nice to model that you want both sRGB and Dream as the visible displays (say in the nuke node) if you load the profile directly with sRGB being the default. eg. active_displays: [sRGB, Dream]

For group2 you would might want the Dream display to be the default so you could set the environment var $OCIO_ACTIVE_DISPLAYS = Dream,sRGB

And the same for group3, $OCIO_ACTIVE_DISPLAYS = DCI,sRGB (and the Dream display would not be visible)

The active_views would be identify the default as the first item and then the order the api would return them in. This would work similarly in being able to override the order for different machines.


....
I gota run guys to Australian Day celebrations.

Happy Australia Day everyone! (get a beer into you)

.malcolm


-Joseph


-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:49 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On
Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where
not all aliases are defined for all devices, or there are
OCIO_DEVICE_MASK specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297
e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively
use the public OCIO for all upcoming productions.

-- Jeremy



Re: Review: DisplayTransform interface update

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

Yes, I like it. Just haven't had a chance to update the code and
re-submit yet. Sorry...

-- Jeremy

On Wed, Jan 26, 2011 at 4:08 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Did you have any thoughts on this?

On 26/01/2011, at 12:12 PM, Malcolm Humphreys wrote:


I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to check to see if a display is supported by default and creating one if it is not.
Could this not be part of the API? the core could just keep around the list that was in the profile as the default list and then the active would either be a copy of this or what was ever dynamically set.

Looking a little more closely I don't understand the need to have multiple defaults in the active_views
active_views: [Film, Log, Raw]
Unless you want to explictly exclude a defined view as a default.
This might answer jeremy's questions as well.

I was thinking the order is important in active_displays and active_views.

I guess the use case for all this is:

Say we have 3 groups of machines.
group1:  dual sRGB heads
group2:  sRGB and one Dreamcolor (DCI-P3 emulation) heads
group3:  sRGB and a DCI projector head

In the profile it would be nice to model that you want both sRGB and Dream as the visible displays (say in the nuke node) if you load the profile directly with sRGB being the default. eg. active_displays: [sRGB, Dream]

For group2 you would might want the Dream display to be the default so you could set the environment var $OCIO_ACTIVE_DISPLAYS = Dream,sRGB

And the same for group3, $OCIO_ACTIVE_DISPLAYS = DCI,sRGB (and the Dream display would not be visible)

The active_views would be identify the default as the first item and then the order the api would return them in. This would work similarly in being able to override the order for different machines.


....
I gota run guys to Australian Day celebrations.

Happy Australia Day everyone! (get a beer into you)

.malcolm


-Joseph


-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:49 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important  given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On
Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
   -!<View> {name: Raw, colorspace: nc10}
   -!<View> {name: Log, colorspace: lg10}
   -!<View> {name: Film, colorspace: srgb8}
DCIP3:
   -!<View> {name: Raw, colorspace: nc10}
   -!<View> {name: Log, colorspace: lg10}
   -!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where
not all aliases are defined for all devices, or there are
OCIO_DEVICE_MASK specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297
e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated.    What previous
was 'TransformName' is now called a 'DisplayAlias',  to minimize
confusion with new users.  (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading).  A new
environment variable is available, $OCIO_DEVICE_MASK,  which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries,  device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively
use the public OCIO for all upcoming productions.

-- Jeremy



Re: Review: DisplayTransform interface update

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

Did you have any thoughts on this?

On 26/01/2011, at 12:12 PM, Malcolm Humphreys wrote:


I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to check to see if a display is supported by default and creating one if it is not.
Could this not be part of the API? the core could just keep around the list that was in the profile as the default list and then the active would either be a copy of this or what was ever dynamically set.

Looking a little more closely I don't understand the need to have multiple defaults in the active_views
active_views: [Film, Log, Raw]
Unless you want to explictly exclude a defined view as a default.
This might answer jeremy's questions as well.

I was thinking the order is important in active_displays and active_views.

I guess the use case for all this is:

Say we have 3 groups of machines.
group1: dual sRGB heads
group2: sRGB and one Dreamcolor (DCI-P3 emulation) heads
group3: sRGB and a DCI projector head

In the profile it would be nice to model that you want both sRGB and Dream as the visible displays (say in the nuke node) if you load the profile directly with sRGB being the default. eg. active_displays: [sRGB, Dream]

For group2 you would might want the Dream display to be the default so you could set the environment var $OCIO_ACTIVE_DISPLAYS = Dream,sRGB

And the same for group3, $OCIO_ACTIVE_DISPLAYS = DCI,sRGB (and the Dream display would not be visible)

The active_views would be identify the default as the first item and then the order the api would return them in. This would work similarly in being able to override the order for different machines.


....
I gota run guys to Australian Day celebrations.

Happy Australia Day everyone! (get a beer into you)

.malcolm


-Joseph


-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:49 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On
Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where
not all aliases are defined for all devices, or there are
OCIO_DEVICE_MASK specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297
e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively
use the public OCIO for all upcoming productions.

-- Jeremy



Re: Review: DisplayTransform interface update

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

I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to check to see if a display is supported by default and creating one if it is not.
Could this not be part of the API? the core could just keep around the list that was in the profile as the default list and then the active would either be a copy of this or what was ever dynamically set.

Looking a little more closely I don't understand the need to have multiple defaults in the active_views
active_views: [Film, Log, Raw]
Unless you want to explictly exclude a defined view as a default.
This might answer jeremy's questions as well.

I was thinking the order is important in active_displays and active_views.

I guess the use case for all this is:

Say we have 3 groups of machines.
group1: dual sRGB heads
group2: sRGB and one Dreamcolor (DCI-P3 emulation) heads
group3: sRGB and a DCI projector head

In the profile it would be nice to model that you want both sRGB and Dream as the visible displays (say in the nuke node) if you load the profile directly with sRGB being the default. eg. active_displays: [sRGB, Dream]

For group2 you would might want the Dream display to be the default so you could set the environment var $OCIO_ACTIVE_DISPLAYS = Dream,sRGB

And the same for group3, $OCIO_ACTIVE_DISPLAYS = DCI,sRGB (and the Dream display would not be visible)

The active_views would be identify the default as the first item and then the order the api would return them in. This would work similarly in being able to override the order for different machines.


....
I gota run guys to Australian Day celebrations.

Happy Australia Day everyone! (get a beer into you)

.malcolm


-Joseph


-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:49 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On
Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where
not all aliases are defined for all devices, or there are
OCIO_DEVICE_MASK specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297
e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively
use the public OCIO for all upcoming productions.

-- Jeremy



Re: Review: DisplayTransform interface update

Joseph Slomka <jsl...@...>
 

Would the 'view' terminology be able to encompass your concept of looks? Id it does then I'm onboard
-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Jeremy Selan
Sent: Tuesday, January 25, 2011 4:54 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Oh, and have we agreed to use 'View' rather than 'Alias'? I'm cool with that...

-- Jeremy

On Tue, Jan 25, 2011 at 4:51 PM, Jeremy Selan <jeremy...@...> wrote:
Would this syntax preserve Display order?  I think that's important.

-- Jeremy

displays:
  sRGB:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: srgb8}
  DCIP3:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: p3dci8}


Re: Review: DisplayTransform interface update

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

Oh, and have we agreed to use 'View' rather than 'Alias'? I'm cool with that...

-- Jeremy

On Tue, Jan 25, 2011 at 4:51 PM, Jeremy Selan <jeremy...@...> wrote:
Would this syntax preserve Display order?  I think that's important.

-- Jeremy

displays:
  sRGB:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: srgb8}
  DCIP3:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: p3dci8}


Re: Review: DisplayTransform interface update

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

Would this syntax preserve Display order? I think that's important.

-- Jeremy

displays:
  sRGB:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: srgb8}
  DCIP3:
     -!<View> {name: Raw, colorspace: nc10}
     -!<View> {name: Log, colorspace: lg10}
     -!<View> {name: Film, colorspace: p3dci8}


Re: Review: DisplayTransform interface update

Joseph Slomka <jsl...@...>
 

Malcom,

I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to check to see if a display is supported by default and creating one if it is not.

Looking a little more closely I don't understand the need to have multiple defaults in the active_views
active_views: [Film, Log, Raw]
Unless you want to explictly exclude a defined view as a default.

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:49 PM
To: ocio...@...
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On
Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where
not all aliases are defined for all devices, or there are
OCIO_DEVICE_MASK specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297
e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively
use the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: DisplayTransform interface update

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

Hi Joesph,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called $OCIO_DEVICE_MASK).

.malcolm

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where not
all aliases are defined for all devices, or there are OCIO_DEVICE_MASK
specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively use
the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: DisplayTransform interface update

Joseph Slomka <jsl...@...>
 

Malcom,

I like your layout. I think that calling the

active_displays: [sRGB, DCIP3] # or active_devices:
default_displays:[sRGB, DCIP3]
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think that this can be important given the ability to dynamically generate colorspaces and display devices.


-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Tuesday, January 25, 2011 3:23 PM
To: OpenColorIO Developers
Subject: Re: [ocio-dev] Review: DisplayTransform interface update

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where not
all aliases are defined for all devices, or there are OCIO_DEVICE_MASK
specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297e
d0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing to do
with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices.
The config format has been updated to reflect these modified names.
Also available are two new entries, device_defaults +
alias_defaults which allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively use
the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: DisplayTransform interface update

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

Hi,

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.
Ok thats a bit clearer. But I think having this as a flat list is not so nice.

After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of displays and a set of views on each of them.

displays:
sRGB:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: srgb8}
DCIP3:
-!<View> {name: Raw, colorspace: nc10}
-!<View> {name: Log, colorspace: lg10}
-!<View> {name: Film, colorspace: p3dci8}
active_displays: [sRGB, DCIP3] # or active_devices:
active_views: [Film, Log, Raw]

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where not
all aliases are defined for all devices, or there are OCIO_DEVICE_MASK
specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).
I think this is great!

.malcolm

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated. What previous
was 'TransformName' is now called a 'DisplayAlias', to minimize
confusion with new users. (The old Transforms has nothing
to do with OCIO::Transform, so this name was misleading). A new
environment variable is available, $OCIO_DEVICE_MASK, which allows
for optional runtime speicification of connected display devices. The
config format has been updated to reflect these modified names. Also
available are two new entries, device_defaults + alias_defaults which
allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively use
the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: DisplayTransform interface update

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

Here's a chunk from spi-vfx with the new options:

displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display> {device: sRGB, alias: Film, colorspace: srgb8}
- !<Display> {device: DCIP3, alias: Raw, colorspace: nc10}
- !<Display> {device: DCIP3, alias: Log, colorspace: lg10}
- !<Display> {device: DCIP3, alias: Film, colorspace: p3dci8}
device_defaults: [sRGB, DCIP3]
alias_defaults: [Film, Log, Raw]

I feel that the term 'alias' is simpler to understand, but then again
I wrote it so if you have a better term I'm open to ideas.

You'll see that the default value is also explicitly specified now.
Under common circumstances, only the 1st value will be returned as
default, but a full search order is allowed for corner cases where not
all aliases are defined for all devices, or there are OCIO_DEVICE_MASK
specified that disallow particular device options.

The idea behind OCIO_DEVICE_MASK is that your config will contain the
master list of all devices in use on a show, but still allow the
flexibility (through the use of envvars) to control which an end user
sees. This allows for example, a facility to roll out code to make
sure the user only has the "sRGB" option on desktop machines. (Which
DLP connected machines may have all the options: sRGB, DCIP3, etc).

-- Jeremy

On Sat, Jan 22, 2011 at 9:40 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi,

Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as terminology in this context.

eg, We have a mixture displays of different make and models and each of these I would call a device (we do group these into manageable sets and calibrate them to an 'ideal' device). I keep wanting to call these a 'target' or 'target-device'.

But I feel like I'm maybe missing something so an example would be good.

.malcolm

On 21/01/2011, at 10:01 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452

Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenColorIO/issues#issue/21
https://github.com/imageworks/OpenColorIO/issues#issue/22

The API to get/set display devices has been updated.    What previous
was 'TransformName' is now called a 'DisplayAlias',  to minimize
confusion with new users.  (The old Transforms has nothing
to do with OCIO::Transform, so this name was misleading).  A new
environment variable is available, $OCIO_DEVICE_MASK,  which allows
for optional runtime speicification of connected display devices. The
config format has been updated to reflect these modified names.  Also
available are two new entries,  device_defaults + alias_defaults which
allow for a specification of defaults for devices and alises.

This breaks compatibility with both the API and the .config format.

FYI, Pretty soon we hope to have a stable branch locked off!
We're going to be switching Imageworks this month to exclusively use
the public OCIO for all upcoming productions.

-- Jeremy


Re: Review: FileTransform supports .cc and .ccc files

"dbr/Ben" <b...@...>
 

On 23/01/2011, at 4:41 AM, Jeremy Selan wrote:
But... what if
we added a button that when pressed provided a popup for the user?
(Calling out to OCIO to enumerate the options).  That would make it
convenient + keep data value 'native'.

This sounds like a good solution, much less error prone than storing the dropdown in the node itself.

The J_3Way node (http://major-kong.blogspot.com/2010/01/jops-10v1a5-released.html ) has a nice UI to load a grade from a .ccc file - when you click the "Import" button, you get a dialog with a drop-down of all the ID's, and it shows a preview of the values, and the description:


Something like this would be simple to do. Could allow an arbitrary string input with a "<Custom>" item in the drop-down, which reveals a string input knob.


Re: Review: FileTransform supports .cc and .ccc files

"dbr/Ben" <b...@...>
 


On 23/01/2011, at 4:39 PM, Malcolm Humphreys wrote:

It would be great to restructure this a bit so the idea of contexts being part of the viewing transforms comes through.

Good point. I've renamed the first section "A contrived example", which just explains using env-vars to find a LUT. The second example is more practical, and applies the grade, then a lin-to-log/3D LUT.


The final one is incomplete, but (attempts to) explains the balance/creative grade workflow. Not sure how to configure the graded linear space. e.g for the steps

- Raw log .dpx
- lg10 to lnh
- Apply "working" balance grade
- Comp
- Reverse balance grade
- Beauty grade
- lnh -> lg10
- lg10 to sRGB

..you could add a lnh_graded space:

- !<ColorSpace>
  name: lnh_graded
  family: ln
  bitdepth: 16f
  from_reference: !<FileTransform> {src: balance_grades.ccc, cccid: "${SHOT}"}

Then if you transform from lg10 to lnh_graded, it would apply the lg10->lnh, and lnh->graded

Does this sound reasonable?


Re: Review: FileTransform supports .cc and .ccc files

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

Hi Ben,

Started writing a "contexts" page for the docs. Does this explanation match with how you intended them to work?


I love docs :) (because of my horrible memory)

My main comments would be I would tend to aim 'contexts' being used as part of the complete viewing transform. Right now it reads as though we recommend having viewing 1D/3D luts per shot / context which I don't think is the case.

It would be great to restructure this a bit so the idea of contexts being part of the viewing transforms comes through.

eg a typical setup could be (order depending on the production requirements)

scene-linear
    `- balance grade .cc or .ccc (Context Controlled)
        `- creative grade .cc, .ccc or .spi1d (Context Controlled)
            `- toLog1d
                `- LogtoDevice3d

.malcolm

1801 - 1820 of 2209