Why in such order? I have read somewhere that we should reverse the effects in a reversed order to the order in which they were created. So, first the lens blur was created and then the matrix issues. Therefore, why not starting with sharpen demosaicing and afterwards continue with lens deblur?
If I understood correctlyā¦
Quote:
" While more than one of these issues can affect the same picture at the same time, it is better to try to fix them separately using multiple instances of the module. When doing so, ensure the issues are corrected from coarse scale to fine scale, and that denoising always happens first. That is, your instances should appear in the following pipe order:
- denoise,
- local contrast enhancement,
- dehaze,
4. lens blur correction,
5. sensor and demosaic correction.
Starting with the coarser-scale reconstructions reduces the probability of introducing or increasing noise when performing the finer-scale reconstructions. This is unintuitive because these processes donāt happen in this order during the formation of the image. For the same reason, denoising should always happen before any attempt at sharpening or increasing acutance."
ā¦ the order is correct.
4 Likes
Neat, thanks! I noticed that you use color look up table. Is there a scene-referred workflow alternative?
You can do similar things using the brightness and colorfulness tabs in CC and using the channel mixer and rgb color balance but the CLUT is quick. Really you can use all the modules in DT ā¦sometime there are caveats but you can use themā¦Boris recently demonstrated the use of CLUT in one of his video seriesā¦he will also use the lowpass filterā¦
Just past 19 min mark hereā¦but you may want to see from the start of the edit for the imageā¦
2 Likes
Working with software where āorderā is the first order of business (rawproc), itās really neat to see this discussion going on darktable.
That said, Iām going to throw a wrench into the discussion: rely less on what others tell you is āgoodā, and find out why for yourself. Iāll give you my simplistic basis, and you can consider it for yourself: The camera records a scene in an array of pixels where the measurements are āenergy-basedā, that is, related to the light energy presented to each pixel from the scene. āScene-referredā is another name for this, and the deal with our processing is to disturb that energy relationship as little as possible in the early operations of raw conversion, saving the departure from it to a more perceptually pleasing presentation, e.g., by filmic and the other tone curve, to the end of the toolchain.
Understanding this, and what is each toolās affect on it, will help you make better ordering decisions on your own, rather than just āwhat @anon41087856 sezā¦ā 
1 Like
FWIW, I would rather just pay attention to the arguments of people who have invested time into understanding these issues, and decide if I find them convincing or not. To form a serious opinion about this would require literally years of investment on my part, comparable to a graduate degree.
The problem with the experimental approach you advocate is that I would need to decide between methods that work 98% and 99.9% of the time, which is tricky because one may not run to all issues first.
My understanding is that the problem with the historical/display-referred/LAB/etc workflows is not that they never ever work, because then no one would have used them. The problem is that they can fail under some circumstances, and scene-referred tries to address these failures.
6 Likes
Fair enough, I know the time investment well, having done just that over the past seven years. It can be hard sometimes to separate from the inquiry long enough to go take picturesā¦
I think youāll get to that eventually, though, as you go through bouts of āwhat the hell is going on here???..ā and boom, you dig into itā¦ 
2 Likes
This is a good point to consider in this discussion, as the old tools arenāt just uniformly bad. Sometimes itās a matter of degree; a scooch of color saturation after the tone curve might not look egregious, but dial it up from there and watch the progressive circusā¦
My software only has crappy HSL color saturation, havenāt spent time figuring out an alternative as of yet. So, I still use it, but only right after the initial processing to linear RGB, and then never more than just a few increments. Just keeping it before the tone curve has helped retain a bit of its usefulnessā¦
Actually, at this point (3.8) I am fine with the complexity of Darktable. Having mostly made the transition to scene-referred, I am trying to focus on the 10-ish modules that I need 99% of the time and ignore everything else.
Currently my core workflow includes:
- filmic rgb,
- color balance rgb,
- diffuse or sharpen,
- color calibration,
- crop,
- tone eq,
- exposure,
- rotate and perspective,
- denoise profiled
- grain,
- retouch
- denoise (profiled).
(I am not counting orientation, chromatic aberrations, lens correction, highlight reconstruction, demosaic etc because these would naturally be enabled with safe defaults and are easy to deal with when I need to).
So the bottom line is that whenever someone says āhey, you can now ignore module X because module Y you are already using has the same functionalityā, I am sold.
5 Likes
Swap your
- grain
with mine
- colour look up table
and we have the same list of modules for those 99% of photos. 
Once you master those with masks and blend modes, you have everything you need to get great results.
5 Likes
But wait, the same page of the manual also says that:
"Diffusion can be removed in order to:
- recover the original image from sensors with an anti-aliasing filter or mitigate the blur created by most demosaicing algorithms (use the sharpen sensor demosaicing preset and move the module before the input color profile module in the pipeline)."
This seems to imply that sensor and demosaic correction should happen first, since the input color profile happens fairly early. Is this a contradiction, or am I missing something?
Going from memory but I think only color calibration is by default between input and diffuse so moving it before input is not a massive change in the pipeline wrt the other modules just the interaction of diffuse on the data before it gets to the input profileā¦
I thinkā¦
I understand that it can be a very useful module, but for tweaking a few colors I found parametric masks w/ color balance rgb a reasonable substitute (if a bit more tedious to set up, because of the mask, but also more control).
Absolutely! I will also recommend the method you described.
I only use the color look up table very sparingly when I want to quickly change one or a few specific colors. In most cases only darken or lighten. It simply saves a lot of time.
The disadvantage is that you can create artifacts very quickly and the module is not suitable for scene-reffered workflow.
But I hope that there will be a scene-reffered version in the future.
1 Like
Yes, I noticed in your tutorials that you often lighten a lens-shaped region in the middle to focus the eye. Neat trick, I have started using it.
I wish there was a picker-like tool that would set up a parametric mask in JzCzHz at the same time based on a region, with some kind of fall-off. This would help me with the ātweak single color, more or lessā workflow.
See:
and perhaps
2 Likes
This is actually already possible with the parametric mask if you use the colour selector for the colour range:
Sure, but I need to do this for Jz, Cz, and Hz separately. Not big deal though, sometimes just one is enough to select a feature in the image.
1 Like
What I miss - and this is the strength of color look up table - is selection of multiple ranges within a certain channel, here for example hue:
You can compensate for this by using several instances of a module, but it is more time-consuming.
3 Likes
Yes, I also miss it:
Please share your thoughts in the issue comments, maybe it would help the issue get some traction.
2 Likes