Date   

Re: Documentation issues

Paul Miller <pa...@...>
 

On 6/11/2012 12:03 PM, Jeremy Selan wrote:
Good idea. I'll make a runtime button to switch between the two. That
will also let us confirm the two code paths give similar results. ;)
I just got out of a bad relationship with some code that was handed to me that was full of #ifdefs, so I thought I'd try to do a solid for everyone else and recommend against them. :-)


On Mon, Jun 11, 2012 at 9:43 AM, Paul Miller<pa...@...> wrote:
On 6/11/2012 11:36 AM, Jeremy Selan wrote:

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

If you can, make it switchable between the two during run-time, or as a
command-line switch. #ifdefs make the code harder to read.


Re: Documentation issues

Boudewijn Rempt <bo...@...>
 

On Monday 11 June 2012 Jun, Jeremy Selan wrote:
Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.
https://github.com/imageworks/OpenColorIO/blob/master/docs/developers/usage_examples.rst -- the "Displaying an image, using the CPU (Full Display Pipeline)" section.

I'd have attached a patch for the docs if I knew for sure what the right way would be :-).


I'd recommend looking into src/apps/ociodisplay/main.cpp
Okay!

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.
Yeah -- it could be nice, or two next to each other, just to show the difference. Also to show the difference in performance.


See UpdateOCIOGLState(), up to the processor = config->getProcessor(transform);
At that point, you can directly apply the processor to perform and
in-place color conversion on your image.

// Wrap the image in a light-weight ImageDescription
OCIO::PackedImageDesc img(imageData, w, h, 4);

// Apply the color transformation (in place)
processor->apply(img);

Unfortunately we dont offer native support for half-float buffers on
the CPU side, so in the meantime you will need to copy to float32.
Okay, that's fine, as long as I know.

The reason some applications expose file selectors is for people who
dont want to use OCIO configurations, but still want to be able to use
raw existing luts. (This is essentially for backwards compatibility).
I would say to not worry about this for now, for an initial
implementation.
Right -- thanks for the hint. Krita comes from the icc world, despite having had openexr support for half a decade now, so there's a bit of mental adaptation to be made.

By the way, I would *highly* recommend looking into using the GPU
pathway for creating a display.
Yes, that's next on my todo. We try to support both cpu and gpu with Krita as much as possible, but we're rewriting our gpu-based canvas implementation at the moment, so I thought I'd get started with the cpu path.

(You should be able to steal much of
the code from src/apps/ociodisplay/main.cpp). For places where
you're baking color transforms into images (loading/saving images,
etc) the CPU pathway is preferred. But for situations where you will
be playing back image sequences to the display, or handling pan/zoom
with frequent updates (real-time preview), the GPU pathway is much
higher performance. Also, when using the GPU codepath you can store
the underlying image in any data type you like. (such as half float,
or even integer should your color-space be amenable to it).
Thanks for all the hints! I'll let you know when I've got more questions or can report that Krita is one of the apps that support OpenColorIO :-)
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: Documentation issues

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

Good idea. I'll make a runtime button to switch between the two. That
will also let us confirm the two code paths give similar results. ;)

On Mon, Jun 11, 2012 at 9:43 AM, Paul Miller <pa...@...> wrote:
On 6/11/2012 11:36 AM, Jeremy Selan wrote:

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at?  I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway.  (Actually, maybe I should
have ifdef's for CPU vs GPU?  It's a nice example.

If you can, make it switchable between the two during run-time, or as a
command-line switch. #ifdefs make the code harder to read.


Re: Documentation issues

Paul Miller <pa...@...>
 

On 6/11/2012 11:36 AM, Jeremy Selan wrote:
Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.
If you can, make it switchable between the two during run-time, or as a command-line switch. #ifdefs make the code harder to read.


Re: Documentation issues

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

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

See UpdateOCIOGLState(), up to the processor = config->getProcessor(transform);
At that point, you can directly apply the processor to perform and
in-place color conversion on your image.

// Wrap the image in a light-weight ImageDescription
OCIO::PackedImageDesc img(imageData, w, h, 4);

// Apply the color transformation (in place)
processor->apply(img);

Unfortunately we dont offer native support for half-float buffers on
the CPU side, so in the meantime you will need to copy to float32.


The reason some applications expose file selectors is for people who
dont want to use OCIO configurations, but still want to be able to use
raw existing luts. (This is essentially for backwards compatibility).
I would say to not worry about this for now, for an initial
implementation.


By the way, I would *highly* recommend looking into using the GPU
pathway for creating a display. (You should be able to steal much of
the code from src/apps/ociodisplay/main.cpp). For places where
you're baking color transforms into images (loading/saving images,
etc) the CPU pathway is preferred. But for situations where you will
be playing back image sequences to the display, or handling pan/zoom
with frequent updates (real-time preview), the GPU pathway is much
higher performance. Also, when using the GPU codepath you can store
the underlying image in any data type you like. (such as half float,
or even integer should your color-space be amenable to it).

-- Jeremy

On Mon, Jun 11, 2012 at 1:50 AM, Boudewijn Rempt <bo...@...> wrote:
Hi!

I'm trying to integrate OpenColorIO into Krita, a 2D painting application
written in C++, and I'm having a bit of trouble with the documentation.

I'm first implementing the CPU path in Krita, GPU will follow. In the CPU
display example, it says

const char * transformName = config->getDefaultDisplayTransformName(device);

I suspect that this should be

const char *  view = config->getDefaultView(displayDevice);

and

transform->setDisplayColorSpaceName( displayColorSpace );

doesn't exist anymore either, so I'm setting view and display on the
transform.

Then I was looking at the mari toobar code, since that probably is closest
to what Krita needs. I don't get why there is a separate file selector for
lut files -- aren't those referenced in the config.ocio file to define the
colorspaces I can get from the config object?

Finally (for now) does OpenColorIO support half as well as float? If not,
I'll need to convert my half data to float before going through ocio -- not
that big a problem, of course, but I would prefer to keep copying and
conversion to a minimum.

--
Boudewijn Rempt, http://krita.org


Bugs in Windows build process

Nathan Weston <elb...@...>
 

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: A simple question About OIIO and OCIO

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

Hi Alex :) you should have a go at using the ocio java binding. It would be pretty straight forward to create a web service that would return a jpg with a ocio transform burnt in.

Jeremy Selan <jere...@...> wrote:

Sorry for the delay.

Yah, oiiotool is definitely your way forward.

There currently isnt a way to apply .cc or .ccc grades, except using ociobakelut (and even then, this just bakes it into another lut, not into an image).

But this is an oversight; we'd love to add an oiiotool --lut and --invlut option.  (or whatever it's called).  Probably wouldn't be too difficult. Probably < 50 lines of code or so.

