Date   

OSX 10.9 static build fails compiling ociocheck

andersl...@...
 

Hello, I'm trying to build 1.0.9 on OSX 10.9, but the build is failing compiling ociocheck:

Linking CXX executable ociocheck
cd /Users/anders/code/OpenColorIO/build/src/apps/ociocheck && /usr/local/Cellar/cmake/2.8.12.1/bin/cmake -E cmake_link_script CMakeFiles/ociocheck.dir/link.txt --verbose=1
/usr/bin/c++    -msse2 -O2 -g -DNDEBUG -arch x86_64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/ociocheck.dir/main.cpp.o CMakeFiles/ociocheck.dir/__/share/argparse.cpp.o CMakeFiles/ociocheck.dir/__/share/pystring.cpp.o CMakeFiles/ociocheck.dir/__/share/strutil.cpp.o  -o ociocheck  -lOpenColorIO 
ld: library not found for -lOpenColorIO
clang: error: linker command failed with exit code 1 (use -v to see invocation)


To do the static build I'm just setting OCIO_BUILD_SHARED to OFF and OCIO_BUILD_STATIC to ON. libOpenColorIO.a is present in build/src/core, but isn't getting found, which is strange as I thought CMake was supposed to handle all that stuff.

I'm also a little bit worried by this message:

