Date   

Re: parseColorSpaceFromString() issue

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

Hi,

> May I suggest making parseColorSpaceFromString() optionally a little more strict?

I'm certainly happy to add in this functionality if it makes your lives easier.

> This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf").

As a quick aside, do many people use this functionality? I was under the impression that this was mostly an SPI thing (baking the colorspaces in to the filenames). Personally we use metadata / heuristics to determine which colorspaces our images are in. (eg, JPG files are sRGB, DPX's are in the camera's log space).

If you feel like knocking up a pull request containing your patch, I'll merge it (assuming it's all good). Otherwise I'm happy to do so on your behalf.

Cheers,
Mark


On Wed, Oct 1, 2014 at 9:49 PM, Sean Looper <sean....@...> wrote:
I've been bitten by this as well. Ended up writing my own parsing function.

On Wed, Oct 1, 2014 at 1:43 PM, Larry Gritz <l...@...> wrote:
+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited.

    "brickKilnFront.jpg"              => "lnf"

This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf").


On Oct 1, 2014, at 12:46 PM, Michael Root <mi...@...> wrote:

May I suggest making parseColorSpaceFromString() optionally a little more strict?

The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one.

Even if strictparsing is true, the 'strictness' is still pretty lax.  Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace.  

For example, parseColorSpaceFromString() returns:

    "dialogSync1020.0100.dpx"         => "nc10"
    "brickKilnFront.jpg"              => "lnf"
    "digiDoubleForeign1029.0100.dpx"  => "gn10"

May I suggest a config option like:

    delimiters: _./

Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string).  By default, delimiters is an empty string, which results in the current behavior.

Attached is a patch against 1.0.9 that implements this idea.

-miker

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



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

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


Re: parseColorSpaceFromString() issue

Sean Looper <sean....@...>
 

I've been bitten by this as well. Ended up writing my own parsing function.

On Wed, Oct 1, 2014 at 1:43 PM, Larry Gritz <l...@...> wrote:
+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited.

    "brickKilnFront.jpg"              => "lnf"

This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf").


On Oct 1, 2014, at 12:46 PM, Michael Root <mi...@...> wrote:

May I suggest making parseColorSpaceFromString() optionally a little more strict?

The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one.

Even if strictparsing is true, the 'strictness' is still pretty lax.  Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace.  

For example, parseColorSpaceFromString() returns:

    "dialogSync1020.0100.dpx"         => "nc10"
    "brickKilnFront.jpg"              => "lnf"
    "digiDoubleForeign1029.0100.dpx"  => "gn10"

May I suggest a config option like:

    delimiters: _./

Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string).  By default, delimiters is an empty string, which results in the current behavior.

Attached is a patch against 1.0.9 that implements this idea.

-miker

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



--
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: parseColorSpaceFromString() issue

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

+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited.

    "brickKilnFront.jpg"              => "lnf"

This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf").


On Oct 1, 2014, at 12:46 PM, Michael Root <mi...@...> wrote:

May I suggest making parseColorSpaceFromString() optionally a little more strict?

The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one.

Even if strictparsing is true, the 'strictness' is still pretty lax.  Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace.  

For example, parseColorSpaceFromString() returns:

    "dialogSync1020.0100.dpx"         => "nc10"
    "brickKilnFront.jpg"              => "lnf"
    "digiDoubleForeign1029.0100.dpx"  => "gn10"

May I suggest a config option like:

    delimiters: _./

Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string).  By default, delimiters is an empty string, which results in the current behavior.

Attached is a patch against 1.0.9 that implements this idea.

-miker

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




parseColorSpaceFromString() issue

Michael Root <mi...@...>
 


May I suggest making parseColorSpaceFromString() optionally a little more strict?

The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one.

Even if strictparsing is true, the 'strictness' is still pretty lax.  Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace. 

For example, parseColorSpaceFromString() returns:

    "dialogSync1020.0100.dpx"         => "nc10"
    "brickKilnFront.jpg"              => "lnf"
    "digiDoubleForeign1029.0100.dpx"  => "gn10"

May I suggest a config option like:

    delimiters: _./

Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string).  By default, delimiters is an empty string, which results in the current behavior.

Attached is a patch against 1.0.9 that implements this idea.

-miker


OSX 10.9 static build fails compiling ociocheck

andersl...@...
 

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

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


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

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

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


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

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

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

Any ideas?


Re: advice, supporting dynamic color space additions to config

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

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

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

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

HP





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

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

Steve


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

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

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

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


Re: advice, supporting dynamic color space additions to config

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

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

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

HP





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

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

Steve


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

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

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


Re: advice, supporting dynamic color space additions to config

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

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

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

Steve


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

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


advice, supporting dynamic color space additions to config

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

Hello,

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

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

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

Any thoughts or advice you can provide would be appreciated.

Thanks,
HP





ocionuke module different in nuke 9.0

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

Hi guys 

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

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

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

cheers

Ash


building latest release w/ Visual Studio 2012

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

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

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

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

Any suggestions?


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

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

Hi Paul,

Could you perhaps copy in the link errors here?

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

Cheers,
Mark

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

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

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

Anyone else have a similar issue?

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


OS X 10.9 build/link issues w/ XCode 5.1.1

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

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

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

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

Anyone else have a similar issue?


How to use OCIO::ROLE_COLOR_PICKER

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

Hi,

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

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

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

Thanks!


Re: PyOpenColorIO on Windows - how?

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

Hi Mark,

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

Thanks for taking a look at it!

Best regards,
Simon



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

+46 (0)70-2859503


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

Hi Simon,

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

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

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

Cheers,
Mark


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

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

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

Thanks for you help.

Best regards,
Simon







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

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

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


Re: PyOpenColorIO on Windows - how?

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

Hi Simon,

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

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

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

Cheers,
Mark


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

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

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

Thanks for you help.

Best regards,
Simon







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

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


PyOpenColorIO on Windows - how?

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

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

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

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

Thanks for you help.

Best regards,
Simon







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

+46 (0)70-2859503


Re: Review: Inital pass at searchpath impl

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

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

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

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

Kevin



Re: Review: Inital pass at searchpath impl

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- Jeremy


Re: Windows Build

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

thanks a lot for this!

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

Hello !

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

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

++

Marie


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

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

Thanks!

-- Jeremy

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

841 - 860 of 2217