Alex, any interest in giving it a shot?  If so, I'm happy to sketch out the overall design for what to add where.  If you're not up for it, I'm happy to try and knock it out later this month.

-- Jeremy




On Fri, May 18, 2012 at 11:03 PM, Alex Fry <ale...@...> wrote:
Cool, so oiiotool is considered the way forward then?

Out if interest, do you know if it's possible to apply .cc or .ccc grades via any of the command line tools (ocioconvert or oiiotool)?

I'm tooling around with the possibility of making a web app to apply CDL grades and display EXR frames in a browser (as a jpg proxy). 

-Alex

--
Alex Fry

On Saturday, 19 May 2012 at 2:41 PM, Jeremy Selan wrote:

ocioconvert is a demo app that's not really needed.  if you'd like to do color conversions, we'd recommend installing OCIO, then installing OIIO (with OCIO build-time depencency) and then trying oiio-tool --colorconvert


On Fri, May 18, 2012 at 6:14 PM, Alex Fry <ale...@...> wrote:
Ahh! I had no idea OCIO could be installed view brew..
Very neat..
Unfortunately it doesn't build it against OIIO, so its still missing ocioconvert.

But I found my original problem:
Stupidly I was using:
export OCIO_PATH=~/Developer/oiio/dist/macosx
rather than:
export OCIO_PATH=/Users/alex/Developer/oiio/dist/macosx

Thanks again
Alex



On Saturday, 19 May 2012 at 10:51 AM, Jeremy Selan wrote:

Are you on OSX?  Have you considered homebrew package manager?

I've never tried it, but if it works as advertised that would make a system install of OCIO simple.

http://mxcl.github.com/homebrew/
http://braumeister.org/formula/opencolorio
http://braumeister.org/formula/openimageio

-- Jeremy

On Fri, May 18, 2012 at 5:46 PM, Alex Fry <ale...@...> wrote:
Was there an easy answer to this?

I'm running into the same problem.

-Alex

On Dec 20 2011, 4:12 pm, Jeremy Selan <jeremy...@...> wrote:
> Hmmm... That should work.  Maybe without the trailing slash on OIIO_PATH?
> (though i wouldnt expect it to make a difference).
>
> Perhaps you built it previously without OIIO support, and now the cmake
> files are out of date?  I'd rm the build directory and try again.
>
> Maybe email the exact build command you're using / output (offline)?
>
> -- Jeremy
>
>
>
>
>
>
>
> On Mon, Dec 19, 2011 at 8:44 PM, Joe <joseph...@...> wrote:
> > Hey all,
> > I'm now trying to build OCIO with the OIIO enabled.  I have built OIIO
> > and it is working  but when I set OIIO_PATH=/Users/josephslomka/
> > Documents/git/oiio/dist/macosx/
> > where I built OIIO
> > I still get the
> >  -- OIIO not found. Specify OIIO_PATH to locate it
> > from cmake.
>
> > Can anyone point me in the right direction?
>
> > Thanks.
> > -Joseph






Re: A simple question About OIIO and OCIO

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

Sorry for the delay.

Yah, oiiotool is definitely your way forward.

There currently isnt a way to apply .cc or .ccc grades, except using ociobakelut (and even then, this just bakes it into another lut, not into an image).

But this is an oversight; we'd love to add an oiiotool --lut and --invlut option.  (or whatever it's called).  Probably wouldn't be too difficult. Probably < 50 lines of code or so.

Alex, any interest in giving it a shot?  If so, I'm happy to sketch out the overall design for what to add where.  If you're not up for it, I'm happy to try and knock it out later this month.

-- Jeremy




On Fri, May 18, 2012 at 11:03 PM, Alex Fry <ale...@...> wrote:
Cool, so oiiotool is considered the way forward then?

Out if interest, do you know if it's possible to apply .cc or .ccc grades via any of the command line tools (ocioconvert or oiiotool)?

I'm tooling around with the possibility of making a web app to apply CDL grades and display EXR frames in a browser (as a jpg proxy). 

-Alex

--
Alex Fry

On Saturday, 19 May 2012 at 2:41 PM, Jeremy Selan wrote:

ocioconvert is a demo app that's not really needed.  if you'd like to do color conversions, we'd recommend installing OCIO, then installing OIIO (with OCIO build-time depencency) and then trying oiio-tool --colorconvert


On Fri, May 18, 2012 at 6:14 PM, Alex Fry <ale...@...> wrote:
Ahh! I had no idea OCIO could be installed view brew..
Very neat..
Unfortunately it doesn't build it against OIIO, so its still missing ocioconvert.

But I found my original problem:
Stupidly I was using:
export OCIO_PATH=~/Developer/oiio/dist/macosx
rather than:
export OCIO_PATH=/Users/alex/Developer/oiio/dist/macosx

Thanks again
Alex



On Saturday, 19 May 2012 at 10:51 AM, Jeremy Selan wrote:

Are you on OSX?  Have you considered homebrew package manager?

I've never tried it, but if it works as advertised that would make a system install of OCIO simple.

http://mxcl.github.com/homebrew/
http://braumeister.org/formula/opencolorio
http://braumeister.org/formula/openimageio

-- Jeremy

On Fri, May 18, 2012 at 5:46 PM, Alex Fry <ale...@...> wrote:
Was there an easy answer to this?

I'm running into the same problem.

-Alex

On Dec 20 2011, 4:12 pm, Jeremy Selan <jeremy...@...> wrote:
> Hmmm... That should work.  Maybe without the trailing slash on OIIO_PATH?
> (though i wouldnt expect it to make a difference).
>
> Perhaps you built it previously without OIIO support, and now the cmake
> files are out of date?  I'd rm the build directory and try again.
>
> Maybe email the exact build command you're using / output (offline)?
>
> -- Jeremy
>
>
>
>
>
>
>
> On Mon, Dec 19, 2011 at 8:44 PM, Joe <joseph...@...> wrote:
> > Hey all,
> > I'm now trying to build OCIO with the OIIO enabled.  I have built OIIO
> > and it is working  but when I set OIIO_PATH=/Users/josephslomka/
> > Documents/git/oiio/dist/macosx/
> > where I built OIIO
> > I still get the
> >  -- OIIO not found. Specify OIIO_PATH to locate it
> > from cmake.
>
> > Can anyone point me in the right direction?
>
> > Thanks.
> > -Joseph






Re: A simple question About OIIO and OCIO

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

ocioconvert is a demo app that's not really needed.  if you'd like to do color conversions, we'd recommend installing OCIO, then installing OIIO (with OCIO build-time depencency) and then trying oiio-tool --colorconvert


