Good suggestion. We'll have to override some of the currently automatically generated transforms. Could you provide some example of when and how you would use the IDTs with OCIO? From a number of

you might want to account for different scalings of the log spaces (full range vs SMPTE levels), although the most useful form for OCIO is obviously the one in which CDL values apply directly. Kevin

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

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

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

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

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

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

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

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

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

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

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

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

+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited. This is an especially egregious failure, considering that JPEG files are by specification LDR

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

Hello, I'm trying to build 1.0.9 on OSX 10.9, but the build is failing compiling ociocheck: To do the static build I'm just setting OCIO_BUILD_SHARED to OFF and OCIO_BUILD_STATIC to ON.

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

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

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