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:
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.
@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 GitHub - ampas/aces-dev: AMPAS Academy Color Encoding System Developer Resources 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.
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.
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:
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:
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…
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…
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.
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
