PhotoFlow, OCIO and ACES

photoflow
ocio
aces

(Carmelo Dr Raw) #1

I have finally managed to introduce some support for OCIO configs in PhotoFlow. At the moment, two type of configs are supported:

In both cases, the interface allows to select among the various output types (“looks” in the filmic case, “views” in the ACES case) offered by the config.

Both configs are designed as “output nodes”, i.e. they are supposed to be placed at the top of the processing pipeline, just before sending the pixels to screen. They both address a similar problem, that is to nicely render scene-referred pixel values onto a destination display device. However, their goals are different:

  • the filmic node targets an sRGB-like output device (DCI-P3 is also supported, but not yet implemented in PhotoFlow), offering various degrees of highlights compression and overall image contrast
  • the ACES node instead aims at producing a consistent output across a large variety of display devices, from standard sRGB to HDR displays and cinema projectors

While the OCIO-Filmic node is already quite well tested, the ACES one is still in a very preliminary state. Moreover, I personally do not have any HDR display, so it is difficult for me to judge wether the ACES output is really consistent across different displays.

If anyone has the good hardware and is willing to test the OCIO-ACES output, it would be really great! The OCIO-ACES tool is found in the “color” tab of the tools dialog. A Linux AppImage with OCIO support is ready for download; Win64 and OSX packages are on their way…

The goal is to introduce an alternative color management system that is better adapted than ICC for HDR displays.

Here is an example of the OCIO-ACES and OCIO-Filmic tools with their options:

53

49


#2

I think enabling HDR on every OS would be a nightmare :grin:
Windows 10 has this API
https://docs.microsoft.com/en-us/windows/desktop/direct3ddxgi/high-dynamic-range-and-wide-color-gamut#hdr-and-wcg-apis
It’s necessary to send the right metadata and switch the monitor mode to hdr.

Probably even the gui needs to be converted with the correct hdr values.
:slight_smile:


#3

Doesn’t Krita support those as well? I can see OCIO support, LCMS, and many color space + depth all the way to rec2020 in Krita to my knowledge. ACES is likely supported too.


#4

@age I guess it depends on the transforms and views. E.g., HLG was conceived with the concept that it could fallback to SD if the screen wasn’t HDR. I have stared at the OCIO code in https://github.com/ampas/aces-dev for hours and it seems to be sensible although still incomplete. I am sure that our brilliant @Carmelo_DrRaw will know how to make it more suitable for our purposes.


(Carmelo Dr Raw) #5

OOOOOPS! You are absolutely right… my fault :wink:


(Graeme W. Gill) #6

Not the best way to do it. If the gui is color managed, then conversion from SDR defined values (i.e. sRGB) into the display HDR should be automatic.


(Carmelo Dr Raw) #7

Art the moment I am not focusing on UI color management, I consider only the image canvas. There pixels are pushed to screen directly, and color management is entirely handled by photoflow.


(Carmelo Dr Raw) #8

Here is an example of the ACES output at work.

One of the ACES test EXR images, directly converted from linear ACES P0 to display profile (sRGB):

Same image, through the ACES sRGB view:

And finally with an intermediate ASC-CDL color correction node. The input image is converted to ACEScg before entering the ASC-CDL node, then is converted to ACES P0 for the view transform:

I think this can be considered as a rudimental ACES workflow, but expert’s advice is very much welcome on this!


#9

Can’t play with it right now but definitely something I will be keeping an eye one, good work @Carmelo_DrRaw!


(Gustavo Adolfo) #10

newbie question: these will only work on hdr displays, right?
I’m asking this because on my non managed display, when I switch on ocio filmic, I get this:


(Carmelo Dr Raw) #11

No, something is wrong with the package… are you using the AppImage? Let me check…
It should work on any display, and is particularly useful with SDR ones…


(Gustavo Adolfo) #12

Yes, I am.


(Carmelo Dr Raw) #13

I have just tested this AppImage, and Filmic works OK for me:

Coud you send me the .pfi file, so that I can check what’s going on exactly?

Thanks!


(Gustavo Adolfo) #14

Sure. Here it goes. It’s from the caturday playraw
20170905_192243.pfi (47.3 KB)
Could it be some problem with Ubuntu 18.04?
Sometimes, this pattern shows up when I’m using other tone mapping tools from photoflow…


(Carmelo Dr Raw) #15

No idea what could be wrong… here is what I get under Ubuntu 18.04:

Could you check the terminal message, and/or try to switch on/off the layer below the OCIO one?


(Gustavo Adolfo) #16

I switched on/off all the layers below and the issue remained.

How to I check the terminal messages?


(Carmelo Dr Raw) #18

I am still working on the OCIO support on Windows, so the current win64 package still lacks the OCIO tools… hopefully this sill be fixed in a couple of days.


(Carmelo Dr Raw) #19

Start the AppImage from the command line, and redirect the output into a file:

./PhotoFlow-git-*.AppImage >& log.txt

(Gustavo Adolfo) #20

Thanks!
Here’s the log: log.txt (51.0 KB)


(Carmelo Dr Raw) #21

This is the reason for the missing processing:

OpenColorIO Error: The specified transform file '/tmp/.mount_PhotoFp9YCNt/usr/share/photoflow/ocio-configs/filmic-blender/looks/Filmic_to_0-85_1-011.spi1d' could not be loaded. Invalid 'From' Tag

Looks like an OCIO bug. Could you try to run

export LC_NUMERIC=C

in the terminal before launching the AppImage?