Le 10/10/2018 à 00:14, William Ferguson a écrit : > On Tue, Oct 9, 2018 at 7:18 PM Aurélien Pierre > <rese...@aurelienpierre.com <mailto:rese...@aurelienpierre.com>> 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. > > I tried this with as ISO 6400 (max normal ISO) and an ISO 12800 > (extended ISO) and didn't see this. I use a profiled denoise triplet > of color, lightness, and average plus hot pixels, demosiac, and > lowpass. The only difference I see is in the lowpass, since it occurs > after local contrast in the pixel pipe. All the other modules I use > for denoising occur before local contrast in the pixel pipe so it > doesn't affect the denoise. How are you doing heavy denoise? Perhaps > the heavy denoise is producing artifacts that the local contrast is > exaggerating. This effect is not systematic, but it's annoying when it happens. > > 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) > > I tried this also, and it did work. In addition, I learned how to use > the color balance module in a way that I hadn't thought of. Thanks. > Mostly I shoot sports, so this isn't something that I would use. > However, I do shoot some portraits so it's a nice trick to have up my > sleeve. This works for every kind of photography, when you want color accuracy. I took portrait as an example because we are more sensible to skin tones shifts, so the example is more dramatic. > > 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. > > Having to go through 2 tabs worth of processing might be fine when > you're processing single portraits, but I'm shooting sports and > processing approximately 100 images at a time. As long as the team > uniform colors are close, I don't mess with color. If the lights are > really bad, then I adjust white balance and tint. My workflow > consists of having the crop and rotate module open then then adjusting > the crop and rotation in the module and the exposure in the histogram, > then going to the next image. When I've done the cropping, rotation, > and exposure I select all the images and apply a denoise style, if > required, then a sharpening style, then I export. But you don't have to go through 2 tabs if you put the modules you use regularly as favorites and want to cross the system. > > 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 ? > > I think we have an education problem, and I'm not sure you can fix > that with the UI. Trying to force users to process an image in a > certain way by reorganizing the UI without educating them as to the > reason will lead to a bunch of frustrated users IMO. Educating the > users about how the modules interact, and how to prepare images for > further processing, takes the UI out of the equation. When enough > people with different workflows understand how the modules work and > get frustrated with how the UI is organized, then perhaps a group > effort, taking into account various workflows, to reorganize the UI > would make sense. I think we have to fix that in the UI. That's basic ergonomics : the UI defines how we use the tool. The way an image is processed inside dt is already enforced by the pixelpipe order, which is defined by technical requirements and some arbitrary dev choices. Your only choice is embrace this order or fight it. But fighting it is almost garanteed to lead you to editing in circles, because some modules perform non-linear operations with settings that don't adapt to the input, so if you change their input (because you have changed a previous module) you will have to adjust their settings as well. And as you don't know what they actually do, and as the UI doesn't guide you through it, you are just waltzing around and hoping for the best.
The same way chemicals work in a photo lab : you put the developer first and the fixer then, you don't get creative about it. If you are a chemist, you know why. If you are not, you follow the manual. A good method is a one that is unidirectional, and even when you are jumping steps for some reason, it's important that you know you are jumping a step. Currently, the UI doesn't do that. Since I have opened the source code of almost every module in dt and understood how it works from a maths perspective, I have been able to divide my editing time by 2-3 with better results, just doing the right thing at the right time, and mainly setting the modules in the same order they are applied. > 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 >> <mailto:darktable-dev+unsubscr...@lists.darktable.org> >> > > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@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
