Date   

Re: OCIO 1.0 Build Issues On Snow Leopard

Jordan Soles <jor...@...>
 

This works like a charm now!

Thanks,
Jordan


Re: Pre-built libraries/examples for Windows?

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

As far as I know, Windows should be building right out of the box. I
presume you're using 1.0.X, correct?

Colin's email you cite below is from May. In August, the Foundry
committed 2 changes should make Windows builds work. (Mari is
currently shipping with OCIO on all platforms, so it at least works in
their build environment).

What specific issues are you seeing?

-- Jeremy

On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> wrote:
Hi all,
I'm resurrecting this thread to see about the current state of
building OCIO for Windows.
I was able to get Cmake to generate a VS 2008 solution, but it isn't
compiling.
Colin's list of fixes seem related to at least some of the errors I am
seeing.  I will try to implement these myself, but I was just curious
what successes/failures people have had building on Windows recently.

Has any further effort been put into Windows in the master git repo?


Thanks,
Paul


---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples for Windows?
To: OpenColorIO Developers


What problems were you having?

Cmake seems to generate usable MSCV 2008 solutions for me when I do

cmake -G "Visual Studio 9 2008 Win64" ..

in the build dir.

There were a few changes I've had to make to successfully compile the
OpenColorIO.lib file, here's a quick list


Re: Pre-built libraries/examples for Windows?

Paul Hudson <phuds...@...>
 

Hi all,
I'm resurrecting this thread to see about the current state of
building OCIO for Windows.
I was able to get Cmake to generate a VS 2008 solution, but it isn't
compiling.
Colin's list of fixes seem related to at least some of the errors I am
seeing. I will try to implement these myself, but I was just curious
what successes/failures people have had building on Windows recently.

Has any further effort been put into Windows in the master git repo?


Thanks,
Paul


---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples for Windows?
To: OpenColorIO Developers


What problems were you having?

Cmake seems to generate usable MSCV 2008 solutions for me when I do

cmake -G "Visual Studio 9 2008 Win64" ..

in the build dir.

There were a few changes I've had to make to successfully compile the
OpenColorIO.lib file, here's a quick list

- I had to download patch forwindows, this comes with Cygwin so just
make sure that's in your PATH environment
- I added an if( NOT WIN32 ) around the CMAKE_CXX_FLAGS as the
compiler wasn't happy with most of them
- I had to use _DUSE_BOOST_PTR=ON and then added INCLUDE_DIRECTORIES
( ${Boost_INCLUDE_DIRS} ) to the CMake file ( I assume everyone else
has boost in their global search paths on *nix systems? )
- I had to have add_definitions("-DWIN64") as the yaml code uses that
vs WIN32 to determine if it needs GCC specific template definitions
- defined an isnan to replace the missing std::isnan
- realpath doesn't exist onWindowsso I had to put PathCanonicalize in
a define instead and include Shlwapi.lib
- fixed the cmake file as the yaml and tinyxml STATIC_LINK paths are
explicitly pointing at *nix library names ( libtinyxml.a instead of
tinyxml.lib )

That seems to build fine.

Just to re-iterate though, the issue wasn't with CMake not working.

I can fork OCIO and make these changes and let someone else try it if
you want.

cheers

On 2011-05-23, at 5:49 AM, Peter wrote:







Hi Paul,
I've also been working on gettting awindowsversion of the OCIO
libraries here, and I ran into similar problems to you.
We managed to build the GCC version fine, but onwindowsI resorted to
just manually setting up a VC2005 project and pulling in whatever
files were necessary.
I'm hoping to look in to the cmake problems further this week so that
we can get a consistent build sytem across all platforms here. I''ll
post here anything I find out, and if you have any insights in this
area please feel free to share them with me too ;)
Regards,
Peter.
On May 20, 7:44 pm, Paul Miller <p....@...> wrote:
Hey folks. I'm starting to look at OCIO for integration into one or more of
my applications and am having trouble getting it built onWindows(my
primary dev machine). I use Visual Studio 2008. I downloaded from github and
tried using cygwin cmake, which doesn't know about VS, so I grabbed the
latest native CMake forWindowsand that was missing all sorts of
dependencies and creating vcproj files that wouldn't build. I'm likely doing
something wrong but I don't have any experience with cmake. Is there
step-by-step "how to build this onWindows, n00b" document? (I'm also having
trouble finding a native rst viewer).
I'll probably end up just compiling the code directly in anyway, but I want
to get built tools to play around with how it's "supposed to work" before I
dive in.
Thanks!