Linking CXX static library libtinyxml.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libtinyxml.a(tinystr.cpp.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libtinyxml.a(tinystr.cpp.o) has no symbols
[100%] Built target tinyxml


If I manually add libOpenColorIO.a's path to the environment using link_directories() then it gets found, but then I get a stream of missing symbols:

Undefined symbols for architecture x86_64:
  "TiXmlElement::SetAttribute(char const*, char const*)", referenced from:
      OpenColorIO::v1::CDLTransform::getXML() const in libOpenColorIO.a(CDLTransform.cpp.o)
  "TiXmlElement::TiXmlElement(char const*)", referenced from:
      OpenColorIO::v1::CDLTransform::getXML() const in libOpenColorIO.a(CDLTransform.cpp.o)
  "TiXmlDocument::Parse(char const*, TiXmlParsingData*, TiXmlEncoding)", referenced from:
      OpenColorIO::v1::LoadCDL(OpenColorIO::v1::CDLTransform*, char const*) in libOpenColorIO.a(CDLTransform.cpp.o)
      OpenColorIO::v1::CDLTransform::CreateFromFile(char const*, char const*) in libOpenColorIO.a(CDLTransform.cpp.o)
  "TiXmlDocument::TiXmlDocument()", referenced from:
      OpenColorIO::v1::LoadCDL(OpenColorIO::v1::CDLTransform*, char const*) in libOpenColorIO.a(CDLTransform.cpp.o)
      OpenColorIO::v1::CDLTransform::CreateFromFile(char const*, char const*) in libOpenColorIO.a(CDLTransform.cpp.o)
      OpenColorIO::v1::CDLTransform::getXML() const in libOpenColorIO.a(CDLTransform.cpp.o)
      OpenColorIO::v1::(anonymous namespace)::LocalFileFormat::Read(std::istream&) const in libOpenColorIO.a(FileFormatCCC.cpp.o)
      OpenColorIO::v1::(anonymous namespace)::LocalFileFormat::Read(std::istream&) const in libOpenColorIO.a(FileFormatIridasLook.cpp.o)
  "YAML::Node::Node()", referenced from:
      OpenColorIO::v1::OCIOYaml::open(std::istream&, std::tr1::shared_ptr<OpenColorIO::v1::Config>&, char const*) const in libOpenColorIO.a(OCIOYaml.cpp.o)
  "YAML::Node::~Node()", referenced from:
      OpenColorIO::v1::OCIOYaml::open(std::istream&, std::tr1::shared_ptr<OpenColorIO::v1::Config>&, char const*) const in libOpenColorIO.a(OCIOYaml.cpp.o)

(this carries on for what must be every single symbol in the library)

Any ideas?


Re: advice, supporting dynamic color space additions to config

Steve Agland <sag...@...>
 

Yes, this is basically what I was thinking. It'd probably work for us.

On 26 September 2014 10:50, Haarm-Pieter Duiker <li...@...> wrote:
If you're working in a single facility and have some way of prompting configs to be regenerated, the Python API gives you most of the functionality needed for an inheritance model. 

Something along the lines of a 'global' config module which defined the base color spaces, views, displays and so on followed by show/shot/sequence specific modules that could import that global config module, use it to generate a Python config object and then modify that config object as necessary before writing the config to disk could work for a single facility.

HP





On Thu, Sep 25, 2014 at 3:53 PM, Steve Agland <sag...@...> wrote:
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: advice, supporting dynamic color space additions to config

Haarm-Pieter Duiker <li...@...>
 

If you're working in a single facility and have some way of prompting configs to be regenerated, the Python API gives you most of the functionality needed for an inheritance model. 

Something along the lines of a 'global' config module which defined the base color spaces, views, displays and so on followed by show/shot/sequence specific modules that could import that global config module, use it to generate a Python config object and then modify that config object as necessary before writing the config to disk could work for a single facility.

HP





On Thu, Sep 25, 2014 at 3:53 PM, Steve Agland <sag...@...> wrote:
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: advice, supporting dynamic color space additions to config

Steve Agland <sag...@...>
 

I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly.

It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc.

Steve


On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:

This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg.


advice, supporting dynamic color space additions to config

Haarm-Pieter Duiker <li...@...>
 

Hello,

I'm working on a project that has a base set of well-defined transforms and a more extended set of transforms/color spaces that are less well-defined. The 'less well defined' transforms are going to come from 3rd parties and will likely be delivered after a config including the main set of 'well-defined' transforms is locked down and released to a number of users.

I'm hoping for a bit of advice from the list on the best approach to deploying this config, and potential feature additions to OCIO to support this situation (if they're deemed in the best interest of the overall project, of course). The options that I see are:
  1. Rerelease a config every time there is a new 3rd party transform
    • Pros
      • There would be one source of 'official' configs
    • Cons
      • Lots and lots of configs. Users would have to update constantly.
      • Different apps typically source their own set of configs. Updating configs for all apps could be tedious. For large shops and people comfortable with environment variables, this isn't a problem. For smaller shops and individual users, that might be a blocker.
  2. Users regenerate configs dynamically as 3rd parties make transforms available
    • Pros
      • Users do this on their own, as they need.
    • Cons
      • There is another process to support. What happens if their are bugs?
      • A splintering of configs. Debugging an 'official' config becomes more complex if the generation process has lots of options.
  3. Extend OCIO to allow some form of automatic, dynamic color space addition
    • Pros
      • Allows a clean separation between the official config and 3rd party transforms. Each data set can evolve on its own.
    • Cons
      • Features to support this need to be defined
      • Workflow for deploying new color spaces / transforms needs to be defined
Are there better approaches to that problem? The 3rd party transforms aren't show, shot or sequence LUTs so just substituting LUT paths based on environment variables isn't enough. They will need to be named and differentiated from each other. Additionally, the number and names of the color spaces/transforms can't be known before the main config is released.

This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg.

Any thoughts or advice you can provide would be appreciated.

Thanks,
HP





ocionuke module different in nuke 9.0

Ashley Retallack <ashley.r...@...>
 

Hi guys 

I was wondering what the strategy is between the project and the Foundry as far as keeping python modules up to date etc. 

As I have found the there are changes to the ocionuke module included with nuke 9.0+ compared with the latest branch of OCIO.

Which means in order to use our build of OCIO,  we need to either merge these changes to our version or edit nuke to not call these new features.

cheers

Ash


building latest release w/ Visual Studio 2012

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

Trying to build master and the build process is failing trying to process tinyxml and yaml, such as this:

