1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
Review(s): OCIOCDLTransform reverse option and others

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

First is some minor doc changes:

Second is a reverse checkbox for the OCIOCDLTransform node, and a "select cccid" button for the OCIOFileTransform (along with a question about determining the file format of a FileTransform)
https://github.com/imageworks/OpenColorIO/pull/101
NAB, Anyone?

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

If any OCIO users (or lurkers) are going to be at NAB next week, and
are interesting in meeting up, please send me an email. I'd love to
say hi in person.

(I will be there to talk about Katana (with native OCIO support) at
the Foundry booth.)
http://www.thefoundry.co.uk/articles/2011/04/05/230/come-and-visit-the-foundry-at-nab-2011-sl5625/

-- Jeremy
Review: Context Bugfix

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

https://github.com/imageworks/OpenColorIO/pull/98

This fixes two major bugs in OCIO::Context.

First, Context.getStringVar didnt work due to an incomplete definition
of the Compare funtion. (The consequence being that keys would be
sorted by string length, but for strings of equal length the wrong
value would be returned.).

Also, setStringVar (used in the Nuke context overrides) had no effect
due to a bug in the use of multimaps.

These have been verified to work now.

-- Jeremy
Review: Fixes a few compiler warnings

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

https://github.com/imageworks/OpenColorIO/pull/97

Fixes warnings when using -pedantic.

-- Jeremy
Review: Adds build option to use boost ptr instead of tr1

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

https://github.com/imageworks/OpenColorIO/pull/96

This adds a compile-time option to use boost ptr instead of tr1. The
tr1 ptr is defaut, but for folks who had already locked off on OCIO
0.7s ABI before the removal of boost (such a Imageworks), this lets us
compile without breaking binary compatibility. This code path will
also be necessary for windows support, which apparently does not have
tr1 support yet.

-- Jeremy
Re: Review: Build Nuke stuff into lib/nuke6.2

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

LGTM

long live the bubbles system ;)

On 04 Apr, 2011,at 11:25 PM, dbr/Ben <...@...> wrote:

https://github.com/imageworks/OpenColorIO/pull/94

Comment should explain the change best:

// Nuke aims to maintain API compatibilty between "v" releases, so
// compiling for 6.1v1 will work with 6.1v2 etc (but not
// 6.2v1). Only exception has been 5.1v5 and 5.1v6 (because it was
// supposed to be 5.2v1)
Mirrors how The Foundry's plugins are supplied (e.g Ocula downloads for 6.1/6.2). The info on 5.1v5-6 was from a message to nuke-dev a while ago.

Combined with the CMAKE_INSTALL_EXEC_PREFIX change, OCIO can now compile perfectly into RSP's project deployment/package management stuff \o/
Review: Build Nuke stuff into lib/nuke6.2

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

https://github.com/imageworks/OpenColorIO/pull/94

Comment should explain the change best:

// Nuke aims to maintain API compatibilty between "v" releases, so
// compiling for 6.1v1 will work with 6.1v2 etc (but not
// 6.2v1). Only exception has been 5.1v5 and 5.1v6 (because it was
// supposed to be 5.2v1)
Mirrors how The Foundry's plugins are supplied (e.g Ocula downloads for 6.1/6.2). The info on 5.1v5-6 was from a message to nuke-dev a while ago.

Combined with the CMAKE_INSTALL_EXEC_PREFIX change, OCIO can now compile perfectly into RSP's project deployment/package management stuff \o/
Review: OCIOCDLTransform node

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

https://github.com/imageworks/OpenColorIO/pull/93

As per #60 - a OCIOCDLTransform Nuke node, along with a bunch of buttons to import/export .cc/.ccc files

Not entirely sure about the node name, but OCIOCDLTransform seemed more consistent with CDLTransform in the config

There are buttons in the node to import and export a .cc file. Also a new Color > OCIO > Utils menu, to create a node for each ColorCorrection in a .ccc, and to export a bunch of nodes as a .ccc

