Date   

Re: ACES OCIO configs, testing and feedback

Dithermaster <dither...@...>
 

I'm looking forward to updates to this config, especially when it includes the existing IDTs.

Once comment so far: You don't need a LUT to convert between ACES and ACESproxy; OpenColorIO can do it more accurately (and likely faster) using an AllocationTransform:

        - !<AllocationTransform> {allocation: lg2, vars: [-9.72, 7.8], direction: inverse} # ACESproxy Annex C to ACES

        - !<AllocationTransform> {allocation: lg2, vars: [-9.72, 7.8]} # ACES to ACESproxy Annex C


On Thu, Oct 30, 2014 at 4:19 PM, Haarm-Pieter Duiker <li...@...> wrote:
Hello OCIO developers and users,

The Academy is moving towards an official 1.0 release of ACES this fall. As part of that development effort, we are looking at the best way to support ACES through OCIO. Building on Alex Fry's earlier work, we have automated the generation of OCIO configs based on the transforms defined in CTL for a given release. Links to the configs representing the latest working group release follow this message.

We are hoping to get your feedback on the following items
  • The new ACES configs
    • What features should we include?
    • What's missing? (IDTs right now, for instance)
  • ACES overall
    • What's blocking adoption as we move towards 1.0
If you are interested in the scripts that were used to generate these configs, let me know and those can be made available.

Thanks in advance for your help,
HP Duiker
Consultant for the Academy on ACES
Duiker Research




Example configs for the latest working group release, WGR8, are available for private evaluation here:

--
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 Looks, graceful failure.

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

Hey guys

I'm trying to implement OCIO Looks on a job at the moment.

Ideally, I'd like to be able to point to a series of shot specific .cc files on disk, but this falls over when I have shots with no grade present on disk.

"OCIOIPNode: The specified file reference 'CDL_testing/$SHOT.cc' could not be found" (This is in RV)

I can get it to behave If I name the .cc file something static like clientCDL.cc, and move the $SHOT variable further up the path string, and then have fallback search paths to SEQ and SHOW directories with generic blank clientCDL.cc files. But I just feel like I might be missing a trick here somewhere.

How are other people implementing Looks in the wild?

Regards
Alex Fry
 



ACES OCIO configs, testing and feedback

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

Hello OCIO developers and users,

The Academy is moving towards an official 1.0 release of ACES this fall. As part of that development effort, we are looking at the best way to support ACES through OCIO. Building on Alex Fry's earlier work, we have automated the generation of OCIO configs based on the transforms defined in CTL for a given release. Links to the configs representing the latest working group release follow this message.

We are hoping to get your feedback on the following items
  • The new ACES configs
    • What features should we include?
    • What's missing? (IDTs right now, for instance)
  • ACES overall
    • What's blocking adoption as we move towards 1.0
If you are interested in the scripts that were used to generate these configs, let me know and those can be made available.

Thanks in advance for your help,
HP Duiker
Consultant for the Academy on ACES
Duiker Research




Example configs for the latest working group release, WGR8, are available for private evaluation here:


OCIO default config when using CreateFromEnv

Michel Lerenard <micheli...@...>
 

Hi,

I have an issue when trying to create a config from the environment, more specifically when no env variable is set.
The configuration that is returned contains one color space named "raw".

In my application, we need to have a colorspace named "linear" in the config, so I check if one already exists in the configuration returned, and add it if it doesn't.
I use the getIndexForColorSpace() function to check if my "linear" color space is there, and the weird thing is that the call returns 0, instead of -1!
I've printed the list of color spaces to be sure, I only have one item in it, "raw". I checked the source code, no role or display named "linear" appears, so I'm really wondering why the function finds something that matches.
Even the call getIndexForColorSpace("foobar") returns 0, so I did a last test:

OCIO::ConstColorSpaceRcPtr cs_ptr =config->getColorSpace("foobar");
printf("Colorspace name=%s\n", cs_ptr->getName());

The printed result was "raw".

I'm really lost here. I need to point out that if I load a configuration from an existing file that does not contains the "linear" color space, my code does work. It's not working only with the default configuration returned by CreateFromEnv.

Any help is appreciated.

Michel


PS:On a side note, I was surprised to see that the CreateFromEnv would not return a null pointer or an empty config if no env variable was set. There is not return code, no exception that can give any clue whether a config could be loaded or not after calling the function. That's quite a problem if you want to create a default config at runtime if none can be loaded.
How can I check that a configuration file was indeed loaded ?


Re: parseColorSpaceFromString() issue

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

I don't think so. I used to use the "colorspace" attribute stored on assets at my *previous* job to determine color space and only fall back to the file name if that didn't exist. Naming conventions are fragile things, as we know.

