Gut the ICC and load the untransformed pixels as they would be fed in Linear. The ICC will be the largest performance hurdle for the load.
The output will be slower if you are set to the sRGB OETF due to the lookup nature of the from_reference direction. Change that to any well defined transform with a to_reference and from_reference and it will claw the cycles down to milliseconds.
A simple matrix transform can be made for the Nikon, via the Adobe matrices in dcraw. The ACES transforms are large due to the 3D LUTs.
I am bumping this old thread to let you know that I have introduced some basic OCIO infrastructure in PhotoFlow.
Currently it is possible to insert the “Filmic Blender” OCIO transform (using one of the supplied “looks” to control the contrast of the rendering) between the output of the processing pipeline and the conversion to the display device.
The filmic display transform is particularly suited to display on screen the output of a scene-referred pipeline, where pixels values can greatly exceed the maximum brightness of the display device. In such cases, the filmic view allows to “squeeze” the scene dynamic range into the range covered by the display. In addition to a filmic tone mapping curve that compresses the highlights in a pleasing an natural way, the view transform also introduces some desaturation and gamut compression in the highlights, mimicking the typical response of film emulsion.
@gez please correct me if anything I said above is wrong…
Here is an example of the display of an HDR image with about 24 stops of dynamic range.
First is the pixel data sent to screen directly through an ICC transform to the monitor profile:
As far as I know this is not entirely right or at least not optimal. In general an OCIO config is defined around a linear/scene referred color space which in case of blender (due to limits of the rendering engines) is a linear space with the sRGB/rec.709 primaries, it might also define some other linear or working spaces (ACES does this with ACEScg for example). When working with this it is preferred to work in the OCIO defined linear space(s) so in your above case the ‘working color space’ option should also be taken from the OCIO config[1] and the “display profile” should be disabled (since it is already set with the display setting of the OCIO settings)
I hope this made sense! And thanks for your work, even considering the above nitpicks I do think this is good enough to start some experimenting of myself!
[1] This can be defined with roles option in OCIO config (note is a bit outdate there is a compositing_linear option as well which can be found in the ACES 1.0.3 config)
The way it currently works in PhF is the following:
the pixel values are converted from linear Rec.2020 (or whatever colorspace they are in at the end of the pipeline) to linear Rec.709
the pixels are processed through the OCIO transform
the output is converted from Rec.709 with gamma=2.2 (which is the output encoding of the filmic looks) to the actual display profile
It is indeed sub-optimal because the gamut is squeezed to Rec.709 for the OCIO processing, but at least is correct from the color management point of view. Refinements will hopefully come in the not-so-far future…
Definitely sub-optimal since not all OCIO configs will work with that setup (for example there is no option to input linear rec.709 into an ACES config at least without adjusting). Still I think still good enough for some experiments with trying to get a per shot look (filmic blender is in this regard actually a bit better/easier to work with then ACES due to having its equivalent to the RRT put in the look instead of the output)
Yes, the reference space is different for each OCIO config, and therefore it needs to be somehow hard-coded. I am going from the working colorspace to linear Rec.709 in the filmic case, and I will have to go to linear ACES2065-1 (if I’m not wrong) in the ACES case.
Ah, yes that makes sense and I do agree that it will be hard to get around something hard coded in a RAW editor since we don’t have these nicely defined log spaces[1] that we can use as input, still I think for a proper OCIO workflow the conversion should happen earlier in the pipeline (note this is with my personal understanding of OCIO) .
Still I would like to thank you for your work on this, having at least basic support will make it much easier to experiment with different options!
[1] Although every manufacturer has their own log space so it can get a bit confusing
