Date   

Re: XML Profile Format

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

I'm completely in favor of making the OCIO configuration files easier
to read and edit.

I have a few specific concerns about YAML, but it's definitely worth
exploring. Care to take a stab at it?
Ok lets jump in :)

In defense of XML ...

* It's the 'no format decision' decision. Support is ubiquitous, and
no one ever wonders, "what the hell is this?" YAML is not nearly as
widely known. Never having looked at YAML before, when I first looked
at your configuration file I was wondering which formatting parts were
important. But this could be made more obvious with a few tweaks to
the outputter format.
There are a few good articles on the subject of choosing XML 'just because', these two I like.

http://www.ibm.com/developerworks/library/x-sbxml.html
http://www.ibm.com/developerworks/xml/library/x-matters23.html

I think XML is a great fit for a lot of things and I would still choose it for these but it's used a
little too much 'just because'.

* We've already got the XML code working.
True, but it feels a bit ridged and requires a lot of code to do relatively simple serialisation. I find
this is inherently part of using xml, and is nothing different from anywhere else I have used it or
seen it used.

Looking at it, the current serialisation boils down to dumping Config::Impl to disk
http://github.com/imageworks/OpenColorIO/blob/master/src/core/Config.cpp (line: 136)

Config::Impl consists of:
- a few std::string's
- RGB float array
- prefixed list of roles
- unordered vector of display devices.
- unordered vector of colorspaces

Config::writeXML (line: 761) and Config::Impl::loadXmlElement (line: 836) do most of the heavy
lifting in terms of overall XML structure.
(Looking at this now there is a bit too much knowledge about <display>'s which we might want
to refactor into a clearer core concept.)

ParseUtils.cpp does most of the string -> ocio data type glue while XmlIO.cpp takes care of all
the logic and structure for every Transform() type.

See below I have attached a yaml-cpp demo for doing the same thing.

* The ASC CDL defines an xml spec which I would like to support (for
interoperability with other CDL apps), so we're not going to be be
able to ditch tinyxml.
I don't think this should change.

But If we were going to have a way to support OCIO Transform() plugins (at compile time or run
time). I think it would be important for each Transform() to know how to seialize themselves.

This means tinyxml would become only a build dependency for the CDL Transform() plugin and
not the entire core.

* This may not be wise in the long term, but I really like how OCIO
has minimal external build dependencies. (Some day when the windows
port needs to be attacked, this should keep life simple I hope!)
Does OSX have YAML as part of its base installation? Do normal linux
distros? (I assume Windows doesnt) Is there a minimal yaml
implementation we could pull internal, similar in spirit to tinyxml?
If so (assuming it can be namespaced properly, and the licence terms
are suitable) I'd love to keep it internal.
Agreed, this should all be internal to OCIO.

