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

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

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

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

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.

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

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

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

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.

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.

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...@...> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> 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

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...@...> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> 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 Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> 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.

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 4:10 PM, Jeremy Selan <jeremy...@...> 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.

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

Hmmm, that patch doesnt quite work for us locally at Imageworks. (I
think it's probably because we use a namespaced version of boost, and
the macro isn't quite right in our context). Let me see if I can find
a solution that works for both of us.

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. Given the issues that can occur when linking against
other apps the rely on different boost versions, boost may be a can of
worms worth avoiding, particularly considering that at this time it
may be a pretty simple dependency to remove.

Does anyone have any strong feelings (or experience) on this?

-- Jeremy

Best way to solve a problem? Post on a mailing list asking for help, then
you'll find the solution within minutes.

Cheers,

Alan.

Hi All,

For some reason the compilation of the latest trunk is failing on FC13.

It's complaining about main not being defined, but from what I've read on the
boost unit testing defining BOOST_TEST_MODULE should take care of that.

Any ideas? Error output is below.

Cheers,

Alan.

Linking CXX executable ocio_core_tests
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [src/core/ocio_core_tests] Error 1
make[1]: *** [src/core/CMakeFiles/ocio_core_tests.dir/all] Error 2