On Fri, May 18, 2012 at 6:14 PM, Alex Fry <ale...@...> wrote:
Ahh! I had no idea OCIO could be installed view brew..
Very neat..
Unfortunately it doesn't build it against OIIO, so its still missing ocioconvert.

But I found my original problem:
Stupidly I was using:
export OCIO_PATH=~/Developer/oiio/dist/macosx
rather than:
export OCIO_PATH=/Users/alex/Developer/oiio/dist/macosx

Thanks again
Alex



On Saturday, 19 May 2012 at 10:51 AM, Jeremy Selan wrote:

Are you on OSX?  Have you considered homebrew package manager?

I've never tried it, but if it works as advertised that would make a system install of OCIO simple.

http://mxcl.github.com/homebrew/
http://braumeister.org/formula/opencolorio
http://braumeister.org/formula/openimageio

-- Jeremy

On Fri, May 18, 2012 at 5:46 PM, Alex Fry <ale...@...> wrote:
Was there an easy answer to this?

I'm running into the same problem.

-Alex

On Dec 20 2011, 4:12 pm, Jeremy Selan <jeremy...@...> wrote:
> Hmmm... That should work.  Maybe without the trailing slash on OIIO_PATH?
> (though i wouldnt expect it to make a difference).
>
> Perhaps you built it previously without OIIO support, and now the cmake
> files are out of date?  I'd rm the build directory and try again.
>
> Maybe email the exact build command you're using / output (offline)?
>
> -- Jeremy
>
>
>
>
>
>
>
> On Mon, Dec 19, 2011 at 8:44 PM, Joe <joseph...@...> wrote:
> > Hey all,
> > I'm now trying to build OCIO with the OIIO enabled.  I have built OIIO
> > and it is working  but when I set OIIO_PATH=/Users/josephslomka/
> > Documents/git/oiio/dist/macosx/
> > where I built OIIO
> > I still get the
> >  -- OIIO not found. Specify OIIO_PATH to locate it
> > from cmake.
>
> > Can anyone point me in the right direction?
>
> > Thanks.
> > -Joseph




Re: RV integration WIP

Alex Fry <ale...@...>
 

Very interested..

Especially in the handling of per shot looks..

-Alex

On Thursday, 2 February 2012 11:07:13 UTC, Hugh Macdonald wrote:

I'm using OCIO in Nuke at the moment, and am in the process of getting RV
properly integrated into Nuke as a flipbooker. I'd certainly be interested
in helping test.
Hugh Macdonald
*n**vizible** – VISUAL EFFECTS
*
hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708
www.nvizible.com
On 2 Feb 2012, at 01:10, Jordan Soles wrote:
Hi,
I use RV and would be happy to test the integration...just let me know.
Thanks,
Jordan
On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...>wrote:
Ben,
Thanks for working on adding RV support!  Very cool.
Are any OCIO users out there currently using RV? (and looking to help in
the integration testing?)
I dont use RV on a daily basis, but I'm sure some of you folks do... ;)
-- Jeremy
On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python
support is non-beta \o/
(I should qualify that with "thirdparty OCIO integration, as my
affiliation with Tweak is no more than "happy user"!)
Only the very basic functionality is there currently (applying a colour
transform a source), but the rest should be relatively straight forward:
https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py
https://github.com/imageworks/OpenColorIO/issues/109
There's some things I'm not sure about:
1. Most important question: what should the default shortcut for "change
view" be?
For example, we use "d" to cycle between the View's, "raw", "lin2log"
and "project"them
Should there be a shortcut for switching display devices, or is this
uncommon enough to just belong in the menu?
(I'll make sure the shortcuts can be customised by env-var or something)
2. How best to allow customising "what colourspace is this" and "what
context variables for this source" functions? Particularly the former for
facilities where the "parseColorSpaceFromString" method will not work
I was thinking just have simple callback functions along the lines of:
try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)
..although this isn't ideal
3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on
input, of course), so the exposure control acts correctly and so on.. Then
the "look LUT" (applied just before viewer) does a SCENE_LINEAR to
output-colorspace.
However the last part is probably 3D, and has no prelut, so values >1.0
get clipped.
To create the look-LUT, what series of colour-transforms should I
perform?
Currently it does:
- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)
Should I use the allocation vars to create a prelut? Or would I be
better using the input_space like ociobakelut uses the "--shaperspace"? I.e:
- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use
allocation vars)
- input_space to output_space
Hope that makes sense - basically I need to bake out 2 LUT's - one from
input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space
4. Maybe a question for Tweak support, although I think Jim and such are
on this list(?) - can RV menu items be dynamically added/removed?
I was thinking of having a "OCIO > Display Device" menu which lists
"Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw",
"lin2log" etc
The View menu would need recreated when you change display, as the lists
are not necessarily the same. Is this possible?
Mostly just curious - there's a bunch of other ways the menu could be
structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw",
"OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)
5. Beyond the basics of "looking at an image with the correct display
transform", what other features would people like to see from the RV/OCIO
integration (either sooner or later)?
- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new
display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO,
but would be fairly easy to export the exposure/saturation/offset/etc
values as CDL)
Err, this email is slightly longer than I intended..
- Ben
--
*JORDAN SOLES*
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles
www.rodeofx.com


Re: static library linking issues

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

A long shot - but have you checked the order in which the static libraries are being added to the linkers command line?  If they're in the wrong order it might not be resolving the symbols.