Both http://code.google.com/p/yaml-cpp and http://pyyaml.org/wiki/LibYAML are MIT Licensed
(http://en.wikipedia.org/wiki/MIT_License). It's pretty open licence you just need to include a
named reference and MIT licence with OCIO.

I have never used the LibYAML but I do like the stream / state based style yaml-cpp has
chosen. http://code.google.com/p/yaml-cpp/wiki/HowToEmitYAML

yaml-cpp is namespaced with YAML:: and I consider it to be pretty small lib.

--snip stlemitter.h--
namespace YAML
{
template <typename T>
inline Emitter& operator << (Emitter& emitter, const std::vector <T>& v) {
typedef typename std::vector <T> vec;
emitter << BeginSeq;
for(typename vec::const_iterator it=v.begin();it!=v.end();++it)
emitter << *it;
emitter << EndSeq;
return emitter;
}
...
--snip stlemitter.h--

I'm not sure that yaml's strong python support is relevant to this
discussion. OCIO serialization is handled on the C++ side, and the
python bindings provide typed interfaces to the transforms. (I.e., a
CDLTransform is a native python class as opposed to a python dict with
particular key value pairs). And, I would prefer that folks
manipulating OCIO profiles in python use the native OCIO API rather
than mucking with the serialized representations. Or is there another
use case I'm missing?
Sure its just an easy way to prototype the yaml, like you said this should all be internal to OCIO.
I don't think you will be able to stop people from mucking with the XML directly in python either.

Attached is a quick yaml-cpp demo which setups a similar structure to configs/testing/config.ocio
then serializes it to YAML, parses that YAML into a new config and checks some of the
data.


Also, in terms of overall development priorities I wouldn't personally
put this at the top of my list. (I was much more excited about your
adding Houdini lut support, for example). But I can see that making
the format less daunting could be a selling point adoption.
I see the profiles as the key concept that makes OCIO interesting. All the other parts are important
on the implementation side of things, but the day to day interaction will be all about the profiles.

As long as the profiles are clear and easily extendable I think we will be in a good place.

.malcolm

-- Jeremy

On Tue, Oct 5, 2010 at 6:43 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Are people super into the idea of using xml?

We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things.

One of the developers introduced the use of YAML (http://www.yaml.org/ http://en.wikipedia.org/wiki/YAML) and it
took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much
everything was XML). RV has started to use it for it's package descriptions as well.

As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand
writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format
then maybe.

btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are
into the idea I'm happy to do the leg work to get it to work.

I have attached a small demo python script for you to check out, it mostly shows off how to define your own
custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo.

Why I like it:
- super simple to parse and serialise objects
- human readable / editable
- easy to define your own custom types
- using yaml in python is so simple

It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file.
http://en.wikipedia.org/wiki/YAML#Other_specified_data_types
--snip--
picture: !!binary |
R0lGODlhDAAMAIQAAP//9/X
17unp5WZmZgAAAOfn515eXv
Pz7Y6OjuDg4J+fn5OTk6enp
56enmleECcgggoBADs=mZmE
--snip--

http://www.yaml.org/spec/1.2/spec.html#id2759572 - Relation to JSON
http://www.yaml.org/spec/1.2/spec.html#id2759732 - Relation to XML

YAML
--snip--
ocs_profile_version: 1
resource_path: luts
luma_b: '0.0722'
luma_g: '0.7152'
luma_r: '0.2126'
role_compositing_log: lgh
role_scene_linear: lnh
strictparsing: true
displays:
Film1D: !Display {colorspace: vd8, device: sRGB}
Log: !Display {colorspace: lg10, device: sRGB}
colorspaces:
dt8: !ColorSpace
bitdepth: 8ui
description: null
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: null, src: diffusemult.spimtx}
- !ColorSpaceTransform {dst: lnh, src: vd8}
lg10: !ColorSpace
bitdepth: 10ui
description: lg10 converts from scanned film to the show linear reference space.
This is a custom conversion based on several Kodak acquisition stocks. All three
color channels have the same response and there is no cross talk. This transform
has a shoulder and toe compensation. This 10bit uiint version is used for DI
deliveries.
family: lg
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
lnh: !ColorSpace
bitdepth: 16f
description: The show reference space. This is a sensor referred linear representation
of the scene with primaries that correspond to scanned film. 0.18 inthis space
corresponds to a properly exposed 18% grey card.
family: ln
gpuallocation: lg2
gpumax: 6
gpumin: -15
isdata: false
to_reference: null
vd8: !ColorSpace
bitdepth: 8ui
description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference
colorspace. This is a 1-d representation does not include any subtractive color
mixing or crosstalk compensation. This is commonly used to interchange files
between internal and external vendors. This is used as the interchange space
for final images on direct to video or television products.
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: linear, src: vd10.spi1d}
--snip--

XML
--snip--
<ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh">
<display device="sRGB" name="Film1D" colorspace="vd8"/>
<display device="sRGB" name="Log" colorspace="lg10"/>
<colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6">
<description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description>
</colorspace>
<colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description>
<to_reference>
<group>
<file src="lg10.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615">
<description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description>
<to_reference>
<group>
<file src="vd10.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description> </description>
<to_reference>
<group>
<file src="diffusemult.spimtx"/>
<colorspacetransform src="vd8" dst="lnh"/>
</group>
</to_reference>
</colorspace>
</ocioconfig>
--snip--




.malcolm


Review: ExponentTransform can serialize itself

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

The ExponentTransform (a publicly exposed class for doing power /
gamma operations) previously could not serialize itself to xml. This
commit adds the feature.

Repo:
http://github.com/jeremyselan/OpenColorIO

Commits:
4581f2e0725466c43cc6237d93d356a4a28bfa3e

-- Jeremy


Re: XML Profile Format

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

Sorry I will be responding to this soon, bit busy for the next 3 days.

.malcolm

On 09/10/2010, at 9:35 AM, bsloan wrote:

http://code.google.com/p/yaml-cpp/

...is the compiled yaml io library. I believe yaml support is built
into the python distro.



-blake

On Oct 7, 2:26 pm, Jeremy Selan <jeremy...@...> wrote:
I'm completely in favor of making the OCIO configuration files easier
to read and edit.

I have a few specific concerns about YAML, but it's definitely worth
exploring. Care to take a stab at it?

In defense of XML ...

* It's the 'no format decision' decision. Support is ubiquitous, and
no one ever wonders, "what the hell is this?" YAML is not nearly as
widely known. Never having looked at YAML before, when I first looked
at your configuration file I was wondering which formatting parts were
important. But this could be made more obvious with a few tweaks to
the outputter format.

* We've already got the XML code working.

* The ASC CDL defines an xml spec which I would like to support (for
interoperability with other CDL apps), so we're not going to be be
able to ditch tinyxml.

* This may not be wise in the long term, but I really like how OCIO
has minimal external build dependencies. (Some day when the windows
port needs to be attacked, this should keep life simple I hope!)
Does OSX have YAML as part of its base installation? Do normal linux
distros? (I assume Windows doesnt) Is there a minimal yaml
implementation we could pull internal, similar in spirit to tinyxml?
If so (assuming it can be namespaced properly, and the licence terms
are suitable) I'd love to keep it internal.

