That's especially because most users are not interested by the insides of darktable that we need to draw a foolproof path for them. I don't want to pull a Steve Jobs here, but if users don't know, engineers have to decide for them (Apple style), or, at very least, give clear guidance, so they can make poor choices knowing how poor they are (Linux style).
Yes, you can create your own workflow and do things in the order you want. But even if it will work sometimes (all the time, if you do nothing complicated), it will not have the reproductibility and the efficiency you expect from a rational workflow. There is one (maybe two) right way to do it and a lot of wrong ways, because the pixelpipe is sequential and immutable, and you don't negociate with maths. In darktable, you have 2 big fulcrums that need precise input to work properly : 1. the color profile. 2. the lens profile. A profile is generated by computing the error on a signal, that is the difference between the actual measure and the expected value. The correction (of lenses, of colors, etc.) will then aim at reverting this error,*assuming* the actual input signal is in the same state than the signal used at calibration time. Any module coming before these modules should be used in order to normalize the input signal so the validity criterions of the profiles are met, and certainly not in a creative way. My example with the exposure in a previous message is the perfect case of a non-intuitive use driven by the technics and giving better results. Whatever module that comes before the color profile should be advertised as a technical module, and users should be aware that they are not intended to give beautiful results, but to salvage the input signal. That is : denoising, exposure, tonemapping, basecurves, graded filter, etc. Because the shadows and highlights module comes in the first tab, we are driven to use it first to fix the dynamic range but it's a mistake because it comes late in the pixelpipe and fixing the dynamic range earlier in the pipe will give better color accuracy. Moreover, base curves and tone curves are redundant as long as we don't explain clearly that base curves come before the color profile and work in RGB, whereas tone curves come after and work in Lab. Same fore tonemapping and global tonemapping : the tonemapping comes before the color profile and should be used with caution. Whatever comes after the profiles modules can be used freestyle, it doesn't matter. Softwares as Lightroom or Capture One provide their own base curves/tonemapping options AND color profiles, so they are able to automatically normalize the input signal back and forth, in a consistent way, before applying the color correction, without the user even knowing. But darktable choosed to be a modular technical RAW editor, with user-editable base curves,color profiles, and several modules that do the same things with different algorithms, so we have to embrace this logic and and push it to its maximum. If you don't draw a clear path for the user to follow, darktable will just look like an impressively clunked tool with many redundant modules. Having a flexible modules interface is relevant if the order of the filters is flexible as well (like layers in Photoshop, Gimp, Photoflow), but not here I think. Cheers, Aurélien. Le 12/10/2018 à 04:54, Matej Martinovic a écrit : > +1 to Maurizio. > As a user, I'm not really interested in the technically correct order in > which the modules need to be applied. I would much rather have the ability to > reorder the modules to my liking inside the favourites tab. Or to be able to > create multiple user defined tabs and/or rename the default tabs and reorder > modules inside of them. > > BR > Matej > > > > ---- On Fr, 12 Okt 2018 10:11:21 +0200 Maurizio Paglia <mpagl...@gmail.com> > wrote ---- > > > Hi all, > > if I can leave my very little opinion. > > I think we have to divide this matter in two separate flows: the > 'technical' and the 'usability' > > > > a) Technicians (developer) can understand and design very well the best > workflow for the image manipulation. > > b) Users (normal users) are not very interested in the above workflow > because they are focused on THEIR workflow. > > > > Users could also study some 'best practices' or follow some guru > reccomendations but I think finally each final user would like to follow its > personal workflow. > > Any user needs to be comfortable and asks the software to do the job in > the best possible way. > > > > For the above reasons I think a possible solution will be to add to > 'favourite modules' the capability to drag and drop modules in the order > preferred by each user (and maybe to ADD sub-groups of modules). > > In this way I can have (SEE) my workflow (modules ordered as I need) and > modules are grouped in the way I need. > > > > For example: > > > > EXPOSURE > > -> Exposure > > -> Levels > > -> ....... > > COLOURS > > -> Colour correction > > -> Velvia > > -> ...... > > CORRECTIONS > > -> Lens correction > > -> Crop and rotate > > -> Noise reduction (bilateral filter) > > -> Perspective > > -> ....... > > > > And so on. > > > > Thank you, > > Maurizio > > > > Il giorno ven 12 ott 2018 alle ore 09:00 rawfiner <rawfi...@gmail.com> ha > scritto: > > > > > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > 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 > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