Re: OCIO 1.0 Build Issues On Snow Leopard

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

I've just rolled this patch into master. Jordan / dbr, please let me
know if you encounter any further issues on Lion.

-- Jeremy

On Sun, Oct 30, 2011 at 6:32 AM, dbr/Ben <dbr....@...> wrote:
Aha, setting SOVERSION on Python plugins causes this error, and this
only happened with SOVERSION evaluated as true in an if() statement
(i.e not zero!)

http://seclists.org/wireshark/2010/Sep/409

Opened pull request with a fix: https://github.com/imageworks/OpenColorIO/pull/175

On Oct 30, 10:58 pm, "dbr/Ben" <dbr....@...> wrote:
Actually, I'm still having the same error. The error occurs with the
following:

set(OCIO_VERSION_MAJOR 1)

..which sets

set(SOVERSION ${OCIO_VERSION_MAJOR} ...)

If that number is changed back to 0, it builds fine, which is slightly
bizarre, albeit related to the "-compatibility_version" in the error
message..

On Oct 28, 8:54 am, dbr/Ben <dbr....@...> wrote:







Could try with a clean build directory - I seem to recall having the same error when I just ran git pull and rerun "cmake .... && make build"
On 28/10/2011, at 6:37, Jeremy Selan <jeremy...@...> wrote:
I've built OCIO successfully on a clean install of snow leopard. Was
this a clean installation or an upgrade (for the OS install)?
-- Jeremy
On Thu, Oct 27, 2011 at 9:47 AM, Jordan Soles <jor...@...> wrote:
Hi All,
Wish I could have figured this out myself (I had no issues building pre-1.0
source on my MacBook Air Snow Leopard laptop, but I'm having issues building
the latest 1.0 source now.
I'm not doing anything crazy, and cmake actually doesn't complain at
all...but once I start the make I get the following error when the library
linking occurs:
Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with
-dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2
...any ideas?
Thanks,
Jordan


Re: Question about IIF config

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

Marie,
 
I am VERY late to the party but a linear spaced 32 or 64 segment lut from aces to a ssrt/odt will be insufficent.
You can create a ACES ADX-> rrt/odt  32 or 64 lut and get acceptable results.  
 
 
-Joseph


From: ocio...@... [mailto:ocio...@...] On Behalf Of Marie Fétiveau
Sent: Thursday, October 27, 2011 7:45 AM
To: ocio...@...
Subject: Re: [ocio-dev] Question about IIF config

Great :)
That's much much better.
Thanks a lot !
I still have some small differencies comparing OCIOColorspaceNode and my two TuttleCTL nodes.
But I need to compare with CTLRender just to be sure it's not a pb with TuttleCTL.

I have another pb. When I export a 3DLUT thanks to ociobakeLut and compare the resulting LUT (using a VectorField node) with the output of a OCIOColorspace node, there a noticable shift. 
Here's my command : ociobakelut --inputspace aces --outputspace rrt_sRGB --format flame aces_to_ODT_sRGB.3dl

Assuming it's a LUT approximation problem, I tried to export 32, 64 and 128 segments LUTs. And indeed, the more I add segments, the less the shift is important.
But even at 128 segments (which is huge), there's still a tiny shift.

May be the RRT is so complex that a linear sampled LUT couldn't be enough ?

Anyway, on the way out I noticed a bug in ociobakeLut using the --cubesize option and exporting 3dl : the header is always computed for 17 segments.
For exemple with cubesize=32 :
header = 0 64 128 192 256 320 384 448 512 575 639 703 767 831 895 959 1023
should be = 0   33   66   99   132   165   198   231   264   297   330   363   396   429   462   495   528   561   594   627   660   693   726   759   792   825   858   891   924   957   990   1023

Thanks again.

Marie

On Wed, Oct 26, 2011 at 12:11 AM, Jeremy Selan <jeremy...@...> wrote:

I just rolled out a new iif profile, with updated 3dluts.

You'll note that inside the iif profile (in the lutimages subdir) are
the lattice images used to bake the rrt / odt into 3d luts. So you
should be able to use these image to bake any rrts you may be using
into a lut suitable for inclusion in the profile.

Please let me know if, using this updated approach, you are not able
to recreate an identical result.

-- Jeremy

On Mon, Oct 10, 2011 at 2:58 PM, Jeremy Selan <jeremy...@...> wrote:
> Your example looks good to me.  Can you test the sub components of
> your transform?
>
> If you skip the ctl nodes, and only try the log2lin portions, does
> that result in an identity transform?
>
> Feel free to send me your lut files / .nk files offline, I'd be happy
> to take a look as well.
>
> -- Jeremy
>
> 2011/10/5 Marie Fétiveau <m...@...>:
>> Thanks for the quick answer and the explanation :)
>> I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
>> not sure to understand how it should work.
>> I started to give a quick try with the Nuke Log2Lin node to see what
>> happened.
>> So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
>> + ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
>> I also create a linToLog.cube (which correspond to Nuke LinToLog).
>> And I set the rrt_odt_r709 colorspace like this :
>> from_reference: !<GroupTransform>
>>       children:
>>         - !<FileTransform> {src: linToLog.cube, interpolation: linear}
>>         - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
>> linear}
>> When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
>> but there's a kind of offset + gamma shift...
>>  A picture is often better than a long talk away (I put the viewer in sRGB
>> instead linear to emphasize the shift on the screenshot).
>> Where's my mistake ?
>> Thanks a lot :)
>> Marie
>>
>> On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:
>>>
>>> Marie,
>>>
>>> Thanks for catching this!   The currently shipping IIF configuration
>>> is based on an older specification (I forget the exact version, but
>>> it's around 8 months old), so my hope is the versions will explain the
>>> differences you are seeing.  We've wanted to update to the latest RRT
>>> for awhile now, so let us take a stab at it and we'll see if it fixes
>>> everything.  We will also take care to note in the profile which RRT
>>> version it is specifically, to help avoid ambiguity in the future.
>>>
>>> The noise (discontinuity) you are seeing in the 3d RRT lut is an
>>> artifact of how we originally generated this table, we'll make sure
>>> it's all fixed in the updated version.
>>>
>>> The AllocationTransform you mention describes a linear -> log
>>> transform (a perfect mathematical log operator), where the range from
>>> ( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
>>> a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
>>> unwarping it through the inverse of the transform, and then applying
>>> the analytical rrt.
>>>
>>> Thanks!
>>>
>>> -- Jeremy
>>>
>>>
>>> 2011/10/4 Marie Fétiveau <m...@...>:
>>> > Hello all !
>>> > I'm having a look at IIF config.ocio and I was wondering how you build
>>> > the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
>>> > I'm asking because when I compare an OCIOColorspace node (in : aces, out
>>> > :
>>> > rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
>>> > another
>>> > with the REC701 softproof ODT), there are some differences :
>>> > - a small shift
>>> > - + some noise in yellows with OCIOColorspace node.
>>> > Here's a screenshot of my nuke scene and a jpg export
>>> > with TuttleCTL nodes
>>> > and an OpenColorIO Node.
>>> > For my tests, I'm using an XRite colorchart shot with a Red One and
>>> > exported
>>> > in EXR thanks to REDCineX (ACES option enabled).
>>> > am I mis-using the OCIOColorspace node ?
>>> > Anyway, I will be pleased to understand how the LUT was processed and
>>> > configured in the ocio config file.
>>> > I don't fully understand the purpose of the AllocationTransform vars
>>> > before
>>> > the FileTransform :
>>> > - !<ColorSpace>
>>> >     name: rrt_odt_r709
>>> >     family: rrt_odt_r709
>>> >     bitdepth: 32f
>>> >     isdata: false
>>> >     allocation: uniform
>>> >     allocationvars: [0, 1]
>>> >     from_reference: !<GroupTransform>
>>> >       children:
>>> >         - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
>>> > 5.52607]}
>>> >         - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
>>> > linear}
>>> >
>>> >
>>> > Thanks a lot !
>>> > Marie
>>
>>
>