I'm not sure that yaml's strong python support is relevant to this
discussion. OCIO serialization is handled on the C++ side, and the
python bindings provide typed interfaces to the transforms. (I.e., a
CDLTransform is a native python class as opposed to a python dict with
particular key value pairs). And, I would prefer that folks
manipulating OCIO profiles in python use the native OCIO API rather
than mucking with the serialized representations. Or is there another
use case I'm missing?

Also, in terms of overall development priorities I wouldn't personally
put this at the top of my list. (I was much more excited about your
adding Houdini lut support, for example). But I can see that making
the format less daunting could be a selling point adoption.

-- Jeremy

On Tue, Oct 5, 2010 at 6:43 PM, Malcolm Humphreys

<malcolmh...@...> wrote:
Are people super into the idea of using xml?
We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things.
One of the developers introduced the use of YAML (http://www.yaml.org/ http://en.wikipedia.org/wiki/YAML) and it
took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much
everything was XML). RV has started to use it for it's package descriptions as well.
As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand
writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format
then maybe.
btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are
into the idea I'm happy to do the leg work to get it to work.
I have attached a small demo python script for you to check out, it mostly shows off how to define your own
custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo.
Why I like it:
- super simple to parse and serialise objects
- human readable / editable
- easy to define your own custom types
- using yaml in python is so simple
It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file.
http://en.wikipedia.org/wiki/YAML#Other_specified_data_types
--snip--
picture: !!binary |
R0lGODlhDAAMAIQAAP//9/X
17unp5WZmZgAAAOfn515eXv
Pz7Y6OjuDg4J+fn5OTk6enp
56enmleECcgggoBADs=mZmE
--snip--
http://www.yaml.org/spec/1.2/spec.html#id2759572- Relation to JSON
http://www.yaml.org/spec/1.2/spec.html#id2759732- Relation to XML
YAML
--snip--
ocs_profile_version: 1
resource_path: luts
luma_b: '0.0722'
luma_g: '0.7152'
luma_r: '0.2126'
role_compositing_log: lgh
role_scene_linear: lnh
strictparsing: true
displays:
Film1D: !Display {colorspace: vd8, device: sRGB}
Log: !Display {colorspace: lg10, device: sRGB}
colorspaces:
dt8: !ColorSpace
bitdepth: 8ui
description: null
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: null, src: diffusemult.spimtx}
- !ColorSpaceTransform {dst: lnh, src: vd8}
lg10: !ColorSpace
bitdepth: 10ui
description: lg10 converts from scanned film to the show linear reference space.
This is a custom conversion based on several Kodak acquisition stocks. All three
color channels have the same response and there is no cross talk. This transform
has a shoulder and toe compensation. This 10bit uiint version is used for DI
deliveries.
family: lg
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
lnh: !ColorSpace
bitdepth: 16f
description: The show reference space. This is a sensor referred linear representation
of the scene with primaries that correspond to scanned film. 0.18 inthis space
corresponds to a properly exposed 18% grey card.
family: ln
gpuallocation: lg2
gpumax: 6
gpumin: -15
isdata: false
to_reference: null
vd8: !ColorSpace
bitdepth: 8ui
description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference
colorspace. This is a 1-d representation does not include any subtractive color
mixing or crosstalk compensation. This is commonly used to interchange files
between internal and external vendors. This is used as the interchange space
for final images on direct to video or television products.
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: linear, src: vd10.spi1d}
--snip--
XML
--snip--
<ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh">
<display device="sRGB" name="Film1D" colorspace="vd8"/>
<display device="sRGB" name="Log" colorspace="lg10"/>
<colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6">
<description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description>
</colorspace>
<colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description>
<to_reference>
<group>
<file src="lg10.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615">
<description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description>
<to_reference>
<group>
<file src="vd10.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description> </description>
<to_reference>
...

read more »


Re: XML Profile Format

bsloan <bsl...@...>
 

http://code.google.com/p/yaml-cpp/

...is the compiled yaml io library. I believe yaml support is built
into the python distro.



-blake

On Oct 7, 2:26 pm, Jeremy Selan <jeremy...@...> wrote:
I'm completely in favor of making the OCIO configuration files easier
to read and edit.

I have a few specific concerns about YAML, but it's definitely worth
exploring.  Care to take a stab at it?

In defense of XML ...

* It's the 'no format decision' decision. Support is ubiquitous, and
no one ever wonders, "what the hell is this?"  YAML is not nearly as
widely known. Never having looked at YAML before, when I first looked
at your configuration file I was wondering which formatting parts were
important.   But this could be made more obvious with a few tweaks to
the outputter format.

* We've already got the XML code working.

* The ASC CDL defines an xml spec which I would like to support (for
interoperability with other CDL apps),  so we're not going to be be
able to ditch tinyxml.