From the ld docs:
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again. See the -( option for a way to force the linker to search archives multiple times. You may list the same archive multiple times on the command line. This type of archive searching is standard for Unix linkers.

cheers

On 2012-05-11, at 8:37 PM, Jeremy Selan wrote:

Great, let me know if you find anything.

By the way, this is the line that *should* be doing the static linking:
https://github.com/imageworks/OpenColorIO/blob/master/src/core/CMakeLists.txt#L69

and if I print the variable, it appears to be right:
message(STATUS "EXTERNAL_GENERAL_LIBRARIES: ${EXTERNAL_GENERAL_LIBRARIES}")

-- EXTERNAL_GENERAL_LIBRARIES: /net/homedirs/jeremys/git/ocio.js/build/ext/dist/lib/libtinyxml.a;/net/homedirs/jeremys/git/ocio.js/build/ext/dist/lib/libyaml-cpp.a

(whats going wrong is to be determined...)

-- Jeremy

On Fri, May 11, 2012 at 5:31 PM, Piotr Stanczyk <piotr.s...@...> wrote:
thanks for catching that one Jeremy; I'll pass it onto our build guys.

Alas, my cmake skills are well below par, though I may have a go at this one  ..

Piotr


On Fri, May 11, 2012 at 5:25 PM, Jeremy Selan <jeremy...@...> wrote:
> Ok, so I'm able to fully reproduce your error when using static linking with
> a simple test case.
>
> g++ main.cpp -Ibuild/dist/include -ostatictest
> build/dist/lib/libOpenColorIO.a
>
> I created a main.cpp, where all it does is print the name of linear.
> https://gist.github.com/2663280
>
> If I manually add the .a for yaml and tinyxml everything works!
>
> g++ main.cpp -Ibuild/dist/include -ostatictest
> build/dist/lib/libOpenColorIO.a build/ext/dist/lib/libyaml-cpp.a
> build/ext/dist/lib/libtinyxml.a
>
> So as you noted, the static symbols from these two dependencies are not
> making into ocio.  I'm not much of a cmake expert, but it doesnt seem like
> this would be too hard to patch up.
>
> -- Jeremy
>
>
> On Fri, May 11, 2012 at 1:08 PM, Jeremy Selan <jeremy...@...>
> wrote:
>>
>> Sorry, i'll try to look into this.
>>
>> Is anyone out there successfully statically building against OCIO?
>>
>> -- Jeremy
>>
>>
>> On Fri, May 11, 2012 at 10:25 AM, Piotr <piotr.s...@...> wrote:
>>>
>>> Just checking in to see if anyone has some magic voodoo for this -
>>> thanks
>>>
>>> Piotr
>>>
>>>
>>> On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
>>> > Hi Jeremy,
>>> >
>>> > Sorry for the delay in getting this info back to you. This is what our
>>> > build people say:
>>> >
>>> > We're actually building verison 1.0.6.  This was a clean build, and
>>> > we're not using ocio elsewhere in our codebase.  The ocio build was
>>> > invoked via:
>>> >
>>> > cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
>>> > PYTHON=/usr/bin/python2.6 ../
>>> >
>>> > Could it be that the symbols from the the YAML and tinxml libs are
>>> > hidden in the ocio build?  Is there a way to disable that and make
>>> > them all publicly available?  Taking the first undefined reference,
>>> > for example:
>>> >
>>> > > objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
>>> >
>>> > 00000000000cfb00 l     F .text  000000000000006c              .hidden
>>> > YAML::Emitter::Emitter()
>>> > 00000000000cfb70 l     F .text  000000000000006c              .hidden
>>> > YAML::Emitter::Emitter()
>>> >
>>> > And in the ocio code it's definitely referenced ( src/core/Config.cpp
>>> > ):
>>> >
>>> > void Config::serialize(std::ostream& os) const
>>> > {
>>> >     try
>>> >     {
>>> >         YAML::Emitter out;
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...>
>>> > wrote:
>>> > > Ugh!
>>> >
>>> > > Sorry to hear you've having trouble with static linking.
>>> >
>>> > > Can you post the shell command you're using to build OCIO with?
>>> >
>>> > > (At SPI we happen to only use OCIO in a dynamically linked context so
>>> > > we
>>> > > havent run into this error yet).
>>> >
>>> > > In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
>>> > > dependency to 0.3.0. I presume you're building 1.0.7?
>>> >
>>> > > A few ideas to test:
>>> > > - Can you confirm that you're using a clean build?  It's possible
>>> > > that if
>>> > > you have old .o files lying around-  built against a prior OCIO - it
>>> > > could
>>> > > cause weirdness.
>>> >
>>> > > - Is it possible that another part of your codebase is statically
>>> > > linking
>>> > > against a different OCIO version? (If you have another part of the
>>> > > code
>>> > > statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol
>>> > > clash)
>>> >
>>> > > -- Jeremy
>>> >
>>> > > On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk
>>> > > <piotr.s...@...>
>>> > > wrote:
>>> >
>>> > >> Hi All,
>>> >
>>> > >> So far I've been using the .so's to link against. However, I've run
>>> > >> into an issue with building a binary that links against the static
>>> > >> libs with a sleuth of errors (see below).
>>> > >> I don't think I did anything unusual in the building of this. I'll
>>> > >> start digging into what could be causing this, but if anyone has any
>>> > >> pointers that would be most welcome.
>>> >
>>> > >> Cheers
>>> >
>>> > >> Piotr
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
>>> > >> m<char, std::char_traits<char> >&) const':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1591:
>>> > >> undefined reference to `YAML::Emitter::Emi
>>> > >> tter()'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1594:
>>> > >> undefined reference to `YAML::Emitter::Set
>>> > >> LocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1594:
>>> > >> undefined reference to `YAML::Emitter::Set
>>> > >> LocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `WriteIntegralType<int>':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::good() const'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
>>> > >> std::char_traits<char>, std::allocator<char> >&)'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
>>> > >> undefined reference t
>>> > >> o
>>> > >> `YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
>>> > >> std::char_traits<char>, std::allocator<char> > const&)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
>>> > >> ....
>>
>>
>



Re: static library linking issues

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

Great, let me know if you find anything.

By the way, this is the line that *should* be doing the static linking:
https://github.com/imageworks/OpenColorIO/blob/master/src/core/CMakeLists.txt#L69

and if I print the variable, it appears to be right:
message(STATUS "EXTERNAL_GENERAL_LIBRARIES: ${EXTERNAL_GENERAL_LIBRARIES}")

-- EXTERNAL_GENERAL_LIBRARIES: /net/homedirs/jeremys/git/ocio.js/build/ext/dist/lib/libtinyxml.a;/net/homedirs/jeremys/git/ocio.js/build/ext/dist/lib/libyaml-cpp.a

(whats going wrong is to be determined...)

-- Jeremy


On Fri, May 11, 2012 at 5:31 PM, Piotr Stanczyk <piotr.s...@...> wrote:
thanks for catching that one Jeremy; I'll pass it onto our build guys.

Alas, my cmake skills are well below par, though I may have a go at this one  ..

Piotr


On Fri, May 11, 2012 at 5:25 PM, Jeremy Selan <jeremy...@...> wrote:
> Ok, so I'm able to fully reproduce your error when using static linking with
> a simple test case.
>
> g++ main.cpp -Ibuild/dist/include -ostatictest
> build/dist/lib/libOpenColorIO.a
>
> I created a main.cpp, where all it does is print the name of linear.
> https://gist.github.com/2663280
>
> If I manually add the .a for yaml and tinyxml everything works!
>
> g++ main.cpp -Ibuild/dist/include -ostatictest
> build/dist/lib/libOpenColorIO.a build/ext/dist/lib/libyaml-cpp.a
> build/ext/dist/lib/libtinyxml.a
>
> So as you noted, the static symbols from these two dependencies are not
> making into ocio.  I'm not much of a cmake expert, but it doesnt seem like
> this would be too hard to patch up.
>
> -- Jeremy
>
>
> On Fri, May 11, 2012 at 1:08 PM, Jeremy Selan <jeremy...@...>
> wrote:
>>
>> Sorry, i'll try to look into this.
>>
>> Is anyone out there successfully statically building against OCIO?
>>
>> -- Jeremy
>>
>>
>> On Fri, May 11, 2012 at 10:25 AM, Piotr <piotr.s...@...> wrote:
>>>
>>> Just checking in to see if anyone has some magic voodoo for this -
>>> thanks
>>>
>>> Piotr
>>>
>>>
>>> On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
>>> > Hi Jeremy,
>>> >
>>> > Sorry for the delay in getting this info back to you. This is what our
>>> > build people say:
>>> >
>>> > We're actually building verison 1.0.6.  This was a clean build, and
>>> > we're not using ocio elsewhere in our codebase.  The ocio build was
>>> > invoked via:
>>> >
>>> > cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
>>> > PYTHON=/usr/bin/python2.6 ../
>>> >
>>> > Could it be that the symbols from the the YAML and tinxml libs are
>>> > hidden in the ocio build?  Is there a way to disable that and make
>>> > them all publicly available?  Taking the first undefined reference,
>>> > for example:
>>> >
>>> > > objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
>>> >
>>> > 00000000000cfb00 l     F .text  000000000000006c              .hidden
>>> > YAML::Emitter::Emitter()
>>> > 00000000000cfb70 l     F .text  000000000000006c              .hidden
>>> > YAML::Emitter::Emitter()
>>> >
>>> > And in the ocio code it's definitely referenced ( src/core/Config.cpp
>>> > ):
>>> >
>>> > void Config::serialize(std::ostream& os) const
>>> > {
>>> >     try
>>> >     {
>>> >         YAML::Emitter out;
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...>
>>> > wrote:
>>> > > Ugh!
>>> >
>>> > > Sorry to hear you've having trouble with static linking.
>>> >
>>> > > Can you post the shell command you're using to build OCIO with?
>>> >
>>> > > (At SPI we happen to only use OCIO in a dynamically linked context so
>>> > > we
>>> > > havent run into this error yet).
>>> >
>>> > > In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
>>> > > dependency to 0.3.0. I presume you're building 1.0.7?
>>> >
>>> > > A few ideas to test:
>>> > > - Can you confirm that you're using a clean build?  It's possible
>>> > > that if
>>> > > you have old .o files lying around-  built against a prior OCIO - it
>>> > > could
>>> > > cause weirdness.
>>> >
>>> > > - Is it possible that another part of your codebase is statically
>>> > > linking
>>> > > against a different OCIO version? (If you have another part of the
>>> > > code
>>> > > statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol
>>> > > clash)
>>> >
>>> > > -- Jeremy
>>> >
>>> > > On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk
>>> > > <piotr.s...@...>
>>> > > wrote:
>>> >
>>> > >> Hi All,
>>> >
>>> > >> So far I've been using the .so's to link against. However, I've run
>>> > >> into an issue with building a binary that links against the static
>>> > >> libs with a sleuth of errors (see below).
>>> > >> I don't think I did anything unusual in the building of this. I'll
>>> > >> start digging into what could be causing this, but if anyone has any
>>> > >> pointers that would be most welcome.
>>> >
>>> > >> Cheers
>>> >
>>> > >> Piotr
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
>>> > >> m<char, std::char_traits<char> >&) const':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1591:
>>> > >> undefined reference to `YAML::Emitter::Emi
>>> > >> tter()'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1594:
>>> > >> undefined reference to `YAML::Emitter::Set
>>> > >> LocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/src/core/Config.cpp:1594:
>>> > >> undefined reference to `YAML::Emitter::Set
>>> > >> LocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `WriteIntegralType<int>':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::good() const'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
>>> > >> std::char_traits<char>, std::allocator<char> >&)'
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
>>> > >> undefined reference t
>>> > >> o
>>> > >> `YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
>>> > >> std::char_traits<char>, std::allocator<char> > const&)'
>>> >
>>> > >>
>>> > >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
>>> > >> O.a(Config.cpp.o):
>>> > >> In function `operator<<':
>>> >
>>> > >>
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
>>> > >> ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
>>> > >> undefined reference t
>>> > >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>>> > >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
>>> > >> ....
>>
>>
>


Re: static library linking issues

Piotr Stanczyk <piotr.s...@...>
 

thanks for catching that one Jeremy; I'll pass it onto our build guys.

Alas, my cmake skills are well below par, though I may have a go at this one ..

Piotr

On Fri, May 11, 2012 at 5:25 PM, Jeremy Selan <jeremy...@...> wrote:
Ok, so I'm able to fully reproduce your error when using static linking with
a simple test case.

g++ main.cpp -Ibuild/dist/include -ostatictest
build/dist/lib/libOpenColorIO.a

I created a main.cpp, where all it does is print the name of linear.
https://gist.github.com/2663280

If I manually add the .a for yaml and tinyxml everything works!

g++ main.cpp -Ibuild/dist/include -ostatictest
build/dist/lib/libOpenColorIO.a build/ext/dist/lib/libyaml-cpp.a
build/ext/dist/lib/libtinyxml.a

So as you noted, the static symbols from these two dependencies are not
making into ocio.  I'm not much of a cmake expert, but it doesnt seem like
this would be too hard to patch up.

-- Jeremy


On Fri, May 11, 2012 at 1:08 PM, Jeremy Selan <jeremy...@...>
wrote:

Sorry, i'll try to look into this.

Is anyone out there successfully statically building against OCIO?

-- Jeremy


On Fri, May 11, 2012 at 10:25 AM, Piotr <piotr.s...@...> wrote:

Just checking in to see if anyone has some magic voodoo for this -
thanks

Piotr


On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
Hi Jeremy,

Sorry for the delay in getting this info back to you. This is what our
build people say:

We're actually building verison 1.0.6.  This was a clean build, and
we're not using ocio elsewhere in our codebase.  The ocio build was
invoked via:

cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
PYTHON=/usr/bin/python2.6 ../

Could it be that the symbols from the the YAML and tinxml libs are
hidden in the ocio build?  Is there a way to disable that and make
them all publicly available?  Taking the first undefined reference,
for example:

objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
00000000000cfb00 l     F .text  000000000000006c              .hidden
YAML::Emitter::Emitter()
00000000000cfb70 l     F .text  000000000000006c              .hidden
YAML::Emitter::Emitter()

And in the ocio code it's definitely referenced ( src/core/Config.cpp
):

void Config::serialize(std::ostream& os) const
{
    try
    {
        YAML::Emitter out;







On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...>
wrote:
Ugh!
Sorry to hear you've having trouble with static linking.
Can you post the shell command you're using to build OCIO with?
(At SPI we happen to only use OCIO in a dynamically linked context so
we
havent run into this error yet).
In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
dependency to 0.3.0. I presume you're building 1.0.7?
A few ideas to test:
- Can you confirm that you're using a clean build?  It's possible
that if
you have old .o files lying around-  built against a prior OCIO - it
could
cause weirdness.
- Is it possible that another part of your codebase is statically
linking
against a different OCIO version? (If you have another part of the
code
statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol
clash)
-- Jeremy
On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk
<piotr.s...@...>
wrote:
Hi All,
So far I've been using the .so's to link against. However, I've run
into an issue with building a binary that links against the static
libs with a sleuth of errors (see below).
I don't think I did anything unusual in the building of this. I'll
start digging into what could be causing this, but if anyone has any
pointers that would be most welcome.
Cheers
Piotr

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
m<char, std::char_traits<char> >&) const':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/src/core/Config.cpp:1591:
undefined reference to `YAML::Emitter::Emi
tter()'

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `operator<<':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `operator<<':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/src/core/Config.cpp:1594:
undefined reference to `YAML::Emitter::Set
LocalValue(YAML::EMITTER_MANIP)'

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/src/core/Config.cpp:1594:
undefined reference to `YAML::Emitter::Set
LocalValue(YAML::EMITTER_MANIP)'

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `operator<<':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `WriteIntegralType<int>':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
undefined reference t
o `YAML::Emitter::good() const'

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
undefined reference t
o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char> >&)'

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
undefined reference t
o
`YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char> > const&)'

