Hi,
An alternative suggestion (as I have also found the module list a bit...
difficult to work with sometimes :-D ). I have often wished for a search
box, so here is an idea; not thought through, but meant as inspiration:
How about one big list of modules, but with collapsible sections (and
thus not have the top buttons for bases, tones, colours, etc.).
At the top of the list, there would be a search bar that would let you
easily filter on
- name of module
- tags associated (from the developers) with the module, such as
bases, colours, enhancements...
In the list, there would be two active foldable sections:
- Enabled modules.
- All modules.
You can right click on the list to
- Create a new (nameable) section.
- Order the sections (maybe All Modules should stay at the bottom,
Enabled module should stay at top).
- Add / Remove modules to/from the custom sections.
- Add a colour marker to the custom sections. When the modules are
displayed in the Enabled Modules list, they would be colour coded with
that colour, or have a colour marker (dot).
Perhaps the order of the modules (in the All Modules and Enabled Modules
sections) could be selectable to
- Sorted alphabetically
- Sorted according to path in the pipeline.
In addition to that, I do not quite like way that modules unfolds under
it's name in the list. I think I would prefer a list of modules (as I
described above :) ) and clicking on each module, would open it up in a
separate Module Settings area.
Reason: Sometimes when modules have (parametric and drawn) masks they
become tall and thus, when open, requires me to scroll excessively (?)
when going up/down the list, searching for something. When clicking on
another module (thus triggering closing and opening of modules) the
change in horizontal position of the list have sometimes also annoyed
me. Having the list and the module settings separate, keeps the list
more steady, compact, and thus I believe I can maintain a better overview.
BR
Jørn
On 08/10/18 06:59, Dominik Markiewicz wrote:
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 <jochen.k...@gmail.com
<mailto:jochen.k...@gmail.com>> napisał(a):
Hi,
On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre
<rese...@aurelienpierre.com <mailto:rese...@aurelienpierre.com>> 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 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
confusion
> as well regarding why some modules of similar functionnality are put
> away in separate tabs.
>
> Thanks for reading ! What do you think ?
>
> Aurélien.
>
>
>
___________________________________________________________________________
> 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
<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>
--
Regards,
Dominik Markiewicz
___________________________________________________________________________
darktable developer mailing list to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org
--
www.talldanestale.dk
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