* This may not be wise in the long term, but I really like how OCIO
has minimal external build dependencies.  (Some day when the windows
port needs to be attacked, this should keep life simple I hope!)
Does OSX have YAML as part of its base installation? Do normal linux
distros?  (I assume Windows doesnt)  Is there a minimal yaml
implementation we could pull internal, similar in spirit to tinyxml?
If so (assuming it can be namespaced properly, and the licence terms
are suitable) I'd love to keep it internal.

I'm not sure that yaml's strong python support is relevant to this
discussion. OCIO serialization is handled on the C++ side, and the
python bindings provide typed interfaces to the transforms.  (I.e., a
CDLTransform is a native python class as opposed to a python dict with
particular key value pairs).   And, I would prefer that folks
manipulating OCIO profiles in python use the native OCIO API rather
than mucking with the serialized representations.  Or is there another
use case I'm missing?

Also, in terms of overall development priorities I wouldn't personally
put this at the top of my list. (I was much more excited about your
adding Houdini lut support, for example). But I can see that making
the format less daunting could be a selling point adoption.

-- Jeremy

On Tue, Oct 5, 2010 at 6:43 PM, Malcolm Humphreys

<malcolmh...@...> wrote:
Are people super into the idea of using xml?
We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things.
One of the developers introduced the use of YAML (http://www.yaml.org/ http://en.wikipedia.org/wiki/YAML) and it
took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much
everything was XML). RV has started to use it for it's package descriptions as well.
As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand
writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format
then maybe.
btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are
into the idea I'm happy to do the leg work to get it to work.
I have attached a small demo python script for you to check out, it mostly shows off how to define your own
custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo.
Why I like it:
- super simple to parse and serialise objects
- human readable / editable
- easy to define your own custom types
- using yaml in python is so simple
It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file.
http://en.wikipedia.org/wiki/YAML#Other_specified_data_types
--snip--
picture: !!binary |
 R0lGODlhDAAMAIQAAP//9/X
 17unp5WZmZgAAAOfn515eXv
 Pz7Y6OjuDg4J+fn5OTk6enp
 56enmleECcgggoBADs=mZmE
--snip--
http://www.yaml.org/spec/1.2/spec.html#id2759572- Relation to JSON
http://www.yaml.org/spec/1.2/spec.html#id2759732- Relation to XML
YAML
--snip--
ocs_profile_version: 1
resource_path: luts
luma_b: '0.0722'
luma_g: '0.7152'
luma_r: '0.2126'
role_compositing_log: lgh
role_scene_linear: lnh
strictparsing: true
displays:
 Film1D: !Display {colorspace: vd8, device: sRGB}
 Log: !Display {colorspace: lg10, device: sRGB}
colorspaces:
 dt8: !ColorSpace
  bitdepth: 8ui
  description: null
  family: vd8
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
  - !File {interpolation: null, src: diffusemult.spimtx}
  - !ColorSpaceTransform {dst: lnh, src: vd8}
 lg10: !ColorSpace
  bitdepth: 10ui
  description: lg10 converts from scanned film to the show linear reference space.
    This is a custom conversion based on several Kodak acquisition stocks. All three
    color channels have the same response and there is no cross talk. This transform
    has a shoulder and toe compensation. This 10bit uiint version is used for DI
    deliveries.
  family: lg
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
 lnh: !ColorSpace
  bitdepth: 16f
  description: The show reference space. This is a sensor referred linear representation
    of the scene with primaries that correspond to scanned film. 0.18 inthis space
    corresponds to a properly exposed 18% grey card.
  family: ln
  gpuallocation: lg2
  gpumax: 6
  gpumin: -15
  isdata: false
  to_reference: null
 vd8: !ColorSpace
  bitdepth: 8ui
  description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference
    colorspace. This is a 1-d representation does not include any subtractive color
    mixing or crosstalk compensation. This is commonly used to interchange files
    between internal and external vendors. This is used as the interchange space
    for final images on direct to video or television products.
  family: vd8
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
  - !File {interpolation: linear, src: vd10.spi1d}
--snip--
XML
--snip--
<ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh">
   <display device="sRGB" name="Film1D" colorspace="vd8"/>
   <display device="sRGB" name="Log" colorspace="lg10"/>
   <colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6">
       <description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description>
   </colorspace>
   <colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description>
       <to_reference>
           <group>
               <file src="lg10.spi1d" interpolation="nearest" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description>
       <to_reference>
           <group>
               <file src="lgf.spi1d" interpolation="nearest" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615">
       <description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description>
       <to_reference>
           <group>
               <file src="lgf.spi1d" interpolation="linear" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description>
       <to_reference>
           <group>
               <file src="vd10.spi1d" interpolation="linear" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description> </description>
       <to_reference>
         
...

read more »


Re: XML Profile Format

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

I'm completely in favor of making the OCIO configuration files easier
to read and edit.

I have a few specific concerns about YAML, but it's definitely worth
exploring. Care to take a stab at it?

In defense of XML ...

* It's the 'no format decision' decision. Support is ubiquitous, and
no one ever wonders, "what the hell is this?" YAML is not nearly as
widely known. Never having looked at YAML before, when I first looked
at your configuration file I was wondering which formatting parts were
important. But this could be made more obvious with a few tweaks to
the outputter format.

