Date   

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.



Re: Crash issue having multiple active_displays in a config

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

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 <mark...@...> 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...@....
For more options, visit https://groups.google.com/d/optout.



Re: Crash issue having multiple active_displays in a config

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

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...@....
For more options, visit https://groups.google.com/d/optout.


Re: Crash issue having multiple active_displays in a config

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

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.


Re: Nuke colorconfig - View "None" is "raw" in OCIO

mikael....@...
 

"This applies only to non-linear input colorspaces" => not non-linear, all colorspaces except Linear.

Den onsdagen den 23:e juli 2014 kl. 09:07:28 UTC+2 skrev mikae...@...:

Not really - it happens outside Nuke using the ocio GPU support:

OCIO::DisplayTransform::create()
displayTransform->setInputColorSpace( "sRGB" )
displayTransform->setDisplay( "display" )
displayTransform->setView( "None" )
+ LUT data and GPU shader generation

This applies only to non-linear input colorspaces, if None is set as view then the input colorspace will not transformed to linear, right?

I modified the Nuke profile:

displays:
  default:
    - !<View> {name: None, colorspace: linear} <= instead of raw

To match the viewerProcess drop-down in nuke. With this setup you'll get a linear representation if None is used as view (in this example sRGB => linear).

I may not be right here :-) but I hope so. Guess it's more of a question about when the actual color transformation happens in nuke and ocio.

Mikael


Den onsdagen den 23:e juli 2014 kl. 01:33:31 UTC+2 skrev Mark Boorer:
Hi Mikael,

Just trying to see if I'm understanding your issue correctly. When using the OCIO Display node inside of Nuke (with the OCIO environment variable pointing to the nuke-default/config.ocio and the viewer transform set to "None") You are getting "raw" as the default input colorspace?

Would you mind letting me know the versions of Nuke / OCIO / OpenColorIO-Configs you are using?

At the moment, I can't seem to replicate the issue on Nuke8.0v5, with libOpenColorIO.so.1.0.7, and using the master branch of OpenColorIO-Configs. I see "linear" by default as expected.

Cheers,
Mark




On Tue, Jul 22, 2014 at 10:21 AM, <mikae...@...> wrote:
I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael

--
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: Nuke colorconfig - View "None" is "raw" in OCIO

mikael....@...
 

Not really - it happens outside Nuke using the ocio GPU support:

OCIO::DisplayTransform::create()
displayTransform->setInputColorSpace( "sRGB" )
displayTransform->setDisplay( "display" )
displayTransform->setView( "None" )
+ LUT data and GPU shader generation

This applies only to non-linear input colorspaces, if None is set as view then the input colorspace will not transformed to linear, right?

I modified the Nuke profile:

displays:
  default:
    - !<View> {name: None, colorspace: linear} <= instead of raw

To match the viewerProcess drop-down in nuke. With this setup you'll get a linear representation if None is used as view (in this example sRGB => linear).

I may not be right here :-) but I hope so. Guess it's more of a question about when the actual color transformation happens in nuke and ocio.

Mikael


Den onsdagen den 23:e juli 2014 kl. 01:33:31 UTC+2 skrev Mark Boorer:

Hi Mikael,

Just trying to see if I'm understanding your issue correctly. When using the OCIO Display node inside of Nuke (with the OCIO environment variable pointing to the nuke-default/config.ocio and the viewer transform set to "None") You are getting "raw" as the default input colorspace?

Would you mind letting me know the versions of Nuke / OCIO / OpenColorIO-Configs you are using?

At the moment, I can't seem to replicate the issue on Nuke8.0v5, with libOpenColorIO.so.1.0.7, and using the master branch of OpenColorIO-Configs. I see "linear" by default as expected.

Cheers,
Mark




On Tue, Jul 22, 2014 at 10:21 AM, <mikae...@...> wrote:
I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael

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


Re: Crash issue having multiple active_displays in a config

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

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...@....
For more options, visit https://groups.google.com/d/optout.


Re: Nuke colorconfig - View "None" is "raw" in OCIO

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

Hi Mikael,

Just trying to see if I'm understanding your issue correctly. When using the OCIO Display node inside of Nuke (with the OCIO environment variable pointing to the nuke-default/config.ocio and the viewer transform set to "None") You are getting "raw" as the default input colorspace?

