|
Re: Review: OCIO namespace update
Malcolm Humphreys <malcolmh...@...>
Sorry I never noticed that section in the main CMakelists file, it all looks good.
toggle quoted message
Show quoted text
"Jeremy Selan" <jeremy...@...> wrote: Can you be more specific? Which CMakeLists file, the root one or the --
Sent from my phone. |
|
|
|
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: 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. Your approach to implementing per-shot looks - using environmentJS: I think it will be preferable when possible to minimize the use of envvars.MH: Can you elaborate on this? 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: Reference !<Colorspace>
Joseph Slomka <jsl...@...>
Rod,
toggle quoted message
Show quoted text
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----- |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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
toggle quoted message
Show quoted text
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, |
|
|
|
Review: Added missing role enum to python
Jeremy Selan <jeremy...@...>
Trivial addition, exposed ROLE_DEFAULT to python.
commit 82dd5a4666f7c5456361e9ec7d78107742e5b427 -- Jeremy |
|
|
|
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 |
|
|
|
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-- Larry Gritz l...@... |
|
|
|
Re: ocio_core_tests linking issue on Ubuntu 10.10
Est <rame...@...>
I had the same problem. It happens when you link to the
toggle quoted message
Show quoted text
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 |
|
|
|
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 toThe build completes successfully commenting out that line. 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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
Re: Review: Added missing role enum to python
Malcolm Humphreys <malcolmh...@...>
LGTM On 03 Nov, 2010,at 09:26 AM, Jeremy Selan <jere...@...> wrote:
|
|
|
|
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:
|
|
|
|
Re: Review: Added missing role enum to python
Malcolm Humphreys <malcolmh...@...>
LGTM On 03 Nov, 2010,at 09:26 AM, Jeremy Selan <jere...@...> wrote:
|
|
|
|
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:
|
|
|
|
Re: Review: Inital pass at searchpath impl
Malcolm Humphreys <malcolmh...@...>
Hi,
It might have to wait a few weeks, I'm in Hong Kong right now and I'm going to be MIA in asia for a bit. But yes a chat would be good when we are both free.
They are a common mechanism for setting up initial state for a lot of apps. This being similar is a nice entry point for integration with existing systems. But I agree the env vars should only be used to setup the initial state. Even if it is possible to change this state with setenv()'s I would discourage this use with a better interface for changing state during execution, similar to what you have suggested. Most places have some form of setshot system which bootstraps the env for a shot, not just for color but things like the required toolchain for that artist session doing task A (I'm guessing you have something similar at SPI). I can guarantee that I would need to write something that grabbed env's and setup an initial state through which ever interface we settle on. I would prefer that this ocio env wrapper type code was internal rather than each shop doing it slightly differently.
+1 Being able to setup/enfoce the initial state like this is important for multiple dept / group workflows. Who are most likely using diffrent toolchains but require to start with the same consistent viewing env between them. In this style of setup each person gets pushed the currently approved viewing env for that session and are not concerned with modification of it.
Neither do I, that would be a bit clumsy for that specific problem.
I think a mixture of the two ideas could work well (see below).
I was thinking the same kind of thing, but with the possibility of these grabbing their initial value from the env (if it exists). I'm also thinking it might be better to be explicit with globals eg. config->addglobal(name) these would end up as a list in the yaml profile. Only the $globals in this list would be expanded and also the only ones initialized from the env. (This does resolve my niggles with the current expand code which has the potential to be a bit slow, if used in many) These globals could be set/get dynamically at run-time ie config->getglobal(), config->setglobal(). I would prefer to call these globals over variables as it suggests their scope. Right now I only see a direct use for globals with string parameters and would only want to add support for other types if we had a strong need for them. As an example this would be nearly a complete list of globals I could see a use for ($JOB, $SCENE, $SEQ, $SHOT, $TASK, $USERGROUP, $BALLANCE_GRADE, $CREATIVE_GRADE, $EDIT_GRADE). I'm sure these have slightly different names per shop but represent the same concepts.
I definitely would like some form of dynamic parameters/variables, but these should be something different to globals.
With the prospect of multiple image sequences / clips with transforms, configs and or grades. For these case are you proposing that we setup a single config and then store some kind of ocio processor relationship per clip?
It would be great to flesh this out as it would be good for client apps not to need to manage the details of this per clip state storage if this is the way we are thinking of going. .malcolm |
|
|