2>------ Build started: Project: tinyxml, Configuration: Debug x64 ------
2> Building Custom Rule D:/paul/src/OpenColorIO/CMakeLists.txt
2> CMake does not need to re-run because D:\paul\src\OpenColorIO\build\CMakeFiles\generate.stamp is up-to-date.
2> Creating directories for 'tinyxml'
2> Performing download step (verify and extract) for 'tinyxml'
2> -- verifying file...
2> file='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz'
2>CUSTOMBUILD : -- verifying file... warning : did not verify file - no URL_HASH specified?
2> -- extracting...
2> src='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz'
2> dst='D:/paul/src/OpenColorIO/build/tinyxml-prefix/src/tinyxml'
2> -- extracting... [tar xfz]
2> -- extracting... [analysis]
2> -- extracting... [rename]
2> -- extracting... [clean up]
2> -- extracting... done
2> No update step for 'tinyxml'
2> Performing patch step for 'tinyxml'
2> 'patch' is not recognized as an internal or external command,
2> operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5): error MSB6006: "cmd.exe" exited with code 9009.
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This later prevents the OpenColorIO target from building.
I also tried with the frederikaalund:master pull request with the same results.

Any suggestions?


Re: OS X 10.9 build/link issues w/ XCode 5.1.1

Mark Boorer <mark...@...>
 

Hi Paul,

Could you perhaps copy in the link errors here?

Also are you building OCIO with the same C++11 features enabled?

Cheers,
Mark

On Fri, Sep 5, 2014 at 4:14 PM, Paul Miller <pa...@...> wrote:
I'm trying to use OCIO with an application built with XCode 5.1.1.

I can configure and build OCIO fine, but when I try to link it into my
application there are link errors.

I'm not using boost pointers, but standard C++11 pointers, in both places.

Anyone else have a similar issue?

--
You received this message because you are subscribed to the Google Groups
"OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


OS X 10.9 build/link issues w/ XCode 5.1.1

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

I'm trying to use OCIO with an application built with XCode 5.1.1.

I can configure and build OCIO fine, but when I try to link it into my application there are link errors.

I'm not using boost pointers, but standard C++11 pointers, in both places.

Anyone else have a similar issue?


How to use OCIO::ROLE_COLOR_PICKER

Antony Riakiotakis <kal...@...>
 

Hi,

I'm trying to hook up OCIO properly to blender's color picker system and allow choosing an arbitrary color tranform before uploading the color picker colors to our display device.
 
In blender, by default, we have a standard linear reference color space with srgb primaries, and our display transform is non-linear srgb.