/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI
O.a(Config.cpp.o):
In function `operator<<':

/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open
ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
....


Re: static library linking issues

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

Ok, so I'm able to fully reproduce your error when using static linking with a simple test case.
g++ main.cpp -Ibuild/dist/include -ostatictest build/dist/lib/libOpenColorIO.a
I created a main.cpp, where all it does is print the name of linear.
https://gist.github.com/2663280

If I manually add the .a for yaml and tinyxml everything works!
g++ main.cpp -Ibuild/dist/include -ostatictest build/dist/lib/libOpenColorIO.a build/ext/dist/lib/libyaml-cpp.a build/ext/dist/lib/libtinyxml.a
So as you noted, the static symbols from these two dependencies are not making into ocio.  I'm not much of a cmake expert, but it doesnt seem like this would be too hard to patch up.

-- Jeremy


On Fri, May 11, 2012 at 1:08 PM, Jeremy Selan <jeremy...@...> wrote:
Sorry, i'll try to look into this.

Is anyone out there successfully statically building against OCIO?

-- Jeremy


On Fri, May 11, 2012 at 10:25 AM, Piotr <piotr.s...@...> wrote:
Just checking in to see if anyone has some magic voodoo for this -
thanks

Piotr


On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
> Hi Jeremy,
>
> Sorry for the delay in getting this info back to you. This is what our
> build people say:
>
> We're actually building verison 1.0.6.  This was a clean build, and
> we're not using ocio elsewhere in our codebase.  The ocio build was
> invoked via:
>
> cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
> PYTHON=/usr/bin/python2.6 ../
>
> Could it be that the symbols from the the YAML and tinxml libs are
> hidden in the ocio build?  Is there a way to disable that and make
> them all publicly available?  Taking the first undefined reference,
> for example:
>
> > objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
>
> 00000000000cfb00 l     F .text  000000000000006c              .hidden
> YAML::Emitter::Emitter()
> 00000000000cfb70 l     F .text  000000000000006c              .hidden
> YAML::Emitter::Emitter()
>
> And in the ocio code it's definitely referenced ( src/core/Config.cpp ):
>
> void Config::serialize(std::ostream& os) const
> {
>     try
>     {
>         YAML::Emitter out;
>
>
>
>
>
>
>
> On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...> wrote:
> > Ugh!
>
> > Sorry to hear you've having trouble with static linking.
>
> > Can you post the shell command you're using to build OCIO with?
>
> > (At SPI we happen to only use OCIO in a dynamically linked context so we
> > havent run into this error yet).
>
> > In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
> > dependency to 0.3.0. I presume you're building 1.0.7?
>
> > A few ideas to test:
> > - Can you confirm that you're using a clean build?  It's possible that if
> > you have old .o files lying around-  built against a prior OCIO - it could
> > cause weirdness.
>
> > - Is it possible that another part of your codebase is statically linking
> > against a different OCIO version? (If you have another part of the code
> > statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol clash)
>
> > -- Jeremy
>
> > On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk <piotr.s...@...>
> > wrote:
>
> >> Hi All,
>
> >> So far I've been using the .so's to link against. However, I've run
> >> into an issue with building a binary that links against the static
> >> libs with a sleuth of errors (see below).
> >> I don't think I did anything unusual in the building of this. I'll
> >> start digging into what could be causing this, but if anyone has any
> >> pointers that would be most welcome.
>
> >> Cheers
>
> >> Piotr
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
> >> m<char, std::char_traits<char> >&) const':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1591:
> >> undefined reference to `YAML::Emitter::Emi
> >> tter()'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
> >> undefined reference to `YAML::Emitter::Set
> >> LocalValue(YAML::EMITTER_MANIP)'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
> >> undefined reference to `YAML::Emitter::Set
> >> LocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `WriteIntegralType<int>':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
> >> undefined reference t
> >> o `YAML::Emitter::good() const'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
> >> undefined reference t
> >> o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
> >> std::char_traits<char>, std::allocator<char> >&)'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
> >> undefined reference t
> >> o `YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
> >> std::char_traits<char>, std::allocator<char> > const&)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
> >> ....



Re: static library linking issues

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

Sorry, i'll try to look into this.

Is anyone out there successfully statically building against OCIO?

-- Jeremy


On Fri, May 11, 2012 at 10:25 AM, Piotr <piotr.s...@...> wrote:
Just checking in to see if anyone has some magic voodoo for this -
thanks

Piotr


On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
> Hi Jeremy,
>
> Sorry for the delay in getting this info back to you. This is what our
> build people say:
>
> We're actually building verison 1.0.6.  This was a clean build, and
> we're not using ocio elsewhere in our codebase.  The ocio build was
> invoked via:
>
> cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
> PYTHON=/usr/bin/python2.6 ../
>
> Could it be that the symbols from the the YAML and tinxml libs are
> hidden in the ocio build?  Is there a way to disable that and make
> them all publicly available?  Taking the first undefined reference,
> for example:
>
> > objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
>
> 00000000000cfb00 l     F .text  000000000000006c              .hidden
> YAML::Emitter::Emitter()
> 00000000000cfb70 l     F .text  000000000000006c              .hidden
> YAML::Emitter::Emitter()
>
> And in the ocio code it's definitely referenced ( src/core/Config.cpp ):
>
> void Config::serialize(std::ostream& os) const
> {
>     try
>     {
>         YAML::Emitter out;
>
>
>
>
>
>
>
> On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...> wrote:
> > Ugh!
>
> > Sorry to hear you've having trouble with static linking.
>
> > Can you post the shell command you're using to build OCIO with?
>
> > (At SPI we happen to only use OCIO in a dynamically linked context so we
> > havent run into this error yet).
>
> > In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
> > dependency to 0.3.0. I presume you're building 1.0.7?
>
> > A few ideas to test:
> > - Can you confirm that you're using a clean build?  It's possible that if
> > you have old .o files lying around-  built against a prior OCIO - it could
> > cause weirdness.
>
> > - Is it possible that another part of your codebase is statically linking
> > against a different OCIO version? (If you have another part of the code
> > statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol clash)
>
> > -- Jeremy
>
> > On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk <piotr.s...@...>
> > wrote:
>
> >> Hi All,
>
> >> So far I've been using the .so's to link against. However, I've run
> >> into an issue with building a binary that links against the static
> >> libs with a sleuth of errors (see below).
> >> I don't think I did anything unusual in the building of this. I'll
> >> start digging into what could be causing this, but if anyone has any
> >> pointers that would be most welcome.
>
> >> Cheers
>
> >> Piotr
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
> >> m<char, std::char_traits<char> >&) const':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1591:
> >> undefined reference to `YAML::Emitter::Emi
> >> tter()'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
> >> undefined reference to `YAML::Emitter::Set
> >> LocalValue(YAML::EMITTER_MANIP)'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
> >> undefined reference to `YAML::Emitter::Set
> >> LocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `WriteIntegralType<int>':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
> >> undefined reference t
> >> o `YAML::Emitter::good() const'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
> >> undefined reference t
> >> o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
> >> std::char_traits<char>, std::allocator<char> >&)'
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
> >> undefined reference t
> >> o `YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
> >> std::char_traits<char>, std::allocator<char> > const&)'
>
> >> /var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
> >> In function `operator<<':
>
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
> >> undefined reference t
> >> o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
> >> /home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
> >> ....


