Date   

Re: ociobakelut clamps tops?

Oliver Farkas <oliver...@...>
 

Hey guys,

Ben, I've tried what you suggested. The input is graded scene linear, the shaper is lin to log and the output is a log to Kodak2383 on a DCI screen. I assumed this would work, but when I applied the generated lut on top of a scene linear exr, then the result I got was a blown out image: everything was fully bright, I could only see few parts of the image, all the rest was white.

I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all. 

ociobakelut --inputspace scene_grey18 --outputspace scene_grey18

But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping. 

The exr files do have rgb values that go over 1.0, so maybe this problem's got to do something with that... but I'm not too sure what's happening. I'll try to dig into the code to see if I can find where this is coming from.

Thanks,
Oliver





On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote:
You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.

If I understood the code right, it does..

CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space

If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)

...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:

--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour

Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18

Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)

- Ben

On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote:

> Hmmm,
>
> Oliver - could you email be your jp_lin2log.lut (directly)?   I'd like
> to re-create this on my end.  Dont worry about the Kodak cube lut, I
> can use one of my own there instead.
>
> One thing I notice, the Dreamcolor family shouldnt be 'lin'.  I'd
> probably set it to 'Dreamcolor' on the absence of other information.
> (The family is often used to short-circuit conversions of the same
> type, but at differing bit depths).  I should probably update the API
> so people can leave it blank if they dont know it, and to assume the
> color-space name in that case).
>
> -- Jeremy
>
> On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
>> Hey guys,
>>
>> I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
>> opencolorio (0.8.0), but getting weird results. It clamps the tops, details
>> in the bright areas are completely gone. I'm wondering if I'm missing
>> something.
>>
>>
>> The command I'm using is this:
>>
>> ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
>> Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp
>>
>> The corresponding parts in the config.ocio look like this:
>>
>>
>>   - !<ColorSpace>
>>     name: scene_grey18
>>     family: lin
>>     bitdepth: 32f
>>     isdata: false
>>     gpuallocation: lg2
>>     gpumin: -15
>>     gpumax: 6
>>
>>
>>   - !<ColorSpace>
>>     name: Dreamcolor
>>     family: lin
>>     bitdepth: 32f
>>     isdata: false
>>     gpuallocation: uniform
>>     gpumin: 0
>>     gpumax: 1
>>     from_reference: !<GroupTransform>
>>       children:
>>          - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
>> 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
>>          - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
>>          - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
>> linear}
>>
>>
>>
>> Cheers,
>> Oliver
>>


Re: ociobakelut clamps tops?

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

You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.

If I understood the code right, it does..

CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space

If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)

...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:

--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour

Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18

Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)

- Ben

On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote:

Hmmm,

Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.

One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).

-- Jeremy

On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
Hey guys,

I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
opencolorio (0.8.0), but getting weird results. It clamps the tops, details
in the bright areas are completely gone. I'm wondering if I'm missing
something.


The command I'm using is this:

ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp

The corresponding parts in the config.ocio look like this:


- !<ColorSpace>
name: scene_grey18
family: lin
bitdepth: 32f
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6


- !<ColorSpace>
name: Dreamcolor
family: lin
bitdepth: 32f
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
from_reference: !<GroupTransform>
children:
- !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
- !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
- !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
linear}



Cheers,
Oliver


Re: ociobakelut clamps tops?

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

Hmmm,

Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.

One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).

-- Jeremy

On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
Hey guys,

I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
opencolorio (0.8.0), but getting weird results. It clamps the tops, details
in the bright areas are completely gone. I'm wondering if I'm missing
something.


The command I'm using is this:

ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp

The corresponding parts in the config.ocio look like this:


  - !<ColorSpace>
    name: scene_grey18
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: lg2
    gpumin: -15
    gpumax: 6


  - !<ColorSpace>
    name: Dreamcolor
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: uniform
    gpumin: 0
    gpumax: 1
    from_reference: !<GroupTransform>
      children:
         - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
         - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
         - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
linear}



Cheers,
Oliver


ociobakelut clamps tops?

Oliver Farkas <oliver...@...>
 

Hey guys,

I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest opencolorio (0.8.0), but getting weird results. It clamps the tops, details in the bright areas are completely gone. I'm wondering if I'm missing something.


The command I'm using is this:

ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp 

The corresponding parts in the config.ocio look like this:


  - !<ColorSpace>
    name: scene_grey18
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: lg2
    gpumin: -15
    gpumax: 6


  - !<ColorSpace>
    name: Dreamcolor
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: uniform
    gpumin: 0
    gpumax: 1
    from_reference: !<GroupTransform>
      children:
         - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814, 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
         - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
         - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation: linear}



Cheers,
Oliver


Review: Mari / OCIO Examples

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

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

This adds two examples demonstration an integration between
OpenColorIO and Mari (Foundry's texture painting app). This is very
much a work in progress, but still serves as a nice API integration
starting point. It is not expected that these will become part of the
OCIO install, but rather will be eventually shipped along inside of
Mari by default.

Note that you cannot test this code without Mari 1.3v2+, so it will be
hard for others to actually test this code. But it's still nice to
email this to ocio-dev to keep everyone in the development loop.

-- Jeremy


Review: boost_ptr convenience fix

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

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

When using the boost_ptr compatibility mode, previously clients would
need to know which option was used and to compile with the same
#define setting (which is error prone). Now, this value is baked into
the header for convenience.

This has been verified to not impact the ABI, and is appropriate for 0.8.

-- Jeremy


OCIO 0.7.9 / 0.8.0 Released

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

The time is ripe to lock off on a stable 0.8 release.

(We've actually been avoiding ABI breaks for awhile now, this should
be anti-climactic). New features / bug fixes will continue to be
welcome in 0.8, presuming they are low risk and the code is vetted.

-- Jeremy

**Version 0.8.0 (Apr 19 2011):**
* ABI Lockoff for stable 0.8 branch
New features can be added, but the ABI will only be extended in
a binary compatible manner
* Otherwise identical to 0.7.9

**Version 0.7.9 (Apr 18 2011):**
* Added support for .vf luts
* Misc. Nuke enhancements
* Adds optional boost ptr support (backwards compatibility)
* Makefile enhancements (Nuke / CMAKE_INSTALL_EXEC_PREFIX)
* cdlTransform.setXML crash fix


Added support for .vf luts

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


Review: Nuke OCIOColorSpace

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

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

OCIOColorSpace node now supports context overrides. Also, a few
additional code cleanups.

-- Jeremy


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...@...>
 

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...@...>
 

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

1721 - 1740 of 2226