The issue I am having is that I suspect that defining a color picker color space and then defining a processor from that space to display space will not help at all since it will void the transform to the color picker color space. I could probably write additional color spaces that "act" on display color space but I imagine that if I did that then OCIO would first convert my colors to the display space and then perform the transforms (I may misunderstand something here, please correct me if I'm wrong).
Is there a way to keep the color picker space transform and upload properly to the device by applying the device dependent transform without transforming to the device color space?

I have digged a few emails and found that OCIO::ROLE_COLOR_PICKER may do what I want, but found no comprehensive examples. Can someone point me to an example and/or explain how to use something like this?

Thanks!


Re: PyOpenColorIO on Windows - how?

Simon Björk <si...@...>
 

Hi Mark,

thanks for your reply. I'm using Python 2.7.8, downloaded from python.org.

Thanks for taking a look at it!

Best regards,
Simon



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


2014-08-22 17:55 GMT+02:00 Mark Boorer <mark...@...>:

Hi Simon,

Unfortunately I haven't really had much of a look into the windows building process. Just wanted to clarify a few things though. Which version of python are you using (and was it one distributed by python.org or one you built yourself?).

If you built it yourself, which compiler / msvc version were you using?

Can't promise a speedy resolution to your problem, but I'll give it a stab when I get the chance.

Cheers,
Mark


On Tue, Aug 19, 2014 at 10:45 PM, Simon Björk <si...@...> wrote:
I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: PyOpenColorIO on Windows - how?

Mark Boorer <mark...@...>
 

Hi Simon,

Unfortunately I haven't really had much of a look into the windows building process. Just wanted to clarify a few things though. Which version of python are you using (and was it one distributed by python.org or one you built yourself?).

If you built it yourself, which compiler / msvc version were you using?

Can't promise a speedy resolution to your problem, but I'll give it a stab when I get the chance.

Cheers,
Mark


On Tue, Aug 19, 2014 at 10:45 PM, Simon Björk <si...@...> wrote:
I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


PyOpenColorIO on Windows - how?

Simon Björk <si...@...>
 

I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working?

I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.

When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application.

Thanks for you help.

Best regards,
Simon







-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Re: Review: Inital pass at searchpath impl

Kevin Wheatley <kevin.j....@...>
 

When I looked at trying to use per-shot grades last, I ended up with the limitation that you couldn't dynamically determine the representation which meant you could not have say a 3D LUT for one shot and a CDL for another.

Something that I did manage to make work was a layering approach allowing a top level look to be published, followed by more specific sequence and under that shot grades, although that didn't scale well it involved well structuring paths and names of files and using the search path capability to find the right one - needless to say this was a very twisted approach to achieving this - it didn't handle multiple versions of looks/grades, which combined with the fact that vendor supplied applications don't necessarily fully expose the OCIO capabilities meant I gave up and did something  less twisted.

As for per shot variables with edited timelines, I was utilizing the config overrides to replace environment variable settings, this worked great in Nuke and other similar applications where this is exposed, but lots of tools don't expose the feature for instance heiro/heiroplayer would be a suitable place to do this.

Kevin



Re: Review: Inital pass at searchpath impl

Tobias Pfeiffer <pixeld...@...>
 

Hi guys,
I do understand the limitations of the use of env vars to point to shot grades, but dont know how to deal with it (even 4 years later) in case of flipbooking with RV.
Do you have any suggestions / Best Practices for that?
Thank you.
Tobi

Am Freitag, 29. Oktober 2010 00:24:03 UTC+2 schrieb Jeremy Selan:

There's a lot of good ideas here, it's taken me a bit of time to think
through the implications.

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further?  (Skype, iChat, etc).  Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.

> What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. > Then re-syncing these profiles would be a nightmare.

Agreed.  Under no circumstances are we going to make per-shot looks
complicated to use. We're in the same boat here.

>> JS:  I think it will be preferable when possible to minimize the use of envvars.
> MH: Can you elaborate on this?

Your approach to implementing per-shot looks - using environment
variables within search paths - is clever.  However, I'm not sold.
The portion I'm concerned about is the use of environment variables as
a communications mechanism.

For an application (such as a compositor) where you're not changing
show / shot / sequence at runtime the use of envvars is no big deal.
For example, say you have a per-shot display lut
(/job/$SHOT/.../shotgrade.3dl).   You could run a script which sets up
the shot environment, launch the APP, and everything just works.

However, consider an image-viewing tool which needs to flipbook
multiple shots (or whole sequences) back to back. I.e., the display
transform, as queried from OCIO, would be different based on the shot
name. Would this approach be possible using an envvar mechanism?  I
dont believe so.   Envvars are commonly locked down at launch time.
And, even if you could modify it at runtime as playback was in
progress, would you want to? How would you notifiy OCIO that it had
changed?  This seems like a tricky implementation, and strikes me as
going down the path of evil.

I would prefer to promote this concept of 'variables' to be an
explicit communications mechanism, rather then using envvars as a
back-door.  Alternate implementation options include:

* a config->setVariable option,  where variables were available for
use in color transforms.  (They could even retain the $SHOW $SHOT
syntax).  This way the OCIO plugin could set it as needed, and with
the python API exposed in client apps the list of variables could even
be amended with facility code, as needed at runtime!

* Alternatively,  with a less stateful implementation the variables /
arguments could be passed along in the config->getProcessor call. This
may be preferable to those computer scientists among us.

Either way, this passing of variables as arguments to a transforms is
half of the work towards allowing fully dynamic colorspaces. (The
other 1/2 being the plugin API to define the lists of transforms at
runtime).

Perhaps this is good reason to move forward on both ASAP?

-- Jeremy


Re: Windows Build

Tobias Pfeiffer <pixeld...@...>
 

thanks a lot for this!

Am Montag, 21. Oktober 2013 17:15:40 UTC+2 schrieb Marie Fétiveau:

Hello !

OpenColorIO.dll and ociobakelut.exe :
Built with msvc10 on win7 (64 bits).

No time right now to do a full build but I'll try next time I'm on Windows.

++

Marie


On Thu, Oct 17, 2013 at 1:54 AM, Jeremy Selan <jere...@...> wrote:
Does anyone have an OCIO build already made for Windows that they're
willing to share?

Specifically, we're interested most in the OpenColorIO.dll and
ociobakelut.exe, but it would be great to get ALL the command-line
utilities if available.

Thanks!

-- Jeremy

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Crash issue having multiple active_displays in a config

simon smith <si.c....@...>
 

Hi Mark - just to confirm that the fix works (as expected) just fine.


On Friday, July 25, 2014 1:17:18 PM UTC+1, simon smith wrote:
I can't check that immediately, but when I have got the time to check it out I shall report back.

Thanks for the help Mark.


  - Simon.

On Friday, July 25, 2014 12:33:23 AM UTC+1, Mark Boorer wrote:
Hi, Just following up.

This issue should now be resolved. I have patched OCIOYaml.cpp, and pushed those changes to master. If you are able, could you confirm that this solves your issue?

Cheers,
Mark


On Thu, Jul 24, 2014 at 11:47 AM, Mark Boorer <mar...@...> wrote:
Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

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

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c...@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.



Re: OCIO error in Hiero

Deke Kincaid <dekek...@...>
 

Hi Jose

You are using a 3d lut which is not reversible.  Only 1d luts are reversible.  Is this a lut that you created?


On Fri, Jul 25, 2014 at 3:47 PM, Jose Enriquez <jenr...@...> wrote:
Hello everyone, I have a problem creating a lut from nuke to hiero, in hiero I receive this error;

LogCrec709 inverse; 1 OpenColor IO Error: 3D Lusts can only e applied in the foward direction.inverse specified

And can't see correctly the Alexa Proress in hiero,

Does anyone had this problem or a solution?

:D

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


OCIO error in Hiero

Jose Enriquez <jenr...@...>
 

Hello everyone, I have a problem creating a lut from nuke to hiero, in hiero I receive this error;

LogCrec709 inverse; 1 OpenColor IO Error: 3D Lusts can only e applied in the foward direction.inverse specified

And can't see correctly the Alexa Proress in hiero,

Does anyone had this problem or a solution?

:D


Re: Crash issue having multiple active_displays in a config

simon smith <si.c....@...>
 

I can't check that immediately, but when I have got the time to check it out I shall report back.

Thanks for the help Mark.


  - Simon.


On Friday, July 25, 2014 12:33:23 AM UTC+1, Mark Boorer wrote:
Hi, Just following up.

This issue should now be resolved. I have patched OCIOYaml.cpp, and pushed those changes to master. If you are able, could you confirm that this solves your issue?

Cheers,
Mark


On Thu, Jul 24, 2014 at 11:47 AM, Mark Boorer <mar...@...> wrote:
Ah right, now I see where the problem is!

Thanks for the breakdown, I've opened an issue on the github bug tracker, and I'll look to patching this tonight.

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

There are a couple of other places where this happens too

Thanks again!

Cheers,
Mark




On Thu, Jul 24, 2014 at 8:51 AM, simon smith <si.c...@...> wrote:
Hi Mark,

I'm using Visual Studio 2012, 64-bit compilation in debug.
If you view the disassembly of OCIOYaml.cpp in the load function  (or set a breakpoint in ~basic_string) you can see where it's destroyed as follows:

                {

                    std::vector<std::string> display;
00007FFDA504E132  lea         rcx,[rsp+0C28h] 
00007FFDA504E13A  call        std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FFDA4F35CAEh) 
00007FFDA504E13F  nop 
                    load(second, display);
00007FFDA504E140  lea         rdx,[rsp+0C28h] 
00007FFDA504E148  mov         rcx,qword ptr [rsp+3B0h] 
00007FFDA504E150  call        OpenColorIO::v1::`anonymous namespace'::load (07FFDA4F357D6h) 
                    const char* displays = JoinStringEnvStyle(display).c_str();
00007FFDA504E155  lea         rdx,[rsp+0C28h] 
00007FFDA504E15D  lea         rcx,[rsp+0C60h] 
00007FFDA504E165  call        OpenColorIO::v1::JoinStringEnvStyle (07FFDA4F331BBh) 
00007FFDA504E16A  mov         qword ptr [rsp+1898h],rax 
00007FFDA504E172  mov         rcx,qword ptr [rsp+1898h] 
00007FFDA504E17A  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (07FFDA4F35EB6h) 
00007FFDA504E17F  mov         qword ptr [rsp+0C58h],rax 
00007FFDA504E187  lea         rcx,[rsp+0C60h] 
00007FFDA504E18F  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (07FFDA4F36F82h) 
                    c->setActiveDisplays(displays);
00007FFDA504E194  mov         rcx,qword ptr [c] 
00007FFDA504E19C  call        boost::shared_ptr<OpenColorIO::v1::Config>::operator-> (07FFDA4F33972h) 
00007FFDA504E1A1  mov         rdx,qword ptr [rsp+0C58h] 
00007FFDA504E1A9  mov         rcx,rax 
00007FFDA504E1AC  call        OpenColorIO::v1::Config::setActiveDisplays (07FFDA4F33323h) 


Hopefully this displays OK for you.
You can see just before the c->setActiveDisplays(displays) the string destructor fires.
So the pointer passed to setActiveDisplay is thus now pointing to freed memory ....

This kind of makes sense - the scope is just for the return value as the object is not assigned to anything (the *contents* are, the c_str, but std::string doesn't reference count that!) but I suspect some compilers aren't so eager to destroy the returned string as Visual Studio 2012 ....


Simon.




On Wednesday, July 23, 2014 12:55:30 AM UTC+1, Mark Boorer wrote:
Hi Simon,

Not sure I see where a bug could be hiding. The scoping around those blocks seems fine to me.
setActiveDisplays(), though taking a const char * as an argument, never actually stores it internally, instead opting to store the results of another call to SplitStringEnvStyle().

SplitStringEnvStyle() makes a new std::string via pystring::strip as one of its first operations, so there is no possibility of char pointers falling out of scope.

This has been fairly stable code (since around 2011), though admittedly OCIOYaml.cpp has recently undergone some changes.

Would you happen to have some more information as to your development environment? Visual Studio / OCIO versions / ways to reproduce the crash you're seeing?

With a little more information I'll hopefully be able to root out the cause of the issue.

Cheers,
Mark


On Tue, Jul 22, 2014 at 4:03 PM, simon smith <si.c...@...> wrote:
I'm testing out some code and I've noticed a crash issue when a config (such as ACES, from the ICIO website) contain multiple active displays or views.

Basically, the code in ICIOYaml.cpp that takes an array of displays tries to join them together into one string using the JoinStringEnvStyle function (in ParseUtils.cpp) is flawed.

JoinStringEnvStyle will return a new std::string instance if more than one string is found in the array (it will pass the original "array" string back if there is only one entry in it).

The caller of JoinStringEnvStylein OCIOYaml.cpp takes a const pointer to this returned std::string to pass to the next function (setActiveDisplays) but it falls out of scope as soon as the const char* has been taken (it goes out of scope as it enters the next line of code). Thus on the next line the pointer is pointing to freed memory. You probably get away with this in release, but in debug (under windows) it will write freed memory markers as guards for this type of thing.

The code currently is:

std::vector<std::string> display;
load(second, display);
const char* displays = JoinStringEnvStyle(display).c_str();
c->setActiveDisplays(displays);

You can easily see the scope issue here.
I suspect a fix would be along the lines of:

std::vector<std::string> display;
load(second, display);
std::string strDisplays = JoinStringEnvStyle(display).c_str();
const char* displays = strDisplays.c_str();
c->setActiveDisplays(displays);

I thought I'd pass this on as I've not seen any notes on it anywhere, but it must be an issue for everyone.


 - Simon.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


861 - 880 of 2233