I hadn’t heard of the new overlay module - very interesting indeed.
Yesterday, while sitting in my campsite at a motorsport event, editing a bunch of photos on my laptop, I was thinking that I really like the new-ish rgb primaries module.
(I’m home now, btw)
The main hue-shifting functionality is useful, and I’m gradually using it more, but I find the global tint really useful as a ‘creative white balance’ module, so one can leave the color calibration CAT alone apart from it’s arguably intended use of ‘neutralising’ any casts.
Rgb primaries is nice for corrections too.
For example, I was using two cameras (both Nikon) at the event, and realised that although they were both set on auto WB, and both were responding well to the lighting conditions through the day, one had a greenish tint compared to the other.
Obviously, there’s many ways I could have corrected this, but as I was happy otherwise with both camera’s automatic WB, the global tint was a perfect solution to add a set ‘shift’, so as to speak, without ‘overriding’ the ‘as shot’ in color calibration.
I know color balance rgb can be used in the same way, but for simple global shifts the primaries is a lot handier.
Yes! I use it loads… especially if I’m on a laptop in unknown lighting. It really helps a lot.
I played with the nice overlay feature today on current master, compiled on Windows 11. It looks very promising & thanks for your effort you have put into this module
May I ask you to help me, as I would like to understand, if it is just related to my not too strong machine, or to the current state of implementation: when I do an overlay, the rendering is completely done on the CPU and not on the GPU (4GB openCL enabled nvidia). Other actions / module typically run fine on my system using the GPU.
I like this little addition. I have always been less than 100% confident about the fidelity of DT exports esp when looking at them zoomed out…this is nice as it will give you a more accurate comparision for previews vs exports…
On my side I see some part done on GPU for the preview & full/dev pipe but not for the dev pipe. Maybe there is a reason but I don’t have a definite answer. Please report on GitHub so that we can discuss this with our OpenCL expert. TIA.
Not sure if this will help but when you use one of the modules in DT they work in a certain colorspace and expect linear/non-linear input. You can see that by hovering. The color LUT module expects display referred input and works in the LAB color. if you introduce it into the pipeline the GUI can only access that data so if you have that coming before a scene-referred module that does not have that limitation you can in a way handy cap the flow of data in the pipeline
As I understand it data is not clipped by the module but the UI can only interact with display referred data… You can move such a module after the display transform and then this is less of an issue.
There is an article often referred to here that might help as well as you think about this…
This question about scene referred and others like it have me intrigued. It seems to imply that scene referred modules are always superior to displayed referred modules. Is this really the case? I see photography as about the look and personally don’t care much if this is produced by a scene referred or displayed referred module. I do understand that early in the processing scene referred is used for good reasons, but at some stage we move the processing into display referred modules. Would there really be an advantage in coding all of these modules to work in the scene referred space? Please take this question on face value. I am not trying to be argumentative. I am just asking an honest question which I don’t have a definitive answer to.
display-referred workflows place too much burden on our eyes and display — both of which can lie to us in a variety of ways.
I guess if you operate as much as you can on pixel data that is not repeatedly transformed before you make your adjustments then there could be at least theoretical preservation of dynamic range and color information…
But at this point anyway as @paperdigits Mica says if you get the results you like I wouldn’t worry too much about it…
Any time a module pushes something beyond white in display-referred, that data is lost. And the module itself needs to take care of how to deal with that clipping behavior in display-referred mode. This makes modules in display-referred harder to code, and in some cases less robust.
However, the modules that already exist in display-referred all handle this gracefully, so there’s no harm in using those. Especially if they’re not touching the brightest pixels much.
As others said, if you are fine with your workflow, that’s good, no matter which modules you are using. However, not all tasks can be accomplished equally well in a display referred domain, and this is why there’s still some functionality missing in the scene referred workflow which already has an equivalent in the display referred domain. This is mainly color related functionality (I’m not sure about the color lookup table that was mentioned though, it’s more a general thing).
Think about processing images for different output media and gamut, e.g. for HDR screens, for regular screens, and for print. This is – at least in theory – much easier to accomplish with a pipeline that is entirely on the scene referred side.
just my 2 cents: aren’t all available LUTs limited to display referred spaces anyway? The magic of the scene referred workflow is its unlimited nature and a LUT is always limited.
that’s why it is placed after filmic/sigmoid in the pipeline and that makes sense
As far as primaries and tone curves go, LUTs can be implemented in arbitrary color spaces. But you’re right in that LUTs have a finite value range, and clip what is out of bounds.
But there are, e.g. Log LUTs for transferring log video into an editing color space, and IIRC also LUTs for changing raw video into log. So long as the clipping value is higher than the sensor/log clipping, they are for all intents and purposes “scene referred”. This is however not common in the photo world, AFAIK.
I think other replies below your question have answered the benefits of scene-referred spaces. For the Color Lookup Table module specifically, I don’t think it handles scene-referred input very well. I’m not actually familiar with the code, so I can’t really speak to that, but you may have noticed that only small adjustments can be made with the module. And I’m talking really small adjustments. I can rarely push one of its sliders more than about 10% away from default before you get artifacts and poor-looking results.
My hope was that it could be made more robust by being converted to unbounded RGB or otherwise just better adapted to working with scene-referred modules. Whether it becomes scene-referred or remains display-referred doesn’t actually matter too much in my opinion, as long as it handles the input and output gracefully like other display-referred modules.
LUTs may well be, but I actually don’t use LUTs with the Color Lookup Table module. I use it as a colour adjustment module by just sampling a colour in my photo and using the LAB sliders, much like the HSL sliders found in almost all RAW editors. The new Colour EQ module coming in the summer may replace this module in my workflow, but that remains to be seen.
thanks for pointing to it.
