On the IDT side, the current Academy repo includes IDTs for the following cameras / configurations Arri Alexa with the following exposure indices: EI800, EI640, EI500, EI400, EI3200, EI320, EI2560,

Hey open source VFX fans, excuse the spam but I wanted to point you to a project I think would be of interest to people on this list. It's MOX, an open source movie format for

Yes, and I suspect we will continue to receive camera native material for a while. VFX houses will adopt ACES more quickly than production houses. Would it be a good idea to include

It's not uncommon to receive external material in camera color spaces and to want to ingest them using the same OCIO-supporting tools that are used for color management internally. That could be

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