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