Le 08/10/2018 à 00:42, Jochen Keil a écrit :
> Hi,
>
> On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre
> <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?
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
>> 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
>>
>> ___________________________________________________________________________
>> 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
