This module can be used mainly to process “high dynamic range images” (as an alternative to Tone-mapping, Log encoding, Dynamic range and Exposure…) , but it can also be used on “normal” images, and of course, like all “LA” modules, deltaE, transitions, etc. and the possibility of masks are an interesting addition.
These 2 modules (Jz and Cam16) can be used in “Log encoding” or “Sigmoid” (with or without taking into account Black Ev and White Ev) mode, the second one giving more possibilities of "solutions » (both Cam16 and Jz, for SDR images, with a first opening towards HDR images and viewing on appropriate monitors).
In the 4 cases, the preservation of the color (hue) is assured because they are CAM (Color Appearance Model).
From a personal point of view, I prefer the Cam16 module
Managing dynamic range is one of my main tasks in post processing so the many good tools are appreciated. My second tricky and recurring task is managing multi light source situations such as artificial and natural light in the same image (typically as seen through a window). Again these tools you are working on are a great help.
Figuring out the characteristics and limits of each tool takes a bit of time and I can’t say I’m there yet. Will look into the new settings and modules.
Been experimenting further with cam16 and sigmoid as local edits (though full image spot). I’m really liking the control and results.
One constant bug bear though is what happens to highlights. It’s the same with log. Any data you’ve recovered with highlights recovery is smashed down to blocks of solid colour. The work around is exclusion spots. It would be so nice to avoid this and solve it in tool. Is this behaviour somehow inherent in the algos?
Yes, as is currently designed RT, where HL processing using “Color propagation” is performed before demoisaicing. This very good algorithm created by Emil Martinec 10 years ago and improved by @agriggio , @heckflosse and myself allows a very good recovery of highlights.
The LA process, as well as the majority of the processes is after this treatment and even if the basis of the treatment is linear, it will come to disturb the upstream work.
So we can use the “excluding spot” or something else, like in the example on Rawpedia thanks to @Wayne_Sutton for the english version.
But, as I wrote in several places, this is only a step towards HDR (which is not only HL processing…), and supposes an HDR monitor (very expensive…) as well as a complete review of the RT output process (but that’s another matter)
As for the link on colorimetry and the term “perceptual” (which I don’t use much), it’s a very good information to share. For your information, I am going to be 75 years old, I have just been hospitalized and I will have another operation in the hospital in the coming weeks. I’m not going to get into a debate that won’t do much good. For your information I’ve been collecting information and learning about colorimetry since about 2005, my first “product” was an ICC input profile made for a D200 in 2006 with ProfilMaker5. I do not pretend to know everything, modesty seems to me an essential quality, especially in this field
Don’t forget a functional HDR display pipeline in Linux for the developers who primarily run Linux.
Windows and MacOS are much farther ahead in that one regard, but there isn’t anywhere close to a unified cross-platform API that supports HDR rendering or compositing. (Maaaaaybe there’s a hackaround for fullscreen Vulkan that Proton uses, but that doesn’t really help something like RT.)
Right now, HDR content pipelines for anything but video content is a shambles full of holes and incompatibilities. Gaming is also in a reasonably OK state, but that works around the whole compositor mess by usually being fullscreen.