Would you mind letting me know the versions of Nuke / OCIO / OpenColorIO-Configs you are using?

At the moment, I can't seem to replicate the issue on Nuke8.0v5, with libOpenColorIO.so.1.0.7, and using the master branch of OpenColorIO-Configs. I see "linear" by default as expected.

Cheers,
Mark




On Tue, Jul 22, 2014 at 10:21 AM, <mikael....@...> wrote:
I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael

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


Crash issue having multiple active_displays in a config

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

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.


Nuke colorconfig - View "None" is "raw" in OCIO

mikael....@...
 

I'm doing automated slap-comps to check render output in sRGB/Cineon and scene-linear, if I use the nuke profile and "None" as the view for the default display the profile returns "raw". It should be linear to match Nuke, right?
Mikael


Re: OCIO Governance Change

Alexander Forsythe <alexfo...@...>
 

You could also try a "pared down" version. ;-).  I love autocorrect. 


On Friday, July 18, 2014, Alexander Forsythe <alexfo...@...> wrote:
Jeremy.  

Just a suggestion but you may want to consider a branch structure similar to the one described here. 


We use a paired down version of this for a ACES and it works quite well. 

Alex

On Friday, July 18, 2014, Jeremy Selan <jeremy...@...> wrote:
Up until now we've been running OpenColorIO with myself as the "Benevolent Dictator". This has seemed appropriate for the early stages of OCIO's life where development was fairly dynamic and we had a smaller community of users. As OCIO now has wider adoption and is relied on in a large number of applications, we're opening up the management of the project to include the following developers who are now tasked as official OpenColorIO project leaders and administrators:

  Malcolm Humphreys
  Robert Molholm
  Brian Hall
  Matthias Scharfenberg
  Mark Boorer

I'll be staying on as well to continue to guide the project but since my new day job doesn't involve using OCIO every day, we wanted to ensure we have an empowered group of project leads. In the absence of an alternative formal governance model*, I'll continue to act as the tie-breaker if there is disagreement on any critical steps. That said, I expect we'll continue to have strong consensus going forward.

As many of you have noticed we have quite the backlog of open pull requests and issues:
  https://github.com/imageworks/OpenColorIO/pulls
  https://github.com/imageworks/OpenColorIO/issues

Our hope is that by empowering a wider group of leaders that we'll be able to make robust progress on both of these fronts.

The next big challenge in my mind is continuing to balance the dual goals of continued feature development, while also preserving a stable API / robust library that by pipeline necessity must be bullet-proof version to version. Perhaps now would be a good time to fork a stable 1.X branch vs a developer branch?

Regards,
Jeremy

* See http://oss-watch.ac.uk/resources/governancemodels for some interesting discussions on more formalized open source governance models.

--
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: Windows Build

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

Wow, I was only expecting to find ociobakelut.exe from the link Marie provided, but as far as I can see there are exes of all of the OCIO command line tools. Very nice and thanks a lot, seems to work as expected!

However, I was not able to get PyOpenColorIO working. I added /.../OCIO_1.0.9/pyglue/python2.7/site-packages/pyOpenColorIO/ to my Python path, but as I try to import it I get an error: ImportError: DLL load failed: %1 is not a valid Win32 application. I'm not sure if I'm doing this correctly or if this is expected to work. Any help would be very appriciated.

Best regards,
Simon



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

+46 (0)70-2859503


2013-10-22 0:19 GMT+02:00 Jeremy Selan <jeremy...@...>:

Excellent, much appreciated!

-- Jeremy

On Mon, Oct 21, 2013 at 8:15 AM, Marie Fétiveau <m...@...> wrote:
> Hello !
>
> OpenColorIO.dll and ociobakelut.exe :
> 1.0.8
> 1.0.9
> 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 <jeremy...@...>
> 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...@....
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> 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/groups/opt_out.

--
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/groups/opt_out.


Re: OCIO Governance Change

Alexander Forsythe <alexfo...@...>
 

Jeremy.  

Just a suggestion but you may want to consider a branch structure similar to the one described here. 


We use a paired down version of this for a ACES and it works quite well. 

