+1 Am Fr., 12. Okt. 2018 um 09:00 Uhr schrieb rawfiner <rawfi...@gmail.com>:
> Hi > > I strongly agree that the order of modules should be more clear in the UI, > and that the UI should guide the user more. I like the suggestion Aurélien > made for this. > > Trying to follow the module order in the pipeline gives the best > performance, as computations are done once. > In addition, not following the module order turns into a nightmare if you > use parametric mask: as soon as you modify a module which is earlier in > pipeline, you have to redo your parametric masks. > Currently, I do that by learning by heart which module comes after which > module, which is not an ideal solution. > > Cheers, > rawfiner > > Le jeudi 11 octobre 2018, Jason Polak <jpo...@jpolak.org> a écrit : > >> I have given a lot of thought about your idea, which is obviously very >> well thought out. Thanks for having this discussion; at the very least, >> it is making me examine editing carefully. Of course I am not a dev so I >> don't make any decisions for darktable, so feel free to ignore this but >> I have some thoughts to your process: >> >> 1. I don't think denoising should happen before sharpening/local >> constrast. Here's why: I take a lot of noisy shots (typically an APS-C >> camera at ISO3200 in the forest will make some noise). I have tried an >> experiment of denoising before the sharpening. What happens here is that >> if I denoise first, the later sharpening stage sometimes can enhance the >> noise, or make the OOF area worse. It seems much more logical to me to >> do the sharpening/equalizer enhancement before denoising. Only then can >> I see what kind and how much denoising to apply. Moreover, your >> suggested experiment with local contrast and denoising does not seem to >> have much effect in a real-life scenario. >> >> 2. However, to your credit, the use of the color balance module as you >> suggested DOES work pretty well for portraits. >> >> To me it seems then that the fundamental problem then is: what is the >> most efficient way to process a photo so that it goes from the flat Raw >> image to something with the correct dynamic range and correct colours at >> the same time with a minimal amount of editing? Is this the same for all >> types of shots? And will changing the user interface help with this >> process? Well I'm not sure...but at least I learned something new in >> this discussion :) >> >> Jason >> >> On 2018-10-09 07:17 PM, Aurélien Pierre wrote: >> > What I call "signal-processing" here are all the module intended to >> > clean the data and turn an (always) damaged picture into what it is >> > supposed to look like in theory. That is : >> > >> > 1. reconstructing missing parts (clipped highlights) >> > 2. recovering the dynamic range (tonemapping) >> > 3. reconstructing the damaged parts (denoising) >> > 4. reverting the optical artefacts (vignette, CA, distorsion), >> > 5. reverting the color inaccuracies (white balance and ICC color >> > correction). >> > >> > You think you can waltz around modules and do the retouch in the order >> > you like. Well, you can, but that is asking for trouble. >> > >> > Take 2 examples : >> > >> > 1. Open a noisy image, turn on the laplacian local contrast, save a >> > snapshot, then enable a heavy denoising, and compare the 2 outputs : in >> > some case, the local contrast output will look harsher with denoising. >> > That means you should fix the noise before setting the local contrast. >> > >> > 2. On a portrait photo done with a camera for which you have an enhanced >> > matrix (basecurve = OFF), tweak the exposure until you get a nice >> > contrast (Lmax = 100, Lmin = 0). Then, in the color balance, tweak the >> > gamma factor to get the L_average on the face = 50. Save the snapshot. >> > Now, disable the color balance, tweak the exposure again to get a dull >> > image (fix Lmax = 96, Lmin = 18). Then, in the color balance, tweak the >> > gain factor to get Lmax = 100, the lift factor to get Lmin = 0 and the >> > gamma factor to get L_average on the face = 50. Which skin tones look >> > the more natural and which has less out-of-gamut issues ? (spoiler alert >> > : #2) >> > >> > Nobody will think of crushing the contrast first in the exposure module, >> > then bring it up later in the pixelpipe, in order to get better colors, >> > until he has seen the math going on inside… In fact, the autoexposure >> > tool even lures you into doing the opposite. >> > >> > Because darktable is modular by nature, modules are fully independant >> > and don't share data, but that leads to a fair amount of inconsistency. >> > You can tweak the contrast and lightness in 8 different modules >> > (exposure, contrast/saturation/lightness, tone curve, base curve, zone >> > system, color balance, unbreak input profile, levels) and people may >> > think they are equivalent, but they are not. I believe this >> > inconsistency should be adressed from the UI. >> > >> > In order to get the color correction right, you need to input a >> > well-behaved, dull-looking, image. So I want to put all the modules >> > doing that (before the color correction) in a #1 tab, and say to the >> > user : at the end of this tab, your image should look dull (not >> > beautiful). If this is done, proceed to tab #2 and never go back. >> > >> > Between tabs #1 and #2 -> correct the colors on (now) valid data. >> > >> > In the tab #2, I want to put all the cleaning modules that can affect >> > all upcoming local contrast ones, and say to the user : at the end of >> > this tab, your image should look clean. If this is done, proceed to tab >> > #3 and never go back. >> > >> > After tab #2, the image should be clean so do whatever you want and >> > enjoy your artistic life. And more importantly, if tabs/steps #1 and #2 >> > are done properly, you can copy/paste the editing done in the following >> > tabs from one picture to the other (almost) without any adjustement. So >> > you gain in reproductibility. >> > >> > If you want your daily-needed modules close to you, you will still have >> > the favorite tab. Currently, I bet they are mostly redundant with the >> > basic modules for most of us. >> > >> > As for high-pass and sharpen modules, the maths inside are exactly the >> > same : they are an unsharp masking >> > <https://en.wikipedia.org/wiki/Unsharp_masking>. The sharpen module has >> > just an hard-set overlay blending mode whereas the high-pass lets you >> > choose. >> > >> > What do you think ? >> > >> > Aurélien. >> > >> > Le 09/10/2018 à 15:11, Jason Polak a écrit : >> >>> * in/out color profiles are stored in the color tabs, whereas they >> are >> >>> "basic" in the sense they are needed from technical requirements >> and >> >>> always on, >> >> Yes they are needed, but I wouldn't want them cluttering up the 'basic' >> >> group. If they have to be modified, it's likely to be not very often >> and >> >> then they can be found in the color group because they have to do with >> >> color (at least, not coming from an image processing background, it >> >> makes sense for them to be there). >> >> >> >>> * signal-processing modules are mixed with creative ones >> >> Do you mean highpass and lowpass? If so, I don't think it's really >> >> strange. The highpass and lowpass modules create a sort of more >> advanced >> >> mask that could be used for sharpening, but they could also be used for >> >> more creative effects by using different blend modes. Regular >> sharpening >> >> and equalizer seem like more basic corrective modules (sharpening is >> >> typically because of anti-aliasing filters or softer lenses, equalizer >> >> for microconstrast-to-macroconstrast adjustments. >> >> >> >> The creative group consists of modules that provide a little more >> >> unusual effects that you might not really need for most shots but can >> >> often radically alter the look of them, or else things like framing and >> >> watermark. >> >> >> >>> * you get sharpen in enhancements and high-pass in effects, but they >> >>> do exactly the same thing >> >> Sharpening and highpass don't do exactly the same thing. In order for >> >> the highpass module to actually do something like sharpening, you have >> >> to combine its output with the image using a blend mode. If you use a >> >> different blend mode, the result wouldn't just be what you might call >> >> sharpening. Just try 'difference' blend mode for instance. You can >> >> create funny effects with it that might actually have an occasional >> use. >> >> >> >>> * same for local-contrast and wavelet equalizer >> >> I agree that this could be confusing, but here is some logic to it as >> >> well. The local constrast module in 'local laplacian filter' mode has >> >> sliders for how it operates on shadows, highlights, and midtones. It is >> >> supposed to enhance by operating on these three brightness areas of an >> >> image, whereas the equalizer more emphasizes the whole image all at >> once. >> >> >> >>> * same for the crop/flip and the perspective correction. >> >> Perspective correction is supposed to correct converging lines caused >> by >> >> the placement of the sensor plane away from the plane of converging >> >> lines. Crop isn't supposed to correct for anything. It's just taking >> >> part of the image. >> >> >> >>> I mean, even with my own workflow set apart, I just think it would >> make >> >>> sense to separate technical and creative modules completely. And by >> >>> technical, I mean everything related to image reconstruction and >> >>> normalization (things you would do in Matlab). Especially since the >> >>> technical modules mostly come early in the pipe, it would make sense >> to >> >>> have them grouped explicitely so that you set them first. >> >> Look, I don't think the arrangement of modules is 100% perfect, and >> >> certainly people will have different preferences. But I am also not >> sure >> >> why modules should be separated based on where they are in the >> >> pixelpipe. The pixelpipe is just the order of how the modules are >> >> applied and there are technical reasons for the pipe to be in a fixed >> >> order. >> >> >> >> For example, in an image I processed today, 'defringe' comes before >> >> 'equalizer' in the pixelpipe. But fringing is one of the last things I >> >> think about when editing because I care a lot more about general >> >> composition and look and feel. >> >> >> >> Jason >> >> >> ___________________________________________________________________________ >> >> darktable developer mailing list >> >> to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> >> > >> > >> > >> ___________________________________________________________________________ >> > darktable developer mailing list to unsubscribe send a mail to >> > darktable-dev+unsubscr...@lists.darktable.org >> >> ___________________________________________________________________________ >> darktable developer mailing list >> to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