On Fri, Oct 3, 2014 at 6:13 PM, Sam Richards <sam.ri...@...> wrote:
I'm going through this right now, and have the horrible problem of trying to educate people to add the right color space to their filename, knowing full well that there is a strong likelyhood that initially things will only get worse, where they are writing files out as linear, but calling them log. 

Is it a horrible idea to use the ICC profile name that is in the file-header (assuming we could ever get that right?) to do the mapping? I'm sure the adobe products are at least trying to write that out correctly (its a shame Nuke isnt).

Sam.



On Thu, Oct 2, 2014 at 10:16 AM, <mike...@...> wrote:
On Wednesday, October 1, 2014 2:23:56 PM UTC-7, Mark Boorer wrote:

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.


Thanks Mark.  If you wouldn't mind handling the pull request, that'd be helpful.  I'm afraid I'm still not fully up to speed on git.

-miker

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

Sam Richards <sam.ri...@...>
 

I'm going through this right now, and have the horrible problem of trying to educate people to add the right color space to their filename, knowing full well that there is a strong likelyhood that initially things will only get worse, where they are writing files out as linear, but calling them log. 

Is it a horrible idea to use the ICC profile name that is in the file-header (assuming we could ever get that right?) to do the mapping? I'm sure the adobe products are at least trying to write that out correctly (its a shame Nuke isnt).

Sam.



On Thu, Oct 2, 2014 at 10:16 AM, <mike...@...> wrote:
On Wednesday, October 1, 2014 2:23:56 PM UTC-7, Mark Boorer wrote:

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.


Thanks Mark.  If you wouldn't mind handling the pull request, that'd be helpful.  I'm afraid I'm still not fully up to speed on git.

-miker

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

mike...@...
 

On Wednesday, October 1, 2014 2:23:56 PM UTC-7, Mark Boorer wrote:

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.


Thanks Mark.  If you wouldn't mind handling the pull request, that'd be helpful.  I'm afraid I'm still not fully up to speed on git.

-miker


Search path vs resource path

Lerenard Michel <micheli...@...>
 

Hi,

I'm a bit puzzled by the existence of these two variables, as they seem to do the same thing at first glance.

Looking quickly at the code it seems they have different behavior, but I don't quite get it.

Could someone explain when and how to use one or the other ?

Thanks.

MIchel


Re: advice, supporting dynamic color space additions to config

Osiris Perez <osiris.pe...@...>
 

Same here. We can easily do this through the API by re-generating configs on the fly as outlined in this thread. However, 3rd party tools that have standard OCIO integration are not aware of our changes. 

Having this support natively would make it easier to support global studio settings and show/project overrides throughout the pipe without having to re-write or work around 3rd party implementations. 

 


On Thursday, 25 September 2014 16:15:21 UTC-7, Steve Agland 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.


Re: parseColorSpaceFromString() issue

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

It's complicated. Metadata, file naming conventions, and color space dictates/restrictions in the specification of particular file formats may all be mutually contradictory. What do you do? What is the decision hierarchy?

Personally, I would prefer that filenames be arbitrary and that metadata be used to indicate colorspace. (Notwithstanding hard color space constraints of particular formats.)

Jeremy and I have discussed this many times before, and (if I may put words in his mouth) he believed strongly that metadata was so frequently wrong as to be useless (image apps may not set, drop, or incorrectly set the color space metadata).

It's true that the convention at SPI is to bake the color space name into the file name, and ignore everything else. This is, IMHO, largely a historical response to file formats that did not support any way to specify color space information, and a hodgepodge of image-handling applications and libraries that might botch it or simply not propagate the color space info from input to output (and more often than not, were almost completely ignorant of metadata). Perhaps with EXR gaining dominance (arbitrary metadata, yay) and OIIO being the basis of a growing majority of our image-handling software (a lot of attention to reading and propagating the metadata), relying on metadata for color space hints is more achievable than it once was. But there are still a lot of edge cases to struggle with.

Jeremy and I had, at some point, discussed the possibility of a coordinated attack involving a function (in one or both of our packages) that might take as parameters the filename, format name, and metadata (if any), and given all this information would return the best guess of color space, with some set of (documented) sensible rules to adjudicate any conflicts. It's even possible that the rules could be part of an OCIO configuration (i.e., a way to say "at studio TLA, filenames take precedence over metadata, here's the regex that isolates the color space name, but override that by knowing that '.blah' files are always color space 'foo'"). But we never quite got around to fully fleshing it out.

-- lg


On Oct 1, 2014, at 2:23 PM, Mark Boorer <mark...@...> wrote:

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.


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

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




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

841 - 860 of 2227