|
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.
|
|
|
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
|
|
|
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.
--
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.
toggle quoted messageShow quoted text
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
"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
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
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.
toggle quoted messageShow quoted text
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/issuesOur 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
--
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.
|
|
|
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
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/issuesOur 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
--
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.
|
|
|
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/issuesOur 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
|
|
|
4th Annual Open Source VFX "Beer of a Feather"
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/gastownHow 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!
|
|
|
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
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
|
|
|
Brew install OCIO breaking under 10.9.3
Hey guys
"brew install opencolorio" is currently failing for me under MacOSX 10.9.3 Was this working a few weeks back?
-Alex
|
|
|
