Date   

OCIO 1.0.8 released

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

It's been a long time since our last release!

There have been a bunch of updates that have not made it into any
tagged release, and seeing as how we have a bunch of development work
in progress it seemed appropriate to release a tagged minor version
prior to adding the new code.

Version 1.0.8 (Dec 11 2012):
* After Effects plugin
* Core increased precision for matrix inversion
* Core md5 symbols no longer leaked
* CMake compatibility with OIIO 1.0 namespacing
* Cmake option to control python soname
* Nuke register_viewers defaults OCIODisplay to "all"
* Nuke ColorLookup <-> spi1d lut examples
* Windows uses boost shared_ptr by default
* Windows fixed csp writing
* Windows build fixes
* ociobakelut supports looks

-- Jeremy


Re: Foundry bugfixes to Nuke nodes?

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

Thanks for bringing this to our attention. I'll contact the foundry
and see if we can find out what they've done.

-- Jeremy

On Tue, Dec 11, 2012 at 4:30 AM, dbr/Ben <dbr....@...> wrote:
I was reading the release notes for Nuke,
http://thefoundry.s3.amazonaws.com/products/nuke/releases/7.0v1/7.0v1_ReleaseNotes.pdf
..and noticed a few items mentioning bug-fixes to OCIO nodes, like:

BUG ID 27628 - OCIO: OCIODisplay didn't update the Viewer correctly when
switching the layer control between all and custom layers.
Any one know if these changes are going to be commited back to the main
repo? Or if we should reproduce the bug and re-do the fixes, or something
like that

Since of course they have no obligation to share their modifications, I only
ask because at least one Foundry-dev contributed fixes already \o/
- Ben

--


Re: icc profile for photoshop

Andrew Britton <andrew.d...@...>
 

There are one, or two, more steps that need to be performed in Photoshop so that you can see the .icc in action. Unfortunately these aren't documented on the link. 
I can write it up and email it if you're interested. 

Andrew


On Dec 11, 2012, at 4:06 AM, dbr/Ben <dbr....@...> wrote:

That's correct! This guide should hopefully explain everything:


If you have access to a Linux machine, you could run ociobakelut on that, then copy the ICC profile to the Windows machine.

It's definitely possible to build on Windows, but building on Linux (or OS X) can be easier - it's been documented, and more widely tested

On 11/12/2012, at 10:20 PM, singha...@... wrote:

I am to compile ocio for windows. Before i do that certain questions crop in my mind.

correct me if i am wrong. Going thru the notes. I understand that to view images in a color space in photoshop I need to make icc profile.
and that too using ociobakelut.

iow, after compiling ocio for windows, one of the products ociobakelut will help create this icc profile from command line.

Is that it to it or is there something more. How exactly does this process go.

--
 
 

--
 
 


Upstreamable patches?

Richard Shaw <hobbe...@...>
 

Hey guys, been a while but things seem to be going well with my Fedora
package of ocio so I haven't needed to ask any questions lately.

I was going through my packages and noticed I have two patches against
the current 1.0.7 source which I think are upstreamable. I may have
already mentioned them but I've slept too many times since then to be
sure.

This one makes sure that no hidden files are packaged in the
documentation (found my rpmlint):
https://dl.dropbox.com/u/34775202/ocio/OpenColorIO-1.0.7-docfix.patch

This one gives me the option to no put a soname on the pyglue library:
https://dl.dropbox.com/u/34775202/ocio/OpenColorIO-1.0.7-pylib_no_soname.patch

Thanks,
Richard


Foundry bugfixes to Nuke nodes?

dbr/Ben <dbr....@...>
 

I was reading the release notes for Nuke,
..and noticed a few items mentioning bug-fixes to OCIO nodes, like:

> BUG ID 27628 - OCIO: OCIODisplay didn't update the Viewer correctly when switching the layer control between all and custom layers.

Any one know if these changes are going to be commited back to the main repo? Or if we should reproduce the bug and re-do the fixes, or something like that

Since of course they have no obligation to share their modifications, I only ask because at least one Foundry-dev contributed fixes already \o/
- Ben


Re: icc profile for photoshop

dbr/Ben <dbr....@...>
 

That's correct! This guide should hopefully explain everything:


If you have access to a Linux machine, you could run ociobakelut on that, then copy the ICC profile to the Windows machine.

It's definitely possible to build on Windows, but building on Linux (or OS X) can be easier - it's been documented, and more widely tested