Re: Question about IIF config

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

A fix for this was just committed to master:
https://github.com/imageworks/OpenColorIO/pull/177

Please let me know if you have any other compatibility issues with 3dl export.

-- Jeremy

On Mon, Oct 31, 2011 at 11:14 AM, Jeremy Selan <jeremy...@...> wrote:
This feels like a bug (not having the shaper lut obey the specified size).

If I remember correctly (the last time I tested at least) flame only
supportex size 17 luts, so even if we make the fix it wont effect
that.  The real test would be to validate the lustre can load a 3dl
with a sized 32 header.

-- Jeremy


2011/10/28 Marie Fétiveau <m...@...>:
Ok, I didn't figure out what were the particularities of "lustre" and
"flame" 3dl formats. That makes sense. I needed a 3dl so I used by default
the flame format.
But it is still strange to me : when using the --cubesize 32, the generated
LUT is really on 32 segments. Only the header is on 17 segments. If I
replace the 17 header by a 32 header, the LUT works on Nuke and RV (with a
17 header, I get weird colors).
Does that mean that Flame, always need a 17 header but can neverthemless
parse other size LUTs ?
thanks !
Marie


Review: ociobakelut improvements

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

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

Added options for specifying simple color corrections (such as
saturation, offsets, etc) in addition to normal lut commands. Also
allow for specification of forward and inverse luts (as supported by
the underlying OCIO library- still no inverse 3d luts allowed).

example: ociobakelut --lut filmlut.3dl --lut calibration.3dl --format
flame display.3dl
example: ociobakelut --lut look.3dl --offset 0.01 -0.02 0.03 --lut
display.3dl --format flame display_wlook.3dl

Config-Free LUT Baking
(all options can be specified multiple times, each is applied in order)
--lut %s Specify a LUT (forward direction)
--invlut %s Specify a LUT (inverse direction)
--slope %f %f %f slope
--offset %f %f %f offset (float)
--offset10 %f %f %f offset (10-bit)
--power %f %f %f power
--sat %f saturation (ASC-CDL luma coefficients)

-- Jeremy


Review: 3dl export shaper lut now matches 3dlut size

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

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

Previously, flame and lustre 3dl export was hard-coded to size 17
shaper luts, even when the cubelut was a different size (33x33x33 for
lustre, for example).

The new default is that the shaper will match the cube size, unless
manually overwritten on the commandline (in which case the specified
shaper size will be obeyed).

Example:

ociobakelut
--format lustre (writes 33 shaper + 33 cube)
--format flame (writes 17 shaper + 17 cube)
--format flame --cubesize 9 (writes 9 shaper + 9 cube)
--format flame --cubesize 9 --shapersize 33 (writes 33 shaper + 9 cube)

This addresses the issue Marie raised earlier in the week:
http://groups.google.com/group/ocio-dev/msg/e596bde48e1f199b

-- Jeremy


OCIO 1.0.1 released

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

Version 1.0.1 (Oct 31 2011):
* Luts with incorrect extensions are properly loaded
* ocio2icc / ociobakelut get --lut option (no longer requires ocio config)
* DisplayTransform looks do not apply to 'data' passes

-- Jeremy


Re: Question about IIF config

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

This feels like a bug (not having the shaper lut obey the specified size).

If I remember correctly (the last time I tested at least) flame only
supportex size 17 luts, so even if we make the fix it wont effect
that. The real test would be to validate the lustre can load a 3dl
with a sized 32 header.

-- Jeremy


2011/10/28 Marie Fétiveau <m...@...>:

Ok, I didn't figure out what were the particularities of "lustre" and
"flame" 3dl formats. That makes sense. I needed a 3dl so I used by default
the flame format.
But it is still strange to me : when using the --cubesize 32, the generated
LUT is really on 32 segments. Only the header is on 17 segments. If I
replace the 17 header by a 32 header, the LUT works on Nuke and RV (with a
17 header, I get weird colors).
Does that mean that Flame, always need a 17 header but can neverthemless
parse other size LUTs ?
thanks !
Marie


Re: OCIO 1.0 Build Issues On Snow Leopard

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

