I am a bit suprised AD seems to have chosen to rename the OCIO profile names so they don’t match the ones coming from the OCIO organisation.
My Questions
It is a very surprising the decision to change these, the confusion on large teams is huge.
Any help appreciated.
wait what did I miss
Flame doesnt have OCIO? It uses syncolor ?
Well, I don’t really know the color science engine running under flame but given it has the ability to setup ACES 1.1 timelines I am assuming it does use the OCIO approach.
I will dive into this during the weekend to make sure I am not confusing everyone.
its a differnt thing, flames colormanagement predates ocio, and one of the core developer of ocio actually came up with syncolor as i understand it.
they are however not compatible.
we all hope that flame will switch to ocio sooner than later to be more pipeline friendly,
That makes sense, clearly they have taken the time to do the conversions of standard OCIO profiles to CTF which is why these are so familiar to me and how they work 1:1 with OCIO color profiles.
OCIO has become a critical component, like OIIO and hopefully soon OTIO, I really do hope Autodesk embrace these open standards.
they did the switch with maya a few years ago.
https://help.autodesk.com/view/MAYAUL/2023/ENU/?guid=GUID-4AE9AABC-A900-4276-AFE4-F9DCD96BA03D
@doug-walker is the brain behind it 
he can probably explain the history and the similarities of syncolor configs and ocio way better than I can.
I agree though, OCIO is critical for vfx work nowadays, at least syncolor is not inherently bad, its very flexible and the flame implementation is honestly extremely good, its jusr annyoing thay we have to do 2 configs one for flame and one ocio for the rest of the pipeline,
Yeah, personally I like Flame’s implementation with ACES much better than what I think is the overly convoluted OCIO.
But I don’t do a ton of work outside of Flame.
May God hear you
ADSK is already a partner in the OTIO consortium and have built some functionality into RV already. I’m assuming the benefits you are looking for with OTIO are the same thing we all wish for: seamless export of timelines from one DCC app into another without any scaling, repo, timing issues, etc etc. however this is not up to Autodesk. Until all the software companies can agree on some kind of standard or open format there’s not much anyone can do about that. I seem to recall @finnjaeger saying Resolve had some of that solved but i’m not holding my breath Adobe or Avid will rewrite their applications out of the goodness of their hearts…
Are you trying to fix an issue that does not exist? All the colour science I have done in Flame seems to match every other system in terms of colour transforms?! Are people finding otherwise.
I would add that I certainly don’t trust Resolve’s Colour Management. We always set the tone mapping to none which gives the anticipated result. You’ve got to be careful with the white point adaption though as it is inconsistent.
When there is the list of what processes Flame is doing to make the transforms, I seem to recall there being reference to OCIO in them but please don’t quote me on that.
@Slabrie @fredwarren Can you confirm what is happening under the hood?
I should also add that I use Flame to double check the colour transforms in Resolve when we are mastering. Predominantly working on Features that have multiple colourspace deliverables (DCDM, DSM, HDR & SDR Home Entertainment deliverables, Non-Graded Archive Masters, etc;) this is really important to us. I certainly rely on it to cross check and haven’t had any issues doing so.
It makes sense when you are not dependent of sophisticated workflows, automation and collaboration with others, this is why OCIO is a must. We need to be able to use the exact same configurations (including custom ones) independently of the software so although Flame Color Management seems perfectly good, it is the rest that we badly need.
In fact, given OCIO has already achieved the status of THE color management system for VFX, it is critical the rest of tools conform to it so I hope Flame move into OCIO soon.
I am aware OCIO configurations are rather overwhelming but it can always be trimmer if need it.
Very true, I saw and tested OTIO on Flame and Nuke and seems a great start, I hope the standard matures quickly and we can rely on OTIO instead of XMLs, AAFs and the relic EDLs are… in all honestly, the biggest issue I have in our industry is exchanging editorial information, truly embarrassing state of affairs.
When we created SynColor, we based it on OCIO version 1 and as you all know, Autodesk was a leading contributor of OCIO version 2, which uses some part of SynColor. We introduced OCIO version 2 in some of our products and who knows what we could do next 
You guys have been doing an exceptional job so I imagine down the line OCIO will be with us…
thanks guys