May I interpret that to mean that ultimately the data needs to be bounded and that happens at the end of the process when the resulting data must be fit to the applicable output profile? Where by output profile that would mean the display device for what image is seen on the monitor or the profile selected for the image file (e.g., jpg, png, tiff, etc.). As it happens, I’ve also been using Elle Stone’s sRGB-ell-V4-g10.icc as my output profile of choice for some years now. However, my monitor (?display) is calibrated and uses a custom profile built using X-Rite.
Oh BTW, when you say linear you mean as opposed to logarithmic as applied in the histogram (i.e., Scopes in the case of DT)?
Kinda. The “bounding” I know of at the end of the pipeline is truncation to the data container bounds. In my hack software the internal image format is floating point, and the data can be pushed past 1.0, the normal convention for “white”. When the image is saved to, say, JPEG, the data has to be converted to 8-bit integers, and in my software data at and above 1.0 is converted to 255. I think dt also works this way, but I’ll leave that to others more familiar.
Same here, but I use her V2 profile for export to files. Not all color management systems grok V4 profiles…
I don’t know about others’ histograms, but my reference to ‘linear’ probably should be qualified to ‘scene-linear’, or ‘energy-linear’, or whatever term is comfortable to you to identify the image data directly related to the light energy of the scene…
It might be good to recall that DT used to have a fixed pipeline and the base curve was much earlier than where it is now. So it was applied earlier and the modules were expecting that bounded data much earlier. Now that you can move modules and have modules that will use unbounded data then this conversion to something that work for display can happen later after much of the editing math has been used with “Linear” unbounded data ie more of what the camera gave you…avoiding the old modules in the pipeline just helps to extend this…
As a result of this discussion I have discovered this article (which appears to have been authored by Aurélien) which pretty directly answers one of the main problems I was having with Filmic RGB. In essence, for the Scene tab it seems to suggest setting the White Relative Exposure by mapping to the histogram (i.e., what to look for) and the Black Relative Exposure to match the camera sensors dynamic range (i.e., what to look for). This is what I just couldn’t find in the User Manual. However, I would like to say that, at present, the User Manual may be what I like most about DT.
The referenced article also provided my first awareness of the https://www.dxomark.com/ website and how to find the dynamic range for my cameras, which is all news to me. Thanks for that.
It might be worth pointing out that, at least, on my first and only raw file to which this I’ve done this, to date, it had the effect of essentially turning the S curve into a straight line. However, when making some adjustment to Contrast and Latitude on the Look tab, also following suggestions from the referenced article, an S curve reappeared.
In conclusion, thanks to this article, I think I can move on and start learning how to use some of the other modules.
I’ve spent a lot of time reading the User Manual and find that when compared to others (both freeware & commercial) it is excellent. However, I have yet to discover the explanation about “pickers” provided herein which is very helpful.
In that, good to know it is NOT limited to picking color. However, picking still implies using the mouse to select something within the image (or possibly even something else) but what about the idea that it changes values (at least on the Scene tab) after just clicking on the picker icon. In that, without picking anything by my concept of what picking means.
Icons for auto processes have been changed in the tone eq and are not shown as pickers…but the default I think for most pickers if you do not specify a region is the entire image…so it takes an average of the image unless you introduce a restriction…in the picker tool itself ie the color picker module a single click is a single point and right clicking picks a specified area… you can save these and also show them on the image…perhaps not as nicely as they are shown in RT but nevertheless shown…
At least for me when you select the picker it is obvious what it is selecting, ie the entire image by default until you impose a different ROI for the picker… Note the selection box…
That’s what does the zone pickers next to whit and black point and auto.
You don’t have to care about how the curve looks like, you should look at your picture instead. If it misses some contrast then you go to look tab and adapt the contrast slider to the desired look.
The shape of the curve depend of your picture and will never be the same from one picture to an other and it also doesn’t have to have the same shape on all your pictures.
Sometimes I find it better to add local contrast instead of changing the global contrast, as the latter works mainly on the midtones, and lowers contrast in the lightest and darkest parts of the image. But this depends very much on the image. More in general, don’t try to do everything with one tool.
Even better, try browsing https://photonstophotos.net/ and learn about the difference between the “engineering dynamic range” DXO reports and the more practical “photographic dynamic range”.
And will continue to do so until display technology changes significantly. Film had the advantage of compressing a wide dynamic range into a narrower one. We still need to do that with the majority of displays in existence (and the only widely deployed standard for delivering still image content), and using the same approach as film is one that’s known to work well.
Things get interesting when you start looking at modern HDR displays - the wider gamut and wider dynamic range the display is capable of mean you don’t have to compress your dynamic range nearly as much. You can potentially skip the tone curve and only apply the inverse EOTF for the display in question (in DT, the output module) and it will actually look good. (For example, only applying the HLG inverse EOTF to linear data, then encoding to H.265 and feeding it to an HLG-capable TV.)
