+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