On 11/12/2012, at 10:20 PM, singha...@... wrote:

I am to compile ocio for windows. Before i do that certain questions crop in my mind.

correct me if i am wrong. Going thru the notes. I understand that to view images in a color space in photoshop I need to make icc profile.
and that too using ociobakelut.

iow, after compiling ocio for windows, one of the products ociobakelut will help create this icc profile from command line.

Is that it to it or is there something more. How exactly does this process go.

--
 
 


Re: Bugs in Windows build process

Andrew Britton <andrew.d...@...>
 

I'd be happy to assist. I don't a wealth of experience with compilers or porting from Mac but I'll be happy to assist and test. I can also help build an installer for Windows.

On Dec 10, 2012, at 8:27 AM, Jeremy Selan <jeremy...@...> wrote:

We dont yet have a how to on the windows build process, though we
certainly would like to get one going!

(Are there any volunteers on the list to assist with this?) In the
long term, I think it would be preferable to include a windows
installer so that users dont have to build OCIO at all!

You should also know that Nuke 6.3v7 and above ship with OCIO (on all
platforms), so if you're only looking to experiment with OCIO, as a
Nuke user, you can just experiment with later versions.

-- Jeremy

On Sat, Dec 8, 2012 at 4:07 AM, <singha...@...> wrote:
It may occur silly to ask. do you have startup on how to build ocio for
windows. Does not matter if it gives a problem later...but a "how to start"
will greatly help,

what version of msvc should I go for. I want to first try for nuke 6.3v1.


On Thursday, May 31, 2012 12:02:09 AM UTC+5:30, Nathan Weston wrote:

After much struggle, I finally managed to get OCIO built on Windows, but
there are several apparent bugs in the build process that require manual
intervetion to work around.

I ran CMake from the Visual Studio 2008 command prompt (32-bit), with the
following command line:
cmake -D CMAKE_INSTALL_PREFIX=c:\ocio-em64t -D CMAKE_BUILD_TYPE=Release
^
-D OCIO_BUILD_STATIC=OFF -D BOOST_ROOT=c:\boost_1_49_0 ^
-D OCIO_BUILD_APPS=OFF -D OCIO_USE_BOOST_PTR=ON ^
-D PYTHON_VERSION="2.6.5" -D PYTHON_LIB=C:/Python26/libs ^
-D PYTHON_INCLUDE=C:/Python26/include ^
-D OCIO_LINK_PYGLUE=ON ^
-G "NMake Makefiles" ..\

Bug #1: I have to specifiy OCIO_BUILD_STATIC here, otherwise it will build
the static lib and the import lib at the same location -- the former
overwrites the latter, which prevents me from linking with the DLL.

Bug #2: The build fails with "NMAKE : fatal error U1073: don't know how to
make 'ext\dist\lib\libyaml-cppmd.lib'"

It turns out that yaml-cpp is built in debug mode, even though this is a
release build. So libyaml-cppmdd.lib (note the extra 'd') exists, but the
release version of the library (upon which OpenColorIO.dll depends) does
not. I worked around this by building yaml-cpp separately and copying the
correct lib into the build directory.

Bug #3: building the python bindings fails because PyDoc.h doesn't exist.
I worked around this by running createPyDocH.py manually.

I'm afraid CMake is something of a mystery to me so I can't offer much
help in the way of fixing these bugs. But if anyone has suggestions or
proposed fixes, I'm happy to try them out.

- Nathan
--

--


Re: Shameless Plug: VES Cinematic Color White Paper

Colin Doncaster <colin.d...@...>
 

A very useful reference, great work Jeremy et al.

On 2012-12-10, at 11:33 AM, Jeremy Selan <jeremy...@...> wrote:

A shameless plug: For those who may be interested, the VES just
released a white paper on motion-picture color management:

Press Release:
http://www.awn.com/news/technology/ves-releases-cinematic-color-white-paper

Download:
http://cinematiccolor.com/

For those familiar with the Siggraph course notes that used to be
posted there, you'll notice a bit of overlap. :)

And by all means, pick it to pieces. We welcome your corrections,
comments, etc at ves-tec...@....

Cheers,
Jeremy

--


Shameless Plug: VES Cinematic Color White Paper

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

A shameless plug: For those who may be interested, the VES just
released a white paper on motion-picture color management:

Press Release:
http://www.awn.com/news/technology/ves-releases-cinematic-color-white-paper

Download:
http://cinematiccolor.com/

