Date   

Re: 3D lut size and bit depth questions

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

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.

On Thu, Sep 23, 2010 at 10:48 AM, Est <rame...@gmail.com> wrote:
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.


3D lut size and bit depth questions

Est <rame...@...>
 

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.


Re: Compilation fail on FC13

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

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.


OCIO 0.6.0 posted

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

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


Re: Compilation fail on FC13

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

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.


Re: Compilation fail on FC13

Alan Jones <sky...@...>
 

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.


Re: Compilation fail on FC13

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

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

On Mon, Sep 20, 2010 at 2:35 PM, Alan Jones <sky...@gmail.com> wrote:
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.


Re: Compilation fail on FC13

Alan Jones <sky...@...>
 

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.


Re: Development Priorities?

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

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


Re: Compilation fail on FC13

Jeremy Selan <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

On Mon, Sep 20, 2010 at 1:05 PM, Alan Jones <sky...@gmail.com> wrote:
Best way to solve a problem? Post on a mailing list asking for help, then
you'll find the solution within minutes.

Cheers,

Alan.


Re: Compilation fail on FC13

Alan Jones <sky...@...>
 

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

Cheers,

Alan.


Compilation fail on FC13

Alan Jones <sky...@...>
 

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


Re: Development Priorities?

srluka <srl...@...>
 

Hello Jeremy,

I would like to see OCIO grow into a library that can handle all our
color transformations. I can see it being used in the current xml'ized
form within our production environment to keep the color options well-
defined, but still want the eventual capability for dynamic color
transformations. Performance for realtime playback is also important
to us.

With that in mind, here are my top five:

- Developer API Docs
- Color Config Authoring Docs
- Overall performance optimization
- Dynamic Color API
- OpenImageIO

Stefan

On Sep 16, 8:36 am, Marie Fétiveau <m....@mikrosimage.eu> wrote:
Hello Jeremy and all !

I don't have much time to focus on OCIO now but soon or late I will...;)

And when that day will come, I'll be happy to find :
- Developer API Docs
- Color Config Authoring Docs
- Add a example ACES ocio config
- End User (Artist) Docs
- Live CDL Support

Thanks !

Marie



On Thu, Sep 16, 2010 at 1:39 AM, Est <rame...@gmail.com> wrote:
Hi Jeremy,
I'm currently adding OpenColorIO support to my compositor.
My list would be:
- End User (Artist) Docs
- Developer API Docs
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Color Config Authoring Docs
- Add example color config authoring scripts
I can port the existing Colorspace and Display Nuke plugins to OFX
if there is interest. Just let me know.
Est.
On Sep 15, 4:49 pm, Alan Jones <sky...@gmail.com> wrote:
Hi Jeremy,
On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@gmail.com>
wrote:
Perhaps reply with the top 5 items you care about?
The top five for me would be as follows.
1) API Documentation (the classes and how the pieces are supposed to
work together - I guess that may count as config documentation)
2) LUT export
3) Unit testing (this kinda should be number one, but I'm trying to be
somewhat pragmatic)
4) Color config authoring docs
5) Additional LUT formats
I'd say for now the biggest thing holding me back on OIIO is there is
no big picture documentation. I don't really know how OCIO is intended
to work and what all the pieces are. I can try piece it together from
the code, but a document covering intended structure would make both
using it and identifying areas to provide meaningful contribution much
easier. The reason I say big picture rather than purely API is I'm
thinking not just of the API for how to access it, but how it's
intended to work within a pipeline.
Cheers,
Alan.


OCIO 0.5.16 posted

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

Version 0.5.16 (Sept 16 2010):
* PyTransforms now use native python class inheritance
* OpenColorIO C++ namespace can now be configured at build time
(for safe distribution in commercial apps)
* Updated make install behavior
* DisplayTransform accepts generic cc operators (instead of CDL
only)
* A few bug fixes / compile warning fixes

And coming next week, 0.6.0 !


Re: Development Priorities?

Marie Fétiveau <m...@...>
 

Hello Jeremy and all !

I don't have much time to focus on OCIO now but soon or late I will...;)

And when that day will come, I'll be happy to find :
- Developer API Docs
- Color Config Authoring Docs
- Add a example ACES ocio config
- End User (Artist) Docs
- Live CDL Support

Thanks !

Marie


On Thu, Sep 16, 2010 at 1:39 AM, Est <rame...@...> wrote:
Hi Jeremy,

I'm currently adding OpenColorIO support to my compositor.

My list would be:

- End User (Artist) Docs
- Developer API Docs
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Color Config Authoring Docs
- Add example color config authoring scripts

I can port the existing Colorspace and Display Nuke plugins to OFX
if there is interest. Just let me know.

Est.

On Sep 15, 4:49 pm, Alan Jones <sky...@...> wrote:
> Hi Jeremy,
>
> On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@...> wrote:
> > Perhaps reply with the top 5 items you care about?
>
> The top five for me would be as follows.
>
> 1) API Documentation (the classes and how the pieces are supposed to
> work together - I guess that may count as config documentation)
> 2) LUT export
> 3) Unit testing (this kinda should be number one, but I'm trying to be
> somewhat pragmatic)
> 4) Color config authoring docs
> 5) Additional LUT formats
>
> I'd say for now the biggest thing holding me back on OIIO is there is
> no big picture documentation. I don't really know how OCIO is intended
> to work and what all the pieces are. I can try piece it together from
> the code, but a document covering intended structure would make both
> using it and identifying areas to provide meaningful contribution much
> easier. The reason I say big picture rather than purely API is I'm
> thinking not just of the API for how to access it, but how it's
> intended to work within a pipeline.
>
> Cheers,
>
> Alan.