Alex

On Friday, July 18, 2014, Jeremy Selan <jeremy...@...> wrote:
Up until now we've been running OpenColorIO with myself as the "Benevolent Dictator". This has seemed appropriate for the early stages of OCIO's life where development was fairly dynamic and we had a smaller community of users. As OCIO now has wider adoption and is relied on in a large number of applications, we're opening up the management of the project to include the following developers who are now tasked as official OpenColorIO project leaders and administrators:

  Malcolm Humphreys
  Robert Molholm
  Brian Hall
  Matthias Scharfenberg
  Mark Boorer

I'll be staying on as well to continue to guide the project but since my new day job doesn't involve using OCIO every day, we wanted to ensure we have an empowered group of project leads. In the absence of an alternative formal governance model*, I'll continue to act as the tie-breaker if there is disagreement on any critical steps. That said, I expect we'll continue to have strong consensus going forward.

As many of you have noticed we have quite the backlog of open pull requests and issues:
  https://github.com/imageworks/OpenColorIO/pulls
  https://github.com/imageworks/OpenColorIO/issues

Our hope is that by empowering a wider group of leaders that we'll be able to make robust progress on both of these fronts.

The next big challenge in my mind is continuing to balance the dual goals of continued feature development, while also preserving a stable API / robust library that by pipeline necessity must be bullet-proof version to version. Perhaps now would be a good time to fork a stable 1.X branch vs a developer branch?

Regards,
Jeremy

* See http://oss-watch.ac.uk/resources/governancemodels for some interesting discussions on more formalized open source governance models.

--
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 Governance Change

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

Up until now we've been running OpenColorIO with myself as the "Benevolent Dictator". This has seemed appropriate for the early stages of OCIO's life where development was fairly dynamic and we had a smaller community of users. As OCIO now has wider adoption and is relied on in a large number of applications, we're opening up the management of the project to include the following developers who are now tasked as official OpenColorIO project leaders and administrators:

  Malcolm Humphreys
  Robert Molholm
  Brian Hall
  Matthias Scharfenberg
  Mark Boorer

I'll be staying on as well to continue to guide the project but since my new day job doesn't involve using OCIO every day, we wanted to ensure we have an empowered group of project leads. In the absence of an alternative formal governance model*, I'll continue to act as the tie-breaker if there is disagreement on any critical steps. That said, I expect we'll continue to have strong consensus going forward.

As many of you have noticed we have quite the backlog of open pull requests and issues:
  https://github.com/imageworks/OpenColorIO/pulls
  https://github.com/imageworks/OpenColorIO/issues

Our hope is that by empowering a wider group of leaders that we'll be able to make robust progress on both of these fronts.

The next big challenge in my mind is continuing to balance the dual goals of continued feature development, while also preserving a stable API / robust library that by pipeline necessity must be bullet-proof version to version. Perhaps now would be a good time to fork a stable 1.X branch vs a developer branch?

Regards,
Jeremy

* See http://oss-watch.ac.uk/resources/governancemodels for some interesting discussions on more formalized open source governance models.


4th Annual Open Source VFX "Beer of a Feather"

Larry Gritz <l...@...>
 

For those of you attending SIGGRAPH 2014 in Vancouver, we will be once
again holding an event for developers and users of VFX-specific open
source projects. It's a great chance to meet in person with people on
the other end of the mail lists.

When: Wed. August 13, 2014, 6-8pm

Where: Rogue Kitchen & Wetbar in Gastown
601 W. Cordova Street
http://www.roguewetbar.com/gastown

How it works:

Our kind sponsors will charge up a tab, and we'll be able to get drinks
until the funding pool runs out (after which you're welcome to stay and
buy your own drinks). We'll also have lots of great food being served.

With proper food and drink in hand, relax and enjoy the company of your
fellow open source developers.

Your generous sponsors:

Ahead.IO
Digital Domain
Double Negative
DreamWorks Animation
Darin Grant
Industrial Light + Magic
Luma Pictures
Method Studios
Peregrine Labs
Pixar Animation Studios
Sebastian Sylwan
SolidAngle SL
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital

Please direct questions to: l...@...


--
Larry Gritz
l...@...


Re: Building "universal" binaries for MacOS