For those familiar with the Siggraph course notes that used to be
posted there, you'll notice a bit of overlap. :)

And by all means, pick it to pieces. We welcome your corrections,
comments, etc at ves-tec...@....

Cheers,
Jeremy


Re: Bugs in Windows build process

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

We dont yet have a how to on the windows build process, though we
certainly would like to get one going!

(Are there any volunteers on the list to assist with this?) In the
long term, I think it would be preferable to include a windows
installer so that users dont have to build OCIO at all!

You should also know that Nuke 6.3v7 and above ship with OCIO (on all
platforms), so if you're only looking to experiment with OCIO, as a
Nuke user, you can just experiment with later versions.

-- Jeremy

On Sat, Dec 8, 2012 at 4:07 AM, <singha...@...> wrote:
It may occur silly to ask. do you have startup on how to build ocio for
windows. Does not matter if it gives a problem later...but a "how to start"
will greatly help,

what version of msvc should I go for. I want to first try for nuke 6.3v1.


On Thursday, May 31, 2012 12:02:09 AM UTC+5:30, Nathan Weston wrote:

After much struggle, I finally managed to get OCIO built on Windows, but
there are several apparent bugs in the build process that require manual
intervetion to work around.

I ran CMake from the Visual Studio 2008 command prompt (32-bit), with the
following command line:
cmake -D CMAKE_INSTALL_PREFIX=c:\ocio-em64t -D CMAKE_BUILD_TYPE=Release
^
-D OCIO_BUILD_STATIC=OFF -D BOOST_ROOT=c:\boost_1_49_0 ^
-D OCIO_BUILD_APPS=OFF -D OCIO_USE_BOOST_PTR=ON ^
-D PYTHON_VERSION="2.6.5" -D PYTHON_LIB=C:/Python26/libs ^
-D PYTHON_INCLUDE=C:/Python26/include ^
-D OCIO_LINK_PYGLUE=ON ^
-G "NMake Makefiles" ..\

Bug #1: I have to specifiy OCIO_BUILD_STATIC here, otherwise it will build
the static lib and the import lib at the same location -- the former
overwrites the latter, which prevents me from linking with the DLL.

Bug #2: The build fails with "NMAKE : fatal error U1073: don't know how to
make 'ext\dist\lib\libyaml-cppmd.lib'"

It turns out that yaml-cpp is built in debug mode, even though this is a
release build. So libyaml-cppmdd.lib (note the extra 'd') exists, but the
release version of the library (upon which OpenColorIO.dll depends) does
not. I worked around this by building yaml-cpp separately and copying the
correct lib into the build directory.

Bug #3: building the python bindings fails because PyDoc.h doesn't exist.
I worked around this by running createPyDocH.py manually.

I'm afraid CMake is something of a mystery to me so I can't offer much
help in the way of fixing these bugs. But if anyone has suggestions or
proposed fixes, I'm happy to try them out.

- Nathan
--


ocio for windows

Nishith Singhai <nishith...@...>
 

Hello,

             Is there a step by step guide to compile ocio for windows. I have been reading thru the articles. Not clear on how exactly to go about.

--
Thanking You,
Nishith P Singhai | Senior Programmer
FutureWorks Media  ltd
t: +91 22 401 45000 | c: +91 92 218 03205 | f: +91 22 267 40332

     


Re: .ICC not requiring --copyright info

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

yup, please clean up that error code too, thanks!

We should also try to take advantage of github for code-checkin
specific comments and discussions. I dont want to overwhelm people
with minutia of code on the email list... :)

-- Jeremy


On Thu, Dec 6, 2012 at 8:49 AM, Andrew Britton
<andrew.d...@...> wrote:
Should I pull out the code path in main.cpp that returns an error if --copyright is not set?
It seems vestigial at this point.

Sent from my iPhone

On Dec 5, 2012, at 9:45 PM, dbr/Ben <dbr....@...> wrote:

Your last sentence is right, it does not error because there is a default value for 'copyright':

std::string copyright = "OpenColorIO (Sony Imageworks)";

Whereas others like description are just:

std::string description;

I think it would only error if you did: ociobakelut --description "" (i.e an empty string)

On 06/12/2012, at 7:55 AM, Andrew Britton wrote:

I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?

Andrew

--

--

--


Re: .ICC not requiring --copyright info

Andrew Britton <andrew.d...@...>
 

Should I pull out the code path in main.cpp that returns an error if --copyright is not set?
It seems vestigial at this point.

