1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Re: Idea: Remove boost:shared_ptr

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

+1 it should be pretty easy to add boost back as a dependency if we need to. I have seen a lot of projects copy the shared_ptr so it seems fairly common practice.

.malcolm

On 03 Nov, 2010,at 09:29 AM, Jeremy Selan <jere...@...> wrote:

Would anyone be against us copying the shared_ptr implementation
internally into OCIO? That would let us make the OCIO boost
dependency optional, which would let it compile on a plain-vanilla OSX
install. The only other part of the code that relies on boost is the
testing framework, which is already if def'd. So if the user has
boost, you'll get the testing If the user doesnt have boost, it will
skip testing.

Thoughts?

-- Jeremy
Re: Review: Added missing role enum to python

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

LGTM

On 03 Nov, 2010,at 09:26 AM, Jeremy Selan <jere...@...> wrote:

Trivial addition, exposed ROLE_DEFAULT to python.

commit 82dd5a4666f7c5456361e9ec7d78107742e5b427

-- Jeremy
Review: Nuke to OCIO exporter

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

I've added a nuke python script to src/testbed that lets you export
specified nuke color spaces into an OCIO profile. It also is a good
example of using the python API to create an OCIO profile.

commit:
b9d48f946b4c39d5334055e089d024d322561812

There is one major 'gotcha' I discovered in writing this script, and
it relates to the python version used at build time. As this script
requires the OCIO module to be imported into the Nuke python
namespace, the PyOpenColorIO module has to be compiled with the same
version that Nuke uses internally (which for current Nukes appears to
be python 2.5). However, the native compilation uses whichever python
happens to be the system install (which in my case is 2.6).
Unfortunately, running a 2.6 python .so in 2.5 does not work in subtle
ways.

This implies that a system level install, for use in a 3rd party app
(such as nuke) may not be appropriate. Should building OCIO for a 3rd
party plugin rebuild all .sos with app-specific settings? Seems like
it may need to.

-- Jeremy
New 0.7 Profile posted

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

A new profile, 'nuke-default' has been added to the 0.7.1 config bundle.
http://sites.google.com/site/opencolorio/profiles

This profile emulates the 'out of the box' color processing luts that
come with nuke 6.1 (should you choose to use them).

I've also checked in the nuke script which is used to generate this
profile, which will allow for the generalized OCIO export of working
Nuke color configurations. This is exciting because for shops which
have configured custom Nuke color processing, you can export an OCIO
profile for use in other apps.

-- Jeremy
Re: ocio_core_tests linking issue on Ubuntu 10.10

Andrew Hunter <and...@...>
 

Hey Jeremy,

On Tue, Nov 2, 2010 at 6:23 PM, Jeremy Selan <jeremy...@...> wrote:
I haven't seen that issue before, but it looks like it's related to
the testing framework (which relies on boost).  I'll try to get an
Ubuntu machine up in the next few days for testing.

But... in the meantime, you can disable compilation of the testing app
by editing CMakeList.txt (in the root dir), and commenting out the
following line:  (Add a "#" to make the line a comment).

#add_subdirectory (src/core_tests)
The build completes successfully commenting out that line.


I can add this as a command-line configuration option if the hack has
to live beyond the week.
If things are as Est mentioned, then I think this is a good idea. It
would be preferable to use the distribution's supplied boost rather
than having to build it locally.

Cheers!

Andrew
Re: ocio_core_tests linking issue on Ubuntu 10.10

Est <rame...@...>
 

I had the same problem. It happens when you link to the
dynamic version of boost's test libraries.
You need to build / install boost test as static libraries
and point CMake to them.

Est.

On Nov 2, 11:23 pm, Jeremy Selan <jeremy...@...> wrote:
I haven't seen that issue before, but it looks like it's related to
the testing framework (which relies on boost).  I'll try to get an
Ubuntu machine up in the next few days for testing.

But... in the meantime, you can disable compilation of the testing app
by editing CMakeList.txt (in the root dir), and commenting out the
following line:  (Add a "#" to make the line a comment).

#add_subdirectory (src/core_tests)

I can add this as a command-line configuration option if the hack has
to live beyond the week.

Please let me know if compilation succeeds with this line commented out?

Thanks!

-- Jeremy

On Tue, Nov 2, 2010 at 9:37 AM, Andrew Hunter <and...@...> wrote:
Hey everyone,
I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was
wondering if anyone could shed some light on whats going on?
Linking CXX executable ocio_core_tests
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [src/core_tests/ocio_core_tests] Error 1
make[1]: *** [src/core_tests/CMakeFiles/ocio_core_tests.dir/all] Error 2
make: *** [all] Error 2
Has anyone else been able to successfully build 0.7 on Ubuntu?
Cheers,
Andrew
Re: Idea: Remove boost:shared_ptr

