There is no mechanism via OCIO; they are designed and open to examination.
Aside from absolute and relative rendering intents[1], Perceptual and Saturation via ICCs are secret sauce, subject to vendor.
On the contrary, ICCs are absolutely mandatory for print work.
[1] Ignoring the fact that even with these they are subject to the vendor using an appropriate adaptation approach. Nothing ensures this of course.
So what is the key difference between print and display? For me, in both cases one needs to transform a scene-referred image into something pleasing for the eyes, and on an output device with a limited dynamic range.
Moreover, most of the people print images in RGB colorspace, and never go into CMYKâŠ
If youâre producing CMYK files for a specific device, you need ICC for the transform.
Although itâs technically possible to go straight from scene to the CMYK output [1], it seems more sensible to produce that output from a proper tonemapped version in the display domain (since ICC management for print sort of draws an equivalence between the display range and the reflectivity of paper under specific lighting conditions).
[1] Iâd like to see a practical example of that and how a blind conversion from say scene-referred rec.709 to Fogra39L turns out, though.
But they send display-referred images to print, not scene-referred as all the commercial print facilities expect display-referred material.
In such case, the output produced by OCIO, being in a known colorspace is adequate for printing.
The only missing element is the colorspace tag in case youâre producing other than sRGB.
ICC is again the way to go.
But that doesnât make ICC absolutely mandatory for going from scene to display, you can grab that from the OCIO output/view.
They are both [display | device | output] referred formats. Post scene referred data rendering. Very little difference at that juncture.
And for performance, creative, technical and other reasons, OCIO fills this requirement very well. That is, if one has adopted a purely linearized reference space. If manipulation and compositing anomalies donât matter, display referred pipelines would suffice just fine.
While I donât have nearly [1]as much experience as @gez, having only been responsible for print magazine and album covers etc., it is safe enough to consider the chain of rasterization for print a black box; no one is painting raw ink values to the page. It would be foolish to not rely on ICCs for this, as they were designed to solve this problem and do so extremely well, with TAC, BPC, etc.
[1] By ânearlyâ meaning an order of a magnitude less knowledge and experience.
@anon11264400 @gez - Ok, letâs see if I finally got at least part of the discussion right.
The target output of an OCIO view is generally an âidealizedâ display with standard primaries (Rec.709, Rec.2020, etcâŠ). To go from there to the specific profile of a calibrated monitor, one still needs ICC, right?
If yes, what happens when the actual display as a gamut which is either smaller or larger than the one of the âstandardâ display used in the OCIO config?
Or I am still completely off track?
Yep, thatâs my main hangup. As long as we are capturing the calibration of cameras and displays as ICC profiles, I donât particularly see myself deleting LittleCMS from the ever-growing list of libraries in my software. Unless Iâm missing something in OCIO.
Video cameras seem to present a referenced starting point; this is conjecture on my part, might be worth discussing a bit.
Idealized output, yes.
Not necessarily. There are many profiling software approaches that will simply use a LUT, that may be software or in some instances hardware.
ICCs could be used, assuming one negotiates the disconnect between the two systems.
OCIO is under the control of the pixel pusher. It wonât do anything. If you are on an HDR10 display, it will dump the code values of whatever display grouping is selected, as per the views under it. If you are on an Apple P3 display and you have selected sRGB views, you will see the transforms as they were developed for sRGB.
OCIO leaves the crafting of the gamut mapping etc. up to the configuration designer, as no âone size fits allâ is sufficient for creative needs. It could be as simple as a colorimetric conversion via matrix, or as complex as a colour science based desaturation, additional crosstalk, etc.
Here is an example of scene-referred image that was entirely obtained with ICC-based tools.
It is the result of the exposure blending of 5 bracketed images. The RAW files were interpolated in PhotoFlow, and saved in the original camera colorspace before being aligned with align_image_stack. The aligned images have been re-imported into PhotoFlow, converted to linear Rec.2020 and blended with luminosity masks.
The blended image has then be saved in two versions, one in the same linear Rec.2020 colorspace, and a second version saved with a V4 sRGB profile.
Both TIFF files have been saved with a +4ev exposure compensation, which results in a significant amount of pixels exceeding 1.0 (just to demonstrate the unbounded conversions). The files can be downloaded from here.
The two screenshots below show the image without exposure compensation. The first one is a direct display of the original image, while the second one corresponds to the sRGB TIFF, re-opened, converted to linear Rec.2020 and with a -4ev exposure compensation applied.
The perfect agreement between the two images shows that V4 profiles with parametric TRCs are perfectly suited for manipulating images with arbitrarily large valuesâŠ
Ok, Iâm trying to follow your steps, so Iâll ask some questions.
You stacked 5 exposures in one single image. I assume that you did this to produce more dynamic range in your image than the approx. 12 stops your DSLR can capture in a single shot.
So whatâs the total dynamic range of your scene? Assuming you scaled the merged image to make middle gray to meet 0.18, how much does the brighter pixel in your scene read?
Asking questions based on assumptions? What if your assumption to stack images to get more dynamic range is wrong, and the real intention to stack the images was to get less noise? Does your question still hold then?
Wouldnât it be more constructive to tell us your point of view for both cases instead of answering with questions?
I made an educated guess (as weâre talking about scene-referred imagery which is likely to have a rather wide dynamic range), but since I wanted to make sure that I was in the same page asked a question. I donât know how @Carmelo_DrRaw produced the image and with what in mind, and both producing more dynamic range and reducing noise were valid examples of stacking.
How is your question out of the blue any constructive?
I didnât wrote that your question wasnât constructive. I wrote that it could have been more constructive.
In contrary you questioned the constructiveness of my question in general. The fact, that you answered my question and clarified one point (at least a bit), shows that my question was constructive 
Actually I was wondering the same thing. From my perspective as a photographer, well, as a photographer who isnât at all interested in tone-mapping huge dynamic range images - the line between ev-bracketing for noise reduction and ev-bracketing for increased dynamic range is a rather ill-defined line. But usually my specific goal is noise-reduction.
Finally got around to checking the file. It is definitely not scene referred, as the dynamic range is extremely compressed.
In the OCIO workflow, does âscene-referred image fileâ mean the intensities in the image file are equal to the scene intensities?
Or does âscene-referred image fileâ mean the intensities in the image file are proportionate to the scene intensities, which would allow exposure compensation and changes in white balance?
Yes.
The two arenât terribly different though.
Both scenarios would permit this.
The latter is different only by some uniform scaling.
In fact, the two concepts are equivalent. The dynamic range of the camera is given by the difference between the âeffectiveâ number of bits of the sensor. Reducing noise increases the ENOB, and thus the dynamic rangeâŠ
Not quite true. If you rise up the exposure, you will see that there is a lot of shadows details that comes up, because of the exposure stacking.
My understanding is that the absolute scaling of the pixel values does not matter (it can be moved up or down with an exposure compensation), what matters is that the pixels are proportional to the intensity of light reaching the sensor.
I thought you said in post 36 above that exposure compensation doesnât make an image ânot scene referredâ.
Exposure compensation is done by modifying the exposure slider, or multiplying or dividing by gray, or etc, of course operating on linear RGB, as Iâm sure @Carmelo_DrRaw in fact did.
Adding negative exposure compensation does compress the dynamic range of the image.
So how/why is it that the sample image posted by @Carmelo_DrRaw is ânot scene referredâ?
Actually not. In digital photography, the dynamic range of a camera is defined as the ratio between the lowest and highest light intensities that can be correctly measured (I.e. they are not completely masked by noise). An ideal 14-bit sensor has a dynamic range of 2^14:1, or 14 stops. If the noise level is three bits, the ENOB becomes 11 and the dynamic range 2^11:1.
Once the values have been converted to floating point, an exposure compensation scales proportionally both the lowest and highest light levels without loss of accuracy, and hence the dynamic range (which is a relative quantity) does not change.
At least this is how I understand the definitions and related mathsâŠ