On Dec 5, 2012, at 9:45 PM, dbr/Ben <dbr....@...> wrote:

Your last sentence is right, it does not error because there is a default value for 'copyright':

std::string copyright = "OpenColorIO (Sony Imageworks)";

Whereas others like description are just:

std::string description;

I think it would only error if you did: ociobakelut --description "" (i.e an empty string)

On 06/12/2012, at 7:55 AM, Andrew Britton wrote:

I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?

Andrew

--

--


Re: .ICC not requiring --copyright info

dbr/Ben <dbr....@...>
 

Your last sentence is right, it does not error because there is a default value for 'copyright':

std::string copyright = "OpenColorIO (Sony Imageworks)";

Whereas others like description are just:

std::string description;

I think it would only error if you did: ociobakelut --description "" (i.e an empty string)

On 06/12/2012, at 7:55 AM, Andrew Britton wrote:

I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?

Andrew

--


Re: Rendering per-shot grades with ocioconvert

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

i'd recommend also looking at oiio-tool (part of openimageio) as a
command-line image utility.

ocioconvert is super bare bones, and i'm actually consider moving into
the oiio project itself. (I dont like how oiio depends on ocio, but
the ocio utils depend on ocio. we can break this circular dependency
by moving ocio utilities that need oiio into oiio itself).

-- Jeremy

On Wed, Dec 5, 2012 at 2:55 PM, bsloan <bsl...@...> wrote:
*Adding*


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:

Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current
ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a
colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented.

Nag, nag nag.

Thanks again,

-blake

--
--transcribed from fMRI data using Google Thought Engine
--


Re: Rendering per-shot grades with ocioconvert

bsloan <bsl...@...>
 

*Adding*


On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine


Re: Rendering per-shot grades with ocioconvert

bsloan <bsl...@...>
 

Thanks all. Yes, I was able to get the desired result by add a colorspace to the config that applies the grade and the display LUT.

We're trying ocioconvert as a way to make LUT-baked jpeg proxies of EDR renders. Nuke, burdened with our facility customizations is too slow to launch per-frame and rvio is too expensive. For a shop that has an OCIO config dir and per-shot grades for every show, ocioconvert looks more like a free, off-the-shelf tool than an API tutorial.

:)



On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine


.ICC not requiring --copyright info

Andrew Britton <andrew.d...@...>
 

I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?

Andrew


Re: Rendering per-shot grades with ocioconvert

Brendan Bolles <bre...@...>
 

On Dec 4, 2012, at 2:59 PM, Blake Sloan wrote:

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

If you look at the spi-vfx configuration, the srgb8 and p3dci8 color spaces incorporate a film look using a 3D LUT. That's why you can use them as an output space but not an input space (the 3D LUT can't be inverted). To do different 3D LUTs for different shots with the software as it currently is, you could create a whole bunch of output color spaces (srgb8-shot1, srgb8-shot2, etc.) as Ben is suggesting.

OCIO has the ability to add a separate "looks" parameter via DisplayTransform.setLooksOverride() and other mechanisms, but none of the current software is using it and none of the sample configs have looks. I'm kind of surprised by that actually - does Sony not use per-shot color corrections and looks?


Brendan


Re: Rendering per-shot grades with ocioconvert

dbr/Ben <dbr....@...>
 

It would be easy to add an "ocioconvert --look blah" argument. Made a ticket for that:


I think ocioconvert is mainly intended as an example of how to use the OCIO API (as is ociodisplay), and facilities would tend to have their own comperable tool.. so it's not necessarily updated with new features (unless they are requested, as you have done!)

That is also one of the reasons there's quite so little documentation on it (along with the usual reasons for lack of documentation!). Ticket for that:


As for a workaround, you could define a colorspace which applies your look, something like:

colorspaces:
  - !<ColorSpace>
    name: lookworkaround
    to_reference: !<GroupTransform>
      children:
        - !<LookTransform> {src: lnf, dst: lnf, looks: "maingradelook,secondlook"}
        - !<FileTransform> {src: blah.spi3d, interpolation: linear}
        - !<ColorSpaceTransform> {src: lnf, dst: lg10}

Then do:
$ ocioconvert in.exr lnf out.exr lookworkaround

(haven't tested the above ColorSpace, and it's been months since I've written a config, but that should give you the general idea..)


On 05/12/2012, at 9:29 AM, Blake Sloan wrote:

Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine

--
 
 

1101 - 1120 of 2209