Re: [darktable-dev] Darkroom UI refactoring
First a message for everyone on this thread: please use just reply-to-list. Else I get 2 copies of the message. No need to cc to me or anyone else. I see your point about your editing, if you have an injury. I use darktable nearly daily and I regularly have to spend many hours in darktable and edit hundreds of shots, and I've become very fast at it so I do not think I would personally benefit. However, I do like the idea of customizable categories, and I think that would be far preferable than changing the interface for most existing users. Another disadvantage of your approach is that it places a huge amount of modules in category 1. That would get even more cumbersome to scroll through them if you have multiple instances of each module. Jason On 2018-10-07 11:39 PM, Aurélien Pierre wrote: > The real question here is : could you get past the change and benefit > from it ? > > I'm biased here, since I developed repetitive strain injury in the wrist > at the early age of 23. So I'm basically trying to improve the > efficiency of the workflow by decreasing as much as possible the number > of user interactions on each picture, especially the mouse interactions. > > If it's only for cropping, it can be fixed. At the end, I think it > really depends on how many hours you spend each week on darktable. > Because editing a whole wedding is definitely not the same as editing a > bunch of holidays pictures, so I guess every user will have a different > sensibility to workflow matters and the occasionnal users will mostly > care about the overhead of the refactoring (having to learn things > again) while the regular users will see it as a long-term investment. > > > Le 07/10/2018 à 23:02, Jason Polak a écrit : >> Hi! >> >> I can certainly see the logic of your idea. I definitely prefer the >> current setup, if only because that's what I started with. I think the >> only way to see if this is a good idea is to poll users because I am >> sure there are some that would like your way and some that prefer the >> current way. >> >> I do have a specific criticism about your approach, though. I think >> cropping should come early in the editing process. I care much more >> about adjusting the general exposure and crop (composition) before I >> could even think about lens correction or noise reduction. This is >> doubly so because I take a multi-pass view on editing. I first do some >> basic edits of exposure, cropping, and tone curve adjustments to the >> shots I think are half-decent, and then promote the best ones to the >> next star level. Only with the highest star rating do I even consider >> spending time on noise reduction and lens correction as there is not >> much point on noise reduction in the bad images. >> >> Personally, I have found after a couple months it's easy to remember >> where all the modules are and changing it would only make it worse for me. >> >> Jason ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Darkroom UI refactoring
Le 08/10/2018 à 00:42, Jochen Keil a écrit : > Hi, > > On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre > wrote: >> The real question here is : could you get past the change and benefit from >> it ? >> >> I'm biased here, since I developed repetitive strain injury in the wrist at >> the early age of 23. So I'm basically trying to improve the efficiency of >> the workflow by decreasing as much as possible the number of user >> interactions on each picture, especially the mouse interactions. >> >> If it's only for cropping, it can be fixed. At the end, I think it really >> depends on how many hours you spend each week on darktable. Because editing >> a whole wedding is definitely not the same as editing a bunch of holidays >> pictures, so I guess every user will have a different sensibility to >> workflow matters and the occasionnal users will mostly care about the >> overhead of the refactoring (having to learn things again) while the regular >> users will see it as a long-term investment. > So, how about custom tabs, that can be named freely and where users > can add and arrange modules to their liking? Because : 1. things have already been decided for everyone, hence the inconsistencies we have now, 2. moving modules between tabs is one line to edit in each IOP file, implementing a whole configurable layout is another (GTK) game. I'm trying to stay realistic here. There are dozens of things inside dt that should be user-edited, beginning with the color theme of the UI. But given the limited ressources we have, I'm trying to solve simple problems in a simple way, not trying to build spaceships. GTK is not Qt. > > The existing arrangement could be shipped as a preset, and other > presets could be added easily. > > Make it configurable instead of trying to figure out what's right for > everyone (hint: won't happen) > > Cheers, > > Jochen > > >> Le 07/10/2018 à 23:02, Jason Polak a écrit : >> >> Hi! >> >> I can certainly see the logic of your idea. I definitely prefer the >> current setup, if only because that's what I started with. I think the >> only way to see if this is a good idea is to poll users because I am >> sure there are some that would like your way and some that prefer the >> current way. >> >> I do have a specific criticism about your approach, though. I think >> cropping should come early in the editing process. I care much more >> about adjusting the general exposure and crop (composition) before I >> could even think about lens correction or noise reduction. This is >> doubly so because I take a multi-pass view on editing. I first do some >> basic edits of exposure, cropping, and tone curve adjustments to the >> shots I think are half-decent, and then promote the best ones to the >> next star level. Only with the highest star rating do I even consider >> spending time on noise reduction and lens correction as there is not >> much point on noise reduction in the bad images. >> >> Personally, I have found after a couple months it's easy to remember >> where all the modules are and changing it would only make it worse for me. >> >> Jason >> >> On 2018-10-07 09:06 PM, Aurélien Pierre wrote: >> >> Hi everyone ! >> >> I would like to propose a lifting for the UI in the darkroom. >> >> *Problem** >> * >> >> Currently, the modules are separated in 5 tabs : >> >> * base >> * tones >> * colors >> * enhancements >> * effects >> >> But : >> >> * some modules in the color group affect the tones as well (color >> zones, color balance) >> * some modules in the tone group affect the colors as well (tone >> curves) >> * what is a "basic" module is rather arbitrary (basic == low-level >> signal processing | traditionnal all-purpose features | simple >> general settings ?) >> * some modules do basically the same thing (local contrast & >> equalizer, sharpen & high-pass filter, tonecurve & basecurve) >> and yet you find them in different tabs >> >> *Workflow** >> * >> >> Over 7-8 years using dt, I have converged (and advocated) to the >> following systematic workflow : >> >> /Step 1 : clean and neutralize the picture/ >> >> 1. normalize the white balance >> 2. normalize the exposure to fit the histogram >> 3. normalize the contrast and tonemap >> 4. clean the noise >> 5. correct the lens >> 6. recover the saturated highlights >> 7. apply a color profile and LUT >> >> At the end of this step, the image should look as close as possible >> to the reality. This step is only aimed at correcting the input >> signal to revert the flaws of the sensor technology >> >> /Step 2 : tone the picture/ >> >> 1. adjust the local and global contrast to be visually pleasing and >> fit the photographer's intentions >> 2. adjust the lightness >> >> This step is the first "artistic" step and is more efficient if the
Re: [darktable-dev] Darkroom UI refactoring
Hi, I've also my workflow, but it's a bit different then yours (crop is one of basic corrections for me, I almost never do noise removal as a one of first steps). I'm not a big fan of arbitrary change here. Agree with Jochen that custom tabs could be quite nice. To achieve something similar I just enable modules, add them as `favorite` and save this as a preset. Then add shortcuts for each of presets and I can easily switch between my groups of modules. Regards, Dominik pon., 8 paź 2018 o 06:42 Jochen Keil napisał(a): > Hi, > > On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre > wrote: > > > > The real question here is : could you get past the change and benefit > from it ? > > > > I'm biased here, since I developed repetitive strain injury in the wrist > at the early age of 23. So I'm basically trying to improve the efficiency > of the workflow by decreasing as much as possible the number of user > interactions on each picture, especially the mouse interactions. > > > > If it's only for cropping, it can be fixed. At the end, I think it > really depends on how many hours you spend each week on darktable. Because > editing a whole wedding is definitely not the same as editing a bunch of > holidays pictures, so I guess every user will have a different sensibility > to workflow matters and the occasionnal users will mostly care about the > overhead of the refactoring (having to learn things again) while the > regular users will see it as a long-term investment. > > So, how about custom tabs, that can be named freely and where users > can add and arrange modules to their liking? > > The existing arrangement could be shipped as a preset, and other > presets could be added easily. > > Make it configurable instead of trying to figure out what's right for > everyone (hint: won't happen) > > Cheers, > > Jochen > > > > Le 07/10/2018 à 23:02, Jason Polak a écrit : > > > > Hi! > > > > I can certainly see the logic of your idea. I definitely prefer the > > current setup, if only because that's what I started with. I think the > > only way to see if this is a good idea is to poll users because I am > > sure there are some that would like your way and some that prefer the > > current way. > > > > I do have a specific criticism about your approach, though. I think > > cropping should come early in the editing process. I care much more > > about adjusting the general exposure and crop (composition) before I > > could even think about lens correction or noise reduction. This is > > doubly so because I take a multi-pass view on editing. I first do some > > basic edits of exposure, cropping, and tone curve adjustments to the > > shots I think are half-decent, and then promote the best ones to the > > next star level. Only with the highest star rating do I even consider > > spending time on noise reduction and lens correction as there is not > > much point on noise reduction in the bad images. > > > > Personally, I have found after a couple months it's easy to remember > > where all the modules are and changing it would only make it worse for > me. > > > > Jason > > > > On 2018-10-07 09:06 PM, Aurélien Pierre wrote: > > > > Hi everyone ! > > > > I would like to propose a lifting for the UI in the darkroom. > > > > *Problem** > > * > > > > Currently, the modules are separated in 5 tabs : > > > > * base > > * tones > > * colors > > * enhancements > > * effects > > > > But : > > > > * some modules in the color group affect the tones as well (color > > zones, color balance) > > * some modules in the tone group affect the colors as well (tone > > curves) > > * what is a "basic" module is rather arbitrary (basic == low-level > > signal processing | traditionnal all-purpose features | simple > > general settings ?) > > * some modules do basically the same thing (local contrast & > > equalizer, sharpen & high-pass filter, tonecurve & basecurve) > > and yet you find them in different tabs > > > > *Workflow** > > * > > > > Over 7-8 years using dt, I have converged (and advocated) to the > > following systematic workflow : > > > > /Step 1 : clean and neutralize the picture/ > > > > 1. normalize the white balance > > 2. normalize the exposure to fit the histogram > > 3. normalize the contrast and tonemap > > 4. clean the noise > > 5. correct the lens > > 6. recover the saturated highlights > > 7. apply a color profile and LUT > > > > At the end of this step, the image should look as close as possible > > to the reality. This step is only aimed at correcting the input > > signal to revert the flaws of the sensor technology > > > > /Step 2 : tone the picture/ > > > > 1. adjust the local and global contrast to be visually pleasing and > > fit the photographer's intentions > > 2. adjust the lightness > > > > This step is the first "artistic" step and is more efficient
Re: [darktable-dev] Darkroom UI refactoring
Hi, On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre wrote: > > The real question here is : could you get past the change and benefit from it > ? > > I'm biased here, since I developed repetitive strain injury in the wrist at > the early age of 23. So I'm basically trying to improve the efficiency of the > workflow by decreasing as much as possible the number of user interactions on > each picture, especially the mouse interactions. > > If it's only for cropping, it can be fixed. At the end, I think it really > depends on how many hours you spend each week on darktable. Because editing a > whole wedding is definitely not the same as editing a bunch of holidays > pictures, so I guess every user will have a different sensibility to workflow > matters and the occasionnal users will mostly care about the overhead of the > refactoring (having to learn things again) while the regular users will see > it as a long-term investment. So, how about custom tabs, that can be named freely and where users can add and arrange modules to their liking? The existing arrangement could be shipped as a preset, and other presets could be added easily. Make it configurable instead of trying to figure out what's right for everyone (hint: won't happen) Cheers, Jochen > Le 07/10/2018 à 23:02, Jason Polak a écrit : > > Hi! > > I can certainly see the logic of your idea. I definitely prefer the > current setup, if only because that's what I started with. I think the > only way to see if this is a good idea is to poll users because I am > sure there are some that would like your way and some that prefer the > current way. > > I do have a specific criticism about your approach, though. I think > cropping should come early in the editing process. I care much more > about adjusting the general exposure and crop (composition) before I > could even think about lens correction or noise reduction. This is > doubly so because I take a multi-pass view on editing. I first do some > basic edits of exposure, cropping, and tone curve adjustments to the > shots I think are half-decent, and then promote the best ones to the > next star level. Only with the highest star rating do I even consider > spending time on noise reduction and lens correction as there is not > much point on noise reduction in the bad images. > > Personally, I have found after a couple months it's easy to remember > where all the modules are and changing it would only make it worse for me. > > Jason > > On 2018-10-07 09:06 PM, Aurélien Pierre wrote: > > Hi everyone ! > > I would like to propose a lifting for the UI in the darkroom. > > *Problem** > * > > Currently, the modules are separated in 5 tabs : > > * base > * tones > * colors > * enhancements > * effects > > But : > > * some modules in the color group affect the tones as well (color > zones, color balance) > * some modules in the tone group affect the colors as well (tone > curves) > * what is a "basic" module is rather arbitrary (basic == low-level > signal processing | traditionnal all-purpose features | simple > general settings ?) > * some modules do basically the same thing (local contrast & > equalizer, sharpen & high-pass filter, tonecurve & basecurve) > and yet you find them in different tabs > > *Workflow** > * > > Over 7-8 years using dt, I have converged (and advocated) to the > following systematic workflow : > > /Step 1 : clean and neutralize the picture/ > > 1. normalize the white balance > 2. normalize the exposure to fit the histogram > 3. normalize the contrast and tonemap > 4. clean the noise > 5. correct the lens > 6. recover the saturated highlights > 7. apply a color profile and LUT > > At the end of this step, the image should look as close as possible > to the reality. This step is only aimed at correcting the input > signal to revert the flaws of the sensor technology > > /Step 2 : tone the picture/ > > 1. adjust the local and global contrast to be visually pleasing and > fit the photographer's intentions > 2. adjust the lightness > > This step is the first "artistic" step and is more efficient if the > image has been cleaned before. But this uses the colorbalance to fit > the gamma. > > /Step 3 : grade the picture/ > > 1. adjust the hue to set the atmosphere > 2. adjust the saturation to get natural colors > 3. remap some colors to get better skin or sky tones > > This step is exactly what is done in video post-production. > > /Step 4 : enhance the picture/ > > 1. crop > 2. fix the rotation and the perspective > 3. fix the sharpness (sharpening, high-pass) > 4. correct the skin, spots, stains, sensor dust, etc. (spots and > retouch) > 5. correct the shapes (liquify) > 6. add filters (vignette, frame, watermark). > > This step is more or less
Re: [darktable-dev] Darkroom UI refactoring
The real question here is : could you get past the change and benefit from it ? I'm biased here, since I developed repetitive strain injury in the wrist at the early age of 23. So I'm basically trying to improve the efficiency of the workflow by decreasing as much as possible the number of user interactions on each picture, especially the mouse interactions. If it's only for cropping, it can be fixed. At the end, I think it really depends on how many hours you spend each week on darktable. Because editing a whole wedding is definitely not the same as editing a bunch of holidays pictures, so I guess every user will have a different sensibility to workflow matters and the occasionnal users will mostly care about the overhead of the refactoring (having to learn things again) while the regular users will see it as a long-term investment. Le 07/10/2018 à 23:02, Jason Polak a écrit : > Hi! > > I can certainly see the logic of your idea. I definitely prefer the > current setup, if only because that's what I started with. I think the > only way to see if this is a good idea is to poll users because I am > sure there are some that would like your way and some that prefer the > current way. > > I do have a specific criticism about your approach, though. I think > cropping should come early in the editing process. I care much more > about adjusting the general exposure and crop (composition) before I > could even think about lens correction or noise reduction. This is > doubly so because I take a multi-pass view on editing. I first do some > basic edits of exposure, cropping, and tone curve adjustments to the > shots I think are half-decent, and then promote the best ones to the > next star level. Only with the highest star rating do I even consider > spending time on noise reduction and lens correction as there is not > much point on noise reduction in the bad images. > > Personally, I have found after a couple months it's easy to remember > where all the modules are and changing it would only make it worse for me. > > Jason > > On 2018-10-07 09:06 PM, Aurélien Pierre wrote: >> Hi everyone ! >> >> I would like to propose a lifting for the UI in the darkroom. >> >> *Problem** >> * >> >> Currently, the modules are separated in 5 tabs : >> >> * base >> * tones >> * colors >> * enhancements >> * effects >> >> But : >> >> * some modules in the color group affect the tones as well (color >> zones, color balance) >> * some modules in the tone group affect the colors as well (tone >> curves) >> * what is a "basic" module is rather arbitrary (basic == low-level >> signal processing | traditionnal all-purpose features | simple >> general settings ?) >> * some modules do basically the same thing (local contrast & >> equalizer, sharpen & high-pass filter, tonecurve & basecurve) >> and yet you find them in different tabs >> >> *Workflow** >> * >> >> Over 7-8 years using dt, I have converged (and advocated) to the >> following systematic workflow : >> >> /Step 1 : clean and neutralize the picture/ >> >> 1. normalize the white balance >> 2. normalize the exposure to fit the histogram >> 3. normalize the contrast and tonemap >> 4. clean the noise >> 5. correct the lens >> 6. recover the saturated highlights >> 7. apply a color profile and LUT >> >> At the end of this step, the image should look as close as possible >> to the reality. This step is only aimed at correcting the input >> signal to revert the flaws of the sensor technology >> >> /Step 2 : tone the picture/ >> >> 1. adjust the local and global contrast to be visually pleasing and >> fit the photographer's intentions >> 2. adjust the lightness >> >> This step is the first "artistic" step and is more efficient if the >> image has been cleaned before. But this uses the colorbalance to fit >> the gamma. >> >> /Step 3 : grade the picture/ >> >> 1. adjust the hue to set the atmosphere >> 2. adjust the saturation to get natural colors >> 3. remap some colors to get better skin or sky tones >> >> This step is exactly what is done in video post-production. >> >> /Step 4 : enhance the picture/ >> >> 1. crop >> 2. fix the rotation and the perspective >> 3. fix the sharpness (sharpening, high-pass) >> 4. correct the skin, spots, stains, sensor dust, etc. (spots and >> retouch) >> 5. correct the shapes (liquify) >> 6. add filters (vignette, frame, watermark). >> >> This step is more or less what you would do in pixels editors (Gimp, >> Photoshop). >> >> *Proposal* >> >> I would like to refactor the UI in 4 tabs : >> >> 1. *correction :* for all the signal-processing and purely technical >> modules (mostly, the first in the pixelpipe, working in >> camera-relative RGB) : >> * *sensor patterns handling :* >> o
Re: [darktable-dev] Darkroom UI refactoring
Hi! I can certainly see the logic of your idea. I definitely prefer the current setup, if only because that's what I started with. I think the only way to see if this is a good idea is to poll users because I am sure there are some that would like your way and some that prefer the current way. I do have a specific criticism about your approach, though. I think cropping should come early in the editing process. I care much more about adjusting the general exposure and crop (composition) before I could even think about lens correction or noise reduction. This is doubly so because I take a multi-pass view on editing. I first do some basic edits of exposure, cropping, and tone curve adjustments to the shots I think are half-decent, and then promote the best ones to the next star level. Only with the highest star rating do I even consider spending time on noise reduction and lens correction as there is not much point on noise reduction in the bad images. Personally, I have found after a couple months it's easy to remember where all the modules are and changing it would only make it worse for me. Jason On 2018-10-07 09:06 PM, Aurélien Pierre wrote: > Hi everyone ! > > I would like to propose a lifting for the UI in the darkroom. > > *Problem** > * > > Currently, the modules are separated in 5 tabs : > > * base > * tones > * colors > * enhancements > * effects > > But : > > * some modules in the color group affect the tones as well (color > zones, color balance) > * some modules in the tone group affect the colors as well (tone > curves) > * what is a "basic" module is rather arbitrary (basic == low-level > signal processing | traditionnal all-purpose features | simple > general settings ?) > * some modules do basically the same thing (local contrast & > equalizer, sharpen & high-pass filter, tonecurve & basecurve) > and yet you find them in different tabs > > *Workflow** > * > > Over 7-8 years using dt, I have converged (and advocated) to the > following systematic workflow : > > /Step 1 : clean and neutralize the picture/ > > 1. normalize the white balance > 2. normalize the exposure to fit the histogram > 3. normalize the contrast and tonemap > 4. clean the noise > 5. correct the lens > 6. recover the saturated highlights > 7. apply a color profile and LUT > > At the end of this step, the image should look as close as possible > to the reality. This step is only aimed at correcting the input > signal to revert the flaws of the sensor technology > > /Step 2 : tone the picture/ > > 1. adjust the local and global contrast to be visually pleasing and > fit the photographer's intentions > 2. adjust the lightness > > This step is the first "artistic" step and is more efficient if the > image has been cleaned before. But this uses the colorbalance to fit > the gamma. > > /Step 3 : grade the picture/ > > 1. adjust the hue to set the atmosphere > 2. adjust the saturation to get natural colors > 3. remap some colors to get better skin or sky tones > > This step is exactly what is done in video post-production. > > /Step 4 : enhance the picture/ > > 1. crop > 2. fix the rotation and the perspective > 3. fix the sharpness (sharpening, high-pass) > 4. correct the skin, spots, stains, sensor dust, etc. (spots and > retouch) > 5. correct the shapes (liquify) > 6. add filters (vignette, frame, watermark). > > This step is more or less what you would do in pixels editors (Gimp, > Photoshop). > > *Proposal* > > I would like to refactor the UI in 4 tabs : > > 1. *correction :* for all the signal-processing and purely technical > modules (mostly, the first in the pixelpipe, working in > camera-relative RGB) : > * *sensor patterns handling :* > o scalepixels > o rotatepixels > o demosaic > o flip > o rawprepare > * *color correction handling :* > o invert > o temperature > o colorout > o colorin > o colorchecker > * *dynamic range handling:* > o exposure > o clipping > o colorreconstruction > o shadhi > o highlights > o profile_gamma > o tonemap > o graduatednd > o dither > * *optics handling :* > o defringe > o hazeremoval > o lens > o cacorrect > * *noise handling :* > o bilateral > o nlmeans > o denoiseprofile > o rawdenoise > o hotpixels > 2. *tones**: *for creative modules affecting lightness and contrast > * *global contrast :* > o tonecurves > o basecurves > o colisa > o levels > *
[darktable-dev] Darkroom UI refactoring
Hi everyone ! I would like to propose a lifting for the UI in the darkroom. *Problem** * Currently, the modules are separated in 5 tabs : * base * tones * colors * enhancements * effects But : * some modules in the color group affect the tones as well (color zones, color balance) * some modules in the tone group affect the colors as well (tone curves) * what is a "basic" module is rather arbitrary (basic == low-level signal processing | traditionnal all-purpose features | simple general settings ?) * some modules do basically the same thing (local contrast & equalizer, sharpen & high-pass filter, tonecurve & basecurve) and yet you find them in different tabs *Workflow** * Over 7-8 years using dt, I have converged (and advocated) to the following systematic workflow : /Step 1 : clean and neutralize the picture/ 1. normalize the white balance 2. normalize the exposure to fit the histogram 3. normalize the contrast and tonemap 4. clean the noise 5. correct the lens 6. recover the saturated highlights 7. apply a color profile and LUT At the end of this step, the image should look as close as possible to the reality. This step is only aimed at correcting the input signal to revert the flaws of the sensor technology /Step 2 : tone the picture/ 1. adjust the local and global contrast to be visually pleasing and fit the photographer's intentions 2. adjust the lightness This step is the first "artistic" step and is more efficient if the image has been cleaned before. But this uses the colorbalance to fit the gamma. /Step 3 : grade the picture/ 1. adjust the hue to set the atmosphere 2. adjust the saturation to get natural colors 3. remap some colors to get better skin or sky tones This step is exactly what is done in video post-production. /Step 4 : enhance the picture/ 1. crop 2. fix the rotation and the perspective 3. fix the sharpness (sharpening, high-pass) 4. correct the skin, spots, stains, sensor dust, etc. (spots and retouch) 5. correct the shapes (liquify) 6. add filters (vignette, frame, watermark). This step is more or less what you would do in pixels editors (Gimp, Photoshop). *Proposal* I would like to refactor the UI in 4 tabs : 1. *correction :* for all the signal-processing and purely technical modules (mostly, the first in the pixelpipe, working in camera-relative RGB) : * *sensor patterns handling :* o scalepixels o rotatepixels o demosaic o flip o rawprepare * *color correction handling :* o invert o temperature o colorout o colorin o colorchecker * *dynamic range handling:* o exposure o clipping o colorreconstruction o shadhi o highlights o profile_gamma o tonemap o graduatednd o dither * *optics handling :* o defringe o hazeremoval o lens o cacorrect * *noise handling :* o bilateral o nlmeans o denoiseprofile o rawdenoise o hotpixels 2. *tones**: *for creative modules affecting lightness and contrast * *global contrast :* o tonecurves o basecurves o colisa o levels * *tone-mapping :* o zonesystem o global tonemap o relight * *local contrast :* o atrous o clahe o equalizer (legacy) 3. *colors :* for creative modules affecting lightness and contrast * *RGB :* o colorbalance o channelmixer * *HSL :* o colorzones o splittoning * *Lab* : o colorcontrast o colorcorrection * *color-mapping :* o colormapping o colortransfer o lowlight o colorize * *saturation* : o vibrance o velvia o monochrome 4. *enhancements :* for creative filters and pixel alteration modules * *sharpness* : o sharpen o highpass * *shoftness* : o bloom o lowpass * *inpainting* : o spots o retouch * *structure deformation :* o crop and rotate (what's its IOP name ?) o liquify o ashift * *creative* : o watermark o borders o grain o vignette *Benefits* I think that would draw a path, mostly one-directional, to follow during edits : every tab is a step, you go into the next tab only when you are finished with the previous one. It would result in less clicking and browsing and more guidance for new users. It would draw less