If you import a .ccc file in the node, it'll display a "select a cccid" dialog - was planning to use the same dialog for the OCIOFileTransform, when a .ccc file is loaded
Re: OCIO for Windows

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

Hello Jeremy !

Thanks for your reply ;)

The IDT/ODTs we made are not already expressed in CTL. They are simple "matrix + transfer function" that can also be computed into 3DLUT.
I also have some samples (created by IIF) that are in CTL. I looked at some of them and it seems that they also describes matrix + function or LUT.

So, as I don't have a CTL_ToSthElse function for now, I think I'll just formulate them in OCIO vocabulary (firstly).

I made a branch but I never used Git before. 
That's a good oppotunity to become familiar with it.
I've just created a GitHub account and started to watch the OCIO project.
I merge my current version of the code with the last version on the remote master branch (good git training) but I didn't have time to check if it still compiles on MSVC. I guess it's not.
Please be aware that my modifications are tests draft ;p


Cheers,

Marie

On Fri, Apr 1, 2011 at 1:40 AM, Jeremy Selan <jeremy...@...> wrote:
Marie,

Thanks for the email.   In terms of testing OCIO with new IDT/ODTs,
are your transforms CTL programs, or have you formulated them in the
OCIO vocabulary. (luts, matricies, etc).

I believe you are the first to attempt to use it on Windows, though it
was always in our plan to add eventual support.  I suppose now is the
time to get it in.

Have you made a branch of the git repository?  Are you on github? I'd
love to see all the changes you've made. If you aren't familiar with
git and would prefer to send me diffs, that will be fine as well.

I'll try to find a Windows machine at work, so we can work through the
remaining compilation issues together.  Then if any changes are needed
for cross-platform compatibility, we can get them in before the 0.8
API lockdown.

Cheers,
Jeremy



2011/3/30 Marie Fétiveau <m...@...>:
> Hello all !
> I finally have some time to have look at OCIO ;)
> In a few words, I'd like in a near future to set up in my studio a Color
> Pipeline integrating IIF and OCIO improvements.
> I'm part of a french project (HD3D²) which is already working on IIF. I'd
> like to make a proof of concept and give one of my partner (using Windows) a
> chance to test OCIO with some IDT/ODT we made.
> For now my first goal is : compile OCIO tools (ociodisplay, ociocheck,
> ocio2icc, ociobakelut, ocioconvert) for Windows.
> My usual tools for building on Windows are Eclipse + Boost.build + Mingw
> ; I'm not used to MSVC and Cmake so much.
> I first started with my favorite toolset with Cmake instead of boost.build.
> But I quickly realized that to make OCIOdisplay works I'll have to compile
> all OIIO plugins with Mingw (meaning a lot of dependencies which isn't
> impossible but very time consuming).
> Furthermore, as Nuke's dll are built with MSVC I might encounter some
> troubles trying to mix MSVC and Mingw libraries.
> On other projects, I tried pexports and friends, it did work but not always.
> Consequently, as I needed some test tools fast, I changed my mind and
> started to build everything using MSVC2010.
> OIIO happened to be really easy to compile (thanks to pre-compiled
> libraries).
> For OCIO, I had to change some piece of code :
> - use boost::rand48 instead of srand48
> - comment part between  the "#pragma GCC visibility" in OCIOYaml.h
> - use _fullPath instead of ::realpath
> - use  boost::shared_ptr + boost::dynamic_pointer_cast instead
> of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
> - comment setStringVar and getStringVar because of some errors on
>  StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440:
> 'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>'
> to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
> - ... (some stuff about srand, isNan...)
> I guess that these changes may have a bad impact but for the moment it
> doesn't matter to me because I just need to see if I can get everything
> compiled.
> I 'm not so aware of the GCC's visibility pragmas.
> So that may be bad to have this part commented.
> Anyway it builds and I get OCIO libs (static and dynamic) and exes.
> But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find
> out that no LUT file formats are recognized.
> Each Lut format registers itself via the AutoRegister static variable but it
> seems that this function is not even present it my exe whereas it is present
> in the original .lib. This prevents my formats to be registered at startup.
> I tried debugging and the file format list was actually empty.
> I tried some options in the Visual project properties ( /OPT:NOREF for
> example) but didn't find any that works.
> So I tried to link dynamically with openColorIO and added  in
> opencolorabi.h :
> #if defined  _MSC_VER
> #if defined EXPORT_DLL
>     #define OCIOEXPORT __declspec(dllexport)
> #else
>   #define OCIOEXPORT  __declspec(dllimport)
> #endif
> #endif
> It creates a .lib for the corresponding OpenColorIO.dll.
> But when I run OCIOCheck.exe I get a crash when the program tries to load
> OpenColorIO.dll...
> So here I am, I won't have time to work on this until next week but I
> thought that some people may have build this for Windows or/and may have
> some advices for me ;)
> Thanks for reading :)
> Cheers,
> Marie
>
>
Review: Add CMAKE_INSTALL_EXEC_PREFIX option

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