Larry Gritz <l...@...>
 

shared_ptr is part of C++0x (in TR1, I think).
So another approach is to rig it so that sufficiently new compilers don't need the boost dependency, and only the old compilers will need to pull it in to get the shared_ptr.

Just a thought.


On Nov 2, 2010, at 3:29 PM, Jeremy Selan wrote:

Would anyone be against us copying the shared_ptr implementation
internally into OCIO? That would let us make the OCIO boost
dependency optional, which would let it compile on a plain-vanilla OSX
install. The only other part of the code that relies on boost is the
testing framework, which is already if def'd. So if the user has
boost, you'll get the testing. If the user doesnt have boost, it will
skip testing.

Thoughts?

-- Jeremy
--
Larry Gritz
l...@...
Idea: Remove boost:shared_ptr

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

Would anyone be against us copying the shared_ptr implementation
internally into OCIO? That would let us make the OCIO boost
dependency optional, which would let it compile on a plain-vanilla OSX
install. The only other part of the code that relies on boost is the
testing framework, which is already if def'd. So if the user has
boost, you'll get the testing. If the user doesnt have boost, it will
skip testing.

Thoughts?

-- Jeremy
Review: Added missing role enum to python

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

Trivial addition, exposed ROLE_DEFAULT to python.

commit 82dd5a4666f7c5456361e9ec7d78107742e5b427

-- Jeremy
Re: ocio_core_tests linking issue on Ubuntu 10.10

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

I haven't seen that issue before, but it looks like it's related to
the testing framework (which relies on boost). I'll try to get an
Ubuntu machine up in the next few days for testing.

But... in the meantime, you can disable compilation of the testing app
by editing CMakeList.txt (in the root dir), and commenting out the
following line: (Add a "#" to make the line a comment).

#add_subdirectory (src/core_tests)

I can add this as a command-line configuration option if the hack has
to live beyond the week.

Please let me know if compilation succeeds with this line commented out?

Thanks!

-- Jeremy

On Tue, Nov 2, 2010 at 9:37 AM, Andrew Hunter <and...@...> wrote:
Hey everyone,

I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was
wondering if anyone could shed some light on whats going on?


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

Has anyone else been able to successfully build 0.7 on Ubuntu?

Cheers,

Andrew
New OCIO users email list

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

We're starting to get some actual OCIO users, so it's time to start a
new mailing list:

http://groups.google.com/group/ocio-users

This will focus on issues related to color profile development, artist
workflows, best practice, etc.
Please sign up if you're interested.

Thanks!

-- Jeremy
ocio_core_tests linking issue on Ubuntu 10.10

Andrew Hunter <and...@...>
 

Hey everyone,

I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was
wondering if anyone could shed some light on whats going on?


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

Has anyone else been able to successfully build 0.7 on Ubuntu?

Cheers,

Andrew
Updated Color Profiles

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

Color profiles suitable for OCIO 0.7 have been posted, along with
basic documentation.

See https://sites.google.com/site/opencolorio/profiles for additional
information.

Note 1: Thanks to Joseph Slomka for putting these together!
Note 2: The docs on the spi-anim profile will be posted tomorrow.
Note 3: An additional profile, nuke-default, will be posted later this
week. It provides OCIO emulation for the current default Nuke color
processing.

-- Jeremy
Re: Reference !<Colorspace>

Joseph Slomka <jsl...@...>
 

Rod,

This is my partial follow-up to Jeremy's response.

A reference space is a useful concept and Imageworks will use them for AMPAS IIF implementation. The colorimetry will match the specification but how that will be arrived at will be subject to show requirements. . It is going to be a colorspace that will be tailored per production.

OCIO is being cast in ICC like terms that aren't fully relevant. OCIO lacks a color management module portion to handle the gamut mapping and other conversions done in an ICC CMM. OCIO has a different design. It is a framework. Pieces of management can be bolted together without anything 'to clever' happening. OCIO does not specify colorimetry; It is necessary to explicitly document the colorimetric meaning of your transformations. This makes OCIO simplistic and gives the control needed to create any case. OCIO provides the flexibility to implement reference spaces as colorspaces. It also leaves you fully free to define that role as you see fit allowing many individual color pipeline to exist.

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Rod Bogart
Sent: Tuesday, October 26, 2010 5:14 PM
To: ocio...@...
Subject: Re: RE: [ocio-dev] Reference !<Colorspace>

My concern is when/where we want to have different primaries on different shows. So the reference space is probably a particular RGB space (rather than XYZ), and it is not obvious what that is by examining a to_linear function.

