I would be willing to help on the manual. Not lead, but assist. Get Outlook for Android<https://aka.ms/ghei36>
________________________________ From: William Ferguson <wpfergu...@gmail.com> Sent: Friday, October 12, 2018 11:51:39 AM To: darktable Subject: Re: [darktable-dev] Darkroom UI refactoring I started darktable, added all the modules to the interface, then opened an image and turned them all on. Then I looked at the pixelpipe order and this is what I found. The order is top to bottom. raw black/white point invert white balance highlight reconstruction chromatic aberrations hot pixels raw denoise demosaic denoise (profiled) tone mapping exposure spot removal lens correction perspective corrections liquify orientation graduated density base curve denoise (bilateral filter) haze removal input color profile color reconstruction color look up table defringe vibrance color balance crop and rotate colorize color mapping bloom denoise (non local means) global tonemap shadows and highlights equalizer local contast color zones lowlight vision monochrome contrast brightness saturation zone system tone curve levels fill light color correction sharpen lowpass highpass grain color contrast output color profile channel mixer soften vignetting split toning velvia framing watermark dithering My sensor doesn't support or require scaling and rotation of pixels, but I'd guess that it occurs somewhere around demosaic in the pixelpipe. There are a few surprises, at least to me, about the order. I've tried to use channel mixer to reconstruct a color channel, but it's so late in the pixelpipe, it's not well suited to that. I'd always thought of graduated density as an artistic module, but it appears to more of a correction module. I'm also surprised at how late denoise (NLM) is in the pipe. I'm always on the lookout for a new way to denoise, since I shoot so many high ISO images. Now I have some more things to think about and experiment with. :-) Now that we have a list of modules, in the order they are applied, where would the tab breaks occur? One other thought. Reorganizing the UI is more than just moving modules around. Significant portions of the manual will have to be reorganized and/or rewritten. And, the user base will need to be re-educated/retrained. Perhaps one or more of the users currently creating videos (Shane Milton, Keif Hunniford, Hans Birkland, Bruce Williams, sorry if I missed someone), would be willing to take on the project. In other words, if the UI is reorganized, then the introduction needs to be thought out and coordinated. Bill On Fri, Oct 12, 2018 at 7:19 AM Oskar Maier <oskarmaie...@gmail.com<mailto:oskarmaie...@gmail.com>> wrote: 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. A very big +1 for this, I agreee with you. I fell like fixing errors in the reverse order they occurred is the way to go here (Sensor -> Lens -> everything else). I'd also like to mention an easy example from my experience: When applying the highlights and shadows module to an image that was taken with a lens with heavy vignetting, the shadows slider will compensate for most of the vignetting. When the lens correction module is then enabled the corners will be brightened again, resulting in overcompensation and negative vignetting. But I am wondering why the lens correction module was put where it is in the first place. >From my workflow I would prefer if there was a first tab that would do basic processing (demosaic, highlight reconstruction, white balance) and correct technical problems of sensor (hot pixels, (profiled) denoise) and lens (lens correction, chromatic abberations, defringe). After that the camera manufacturers preferences could be applied (base curve and color LUT presets). At this point the Image should look like a better version of the OOC JPEG and the artistic part could begin with the other modules. If You wish to start with minimal preprocessing you could disable the base curve and the vendor specific LUT 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. I thought the same way but keep in mind that almost any module can be removed from the UI or put in the "starred tab" Also I have the feeling we are mixing two topics that are only somewhat related: The order of processing and the order in the UI. Thanks a lot for your good suggestions and bringing this (difficult) topic up, Aurélien! Cheers, Oskar 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><mailto: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><mailto:rawfi...@gmail.com> ha scritto: > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org<mailto: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><mailto: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><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<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+unsubscr...@lists.darktable.org> > ___________________________________________________________________________ > 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+unsubscr...@lists.darktable.org> > ___________________________________________________________________________ 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<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