* We've already got the XML code working.

* The ASC CDL defines an xml spec which I would like to support (for
interoperability with other CDL apps), so we're not going to be be
able to ditch tinyxml.

* This may not be wise in the long term, but I really like how OCIO
has minimal external build dependencies. (Some day when the windows
port needs to be attacked, this should keep life simple I hope!)
Does OSX have YAML as part of its base installation? Do normal linux
distros? (I assume Windows doesnt) Is there a minimal yaml
implementation we could pull internal, similar in spirit to tinyxml?
If so (assuming it can be namespaced properly, and the licence terms
are suitable) I'd love to keep it internal.

I'm not sure that yaml's strong python support is relevant to this
discussion. OCIO serialization is handled on the C++ side, and the
python bindings provide typed interfaces to the transforms. (I.e., a
CDLTransform is a native python class as opposed to a python dict with
particular key value pairs). And, I would prefer that folks
manipulating OCIO profiles in python use the native OCIO API rather
than mucking with the serialized representations. Or is there another
use case I'm missing?

Also, in terms of overall development priorities I wouldn't personally
put this at the top of my list. (I was much more excited about your
adding Houdini lut support, for example). But I can see that making
the format less daunting could be a selling point adoption.

-- Jeremy

On Tue, Oct 5, 2010 at 6:43 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Are people super into the idea of using xml?

We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things.

One of the developers introduced the use of YAML (http://www.yaml.org/  http://en.wikipedia.org/wiki/YAML) and it
took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much
everything was XML). RV has started to use it for it's package descriptions as well.

As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand
writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format
then maybe.

btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are
into the idea I'm happy to do the leg work to get it to work.

I have attached a small demo python script for you to check out, it mostly shows off how to define your own
custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo.

Why I like it:
- super simple to parse and serialise objects
- human readable / editable
- easy to define your own custom types
- using yaml in python is so simple

It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file.
http://en.wikipedia.org/wiki/YAML#Other_specified_data_types
--snip--
picture: !!binary |
 R0lGODlhDAAMAIQAAP//9/X
 17unp5WZmZgAAAOfn515eXv
 Pz7Y6OjuDg4J+fn5OTk6enp
 56enmleECcgggoBADs=mZmE
--snip--

http://www.yaml.org/spec/1.2/spec.html#id2759572 - Relation to JSON
http://www.yaml.org/spec/1.2/spec.html#id2759732 - Relation to XML

YAML
--snip--
ocs_profile_version: 1
resource_path: luts
luma_b: '0.0722'
luma_g: '0.7152'
luma_r: '0.2126'
role_compositing_log: lgh
role_scene_linear: lnh
strictparsing: true
displays:
 Film1D: !Display {colorspace: vd8, device: sRGB}
 Log: !Display {colorspace: lg10, device: sRGB}
colorspaces:
 dt8: !ColorSpace
  bitdepth: 8ui
  description: null
  family: vd8
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
  - !File {interpolation: null, src: diffusemult.spimtx}
  - !ColorSpaceTransform {dst: lnh, src: vd8}
 lg10: !ColorSpace
  bitdepth: 10ui
  description: lg10 converts from scanned film to the show linear reference space.
    This is a custom conversion based on several Kodak acquisition stocks. All three
    color channels have the same response and there is no cross talk. This transform
    has a shoulder and toe compensation. This 10bit uiint version is used for DI
    deliveries.
  family: lg
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
 lnh: !ColorSpace
  bitdepth: 16f
  description: The show reference space. This is a sensor referred linear representation
    of the scene with primaries that correspond to scanned film. 0.18 inthis space
    corresponds to a properly exposed 18% grey card.
  family: ln
  gpuallocation: lg2
  gpumax: 6
  gpumin: -15
  isdata: false
  to_reference: null
 vd8: !ColorSpace
  bitdepth: 8ui
  description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference
    colorspace. This is a 1-d representation does not include any subtractive color
    mixing or crosstalk compensation. This is commonly used to interchange files
    between internal and external vendors. This is used as the interchange space
    for final images on direct to video or television products.
  family: vd8
  gpuallocation: uniform
  gpumax: 1
  gpumin: 0
  isdata: false
  to_reference:
  - !File {interpolation: linear, src: vd10.spi1d}
--snip--

XML
--snip--
<ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh">
   <display device="sRGB" name="Film1D" colorspace="vd8"/>
   <display device="sRGB" name="Log" colorspace="lg10"/>
   <colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6">
       <description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description>
   </colorspace>
   <colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description>
       <to_reference>
           <group>
               <file src="lg10.spi1d" interpolation="nearest" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description>
       <to_reference>
           <group>
               <file src="lgf.spi1d" interpolation="nearest" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615">
       <description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description>
       <to_reference>
           <group>
               <file src="lgf.spi1d" interpolation="linear" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description>
       <to_reference>
           <group>
               <file src="vd10.spi1d" interpolation="linear" />
           </group>
       </to_reference>
   </colorspace>
   <colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
       <description> </description>
       <to_reference>
           <group>
               <file src="diffusemult.spimtx"/>
               <colorspacetransform src="vd8" dst="lnh"/>
           </group>
       </to_reference>
   </colorspace>