In the SPI examples, there was never more than one set of primaries in use, but that seems unrealistic for the future. Right?

RGB

On Mon, Oct 25, 2010 at 10:17 PM, Jeremy Selan<jeremy...@...> wrote:

I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).

Thoughts?

In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.

-- Jeremy
Re: Review: Inital pass at searchpath impl

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

There's a lot of good ideas here, it's taken me a bit of time to think
through the implications.

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further? (Skype, iChat, etc). Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.

What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. > Then re-syncing these profiles would be a nightmare.
Agreed. Under no circumstances are we going to make per-shot looks
complicated to use. We're in the same boat here.

JS: I think it will be preferable when possible to minimize the use of envvars.
MH: Can you elaborate on this?
Your approach to implementing per-shot looks - using environment
variables within search paths - is clever. However, I'm not sold.
The portion I'm concerned about is the use of environment variables as
a communications mechanism.

For an application (such as a compositor) where you're not changing
show / shot / sequence at runtime the use of envvars is no big deal.
For example, say you have a per-shot display lut
(/job/$SHOT/.../shotgrade.3dl). You could run a script which sets up
the shot environment, launch the APP, and everything just works.

However, consider an image-viewing tool which needs to flipbook
multiple shots (or whole sequences) back to back. I.e., the display
transform, as queried from OCIO, would be different based on the shot
name. Would this approach be possible using an envvar mechanism? I
dont believe so. Envvars are commonly locked down at launch time.
And, even if you could modify it at runtime as playback was in
progress, would you want to? How would you notifiy OCIO that it had
changed? This seems like a tricky implementation, and strikes me as
going down the path of evil.

I would prefer to promote this concept of 'variables' to be an
explicit communications mechanism, rather then using envvars as a
back-door. Alternate implementation options include:

* a config->setVariable option, where variables were available for
use in color transforms. (They could even retain the $SHOW $SHOT
syntax). This way the OCIO plugin could set it as needed, and with
the python API exposed in client apps the list of variables could even
be amended with facility code, as needed at runtime!

* Alternatively, with a less stateful implementation the variables /
arguments could be passed along in the config->getProcessor call. This
may be preferable to those computer scientists among us.

Either way, this passing of variables as arguments to a transforms is
half of the work towards allowing fully dynamic colorspaces. (The
other 1/2 being the plugin API to define the lists of transforms at
runtime).

Perhaps this is good reason to move forward on both ASAP?

-- Jeremy
Re: Review: OCIO namespace update

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

Excellent, thanks.

On Thu, Oct 28, 2010 at 2:31 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Sorry I never noticed that section in the main CMakelists file, it all looks good.
Re: Review: OCIO namespace update

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

Sorry I never noticed that section in the main CMakelists file, it all looks good.

"Jeremy Selan" <jeremy...@...> wrote:

Can you be more specific? Which CMakeLists file, the root one or the
one in src/core?

The main CMake file has this chunk,

# Set the default namespace
if(NOT OCIO_NAMESPACE)
set(OCIO_NAMESPACE OpenColorIO CACHE STRING
"Specify the master OCIO C++ namespace: Options include
OpenColorIO OpenColorIO_<YOURFACILITY> etc."
FORCE)
endif(NOT OCIO_NAMESPACE)

What is not working for you?
Can you nuke your build dir and try again 'fresh'?

-- Jeremy

On Wed, Oct 27, 2010 at 11:10 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION
"${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..
Other than that it LGTM.
.malcolm
On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a

--
Sent from my phone.
Re: Review: OCIO namespace update

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

Can you be more specific? Which CMakeLists file, the root one or the
one in src/core?

The main CMake file has this chunk,

# Set the default namespace
if(NOT OCIO_NAMESPACE)
set(OCIO_NAMESPACE OpenColorIO CACHE STRING
"Specify the master OCIO C++ namespace: Options include
OpenColorIO OpenColorIO_<YOURFACILITY> etc."
FORCE)
endif(NOT OCIO_NAMESPACE)

What is not working for you?
Can you nuke your build dir and try again 'fresh'?

-- Jeremy

On Wed, Oct 27, 2010 at 11:10 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION
"${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..
Other than that it LGTM.
.malcolm
On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a
Re: Review: OCIO namespace update

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

I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION "${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..

Other than that it LGTM.

.malcolm

On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a
Re: Review: Updated cmake_minimum_required to 2.8

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

LGTM

On 27/10/2010, at 9:14 AM, Jeremy Selan wrote:

We already required cmake 2.8 (for ExternalProject usage), now this is explicit.

commits:
949855cca45431a6e813ac3b6f3688de0799f379
1961 - 1980 of 2197