Re: Development Priorities?

Est <rame...@...>
 

Hi Jeremy,

I'm currently adding OpenColorIO support to my compositor.

My list would be:

- End User (Artist) Docs
- Developer API Docs
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Color Config Authoring Docs
- Add example color config authoring scripts

I can port the existing Colorspace and Display Nuke plugins to OFX
if there is interest. Just let me know.

Est.

On Sep 15, 4:49 pm, Alan Jones <sky...@gmail.com> wrote:
Hi Jeremy,

On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Perhaps reply with the top 5 items you care about?
The top five for me would be as follows.

1) API Documentation (the classes and how the pieces are supposed to
work together - I guess that may count as config documentation)
2) LUT export
3) Unit testing (this kinda should be number one, but I'm trying to be
somewhat pragmatic)
4) Color config authoring docs
5) Additional LUT formats

I'd say for now the biggest thing holding me back on OIIO is there is
no big picture documentation. I don't really know how OCIO is intended
to work and what all the pieces are. I can try piece it together from
the code, but a document covering intended structure would make both
using it and identifying areas to provide meaningful contribution much
easier. The reason I say big picture rather than purely API is I'm
thinking not just of the API for how to access it, but how it's
intended to work within a pipeline.

Cheers,

Alan.


Re: Development Priorities?

Alan Jones <sky...@...>
 

Hi Jeremy,

On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Perhaps reply with the top 5 items you care about?
The top five for me would be as follows.

1) API Documentation (the classes and how the pieces are supposed to
work together - I guess that may count as config documentation)
2) LUT export
3) Unit testing (this kinda should be number one, but I'm trying to be
somewhat pragmatic)
4) Color config authoring docs
5) Additional LUT formats

I'd say for now the biggest thing holding me back on OIIO is there is
no big picture documentation. I don't really know how OCIO is intended
to work and what all the pieces are. I can try piece it together from
the code, but a document covering intended structure would make both
using it and identifying areas to provide meaningful contribution much
easier. The reason I say big picture rather than purely API is I'm
thinking not just of the API for how to access it, but how it's
intended to work within a pipeline.

Cheers,

Alan.


Re: Development Priorities?

"Nathaniel Hoffman" <na...@...>
 

1) Document 'best practice' for each config, provide examples with imagery
2) Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
3) Add example color config authoring scripts
4) End User (Artist) Docs
5) Color Config Authoring Docs

Naty

Folks,

If you're considering using OpenColorIO in the near term, we would
greatly appreciate it if you would respond and let us know which of
the topics below you personally consider to be most important.
Perhaps reply with the top 5 items you care about?

(Note: We plan on addressing all of these issues, but would love to
get a sense of what's holding people up in the short term).

If there's an important task that isn't represented on this list, please
add it!

Thanks!

-- Jeremy

--------------------------------------------------------------------------------



Fall 2010 OpenColorIO Development Topics:

Documentation
- Quickstart Guide
- End User (Artist) Docs
- Developer API Docs
- Color Config Authoring Docs

Facility Integration
- Support for additional lut formats (import)
- Support for lut export
- 3rd party app plugins
RV
OFX
OpenImageIO
Houdini
<Your App Here!>

"Real" Color Configurations
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Add a example ACES ocio config
- Add a config that emulates the default nuke color configuration
- Add example color config authoring scripts
- Document 'best practice' for each config, and provide workflow
examples with imagery

Core Library:
- Unit testing / correctness validation
- Overall performance optimization

Issues deferred until after 1.0 (tentatively Jan '11):
- Dynamic Color API (OCIO Plugin API)
- Live CDL Support


Development Priorities?

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

Folks,

If you're considering using OpenColorIO in the near term, we would
greatly appreciate it if you would respond and let us know which of
the topics below you personally consider to be most important.
Perhaps reply with the top 5 items you care about?

(Note: We plan on addressing all of these issues, but would love to
get a sense of what's holding people up in the short term).

If there's an important task that isn't represented on this list, please add it!

Thanks!

-- Jeremy

--------------------------------------------------------------------------------



Fall 2010 OpenColorIO Development Topics:

Documentation
- Quickstart Guide
- End User (Artist) Docs
- Developer API Docs
- Color Config Authoring Docs

Facility Integration
- Support for additional lut formats (import)
- Support for lut export
- 3rd party app plugins
RV
OFX
OpenImageIO
Houdini
<Your App Here!>

"Real" Color Configurations
- Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use
- Add a example ACES ocio config
- Add a config that emulates the default nuke color configuration
- Add example color config authoring scripts
- Document 'best practice' for each config, and provide workflow
examples with imagery

Core Library:
- Unit testing / correctness validation
- Overall performance optimization

Issues deferred until after 1.0 (tentatively Jan '11):
- Dynamic Color API (OCIO Plugin API)
- Live CDL Support


OCIO 0.5.15 posted

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

Version 0.5.15 (Sept 8 2010):
* Library is well behaved when $OCIO is unset, allowing for use in
an un-colormanaged environment
* Color Transforms can be applied in Python (config->getProcessor)
* Simplification of API (getColorSpace allows cs name, role names,
and cs objects)
* Makefile enhancements (courtesy Malcolm Humphreys)
* A bunch of bug fixes

2061 - 2080 of 2189