</ocioconfig>
--snip--




.malcolm


Re: Inital Houdini lut support

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

* In terms of coding style, you put the return value on a new line,
where as I tend to not. I'm actually fine either way, but I'd really
like to keep the codebase uniform in this regard. I'm going to be
putting together coding guidelines together in the next few days, and
once we pick what's preferred I'll do a single cleanup pass to bring
the whole codebase up to spec. (I'll also attack line lengths, and
#include order at the same time).
I'm happy to match what ever style you put forward, I mainly like doing
this as it makes it really clear what a function / method is returning. We
don't have function overloading but in code bases where you do I find
this helps.

My only other note would be about indenting all namespaces, I see you
want to limit to 80 char columns (+1) this with the namespace indenting
is going to make for some very compact coding.

ie.
--snip--
OCIO_NAMESPACE_ENTER
{
namespace
{

void foo();

}
}
OCIO_NAMESPACE_EXIT
--snip--

--snip--
OCIO_NAMESPACE_ENTER
{
namespace
{

void foo();

} // anonymous namespace
}
OCIO_NAMESPACE_EXIT
--snip--

* Your commit, c7a1bfadeb..., (where you change the walk order to
match GLs ordering) was not strictly necessary. Lut3DOp.h defines two
3dlut index helpers:

int GetGLLut3DArrayOffset(...)
int GetAutodeskLut3DArrayOffset(...)

You could have used the second function, rather than the first, to
save yourself this trouble. (It is poorly named though, any better
idea on names?)
int GetRGBLut3DArrayOffset(...)?

* We will be able to resolve ambiguously named formats (such as the
super ambiguous .lut) with a minor addition to FileTransform.cpp.
(This code is already in FileTransform:GetFile in code comment form).

The idea is inspired by image reading in Nuke. OCIO will use the
file extension to guess the format, and attempt to load it. (in the
case of multiple formats with the same extension, just pick one). If
this fails, then try to load all other formats with the same extension
until one succeeds. If this fails too, then go ahead and try all
known formats in case it's a misnamed file. The cool part of this
is that users don't have to worry about file format naming (assuming
the lut readers all are good about throwing exceptions early on
malformed luts), and performance doesnt suffer either as the format
results are cached so the rollover detection only happens once per
session.

I'll implement this behavior before the next .lut format is added.
Sounds good, like in nuke could your see us forcing a loader in the
profile format?

.malcolm


Re: Review: pkg-config support and some OCIO_VERSION changes

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

Looks good to me!

I really like the VERSION consolidation and the cmake "configure_file"
mojo.
Now that I know about that approach, I'll use it for the
OCIO_NAMESPACE #define as well...

-- Jeremy


Re: Inital Houdini lut support

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

Also - for future reference - you don't need to include the patch
file. It will be sufficient to just include the SHA1 hash for the top-
most commit that corresponds to the topic.

For example, in this case 9c2a6d47bb18ee6ca565e2ae1691486f8ae57c0b
(You can find this for old commits using gitk, in your repo).

Thanks!

-- Jeremy


Re: Inital Houdini lut support

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

Looks good to me!

I have a few comments, but these dont need to be addressed yet.

* In terms of coding style, you put the return value on a new line,
where as I tend to not. I'm actually fine either way, but I'd really
like to keep the codebase uniform in this regard. I'm going to be
putting together coding guidelines together in the next few days, and
once we pick what's preferred I'll do a single cleanup pass to bring
the whole codebase up to spec. (I'll also attack line lengths, and
#include order at the same time).

* Your commit, c7a1bfadeb..., (where you change the walk order to
match GLs ordering) was not strictly necessary. Lut3DOp.h defines two
3dlut index helpers:

int GetGLLut3DArrayOffset(...)
int GetAutodeskLut3DArrayOffset(...)

You could have used the second function, rather than the first, to
save yourself this trouble. (It is poorly named though, any better
idea on names?)

* We will be able to resolve ambiguously named formats (such as the
super ambiguous .lut) with a minor addition to FileTransform.cpp.
(This code is already in FileTransform:GetFile in code comment form).

The idea is inspired by image reading in Nuke. OCIO will use the
file extension to guess the format, and attempt to load it. (in the
case of multiple formats with the same extension, just pick one). If
this fails, then try to load all other formats with the same extension
until one succeeds. If this fails too, then go ahead and try all
known formats in case it's a misnamed file. The cool part of this
is that users don't have to worry about file format naming (assuming
the lut readers all are good about throwing exceptions early on
malformed luts), and performance doesnt suffer either as the format
results are cached so the rollover detection only happens once per
session.

I'll implement this behavior before the next .lut format is added.

-- Jeremy


Review: pkg-config support and some OCIO_VERSION changes

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

