Thanks for all the feedback, everyone! It has been very helpful.

Having tabulated the results, the winner - by a landslide - is documentation!

So this will be the (rough) order of development:

1) Developer API / Facility Integration Docs
2) End User (Artist) Docs
3) Color Config Authoring Docs / Examples
4) Flesh out existing OCIO configs

I think this will go a long way towards making OCIO useful in practice.

-- Jeremy

Hi Jeremy,

On Mon, Sep 20, 2010 at 4:10 PM, Jeremy Selan <jeremy...@gmail.com> wrote:

I've also been rethinking the use of boost within OCIO.  Currently
there are only two things we use it for: shared_ptr and the unit test
framework.

shared_ptr is header only and you're already using CMake, so perhaps
it'd be worth
looking at using CMake's unit testing instead of boost's?

This way there's no linking dependencies against boost.

Cheers,

Alan.

Actually, I dont believe there currently is a link dependency to boost.

ldd src/core/libOpenColorIO.so :

linux-vdso.so.1 => (0x00007fff63afb000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4b3241a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4b32196000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f4b31f80000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b31c30000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b329e5000)

And, a bit surprisingly, even the unit test program doesnt appear to
link to boost:
ldd src/core/ocio_core_tests:

linux-vdso.so.1 => (0x00007fff09fb8000)
libOpenColorIO.so => libOpenColorIO.so (0x00007f41d812d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f41d7e1f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f41d7b9c000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f41d7986000)
libc.so.6 => /lib64/libc.so.6 (0x00007f41d7636000)
/lib64/ld-linux-x86-64.so.2 (0x00007f41d83b3000)


So the only benefit would be to remove it as a compile time dependency
(presuming that we dont let anyone use at link time, either).

-- Jeremy

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@gmail.com> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.

Ok, so I just checked in a bunch of changes to the unit testing (spi
github repository). These changes may or may not affect the build
error you've gotten. I'll check your error on OSX when I get home
tonight, my hope is that i'll be able to re-create your error there).

Previously, the unit tests were in their own .cpp files, interleaved
within the src/core directory. This had the advantage of simplicity,
but one major disadvantage that anything that wanted to be unit tested
had to be available in an include. Being a major fan of anonymous
namespaces, and really prefering to keep as much as possible in .cpp
files (rather than .h files), this wasn't ideal.

In this new unittest approach we build src/core twice. Once normally,
and then again with an additional #define, OCIO_UNIT_TEST. (This is
controlled through the src/core_tests submodule).

The upside is we can build the core library without including boost symbols:

nm -C lib/libOpenColorIO.so | grep unit | wc -l

0

and then build the test library including boost testing, as a
build-time dependency

nm -C bin/ocio_core_tests | grep unit | wc -l

1430

I also really like that you can easily nit test small helper functions
that do not escape the file.

For an example of this in practice see
src/core/FileFormatCSP.cpp

The downsides are the the build process (for core) is twice as long,
and that the implementation files may get longer. But I think it's
worth it to keep the code and associated tests together.

Thoughts?

-- Jeremy


On Mon, Sep 20, 2010 at 3:19 PM, Alan Jones <sky...@gmail.com> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@gmail.com> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.

Version 0.6.0 (Sept 21 2010):
* Start of 0.6, "stable" branch

All 0.6.x builds will be ABI compatible (forward only).
New features (even experimental ones) will be added to the 0.6
branch,
as long as binary and source compatibility is maintained.
Once this no longer is possible, a 0.7 "dev" branch will be
forked.

* Split public header into 3 parts for improved readability
(you still only import <OpenColorIO/OpenColorIO.h> though)
* Added MatrixTransform
* Refactored internal unit testing
* Fixed many compile warnings

The downsides are the the build process (for core) is twice as long,
and that the implementation files may get longer. But I think it's
worth it to keep the code and associated tests together.

Thoughts?

I think thats fine, the DEBUG/TEST build would build both and the RELEASE wouldn't.

.malcolm

-- Jeremy


On Mon, Sep 20, 2010 at 3:19 PM, Alan Jones <sky...@gmail.com> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@gmail.com> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.

Hi All,

I recently started using OpenColorIO and I have some questions:

In my current code, I'm using a 32x32x32 lut, just for the display,
not for processing.
Is it a good size? How do you choose a 3d lut size?

In the spi-cg config, what's the difference between vd16 and vdf?
I see they have the same parameters and lut. The only difference is
the
bitdepth. I haven't read all the code yet but it doesn't seem that
the bitdepth is used when converting colorspaces.

Thank you.

Est.

Est,

A 32x32x32 cube lut is a totally reasonable size, it's what we happen
to use internally at Imageworks.

Some other popular sizes include 17x17x17 (flame), and 33x33x33 (a few
commercial color graders). There are probably some clients that use
larger sizes, but as you get to larger sizes there can be noticeable
performance degradation. (Which is often image content dependent, has
anyone else noticed that!?!)

There's currently no way to query a recommended lut size through the
OpenColorIO API. In the case of a transform having a 3d lut there may
be times where one particular size is 'native', but on many other
occasions there wont be native resolution. The question for whether
or not to add such a function is based on whether a 3d display
transform size is most often tied to a particular color configuration
(in which case OCIO is the right place), or if it's more appropriately
tied to a client or plugin (in which case and API call does not belong
in OCIO).

Thoughts?

Good observation on the vd16 - vdf issue. That's a bug with the
spi-cg profile, and we'll have it fixed in the next few weeks. (Both
profiles will be getting a huge upgrade). What should be happening
is that they both reference the same LUT, but that the vdf profile
should be using linear interpolation, and the vd16 profile nearest.
(This table has 17 bits of entries, so there is no quality difference
using nearest neighbor for 16-bit int data, and the performance is a
lot better).

You are completely correct in that the bit depth tag is not used when
converting colorspaces. It is merely a tag that the UI can use. (All
of this will be explained in the docs in the near future). :)

-- Jeremy

ps - I'll be out of town for the next week, so my email response time
may suffer.

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

Commit: 77639305a291d929b257bb1b3211462b8c9428ed
http://github.com/imageworks/OpenColorIO/commit/77639305a291d929b257bb1b3211462b8c9428ed
Author: Jeremy Selan <jeremy...@gmail.com>
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...@gmail.com>
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...@gmail.com>
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

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

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

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.

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

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

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

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

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

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

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

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

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!

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