Aha, setting SOVERSION on Python plugins causes this error, and this
only happened with SOVERSION evaluated as true in an if() statement
(i.e not zero!)

http://seclists.org/wireshark/2010/Sep/409

Opened pull request with a fix: https://github.com/imageworks/OpenColorIO/pull/175

On Oct 30, 10:58 pm, "dbr/Ben" <dbr....@...> wrote:
Actually, I'm still having the same error. The error occurs with the
following:

set(OCIO_VERSION_MAJOR 1)

..which sets

set(SOVERSION ${OCIO_VERSION_MAJOR} ...)

If that number is changed back to 0, it builds fine, which is slightly
bizarre, albeit related to the "-compatibility_version" in the error
message..

On Oct 28, 8:54 am, dbr/Ben <dbr....@...> wrote:







Could try with a clean build directory - I seem to recall having the same error when I just ran git pull and rerun "cmake .... && make build"
On 28/10/2011, at 6:37, Jeremy Selan <jeremy...@...> wrote:
I've built OCIO successfully on a clean install of snow leopard. Was
this a clean installation or an upgrade (for the OS install)?
-- Jeremy
On Thu, Oct 27, 2011 at 9:47 AM, Jordan Soles <jor...@...> wrote:
Hi All,
Wish I could have figured this out myself (I had no issues building pre-1.0
source on my MacBook Air Snow Leopard laptop, but I'm having issues building
the latest 1.0 source now.
I'm not doing anything crazy, and cmake actually doesn't complain at
all...but once I start the make I get the following error when the library
linking occurs:
Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with
-dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2
...any ideas?
Thanks,
Jordan


Re: OCIO 1.0 Build Issues On Snow Leopard

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

Actually, I'm still having the same error. The error occurs with the
following:

set(OCIO_VERSION_MAJOR 1)

..which sets

set(SOVERSION ${OCIO_VERSION_MAJOR} ...)

If that number is changed back to 0, it builds fine, which is slightly
bizarre, albeit related to the "-compatibility_version" in the error
message..

On Oct 28, 8:54 am, dbr/Ben <dbr....@...> wrote:
Could try with a clean build directory - I seem to recall having the same error when I just ran git pull and rerun "cmake .... && make build"

On 28/10/2011, at 6:37, Jeremy Selan <jeremy...@...> wrote:







I've built OCIO successfully on a clean install of snow leopard. Was
this a clean installation or an upgrade (for the OS install)?
-- Jeremy
On Thu, Oct 27, 2011 at 9:47 AM, Jordan Soles <jor...@...> wrote:
Hi All,
Wish I could have figured this out myself (I had no issues building pre-1.0
source on my MacBook Air Snow Leopard laptop, but I'm having issues building
the latest 1.0 source now.
I'm not doing anything crazy, and cmake actually doesn't complain at
all...but once I start the make I get the following error when the library
linking occurs:
Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with
-dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2
...any ideas?
Thanks,
Jordan


Review: DisplayTransform looks are no longer automatically applied to 'data'

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

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

DisplayTransform looks are no longer automatically applied to 'data'
('data' being normals, pts, etc).

By design, colorspaces tagged as data do not have the display
transforms applied, and the fact that the looks were being applied was
an oversight.

DisplayTransforms that utilize the looksOverride functionality will be
unchanged.

-- Jeremy


Review: update to ociobakelut

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

Adds --lut option, which lets you create a baked output lut, even in
the absence of an input configuration.

Example:
ociobakelut --lut filmlut.3dl --lut calibration.3dl --format flame
lg_to_srgb.3dl

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

-- Jeremy


Review: Luts with incorrect file extensions are now correctly loaded

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

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

Luts with incorrect file extensions are now correctly loaded.

This was always the intent, but there was a bug in the implementation,
where were doing seekg on the filestream without clearing potential
error states beforehand.

-- Jeremy


Re: Question about IIF config

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

Thanks for the reply !

The Vectorfield node is a bit buggy - even if you write out a no-op lut (CMS test pattern->GenerateLUT) you get a luminance shift with several formats:

http://opencolorio.org/FAQ.html#what-are-the-differences-between-nuke-s-vectorfield-and-ociofiletransform
Ok, I didn't know that. I'll have a look, it's interesting !
I see in the table that 3dl are ok... But I'm using Nuke 6.2v4...

And I also have a shift with RV. Has RV a pb with 3dls too ?

Can you advice me a soft where a can surely check my LUT ?

Think the "ociobakut --format flame" and lustre 3dl bakers have fixed cube sizes, as I guess the applications only accept these sized LUT's?
Ok, I didn't figure out what were the particularities of "lustre" and "flame" 3dl formats. That makes sense. I needed a 3dl so I used by default the flame format.

But it is still strange to me : when using the --cubesize 32, the generated LUT is really on 32 segments. Only the header is on 17 segments. If I replace the 17 header by a 32 header, the LUT works on Nuke and RV (with a 17 header, I get weird colors).
Does that mean that Flame, always need a 17 header but can neverthemless parse other size LUTs ?

thanks !

Marie


Re: Question about IIF config

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

On 28/10/2011, at 1:15, Marie Fétiveau <m...@...> wrote:

compare the resulting LUT (using a VectorField node) with the output of a OCIOColorspace node, there a noticable shift.
The Vectorfield node is a bit buggy - even if you write out a no-op lut (CMS test pattern->GenerateLUT) you get a luminance shift with several formats:

http://opencolorio.org/FAQ.html#what-are-the-differences-between-nuke-s-vectorfield-and-ociofiletransform

Anyway, on the way out I noticed a bug in ociobakeLut using the --cubesize option and exporting 3dl : the header is always computed for 17 segments.
Think the "ociobakut --format flame" and lustre 3dl bakers have fixed cube sizes, as I guess the applications only accept these sized LUT's?

If that's true, would be easy to add a more generic --format 3dl that respects the cube size (and have the flame/lustre formats error usefully of you try and change the cube size)


Re: OCIO 1.0 Build Issues On Snow Leopard

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

Could try with a clean build directory - I seem to recall having the same error when I just ran git pull and rerun "cmake .... && make build"

On 28/10/2011, at 6:37, Jeremy Selan <jeremy...@...> wrote:

I've built OCIO successfully on a clean install of snow leopard. Was
this a clean installation or an upgrade (for the OS install)?

-- Jeremy

On Thu, Oct 27, 2011 at 9:47 AM, Jordan Soles <jor...@...> wrote:
Hi All,
Wish I could have figured this out myself (I had no issues building pre-1.0
source on my MacBook Air Snow Leopard laptop, but I'm having issues building
the latest 1.0 source now.
I'm not doing anything crazy, and cmake actually doesn't complain at
all...but once I start the make I get the following error when the library
linking occurs:

Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with
-dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2

...any ideas?
Thanks,
Jordan


Re: OCIO 1.0 Build Issues On Snow Leopard

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

I've built OCIO successfully on a clean install of snow leopard. Was
this a clean installation or an upgrade (for the OS install)?

-- Jeremy

On Thu, Oct 27, 2011 at 9:47 AM, Jordan Soles <jor...@...> wrote:
Hi All,
Wish I could have figured this out myself (I had no issues building pre-1.0
source on my MacBook Air Snow Leopard laptop, but I'm having issues building
the latest 1.0 source now.
I'm not doing anything crazy, and cmake actually doesn't complain at
all...but once I start the make I get the following error when the library
linking occurs:

Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with
-dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2

...any ideas?
Thanks,
Jordan


OCIO 1.0 Build Issues On Snow Leopard

Jordan Soles <jor...@...>
 

Hi All,

Wish I could have figured this out myself (I had no issues building pre-1.0 source on my MacBook Air Snow Leopard laptop, but I'm having issues building the latest 1.0 source now.

I'm not doing anything crazy, and cmake actually doesn't complain at all...but once I start the make I get the following error when the library linking occurs:

Linking CXX shared module PyOpenColorIO.so
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed with -dynamiclib
make[2]: *** [src/pyglue/PyOpenColorIO.1.0.0.so] Error 1
make[1]: *** [src/pyglue/CMakeFiles/PyOpenColorIO.dir/all] Error 2
make: *** [all] Error 2

...any ideas?

Thanks,
Jordan

1581 - 1600 of 2243