I wanted some pkgconfig (http://en.wikipedia.org/wiki/Pkg-config) support to make it easier to build against OCIO.

Part of this needed burning the ocio version into the .pc file, so I rejigged things a little so there is only one place to
change the OCIO_VERSION

Notes:
* added some basic pkg-config .pc building
* moved OCIO_VERSION into top most CMakeLists.txt
* added OpenColorVersion.h.in which gets configured() at build time with OCIO_VERSION
* added ${CMAKE_BINARY_DIR}/export/ to a few CMakeLists.h so they can find the resloved OpenColorVersion.h
* added OpenColorIO.pc.in which gets configured() at build time with OCIO_VERSION and CMAKE_INSTALL_PREFIX

.malcolm


Development Guidelines + New Website

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

Now that we've got a few people actively contributing code, we're
going to start formalizing the development process. (Thanks to Malcolm
Humphreys for being the guinea-pig in the process).

Please refer to our new website, opencolorio.org (still in
development), for further details.

Thanks!


XML Profile Format

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

Are people super into the idea of using xml?

We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things.

One of the developers introduced the use of YAML (http://www.yaml.org/ http://en.wikipedia.org/wiki/YAML) and it
took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much
everything was XML). RV has started to use it for it's package descriptions as well.

As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand
writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format
then maybe.

btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are
into the idea I'm happy to do the leg work to get it to work.

I have attached a small demo python script for you to check out, it mostly shows off how to define your own
custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo.

Why I like it:
- super simple to parse and serialise objects
- human readable / editable
- easy to define your own custom types
- using yaml in python is so simple

It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file.
http://en.wikipedia.org/wiki/YAML#Other_specified_data_types
--snip--
picture: !!binary |
R0lGODlhDAAMAIQAAP//9/X
17unp5WZmZgAAAOfn515eXv
Pz7Y6OjuDg4J+fn5OTk6enp
56enmleECcgggoBADs=mZmE
--snip--

http://www.yaml.org/spec/1.2/spec.html#id2759572 - Relation to JSON
http://www.yaml.org/spec/1.2/spec.html#id2759732 - Relation to XML

YAML
--snip--
ocs_profile_version: 1
resource_path: luts
luma_b: '0.0722'
luma_g: '0.7152'
luma_r: '0.2126'
role_compositing_log: lgh
role_scene_linear: lnh
strictparsing: true
displays:
Film1D: !Display {colorspace: vd8, device: sRGB}
Log: !Display {colorspace: lg10, device: sRGB}
colorspaces:
dt8: !ColorSpace
bitdepth: 8ui
description: null
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: null, src: diffusemult.spimtx}
- !ColorSpaceTransform {dst: lnh, src: vd8}
lg10: !ColorSpace
bitdepth: 10ui
description: lg10 converts from scanned film to the show linear reference space.
This is a custom conversion based on several Kodak acquisition stocks. All three
color channels have the same response and there is no cross talk. This transform
has a shoulder and toe compensation. This 10bit uiint version is used for DI
deliveries.
family: lg
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
lnh: !ColorSpace
bitdepth: 16f
description: The show reference space. This is a sensor referred linear representation
of the scene with primaries that correspond to scanned film. 0.18 inthis space
corresponds to a properly exposed 18% grey card.
family: ln
gpuallocation: lg2
gpumax: 6
gpumin: -15
isdata: false
to_reference: null
vd8: !ColorSpace
bitdepth: 8ui
description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference
colorspace. This is a 1-d representation does not include any subtractive color
mixing or crosstalk compensation. This is commonly used to interchange files
between internal and external vendors. This is used as the interchange space
for final images on direct to video or television products.
family: vd8
gpuallocation: uniform
gpumax: 1
gpumin: 0
isdata: false
to_reference:
- !File {interpolation: linear, src: vd10.spi1d}
--snip--

XML
--snip--
<ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh">
<display device="sRGB" name="Film1D" colorspace="vd8"/>
<display device="sRGB" name="Log" colorspace="lg10"/>
<colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6">
<description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description>
</colorspace>
<colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description>
<to_reference>
<group>
<file src="lg10.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="nearest" />
</group>
</to_reference>
</colorspace>
<colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615">
<description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description>
<to_reference>
<group>
<file src="lgf.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description>
<to_reference>
<group>
<file src="vd10.spi1d" interpolation="linear" />
</group>
</to_reference>
</colorspace>
<colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1">
<description> </description>
<to_reference>
<group>
<file src="diffusemult.spimtx"/>
<colorspacetransform src="vd8" dst="lnh"/>
</group>
</to_reference>
</colorspace>
</ocioconfig>
--snip--



.malcolm


ICC Support

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

I have been playing with littlecms a little (building profiles for photoshop etc) and was wondering if people have an idea on how they envisioned these fitting into OCIO?

There could be reader and writers. But the icc tag system isn't super straight forward.

Most ICC profiles need to have there PCS (profile connection space) as Lab for them to be used in photoshop for soft proofing etc.. with OCIO being RGB and all the options for rendering intent, some ideas on how this could fit would help.