Re: OCIO for Windows

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

Marie,

Thanks for the email. In terms of testing OCIO with new IDT/ODTs,
are your transforms CTL programs, or have you formulated them in the
OCIO vocabulary. (luts, matricies, etc).

I believe you are the first to attempt to use it on Windows, though it
was always in our plan to add eventual support. I suppose now is the
time to get it in.

Have you made a branch of the git repository? Are you on github? I'd
love to see all the changes you've made. If you aren't familiar with
git and would prefer to send me diffs, that will be fine as well.

I'll try to find a Windows machine at work, so we can work through the
remaining compilation issues together. Then if any changes are needed
for cross-platform compatibility, we can get them in before the 0.8
API lockdown.

Cheers,
Jeremy



2011/3/30 Marie Fétiveau <m...@...>:

Hello all !
I finally have some time to have look at OCIO ;)
In a few words, I'd like in a near future to set up in my studio a Color
Pipeline integrating IIF and OCIO improvements.
I'm part of a french project (HD3D²) which is already working on IIF. I'd
like to make a proof of concept and give one of my partner (using Windows) a
chance to test OCIO with some IDT/ODT we made.
For now my first goal is : compile OCIO tools (ociodisplay, ociocheck,
ocio2icc, ociobakelut, ocioconvert) for Windows.
My usual tools for building on Windows are Eclipse + Boost.build + Mingw
; I'm not used to MSVC and Cmake so much.
I first started with my favorite toolset with Cmake instead of boost.build.
But I quickly realized that to make OCIOdisplay works I'll have to compile
all OIIO plugins with Mingw (meaning a lot of dependencies which isn't
impossible but very time consuming).
Furthermore, as Nuke's dll are built with MSVC I might encounter some
troubles trying to mix MSVC and Mingw libraries.
On other projects, I tried pexports and friends, it did work but not always.
Consequently, as I needed some test tools fast, I changed my mind and
started to build everything using MSVC2010.
OIIO happened to be really easy to compile (thanks to pre-compiled
libraries).
For OCIO, I had to change some piece of code :
- use boost::rand48 instead of srand48
- comment part between  the "#pragma GCC visibility" in OCIOYaml.h
- use _fullPath instead of ::realpath
- use  boost::shared_ptr + boost::dynamic_pointer_cast instead
of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
- comment setStringVar and getStringVar because of some errors on
 StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440:
'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>'
to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
- ... (some stuff about srand, isNan...)
I guess that these changes may have a bad impact but for the moment it
doesn't matter to me because I just need to see if I can get everything
compiled.
I 'm not so aware of the GCC's visibility pragmas.
So that may be bad to have this part commented.
Anyway it builds and I get OCIO libs (static and dynamic) and exes.
But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find
out that no LUT file formats are recognized.
Each Lut format registers itself via the AutoRegister static variable but it
seems that this function is not even present it my exe whereas it is present
in the original .lib. This prevents my formats to be registered at startup.
I tried debugging and the file format list was actually empty.
I tried some options in the Visual project properties ( /OPT:NOREF for
example) but didn't find any that works.
So I tried to link dynamically with openColorIO and added  in
opencolorabi.h :
#if defined  _MSC_VER
#if defined EXPORT_DLL
    #define OCIOEXPORT __declspec(dllexport)
#else
  #define OCIOEXPORT  __declspec(dllimport)
#endif
#endif
It creates a .lib for the corresponding OpenColorIO.dll.
But when I run OCIOCheck.exe I get a crash when the program tries to load
OpenColorIO.dll...
So here I am, I won't have time to work on this until next week but I
thought that some people may have build this for Windows or/and may have
some advices for me ;)
Thanks for reading :)
Cheers,
Marie
Re: 0.7.8 Released

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

A big heads up I forgot to mention, 0.7.8 is not binary compatible
with 0.7.7 due to the boost ptr change. My hope (and intent) is for
this to be the final binary incompatible change before locking off on
0.8.x stable releases (hopefully in the next week or two).

-- Jeremy

On Thu, Mar 31, 2011 at 3:41 PM, Jeremy Selan <jeremy...@...> wrote:
Version 0.7.8:
   * Iridas lut (.cube) bugfix, DOMAIN_MIN / DOMAIN_MAX now obeyed
   * Exposed GPU functions in python (needed for Mari)
   * Nuke OCIODisplay cleanup: Fixed knob names and added envvar support
   * ociobaker cleanup
   * tinyxml ABI visibility cleaned up
   * Removed Boost dependency, tr1::shared_ptr now used instead

-- Jeremy
0.7.8 Released

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

Version 0.7.8:
* Iridas lut (.cube) bugfix, DOMAIN_MIN / DOMAIN_MAX now obeyed
* Exposed GPU functions in python (needed for Mari)
* Nuke OCIODisplay cleanup: Fixed knob names and added envvar support
* ociobaker cleanup
* tinyxml ABI visibility cleaned up
* Removed Boost dependency, tr1::shared_ptr now used instead

-- Jeremy
OCIO for Windows

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

Hello all !

I finally have some time to have look at OCIO ;)

In a few words, I'd like in a near future to set up in my studio a Color Pipeline integrating IIF and OCIO improvements.
I'm part of a french project (HD3D²) which is already working on IIF. I'd like to make a proof of concept and give one of my partner (using Windows) a chance to test OCIO with some IDT/ODT we made.

For now my first goal is : compile OCIO tools (ociodisplay, ociocheck, ocio2icc, ociobakelut, ocioconvert) for Windows.

My usual tools for building on Windows are Eclipse + Boost.build + Mingw ; I'm not used to MSVC and Cmake so much.

I first started with my favorite toolset with Cmake instead of boost.build.
But I quickly realized that to make OCIOdisplay works I'll have to compile all OIIO plugins with Mingw (meaning a lot of dependencies which isn't impossible but very time consuming). 
Furthermore, as Nuke's dll are built with MSVC I might encounter some troubles trying to mix MSVC and Mingw libraries.
On other projects, I tried pexports and friends, it did work but not always.

Consequently, as I needed some test tools fast, I changed my mind and started to build everything using MSVC2010.

OIIO happened to be really easy to compile (thanks to pre-compiled libraries).

For OCIO, I had to change some piece of code :
- use boost::rand48 instead of srand48
- comment part between  the "#pragma GCC visibility" in OCIOYaml.h 
- use _fullPath instead of ::realpath
- use  boost::shared_ptr + boost::dynamic_pointer_cast instead of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
- comment setStringVar and getStringVar because of some errors on  StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440: 'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>' to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
- ... (some stuff about srand, isNan...)