Re: static library linking issues

Piotr <piotr.s...@...>
 

Just checking in to see if anyone has some magic voodoo for this -
thanks

Piotr

On May 7, 4:51 pm, Piotr Stanczyk <piotr.s...@...> wrote:
Hi Jeremy,

Sorry for the delay in getting this info back to you. This is what our
build people say:

We're actually building verison 1.0.6.  This was a clean build, and
we're not using ocio elsewhere in our codebase.  The ocio build was
invoked via:

cmake -D CMAKE_INSTALL_PREFIX=../dist -D CMAKE_SKIP_RPATH=YES -D
PYTHON=/usr/bin/python2.6 ../

Could it be that the symbols from the the YAML and tinxml libs are
hidden in the ocio build?  Is there a way to disable that and make
them all publicly available?  Taking the first undefined reference,
for example:

objdump -tC libOpenColorIO.so.1.0.6 | grep "YAML::Emitter::Emitter"
00000000000cfb00 l     F .text  000000000000006c              .hidden
YAML::Emitter::Emitter()
00000000000cfb70 l     F .text  000000000000006c              .hidden
YAML::Emitter::Emitter()

And in the ocio code it's definitely referenced ( src/core/Config.cpp ):

void Config::serialize(std::ostream& os) const
{
    try
    {
        YAML::Emitter out;







On Tue, May 1, 2012 at 4:24 PM, Jeremy Selan <jeremy...@...> wrote:
Ugh!
Sorry to hear you've having trouble with static linking.
Can you post the shell command you're using to build OCIO with?
(At SPI we happen to only use OCIO in a dynamically linked context so we
havent run into this error yet).
In the latest OCIO release (1.0.7) we bumped the internal yaml-cpp
dependency to 0.3.0. I presume you're building 1.0.7?
A few ideas to test:
- Can you confirm that you're using a clean build?  It's possible that if
you have old .o files lying around-  built against a prior OCIO - it could
cause weirdness.
- Is it possible that another part of your codebase is statically linking
against a different OCIO version? (If you have another part of the code
statically links to 0.2.X yaml-cpp, I could imagine a yaml-cpp symbol clash)
-- Jeremy
On Tue, May 1, 2012 at 11:35 AM, Piotr Stanczyk <piotr.s...@...>
wrote:
Hi All,
So far I've been using the .so's to link against. However, I've run
into an issue with building a binary that links against the static
libs with a sleuth of errors (see below).
I don't think I did anything unusual in the building of this. I'll
start digging into what could be causing this, but if anyone has any
pointers that would be most welcome.
Cheers
Piotr
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `OpenColorIO::v1::Config::serialize(std::basic_ostrea
m<char, std::char_traits<char> >&) const':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1591:
undefined reference to `YAML::Emitter::Emi
tter()'
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `operator<<':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `operator<<':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
undefined reference to `YAML::Emitter::Set
LocalValue(YAML::EMITTER_MANIP)'
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/src/core/Config.cpp:1594:
undefined reference to `YAML::Emitter::Set
LocalValue(YAML::EMITTER_MANIP)'
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `operator<<':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `WriteIntegralType<int>':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:104:
undefined reference t
o `YAML::Emitter::good() const'
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:108:
undefined reference t
o `YAML::Emitter::PreWriteIntegralType(std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char> >&)'
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:110:
undefined reference t
o `YAML::Emitter::PostWriteIntegralType(std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char> > const&)'
/var/tmp-ssd/doNotRemove/builds/zeno3_ssd/RHEL5_AMD64_OPT/lib/libOpenColorI O.a(Config.cpp.o):
In function `operator<<':
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/imageworks-Open ColorIO-a16d9ac/build/ext/dist/include/yaml-cpp/emitter.h:152:
undefined reference t
o `YAML::Emitter::SetLocalValue(YAML::EMITTER_MANIP)'
/home/ewimmer/ewimmer_importlibs/importlibs/src/OpenColorIO/ima
....


Re: RV integration WIP

georges...@...
 

So would I/we.

George - BlueBolt

On Thursday, 2 February 2012 11:07:13 UTC, Hugh Macdonald wrote:
I'm using OCIO in Nuke at the moment, and am in the process of getting RV properly integrated into Nuke as a flipbooker. I'd certainly be interested in helping test.

Hugh Macdonald
nvizible – VISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com

On 2 Feb 2012, at 01:10, Jordan Soles wrote:

Hi,

I use RV and would be happy to test the integration...just let me know.

Thanks,
Jordan

On Wed, Feb 1, 2012 at 7:51 PM, Jeremy Selan <jeremy...@...> wrote:
Ben,

Thanks for working on adding RV support!  Very cool.

Are any OCIO users out there currently using RV? (and looking to help in the integration testing?)

I dont use RV on a daily basis, but I'm sure some of you folks do... ;)

-- Jeremy


On Sun, Jan 15, 2012 at 6:58 AM, dbr/Ben <dbr....@...> wrote:
I've resumed looking into integrating OCIO into RV, now that RV's Python support is non-beta \o/

(I should qualify that with "thirdparty OCIO integration, as my affiliation with Tweak is no more than "happy user"!)


Only the very basic functionality is there currently (applying a colour transform a source), but the rest should be relatively straight forward:

https://github.com/dbr/OpenColorIO/blob/rv/src/rv/Python/ociorv.py

https://github.com/imageworks/OpenColorIO/issues/109


There's some things I'm not sure about:

1. Most important question: what should the default shortcut for "change view" be?

For example, we use "d" to cycle between the View's, "raw", "lin2log" and "project"them

Should there be a shortcut for switching display devices, or is this uncommon enough to just belong in the menu?

(I'll make sure the shortcuts can be customised by env-var or something)


2. How best to allow customising "what colourspace is this" and "what context variables for this source" functions? Particularly the former for facilities where the "parseColorSpaceFromString" method will not work

I was thinking just have simple callback functions along the lines of:

try:
   import ocio_rv_custom
except ImportError:
   in_space = cfg. parseColorSpaceFromString(path)
else:
   in_space = ocio_rv_custom.colorspace_for_path(path)

..although this isn't ideal


3. The "file LUT" does a lg10 to SCENE_LINEAR transform (depending on input, of course), so the exposure control acts correctly and so on.. Then the "look LUT" (applied just before viewer) does a SCENE_LINEAR to output-colorspace.

However the last part is probably 3D, and has no prelut, so values >1.0 get clipped.

To create the look-LUT, what series of colour-transforms should I perform?

Currently it does:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to output_space (probably as 3D LUT)

Should I use the allocation vars to create a prelut? Or would I be better using the input_space like ociobakelut uses the "--shaperspace"? I.e:

- input_space to SCENE_LINEAR (probably as 1D LUT)
- RV's grading controls
- SCENE_LINEAR to input_space (probably as 1D LUT, if not, use allocation vars)
- input_space to output_space

Hope that makes sense - basically I need to bake out 2 LUT's - one from input to SCENE_LINEAR, and another from SCENE_LINEAR to the output space


4. Maybe a question for Tweak support, although I think Jim and such are on this list(?) - can RV menu items be dynamically added/removed?

I was thinking of having a "OCIO > Display Device" menu which lists "Rec709", "P3" etc, then a separate "OCIO > Views" menu which lists "raw", "lin2log" etc

The View menu would need recreated when you change display, as the lists are not necessarily the same. Is this possible?

Mostly just curious - there's a bunch of other ways the menu could be structured, which would avoid the need for this (e.g "OCIO > Rec709 > raw", "OCIO > Rec709 > lin2log", "OCIO > P3 > raw" etc)


5. Beyond the basics of "looking at an image with the correct display transform", what other features would people like to see from the RV/OCIO integration (either sooner or later)?

- Per-source context variables (would be a fairly high priority for me)
- Ability to apply a arbitrary "Look" transforms (without adding a new display-View)?
- export grades as .ccc (maybe belongs in RV itself, rather than OCIO, but would be fairly easy to export the exposure/saturation/offset/etc values as CDL)


Err, this email is slightly longer than I intended..
- Ben




--
JORDAN SOLES
Chief Technology Officer | Producer
Office:     514 397 9999  x 400
Cell:       514 699 0414
Skype:    jordansoles







Re: Tetrahedral is Best

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

So if you look in the aces configuration, you'll see there are two .ocio files.  config.ocio and config_1_0_3.ocio.   config_1_0_3 explicitly specifies tetrahedral interpolation for the rrt 3dluts.  The reason we havent chosen to roll that into the normal config.ocio is that tetrahedral interpolation was only added in 1.0.3, and I dont want to leave those folks locked off on prior versions (such as nuke 6.3v8) with configs that dont load.    (If anyone has a better idea on how to approach this, please let me know).

But this does raise the question, of what should OCIO::INTERP_BEST do?  Currently it defaults to linear for both 1d and 3d luts.  It would be a one line change to default BEST to tetrahedral for the 3dlut case.

In peoples experience, are there ever cases where trilinear is preferable to tetrahedral for 3d lut interpolation?

In terms of GPU tetrahedral support, we have some ideas how to add it in, and hope to explore them by the end of summer.

-- Jeremy


On Tue, May 8, 2012 at 9:54 AM, Brendan Bolles <bre...@...> wrote:
I was experimenting with the ACES configuration the other day. I
applied the RRT to a grey ramp and saw some subtle color artifacts,
which could be verified by boosting the saturation. I tried applying
the rrt_ut33_sRGB.spi3d LUT directly and saw the same artifacts, until
I switched to tetrahedral interpolation which made them go away. Maybe
there's something to this tetrahedral business after all. ;)

So maybe should we switch ACES and other configurations to use
Tetrahedral when doing a 3D LUT?

Also, one of the interpolation types is "Best", which currently uses
Linear for both 1D and 3D LUTs. Seems to me the best interpolation for
a 3D LUT is Tetrahedral. Ben says it's actually faster than tri-linear
in his tests, although I don't think anyone's ever figured out how to
do it in the GPU.


Brendan


Tetrahedral is Best

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

I was experimenting with the ACES configuration the other day. I
applied the RRT to a grey ramp and saw some subtle color artifacts,
which could be verified by boosting the saturation. I tried applying
the rrt_ut33_sRGB.spi3d LUT directly and saw the same artifacts, until
I switched to tetrahedral interpolation which made them go away. Maybe
there's something to this tetrahedral business after all. ;)

So maybe should we switch ACES and other configurations to use
Tetrahedral when doing a 3D LUT?

Also, one of the interpolation types is "Best", which currently uses
Linear for both 1D and 3D LUTs. Seems to me the best interpolation for
a 3D LUT is Tetrahedral. Ben says it's actually faster than tri-linear
in his tests, although I don't think anyone's ever figured out how to
do it in the GPU.


Brendan


Re: Need disto install section on home page?

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

On Mon, May 7, 2012 at 4:41 PM, Jeremy Selan <jeremy...@...> wrote:
Sounds great.  Can you send me the real distro list?  Im happy to add it.
Or you can edit the docs rst file, and submit a pull request.
Ack. I tried editing it in github since it's a minor change but when I
submit it I get a github 404 not found. I'll submit something straight
from git when I get a chance and I'll add EPEL when it hits the stable
repositories.

Richard

1201 - 1220 of 2226