.malcolm


Inital Houdini lut support

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

Hi,

I have a few emails to send through I have been discussing with jeremy, I have split them up so they can be discussed in different threads.

Here is an initial pass at the Houidini lut loader. I have only really tested the 3D+1D type as that what we are using. There is support for the 3D type and partial support for the 1D type. There is no support for the binary type.

houdini luts has a not so good extension (.lut) and (.blut for the binary version),. Do you think we need a better way to choose a lut loader other than file extensions?

I have attached another patch staticlink_breaksRegisterFileFormat.patch which you need to edit a little to get OCIO to link statically but on OSX at least RegisterFileFormat() will not be called for the AutoRegister struct in each loader. I'm not sure this is expected.





.malcolm


OCIO 0.6.1 posted

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

Version 0.6.1 (Oct 5 2010):
* Exposed ExponentTransform
* Added CineonLogToLinTransform - a simple 'straight-line'
negative
linearization. Not strictly needed (could be done previously
with LUTs) but often convenient to have.
* Added DisplayTransform.displayCC for post display lut CC.
* Many python improvements
* A few bug fixes
* A few Makefile enhancements


[imageworks/OpenColorIO] 5a24dc: bump

nor...@...
 

Branch: refs/heads/master
Home: http://github.com/imageworks/OpenColorIO

Commit: 5a24dca1b81c5275051b769adeaef6c634a10e1d
http://github.com/imageworks/OpenColorIO/commit/5a24dca1b81c5275051b769adeaef6c634a10e1d
Author: Jeremy Selan <jeremy...@...>
Date: 2010-10-05 (Tue, 05 Oct 2010)

Changed paths:
M ChangeLog
M export/OpenColorIO/OpenColorIO.h
M tgz_create

Log Message:
-----------
bump


Re: 3D lut size and bit depth questions

Est <rame...@...>
 

Hi Jeremy,

Thank you for your replies.
Everything is clear now.

I think that the lut size is an implementation detail of the client
and a recommended lut size function wouldn't have much use
as most of the clients / plugins would use a fixed size lut.

Est.


Re: 776393: added comment

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

Oops. This is actually a callback on commits themselves, not pull
requests. I'll disable the callback until I get it worked out.


Re: 776393: added comment

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

Testing, 1 2 3...

I've updated our github acct. so all pull requests get cc'd to this
list.

I really like how OpenImageIO reviews commits in their public dev
forum before adding them to the repo, this will let us automate the
process similarly.

If anyone objects to this approach (as spam!) please let me know, but
if no one says otherwise we'll let the commit threads begin!

-- Jeremy


[imageworks/OpenColorIO] 776393: added comment

nor...@...
 

Branch: refs/heads/master
Home: http://github.com/imageworks/OpenColorIO

Commit: 77639305a291d929b257bb1b3211462b8c9428ed
http://github.com/imageworks/OpenColorIO/commit/77639305a291d929b257bb1b3211462b8c9428ed
Author: Jeremy Selan <jeremy...@...>
Date: 2010-09-22 (Wed, 22 Sep 2010)

Changed paths:
M src/pyglue/PyGroupTransform.cpp

Log Message:
-----------
added comment


Commit: 13dfeebb9ba726e4a9131ce73ed772d9cc12420d
http://github.com/imageworks/OpenColorIO/commit/13dfeebb9ba726e4a9131ce73ed772d9cc12420d
Author: Jeremy Selan <jeremy...@...>
Date: 2010-09-22 (Wed, 22 Sep 2010)

Changed paths:
M src/core/ExponentOps.cpp

Log Message:
-----------
exponentop implements gpu path


Commit: 6d75841a64bd110a78ba000abbca25574fd1ff05
http://github.com/imageworks/OpenColorIO/commit/6d75841a64bd110a78ba000abbca25574fd1ff05
Author: malcolmhumphreys <malcolmh...@...>
Date: 2010-09-23 (Thu, 23 Sep 2010)

Changed paths:
M export/OpenColorIO/OpenColorIO.h
M export/OpenColorIO/OpenColorTransforms.h
M export/OpenColorIO/OpenColorTypes.h
M src/core/Config.cpp
M src/core/FileFormat3DL.cpp
M src/core/FileFormatCSP.cpp
A src/core/JPLogOp.cpp
A src/core/JPLogOp.h
A src/core/JPLogTransform.cpp
M src/core/OpBuilders.h
M src/core/Transform.cpp
A src/core/UnitTest.cpp

Log Message:
-----------
- added OCIO::Config::CreateFromStream() so we can read a config from a stream
- added UnitTest.cpp which defines BOOST_TEST_MODULE for the core unit tests
- added BOOST_AUTO_TEST_SUITE to CSP and 3DL unit tests so you can differentiate between test when running 'ocio_core_tests --log_level=test_suite'
- added JPLogOp for applying the Josuha Pines loglin method
- added JPLogTransform so you can use the JPLogOp in the OCIO config
- added Config code of the <JPLog \> type

2061 - 2080 of 2209