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.
3 Likes
Scene refered will give you more editing latitude, but if a module gives you the results you want reliably, then just use it and don’t worry about it.
5 Likes
This is a partial quote I saw one time…
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…
1 Like
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.
4 Likes
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.
1 Like
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.
2 Likes
I just filed issue 16448 for this. Let’s see if the attached logfile will already help to answer my questions.
1 Like
They have been talking about the CLUT module and it actually by default comes fairly early…
I’m trying overlay/composite to fix some problems with focus stacking. I’m using GitHub - PetteriAimonen/focus-stack: Fast and easy focus stacking to focus stack and to generate the intermediate aligned images.
I did a quick test, selecting a original image in overlay and a draw mask (with harmonic mean as blending), very impressive for little effort!
(yes, the mini lost a finger…)
5 Likes
Simple focus stacking is a new use for overlays that I had not thought of. Composite/overlay opens up a world of future possibilities for DT.
2 Likes
But you may need an alignment option for this (and other more advanced uses of compositing images, like panos). While this may be a nice feature to have, I don’t think it will (or should!) replace programs like GIMP, Krita, Hugin, … which are much better suited to the kind of image “manipulation” they are designed for.
I wouldn’t (and can’t 
) use Gimp for raw development, but it’s very good at combining images in all kinds of ways. But neither Gimp nor dt do panos, which is the forte of Hugin, etc. Yes, that requires learning several programs, each with its own quirks.
5 Likes
@Pascal_Obry
Some aspects of the new modules Composite and Canvas enlargement have been discussed in the thread canvas enlargement colors aren't independent.
It’s been clarified that the canvas extension is limited to a maximum of 100 percent in one direction. This means that using the new module for creating diptychs (with images of same size, which is the most usual), it will not be possible to create diptychs with some space/frame between.
This make me wonder whether there is some coding aspect that “dictates” the 100 percent limit, or whether this limit is set somewhat more arbitrarily.
If the latter is the case, could one then rather increase the maximum limit somewhat (eg. 120) to facilitate a certain spacing?
I would also appreciate it if somebody could clarify where in the pixelpipe the two new modules are placed.
Isn’t the placement of modules always obvious by activating them and looking at what is the order in the show only active modules tab? The modules are processed from bottom to top.
Of course it is, Terry – if one has the development version installed, that is …
Thanks for the info!
Could you not open a white or image of your choice…make it as large as you can. Then use two instances of overlay with images sized and positioned so that they have the border in between??
The memory needed to handle the final images. For composition like you want we had discussion of adding this support in the print module. This is already good for composition a page with multiple image and space between. We “only” need to add support for generating jpeg from this module.
Sounds like an excellent idea, thanks! – which just proves that there usually are more than one way to the goal, and that two minds often think better than one … 
EDIT: But using an image as “canvas”, I guess, might increase memory usage substantially?
Yes, I’ve previously thought about that print-function – and a “print to file” would be a valuable addition. Regrettably my own coding abilities are way below what’s needed to contribute in any way.
(Hopefully memory consideration will anyhow allow a slight increase in the expansion limit.)