## OCIO Colorspace

Moderator: SecondMan

mseredkin
One Hundred
Posts: 98
Joined: Mon Sep 15, 2014 9:57 am
Location: Moscow, Russia
Been thanked: 5 times

### Re: OCIO Colorspace

It would be nice to see what color space the current node is in instead of keeping it in memory. Maybe there is a way, except "by eye"?

SirEdric
Fusionator
Posts: 1873
Joined: Tue Aug 05, 2014 10:04 am
Real name: Eric Westphal
Been thanked: 112 times
Contact:

### Re: OCIO Colorspace

Well...one could come up with a script to check each tool's colorspace like tool.Gamut.ColorSpace[1],
or if it's not a creator tool tool.Output[1].Metadata,
and then either write that information into the tool's InfoTab, or use that info to colorcode the nodes themselves.

mseredkin
One Hundred
Posts: 98
Joined: Mon Sep 15, 2014 9:57 am
Location: Moscow, Russia
Been thanked: 5 times

### Re: OCIO Colorspace

intresting...

SirEdric
Fusionator
Posts: 1873
Joined: Tue Aug 05, 2014 10:04 am
Real name: Eric Westphal
Been thanked: 112 times
Contact:

### Re: OCIO Colorspace

This lua comp-script could be a starting point...

Code: Select all

ct = comp.CurrentTime
for n, tool in pairs(comp:GetToolList())do
if tool.Output then
if tool.Output[ct] then
print(csID)
tool.Comments[ct]:gsub('! %w+ !', '! ' .. csID .. ' !')
else
end
end
end
end
end
end
Added in 12 minutes 26 seconds:
Alternatively with Tile ColorCoding

Code: Select all

ct = comp.CurrentTime
csCode = {['ACES']={R=0.7,G=0.3,B=0.3}, ['Rec709Display']={R=0.3,G=0.7,B=0.3}, ['SimplifiedsRGB']={R=0.3,G=0.3,B=0.7}}
for n, tool in pairs(comp:GetToolList())do
if tool.Output then
if tool.Output[ct] then
if csID ~= nil then
print(csID)
tool.Comments[ct]:gsub('! %w+ !', '! ' .. csID .. ' !')
else
end
if csCode[csID] then
tool.TileColor = csCode[csID]
end
end
end
end
end
end
end



SirEdric
Fusionator
Posts: 1873
Joined: Tue Aug 05, 2014 10:04 am
Real name: Eric Westphal
Been thanked: 112 times
Contact:

### Re: OCIO Colorspace

Ah...darn...once you start playing....

Code: Select all

ct = comp.CurrentTime
csCode = {
['ACES']			=		{['Tile'] = {R=0.5,G=0.2,B=0.2}, ['Text'] = {R=0.0,G=0.0,B=0.0}} ,
['Rec709Display']	=		{['Tile'] = {R=0.2,G=0.5,B=0.2}, ['Text'] = {R=0.0,G=0.0,B=0.0}} ,
['SimplifiedsRGB']	=		{['Tile'] = {R=0.2,G=0.2,B=0.5}, ['Text'] = {R=0.0,G=0.0,B=0.0}} ,
['ProPhoto']		=		{['Tile'] = {R=0.5,G=0.2,B=0.5}, ['Text'] = {R=0.0,G=0.0,B=0.0}} ,
}

function getMeta(tool)
end

for n, tool in pairs(comp:GetToolList())do
--status, csID, err = xpcall (getMeta, debug.traceback, tool)
status, csID = pcall (getMeta, tool)
if status == true and csID ~= nil then
print(csID)
print('changing ID')
tool.Comments[ct] = tool.Comments[ct]:gsub('! %w+ !', '! ' .. csID .. ' !')
else
end
if csCode[csID] then
tool.TileColor = csCode[csID]['Tile']
tool.TextColor = csCode[csID]['Text']
end
end
end



gez
Fusioneer
Posts: 140
Joined: Mon Jul 16, 2018 6:21 pm
Location: Argentina
Been thanked: 15 times
Contact:

### Re: OCIO Colorspace

Personally I'm not a big fan of metadata for colorspaces. I think it makes much more sense to settle on a reference colorspace and keep that in mind to apply the to-reference/from-reference transform only where they belong.
It keeps things easier.
In other words, colorspace stuff should probably take place ONLY after loaders and before savers. It's an input/output thing really, so keeping metadata (and the idea that that specific metadata will live through the comp as it should) sounds like calling for trouble.
Just imagine having merged an ACES asset on a sRGB background. What colorspace would survive? By convention I'm guessing that probably the one from the BG, but that makes the result incorrect. As the other way around.
So instead of trusting some colorspace definition in metadata, I think that it would be more sensible to always keep in mind that you want to do your compositing in a specific colorspace, so every input that is not in that colorspace should be converted to that reference.
With OCIO you have to know the colorspace of your assets and your reference colorspace. Metadata won't be passed to OCIO, so if you're using the official ACES ocio config, the metadata used in Fusion won't be of much use (you'll have to manually choose the source and destination colorspaces).
Last edited by gez on Sat Jun 15, 2019 9:26 am, edited 1 time in total.

gez
Fusioneer
Posts: 140
Joined: Mon Jul 16, 2018 6:21 pm
Location: Argentina
Been thanked: 15 times
Contact:

### Re: OCIO Colorspace

btw, regarding the original question, there's an important thing to note:
sRGB images are display-referred images, while the ACES workflow for compositing is intended to be a scene-referred workflow.
This means that your sRGB assets are in a format that was already transformed (destructively) to a specific display's constraints and it doesn't keep the energy ratios that you'd expect from a real scene.
Think of it as a printed photo of a landscape: it may look like a reasonable rendition of the original scene, but it's impossible to infer the original dynamic range of the actual landscape from it.
So, when you're ingesting a sRGB asset into a scene-referred workflow you have to think of it as a texture.
The ACES workflow has an appropriate input for that, the "Utility - sRGB texture" definition.
Using that input transform will convert your sRGB image properly to the ACES (cg in this case) colorspace, but it won't magically recover its dynamic range.
It would be more or less like bringing a printed photo to a real scene. You can use it for a billboard and use some tricks to convince the viewer that she's looking at the real thing, but it will never be the real thing.

TL;DR: Avoid using the output sRGB transform as input. It's called output for a reason. That transform is only intended for taking your ACES comp to an sRGB output.