On Wed, Oct 10, 2018 at 12:53 AM Aurélien Pierre <rese...@aurelienpierre.com> wrote:
> 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> > 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. > You load Tri-X Pan into your camera, set your ASA to 1600 or 3200 and shoot the roll. Then you put it in the developer and increase the time to develop your under exposed film. You could also vary temperature and agitation to get different results. You could and did get creative with the developer to achieve the results you wanted. :-) I'm not a chemist, but I am old and have shot and developed my fair share of film. > > 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. > So, you educated yourself on how the modules work and interact, and you apply them in the order you determined from your education, regardless of the UI. :-) If you just rearrange the UI without educating the users, then the users will just continue using dt in the same way they have with some added frustration because everything is not where they are used to finding it. Education teaches the users to apply the modules in the correct order. Reorganizing the UI just makes it easier. > > 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