I guess that these changes may have a bad impact but for the moment it doesn't matter to me because I just need to see if I can get everything compiled. 
I 'm not so aware of the GCC's visibility pragmas.
So that may be bad to have this part commented. 

Anyway it builds and I get OCIO libs (static and dynamic) and exes.

But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find out that no LUT file formats are recognized. 
Each Lut format registers itself via the AutoRegister static variable but it seems that this function is not even present it my exe whereas it is present in the original .lib. This prevents my formats to be registered at startup. I tried debugging and the file format list was actually empty.
I tried some options in the Visual project properties ( /OPT:NOREF for example) but didn't find any that works.

So I tried to link dynamically with openColorIO and added  in opencolorabi.h :
#if defined  _MSC_VER
#if defined EXPORT_DLL
    #define OCIOEXPORT __declspec(dllexport)
#else
  #define OCIOEXPORT  __declspec(dllimport)
#endif
#endif
It creates a .lib for the corresponding OpenColorIO.dll.

But when I run OCIOCheck.exe I get a crash when the program tries to load OpenColorIO.dll...

So here I am, I won't have time to work on this until next week but I thought that some people may have build this for Windows or/and may have some advices for me ;)

Thanks for reading :)

Cheers,

Marie
Review: Iridas (.cube) lut bugfix

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

https://github.com/imageworks/OpenColorIO/pull/90

Bugfix in Iridas (.cube) lut support. DOMAIN_MIN / DOMAIN_MAX now supported.
(also fixes a bug in Lut3DOp. from_min, from_max are now obeyed when
using linear interpolation.)

Thanks to Alex F. for providing lut example.

-- Jeremy
Review: Exposed Processor GPU functions to python

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

https://github.com/imageworks/OpenColorIO/pull/89

First step in the development of the Mari OCIO viewer plugin.

-- Jeremy
Review: Benign header cleanup

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

https://github.com/imageworks/OpenColorIO/pull/88

Removed OpenColorABI.h. Simpler just to put all the compiler specific
stuff in one header, OpenColorTypes.h
This doesnt effect ABI or code compatibility.

closes GH-57
Review: First pass at a ICCTransform

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

https://github.com/imageworks/OpenColorIO/pull/87

Had sometime on the plane so did a first pass at a ICCTransform, which will be needed for 'iv color profiles/LUTs' on the https://github.com/OpenImageIO/oiio/wiki/GSoC-Idea-Page.

Would like some feedback on where the filepath resolution should be? It's easy for me to add this in the Op but most other things have this in the Transform, is this where this logic should sit?

I have not implemented the setInputMem(const void * inputPtr, int size) functions yet, but have added these to the transform interface, these would be used when loading icc profile embedded in file headers.

.malcolm
Review: Updated Nuke OCIODisplay, added config.getCacheID(), context.getCacheID(), ClearAllCaches()

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

https://github.com/imageworks/OpenColorIO/pull/84

nuke ociodisplay: ocio_populate_viewer works again
nuke ociodisplay: Renamed viewer knobs to "gain" and "gamma". This
allows them, when used as ViewerOps, to be driven by the existing
monitor interface.
nuke ociodisplay: added prototype for channel swizzling support. This
can't be enabled though until the OCIO cpu path supports alpha channel
handling (otherwise 'alpha' visualization wont be supported)
nuke ociodisplay: Added context support (per shot support)
core library: configs, and contexts can report cacheIDs.
Added OCIO::ClearAllCaches(), which will drop all cached information
about files on disk. (Will cause luts to be reloaded on next use)

closes GH-46
closes GH-15

-- Jeremy
Interesting article: How to use github effectively

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

Not directly related to OCIO, but I thought those github users on the
list may enjoy this article:
http://lumberjaph.net/dancer/2011/03/06/how_to_use_github_effectively_for_your_project.html

My favorite tip: if you include in your commit comment text such as,
"closes GH-123", it will automatically close the specified issue, and
link to the commit. How cool!

-- Jeremy
1701 - 1720 of 2197