Andrea Mantler <man...@...>
 

Hi Robert,

I'm curious... will your changes be rolled into the main OCIO repository?  (If not, I should probably make a patch to apply to the main one for the next time we need to update our OCIO libraries.)

Thanks again for all your help!

Cheers,
Andrea


On Friday, May 30, 2014 1:51:06 PM UTC-5, Robert Minsk wrote:
If you do another pull the cmake file should use the internal lcms by default.

On Friday, May 30, 2014 10:19:00 AM UTC-7, Andrea Mantler wrote:
Yeah, I'm working at getting a universal version compiled now.  Thanks!

On Friday, May 30, 2014 11:50:22 AM UTC-5, rmi...@... wrote:
> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, rmi...@... wrote:
I have created a new CMakeLists.txt file but I currently do not have a way to test it.  If someone could please test the CMakeOSXArch branch on the rminsk/OpenColorIO repository (git clone -b CMakeOSXArch https://github.com/rminsk/OpenColorIO.git).

Thanks

On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


icc profiles not working

Alex Fry <al...@...>
 

Hey guys

Has anyone tried baking out icc profiles recently?

I've been trying to bake one out with variations on the following command:

ociobakelut --format icc --inputspace acesproxy --outputspace rrt_rec709_full_100nits  --description "AcesProxy to Rec709" ~/Library/ColorSync/Profiles/acesproxy_to_rec709.icc

ociobakelut doesn't throw any errors, and a profile is created.
But neither Preview or Photoshop are picking it up.

ColorSync Utility.app throws the following error when verifying .

~/Library/ColorSync/Profiles/acesproxy_to_rec709.icc

   Header message digest (MD5) is missing. 


It's also not showing any graphical representation of the profile in the "Lab plot" pane.


This is a fresh install of OCIO via brew.


-Alex



Re: Brew install OCIO breaking under 10.9.3

Alex Fry <al...@...>
 

Ignore this...

It was something broken in my brew..


On Sun, Jun 29, 2014 at 4:41 PM, Alex Fry <al...@...> wrote:
Hey guys

"brew install opencolorio" is currently failing for me under MacOSX 10.9.3
Was this working a few weeks back?

-Alex

192-168-1-7:~ alex$ brew install opencolorio

==> Downloading https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

Already downloaded: /Library/Caches/Homebrew/opencolorio-1.0.9.tar.gz

==> Downloading https://github.com/imageworks/OpenColorIO/commit/ebd6efc036b6d0b17c869e3342f17f9c5ef8bbfc.diff

Already downloaded: /Library/Caches/Homebrew/opencolorio--patch-f4acc4028090ea8d438c6e0093e931afd836314c.diff

==> Patching

patching file export/OpenColorIO/OpenColorABI.h.in

patching file export/OpenColorIO/OpenColorIO.h

==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencolorio/1.0.9 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCM

==> make

Linking CXX static library libOpenColorIO.a

[100%] Built target OpenColorIO_STATIC

Linking CXX executable ociobakelut

[100%] Built target ociobakelut

make: *** [all] Error 2


READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting




Brew install OCIO breaking under 10.9.3

Alex Fry <al...@...>
 

Hey guys

"brew install opencolorio" is currently failing for me under MacOSX 10.9.3
Was this working a few weeks back?

-Alex

192-168-1-7:~ alex$ brew install opencolorio

==> Downloading https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

Already downloaded: /Library/Caches/Homebrew/opencolorio-1.0.9.tar.gz

==> Downloading https://github.com/imageworks/OpenColorIO/commit/ebd6efc036b6d0b17c869e3342f17f9c5ef8bbfc.diff

Already downloaded: /Library/Caches/Homebrew/opencolorio--patch-f4acc4028090ea8d438c6e0093e931afd836314c.diff

==> Patching

patching file export/OpenColorIO/OpenColorABI.h.in

patching file export/OpenColorIO/OpenColorIO.h

==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencolorio/1.0.9 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCM

==> make

Linking CXX static library libOpenColorIO.a

[100%] Built target OpenColorIO_STATIC

Linking CXX executable ociobakelut

[100%] Built target ociobakelut

make: *** [all] Error 2


READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting


861 - 880 of 2215