Re: [darktable-dev] Darkroom UI refactoring

[sturmflut]

Hi,

On 28.10.18 15:51, Jason Polak wrote:
> Make a new preset where the base curve has no nodes (i.e. is a line).
> When you are making the preset check 'auto apply this preset to matching
> images'. Then click OK. It will still be on from now on but do nothing.

This is what I did. Then I created a Tone Curve preset for each of my
cameras and configured those to auto-apply based on the manufacturer and
model.

Worked fine for the last ~1100 pictures.

regards,
Simon
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[philippe . weyland]

Hi Aurélien
I like the idea of supporting a kind of workflow. That would help a lot of 
people to get things right faster.

Looking at :
>> The branch is here :
>> https://github.com/aurelienpierre/darktable/tree/UI-refactor.

I'm wondering why color look up table is not placed in the basic group (it is 
in color group). The camera calibration is matter of getting a clean picture, 
your step 1, so I expected to find color look up table is basic group.

Related question. In the workflow based on new versions of unbreak input 
profile and color balance, how you would include the camera calibration stuff 
(and color look up table) ?

Philippe
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

RE: [darktable-dev] Darkroom UI refactoring

[Rob Z. Smith]

It's a long time since I played with base curves as I very much like the 
standard Pentax one I use. However, unless things have changed, you can select 
*any* basecurve you like, you don't have to choose one that matches your camera 
so you don't have to use one that is more exaggerated than you want, I think 
you can do a lot better than just a straight line :-)

-Original Message-
From: Jason Polak [mailto:jpo...@jpolak.org] 
Sent: 28 October 2018 14:51
To: darktable-dev@lists.darktable.org
Subject: Re: [darktable-dev] Darkroom UI refactoring


> How can we turn it off, "base curve" presets are protected in preset settings 
> ?

Make a new preset where the base curve has no nodes (i.e. is a line).
When you are making the preset check 'auto apply this preset to matching 
images'. Then click OK. It will still be on from now on but do nothing.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



National House-Building Council (00320784), NHBC Services Limited (03067703) 
and NHBC Building Control Services Limited (01952969) are registered in England 
and Wales with their registered office at NHBC House, Davy Avenue, Knowlhill, 
Milton Keynes, Buckinghamshire MK5 8FP. 

National House-Building Council is authorised by the Prudential Regulation 
Authority and regulated by the Financial Conduct Authority and the Prudential 
Regulation Authority. 

This email message (including any attachments) is intended solely for the 
addressee and may contain confidential, proprietary or legally privileged 
information. If you have received this message in error, please send it back to 
us, and immediately and permanently delete it. Do not use, copy, disseminate, 
distribute or disclose the information contained in this message or in any 
attachment. We have taken all reasonable precautions to ensure that no viruses 
are transmitted with this message. However, we can accept no responsibility for 
any loss or damage resulting directly or indirectly from the use of this e-mail 
or its contents. Incoming and outgoing e-mails are subject to scanning and may 
be intercepted by our e-mail administrators.

For information about how we process data please see our privacy policy at 
www.nhbc.co.uk/Legal/PrivacyPolicy and for terms of use please see the terms at 
www.nhbc.co.uk/Legal.

 



___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.or

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

Note to Rob and Phillipe: I would very much appreciate just addressing
emails to the list, not to me (in most programs this is accomplished via
'Reply to List' function), as otherwise I get two copies of the same mail

Rob: Yes, it is possible to use other basecurves. Some people were
asking how to turn the base curve _off_ completely, and this is the
solution. The point here is that it is possible to accomplish the
dynamic range adjustments of your image without the base curve at all by
using other modules.

On 2018-10-29 5:56 a.m., Rob Z. Smith wrote:
> It's a long time since I played with base curves as I very much like the 
> standard Pentax one I use. However, unless things have changed, you can 
> select *any* basecurve you like, you don't have to choose one that matches 
> your camera so you don't have to use one that is more exaggerated than you 
> want, I think you can do a lot better than just a straight line :-)
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[philippe . weyland]

Thanks Jason, this works.
I understand that preconfigured curves should be protected, but the conditions 
to auto apply them could stay configurable, couldn't they ?


- Mail original -
De: "Jason Polak" 
À: darktable-dev@lists.darktable.org
Envoyé: Dimanche 28 Octobre 2018 15:51:03
Objet: Re: [darktable-dev] Darkroom UI refactoring


> How can we turn it off, "base curve" presets are protected in preset settings 
> ?

Make a new preset where the base curve has no nodes (i.e. is a line).
When you are making the preset check 'auto apply this preset to matching
images'. Then click OK. It will still be on from now on but do nothing.
___
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

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

> How can we turn it off, "base curve" presets are protected in preset settings 
> ?

Make a new preset where the base curve has no nodes (i.e. is a line).
When you are making the preset check 'auto apply this preset to matching
images'. Then click OK. It will still be on from now on but do nothing.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[philippe . weyland]

Hi Andreas,

> It shouldn't be turned of by default in darktable but you can turn it off in 
> the preset settings for your installation.

How can we turn it off, "base curve" presets are protected in preset settings ?

Philippe
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Coding Dave]

Hi Andreas,

Thanks for the write-up. After vacation I will try it out. Thanks in
advance!

Andreas Schneider  schrieb am So., 28. Okt. 2018, 04:09:

> On Saturday, 27 October 2018 08:17:44 CEST Coding Dave wrote:
> > I wonder 2 things:
>
> Hi Dave,
>
> > 1) Is this whole color topic written down somewhere with like a tutorial
> > how to tune darktable for your camera to have nice colors (A video would
> be
> > ok for me too)?
>
> take a look at:
>
>
> https://blog.pixelbook.org/2018/10/sony-alpha-7-iii-basecurve-and-camera-profile-for-darktable/
>
> > 2) can we turn off the basecurve as default module if this is not the
> > correct way to get nice colors?
>
> It shouldn't be turned of by default in darktable but you can turn it off
> in
> the preset settings for your installation.
>
>
> Andreas
>
> --
> Andreas Schneider a...@cryptomilk.org
> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Andreas Schneider]

On Saturday, 27 October 2018 08:17:44 CEST Coding Dave wrote:
> I wonder 2 things:

Hi Dave,
 
> 1) Is this whole color topic written down somewhere with like a tutorial
> how to tune darktable for your camera to have nice colors (A video would be
> ok for me too)?

take a look at:

https://blog.pixelbook.org/2018/10/sony-alpha-7-iii-basecurve-and-camera-profile-for-darktable/

> 2) can we turn off the basecurve as default module if this is not the
> correct way to get nice colors?

It shouldn't be turned of by default in darktable but you can turn it off in 
the preset settings for your installation.


Andreas

-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Coding Dave]

Seems like I never have understood the basecurve and LUT correctly. Since
basecurve is one of the default modules applies on every image upon opening
I never was questioning that it is required. I always wanted to tune it to
get good results with my Nikon D750 (I also have tried to create my own
profile from an IT8 chart but it makes the images greenish). Your comment
now explains that this is a difficult path and others like the LUT module
are far easier and give better results.

I wonder 2 things:

1) Is this whole color topic written down somewhere with like a tutorial
how to tune darktable for your camera to have nice colors (A video would be
ok for me too)?

2) can we turn off the basecurve as default module if this is not the
correct way to get nice colors?

Cheers
Dave

Aurélien Pierre  schrieb am Fr., 26. Okt. 2018,
13:51:

>
> Le 26/10/2018 à 00:49, Jason Polak a écrit :
>
> Dear Aurelien,
>
> It's clear that you put a lot of thought into this and I am eager to try
> it. It is very helpful to see the GUI screenshots, and based on those I
> do have a few comments/questions:
>
> 1) Don't you think that the equalizer/local contrast module are more
> similar to the sharpening module rather than the tone curve/fill light
> module? Especially with the equalizer, part of it performs a very
> similar effect to sharpening. I understand though that the algorithms
> behind them might be different.
>
> There is still a certain amount of arbitrary choices in this order, I
> won't deny it. Local contrast, at a very local scale, is similar to a
> sharpening, but it's a perceptual sharpening (you fool the eye), not an
> optical sharpening (you don't restore blurry edges). Even with a tone
> curve, if carefully adjusted, you can increase the feeling of sharpness, as
> a side-effect. But local contrast stays contrast, and as equalizer and
> local contrast can affect the global contrast dramatically (the same way as
> shadows-highlights), I put them with tones. Sharpen is a sort of high-pass
> filter so its effect will always be more selective.
>
> Besides, local contrast and equalizer are best used before high-pass and
> sharpen (retouch from more global to more specific).
>
> 2) In your description of the correction tab, you say that after leaving
> this tab, the image should look clean and dull. That makes sense -
> though I am wondering how this works considering the automatic
> application of the base curve? If the base curve is applied upon image
> opening, the tones of the image look already pretty manipulated compared
> to the dull-looking image without the base curve. In other words, it
> seems as though having the base curve applied can already push the tones
> in the image pretty far, leaving little room for colour balance
> adjustments later on in the tone-modules tab.
>
> I believe the basecurve is a mistake and should be deprecated. First and
> foremost, it's applied before the input color profile, so you have to
> disable it if you work with an enhanced/custom matrix, otherwise your
> profile is useless (never add contrast before the input color profile, do a
> gamma or log correction but don't darken blacks while you light mid-tones).
> The basecurve was intended, at first, to emulate in-camera JPEG
> color-rendition with filmic curves
> .
> Turns out the quality of the users-provided curves is not equal from brand
> to brand, it creates out-of-gamut colors and over-saturation (on Nikon, the
> reds get boosted like crazy - people all look like alcoholics) and the devs
> have stopped adding new curves a few years ago. The new module for that
> purpose is the colorchecker/LUT, which can "easily" be used by anyone to
> create custom LUTs from color charts and in-camera JPGs and occurs later in
> the pixelpipe, where it is safe.
>
> The base curve can still be used to (carefully) tonemap HDRs from a single
> exposure. But do yourself a favor, buy a colorchart
>  (30 €), make your own
> camera profile
> ,
> and never ever use the default base curves.
>
> I am just wondering how having a default base curve fits in with your
> editing paradigm?
>
> Sincerely,
> Jason
>
> Thanks for your input,
>
> Aurélien.
>
> On 2018-10-25 08:28 PM, Aurélien Pierre wrote:
>
> Hi everyone !
>
> To follow up on that matter, I have done a pull request doing what I
> discussed here : https://github.com/darktable-org/darktable/pull/1745
>
> You will find screenshots showing the changes, a sum-up of the benefits
> and a poll to vote for/against the change and give your feedback. After
> that, I suppose the core devs will decide what they want to do.
>
> I know it's still not the flexible UI some of you asked, the problem is
> we don't have the workforce for it. darktable 2.6 is supposed to be
> released in 2 months, so now is 

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

Thanks for the explanation about the base curve, Aurelien. Makes sense.
The base curve seemed to be too extreme in some cases and caused
unnatural colour gradients to appear in skin tones. I have since
reprocessed about 100 shots with the base curve disabled and the
improvement is quite noticeable with gradients in high dynamic range scenes.

Jason
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Aurélien Pierre]

Le 26/10/2018 à 00:49, Jason Polak a écrit :
> Dear Aurelien,
>
> It's clear that you put a lot of thought into this and I am eager to try
> it. It is very helpful to see the GUI screenshots, and based on those I
> do have a few comments/questions:
>
> 1) Don't you think that the equalizer/local contrast module are more
> similar to the sharpening module rather than the tone curve/fill light
> module? Especially with the equalizer, part of it performs a very
> similar effect to sharpening. I understand though that the algorithms
> behind them might be different.

There is still a certain amount of arbitrary choices in this order, I
won't deny it. Local contrast, at a very local scale, is similar to a
sharpening, but it's a perceptual sharpening (you fool the eye), not an
optical sharpening (you don't restore blurry edges). Even with a tone
curve, if carefully adjusted, you can increase the feeling of sharpness,
as a side-effect. But local contrast stays contrast, and as equalizer
and local contrast can affect the global contrast dramatically (the same
way as shadows-highlights), I put them with tones. Sharpen is a sort of
high-pass filter so its effect will always be more selective.

Besides, local contrast and equalizer are best used before high-pass and
sharpen (retouch from more global to more specific).

> 2) In your description of the correction tab, you say that after leaving
> this tab, the image should look clean and dull. That makes sense -
> though I am wondering how this works considering the automatic
> application of the base curve? If the base curve is applied upon image
> opening, the tones of the image look already pretty manipulated compared
> to the dull-looking image without the base curve. In other words, it
> seems as though having the base curve applied can already push the tones
> in the image pretty far, leaving little room for colour balance
> adjustments later on in the tone-modules tab.

I believe the basecurve is a mistake and should be deprecated. First and
foremost, it's applied before the input color profile, so you have to
disable it if you work with an enhanced/custom matrix, otherwise your
profile is useless (never add contrast before the input color profile,
do a gamma or log correction but don't darken blacks while you light
mid-tones). The basecurve was intended, at first, to emulate in-camera
JPEG color-rendition with filmic curves
.
Turns out the quality of the users-provided curves is not equal from
brand to brand, it creates out-of-gamut colors and over-saturation (on
Nikon, the reds get boosted like crazy - people all look like
alcoholics) and the devs have stopped adding new curves a few years ago.
The new module for that purpose is the colorchecker/LUT, which can
"easily" be used by anyone to create custom LUTs from color charts and
in-camera JPGs and occurs later in the pixelpipe, where it is safe.

The base curve can still be used to (carefully) tonemap HDRs from a
single exposure. But do yourself a favor, buy a colorchart
 (30 €), make your own
camera profile
,
and never ever use the default base curves.

> I am just wondering how having a default base curve fits in with your
> editing paradigm?
>
> Sincerely,
> Jason

Thanks for your input,

Aurélien.

> On 2018-10-25 08:28 PM, Aurélien Pierre wrote:
>> Hi everyone !
>>
>> To follow up on that matter, I have done a pull request doing what I
>> discussed here : https://github.com/darktable-org/darktable/pull/1745
>>
>> You will find screenshots showing the changes, a sum-up of the benefits
>> and a poll to vote for/against the change and give your feedback. After
>> that, I suppose the core devs will decide what they want to do.
>>
>> I know it's still not the flexible UI some of you asked, the problem is
>> we don't have the workforce for it. darktable 2.6 is supposed to be
>> released in 2 months, so now is not the time for ground-breaking
>> changes. This is intended to make things more logical (or less bad)
>> using realistic means. I changed 30 lines of code, so I'm pretty sure it
>> won't break anything.
>>
>> Cheers,
>>
>> 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

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

Dear Aurelien,

It's clear that you put a lot of thought into this and I am eager to try
it. It is very helpful to see the GUI screenshots, and based on those I
do have a few comments/questions:

1) Don't you think that the equalizer/local contrast module are more
similar to the sharpening module rather than the tone curve/fill light
module? Especially with the equalizer, part of it performs a very
similar effect to sharpening. I understand though that the algorithms
behind them might be different.

2) In your description of the correction tab, you say that after leaving
this tab, the image should look clean and dull. That makes sense -
though I am wondering how this works considering the automatic
application of the base curve? If the base curve is applied upon image
opening, the tones of the image look already pretty manipulated compared
to the dull-looking image without the base curve. In other words, it
seems as though having the base curve applied can already push the tones
in the image pretty far, leaving little room for colour balance
adjustments later on in the tone-modules tab.

I am just wondering how having a default base curve fits in with your
editing paradigm?

Sincerely,
Jason

On 2018-10-25 08:28 PM, Aurélien Pierre wrote:
> Hi everyone !
> 
> To follow up on that matter, I have done a pull request doing what I
> discussed here : https://github.com/darktable-org/darktable/pull/1745
> 
> You will find screenshots showing the changes, a sum-up of the benefits
> and a poll to vote for/against the change and give your feedback. After
> that, I suppose the core devs will decide what they want to do.
> 
> I know it's still not the flexible UI some of you asked, the problem is
> we don't have the workforce for it. darktable 2.6 is supposed to be
> released in 2 months, so now is not the time for ground-breaking
> changes. This is intended to make things more logical (or less bad)
> using realistic means. I changed 30 lines of code, so I'm pretty sure it
> won't break anything.
> 
> Cheers,
> 
> Aurélien.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

On 2018-10-12 06:26 AM, Aurélien Pierre wrote:
> Moreover, base curves and tone curves are redundant as long as we don't
> explain clearly that base curves come before the color profile and work
> in RGB, whereas tone curves come after and work in Lab.

I do think that this is a very interesting point. While I don't agree
with all of the reorderings of the modules (like crop and denoising), I
think that the placement of the tone-curve is a little misleading.
Especially for portraits and skin-tones in general, after following
Aurelien's advice about color balance before tone curve, it seems as
though colour balance should actually come before the tone curve (right?
- or did I get that wrong again... :( )

Well, whatever happens to the modules, I'm willing to try out a new
reordering...but please if this happens keep crop in the basic tab.

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Timothy Spear]

I would be willing to help on the manual. Not lead, but assist.

Get Outlook for Android<https://aka.ms/ghei36>


From: William Ferguson 
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 
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 or

Re: [darktable-dev] Darkroom UI refactoring

[William Ferguson]

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  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 

Re: [darktable-dev] Darkroom UI refactoring

[Oskar Maier]

> 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
  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
  ha scritto:
 >
 >
 > ___
darktable developer mailing list to unsubscribe send a mail to
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 

Re: [darktable-dev] Darkroom UI refactoring

[Coding Dave]

+1

Am Fr., 12. Okt. 2018 um 09:00 Uhr schrieb rawfiner :

> 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  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 

Re: [darktable-dev] Darkroom UI refactoring

[rawfiner]

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  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 : 

Re: [darktable-dev] Darkroom UI refactoring

[Aurélien Pierre]

Le 10/10/2018 à 00:14, William Ferguson a écrit :
> On Tue, Oct 9, 2018 at 7:18 PM Aurélien Pierre
> mailto: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 

Re: [darktable-dev] Darkroom UI refactoring

[William Ferguson]

On Tue, Oct 9, 2018 at 7:18 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.
>
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.

> 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.

> 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.

> If you want your daily-needed modules close to you, you will still have
> the favorite tab. 

Re: [darktable-dev] Darkroom UI refactoring

[Aurélien Pierre]

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
. 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
> 

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

> 
>   * 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

Re: [darktable-dev] Darkroom UI refactoring

[Mark Feit]

On 10/9/18 3:02 AM, Aurélien Pierre wrote:


But even if we keep the actual disposition, don't you think it's weird 
that :


  * 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,

I don't think that's weird.  The first place I'd look to change the 
color profile is in the same tab with all of the other 
color-behavior-changing tools.  The fact that an input profile always 
has to be be processed is an implementation detail.  I don't think users 
who are unacquainted with what's going on under the hood are going to 
care about that.



  * signal-processing modules are mixed with creative ones



The same applies here.  I get the distinction you're making, but every 
module is still a signal processor and is there in pursuit of a creative 
goal.



The main problem I have with the current disposition is low-level 
stuff comes last in the UI.
I grouse about that a bit sometimes as well, but my workflow has turned 
out that 75% of what I process gets the same half-dozen low-level things 
applied from a preset and then everything I actually need to adjust is 
up top.  The things I toggle and/or adjust frequently are favorites, 
everything that's already in the pipe is under what's on and I go grab 
the rarities from their tabs as I need them.


Maybe the way to solve that problem would be to have a switch to invert 
the displayed order so the early-in-the-pipe stuff comes first.  
There'd  need to be some visual cue that it's being displayed that way, 
but I'm not sure I'd want to devote the screen real estate to it.


--Mark


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Timothy Spear]

I have been using Lightroom for six years. Before that Aperature for three 
years. Over the past year, ACDPro, Capture One, Luminar, CyberShot and a few 
others (looking to replace Lightroom, selected dt).

It just hit me based on Aurélien's email.
Every commercial product has the interface organized in the order they effects 
are processed. In learning dt, I have found I rework modules constantly and 
never paid attention to why.

Get Outlook for Android<https://aka.ms/ghei36>



From: Aurélien Pierre
Sent: Tuesday, October 9, 3:03 AM
Subject: Re: [darktable-dev] Darkroom UI refactoring
To: darktable-dev@lists.darktable.org


But even if we keep the actual disposition, don't you think it's weird that :
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, 
signal-processing modules are mixed with creative ones you get sharpen in 
enhancements and high-pass in effects, but they do exactly the same thing same 
for local-contrast and wavelet equalizer same for the crop/flip and the 
perspective correction.
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. Because late modules like levels and tonecurves depend on the exposure 
and tonemapping set earlier in the pipe, so if you begin with the curves and 
end with the tonemapping, you will have to redo the curves. Not funny.
Same with unbreak color profile and contrast/lightness/saturation. In both 
cases, they perform a gamma correction, but the former does it in RGB before 
the input color profile, while the later does it in Lab much later in the pipe, 
and they are both specialized on different issues : don't try to get creative 
with the unbreak color profile, it should be used to put the average lightness 
at 50 % L(ab), nothing else.
Let the UI reflect that, because I have used dt for 7 years, and it's only now 
that I look at the code that I understand what's going on. To be efficient, 
there are things you need to fix first, for example before the ICC input 
profile is applied, and in RGB. A regular user doesn't stand a chance to figure 
out what comes first when the unbreak color profile module is hidden between 
creative color modules.
And that's just an example. If you don't follow at least roughly the pixelpipe 
order, you will end up passing 2-5 times on each module, whereas it could be 
done in 2 passes in a reproductible way, fixing first, tweaking after.
What I would like is to draw a path between critical milestones, that is 
between the technical requirements that should be met :
having your tonal range mapped between 16 % and 96 % L(ab) before you apply any 
input profile, otherwise you mess up the saturation and shift the colors 
linearize the tones (beat up the contrast) early and add contrast late in the 
pipe,
having the contrast fixed in RGB as much as possible to avoid 
de/over-saturation,  fix the color after you fix the contrast and lightness, 
especially if you work in Lab modules normalize the histogram just at the end …
The main problem I have with the current disposition is low-level stuff comes 
last in the UI.

Le 08/10/2018 à 22:07, Jason Polak a écrit :
I've been thinking a little more about this idea, and while some modules might 
be better moved to other tabs (or a new set of tabs) like perhaps 'color 
reconstruction', the current setup still seems to make more sense in some ways 
too. For example: 1. I prefer the idea of the 'effects' tab (like watermark and 
framing) to be separate from other things like perspective correction or spot 
removal. Those things that are sometimes useful or interesting like split 
toning seem to be genuinely different than correcting spots. 2. I don't think 
the base tab should have tonemap in it. It is a more advanced tone module that 
belongs more in a separate tone group. One of the arguments made in this thread 
is that there have been many usability requests in the past, and therefore that 
there is a huge demand to improve the software. These requests only imply that 
there is a subset of people who have trouble using darktable. Changing 
darktable to be more aligned with their style might make darktable easier to 
use for them, but in turn it might make it more cumbersome to use for others. 
Now, I'm not saying that these ideas are bad, but because people who want 
darktable to change are going to be naturally more vocal than people who like 
it as it is, we need to be careful that we don't make it worse for many users 
by changing the UI for a few. For example, Aurelien's modifications are 
designed with a certain 

Re: [darktable-dev] Darkroom UI refactoring

[Aurélien Pierre]

But even if we keep the actual disposition, don't you think it's weird
that :

  * 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,
  * signal-processing modules are mixed with creative ones
  * you get sharpen in enhancements and high-pass in effects, but they
do exactly the same thing
  * same for local-contrast and wavelet equalizer
  * same for the crop/flip and the perspective correction.

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. Because late
modules like levels and tonecurves depend on the exposure and
tonemapping set earlier in the pipe, so if you begin with the curves and
end with the tonemapping, you will have to redo the curves. Not funny.

Same with unbreak color profile and contrast/lightness/saturation. In
both cases, they perform a gamma correction, but the former does it in
RGB before the input color profile, while the later does it in Lab much
later in the pipe, and they are both specialized on different issues :
don't try to get creative with the unbreak color profile, it should be
used to put the average lightness at 50 % L(ab), nothing else.

Let the UI reflect that, because I have used dt for 7 years, and it's
only now that I look at the code that I understand what's going on. To
be efficient, there are things you need to fix first, for example before
the ICC input profile is applied, and in RGB. A regular user doesn't
stand a chance to figure out what comes first when the unbreak color
profile module is hidden between creative color modules.

And that's just an example. If you don't follow at least roughly the
pixelpipe order, you will end up passing 2-5 times on each module,
whereas it could be done in 2 passes in a reproductible way, fixing
first, tweaking after.

What I would like is to draw a path between critical milestones, that is
between the technical requirements that should be met :

 1. having your tonal range mapped between 16 % and 96 % L(ab) before
you apply any input profile, otherwise you mess up the saturation
and shift the colors
 2. linearize the tones (beat up the contrast) early and add contrast
late in the pipe,
 3. having the contrast fixed in RGB as much as possible to avoid
de/over-saturation, 
 4. fix the color after you fix the contrast and lightness, especially
if you work in Lab modules
 5. normalize the histogram just at the end
 6. …

The main problem I have with the current disposition is low-level stuff
comes last in the UI.


Le 08/10/2018 à 22:07, Jason Polak a écrit :
> I've been thinking a little more about this idea, and while some modules
> might be better moved to other tabs (or a new set of tabs) like perhaps
> 'color reconstruction', the current setup still seems to make more sense
> in some ways too. For example:
>
> 1. I prefer the idea of the 'effects' tab (like watermark and framing)
> to be separate from other things like perspective correction or spot
> removal. Those things that are sometimes useful or interesting like
> split toning seem to be genuinely different than correcting spots.
>
> 2. I don't think the base tab should have tonemap in it. It is a more
> advanced tone module that belongs more in a separate tone group.
>
> One of the arguments made in this thread is that there have been many
> usability requests in the past, and therefore that there is a huge
> demand to improve the software. These requests only imply that there is
> a subset of people who have trouble using darktable. Changing darktable
> to be more aligned with their style might make darktable easier to use
> for them, but in turn it might make it more cumbersome to use for others.
>
> Now, I'm not saying that these ideas are bad, but because people who
> want darktable to change are going to be naturally more vocal than
> people who like it as it is, we need to be careful that we don't make it
> worse for many users by changing the UI for a few.
>
> For example, Aurelien's modifications are designed with a certain
> workflow in mind. But for a different type of workflow, the new design
> might actually be worse. For example, I like the idea of having the
> modules grouped by what they do, not what order they come in during the
> workflow. That's just the way my mind works. I suspect that some people
> will prefer a more chronological ordering, and some people will prefer
> an ordering based on their similarities in algorithm. darktable isn't
> exactly like that now because of the basic tab, but aside from the basic
> tab, it mostly is like that.
>
> Another thing we have to be 

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

I've been thinking a little more about this idea, and while some modules
might be better moved to other tabs (or a new set of tabs) like perhaps
'color reconstruction', the current setup still seems to make more sense
in some ways too. For example:

1. I prefer the idea of the 'effects' tab (like watermark and framing)
to be separate from other things like perspective correction or spot
removal. Those things that are sometimes useful or interesting like
split toning seem to be genuinely different than correcting spots.

2. I don't think the base tab should have tonemap in it. It is a more
advanced tone module that belongs more in a separate tone group.

One of the arguments made in this thread is that there have been many
usability requests in the past, and therefore that there is a huge
demand to improve the software. These requests only imply that there is
a subset of people who have trouble using darktable. Changing darktable
to be more aligned with their style might make darktable easier to use
for them, but in turn it might make it more cumbersome to use for others.

Now, I'm not saying that these ideas are bad, but because people who
want darktable to change are going to be naturally more vocal than
people who like it as it is, we need to be careful that we don't make it
worse for many users by changing the UI for a few.

For example, Aurelien's modifications are designed with a certain
workflow in mind. But for a different type of workflow, the new design
might actually be worse. For example, I like the idea of having the
modules grouped by what they do, not what order they come in during the
workflow. That's just the way my mind works. I suspect that some people
will prefer a more chronological ordering, and some people will prefer
an ordering based on their similarities in algorithm. darktable isn't
exactly like that now because of the basic tab, but aside from the basic
tab, it mostly is like that.

Another thing we have to be careful with is the 'simplified' scheme
where a simplified panel is presented but where more advanced
modifications can be made if necessary. If this ever were to happen
(like a Lightroom style panel), there should be an option to disable it
and hide it completely because it would just get in my way. It does
sound like a good idea for some people, but again, that's just a mindset
and style of doing things that doesn't apply to everyone. I prefer for
example to see exactly what is going on and get into the details right away.

I also like the way the modules currently are displayed. I have most of
the modules activated (though not on a single picture) and I just have
the 'one open at at time' option, and I find the interface intuitive in
terms of switching and editing settings. Again, if others think
differently about how that works I would love there to be a setting for
them too, but the point is, drastic modifications at this point should
probably be an option unless it is crystal clear that it benefits everyone.

Part of the appeal of darktable at least to me is that it just lays all
of its options plain and clear without trying to force a specific
editing style on the user. I would hate for darktable to become muddled
like lightroom with a 'clarity' slider or other sliders with ambiguous
labels that do things under the hood without my knowledge of exactly
what they are doing. Or even worse, something like
https://skylum.com/luminar, which aims to make the defaults something
95% of people will be happy withtakes the fun out of raw editing in
my opinion - I am one of those that enjoys raw editing almost as much as
photography itself.

Can the UI of darktable be improved? I am sure there are some
improvements to be made (like the middle-mouse click for new module that
was recently introdced - thanks devs!). On the other hand, I am sure a
lot of people (including myself) already find darktable to be pretty
intuitive and snappy to use, and we should be cautious of making changes
to it lest it upset the greatness it has achieved so far.

Jason

On 2018-10-08 12:59 AM, 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
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Coding Dave]

Hi community,

I like the idea to improve the UI and I appreciate the enthusiasm Aurelien
has put into it!

Darktable is a very nice piece of software feature-wise. Their developers
have created some great, feature-rich, wonderful tool in their spare time
and we are all very thankful for that. We love darktable, we love the many
ways we can make our images better. Darktable is so good that a community
has been evolved caring about it, and we, the community, are greateful for
the developers to have crafted this wonderful non-destructive photo-editor.

Over the past years I have read many usability improvement requests in the
mailing list. This clearly shows how huge the demand is to improve that
part of the software. What is a feature worth if it can not be understood
or found or is too cumbersome to be used?

In this thread we can read many nice requests that may be very valuable for
darktable. I like Aureliens suggestions and others too.  You know,
sometimes less is more and making the UI more simple is helping more than
adding new elements like customization and search bars - but I also think
these features would be nice.

UI Design is hard. You need to know the featureset you are targeting for
and you need to play the new UI through often because each iteration
usually reveals other issues (I know this part very well from my current
professional situation). User eXperience designers can be very valuable and
helpful here and if anyone would offer for volunteering to make the UX
better would be a big win for the community!

I think it would be great if we can create a feature request wiki where
each contributor describes what exactly he means (his vision),
referencing/contrasting the other suggestion-articles. Each community
member can comment on these and drive them and with productive feedback. A
final vote could bring us the clarity of what the users of the software
desire the most.

Kind regard
Dave

Am Mo., 8. Okt. 2018 um 14:22 Uhr schrieb Rolf Meyerhoff :

> Hi all
>
> I don't think that reordering the modules would change much. The problem
> remains the same: Either there are way to many parameters at once on the
> screen to keep track of or there is a lot of clicking involved to dive
> in and out of the individual modules.
>
> I know that the advanced parameters are needed in many cases but the
> defaults for most modules are usually very very good. So in practice
> they often are just sitting there taking up precious screen space. Eg
> the highlights/shadows module has a lot of parameters to fine tune the
> result but most of the time a user will just increase shadows or
> decrease highlights.
>
> One solution would be to strip down the modules but I think that any
> simplification should begin at a higher level.
>
> What I am thinking of is a kind of a meta module on the first page with
> just the essential parameters for raw development (linked internally to
> the respective modules). As an example:
>
> White balance temp (with picker)
> White balance tint
>
> Exposure level (with picker)
> Black level
> White level
> Shadow level
> Highlight level
>
> Crop button that jumps to or opens the crop module
>
> Saturation amount
> Contrast amount
> Local contrast amount
> Haze removal amount
>
> Chroma denoise amount
> Luma denoise amount
> Lens correction on/off
> Defringe on/off
>
> Sharpening amount
> Sharpening threshold
>
> To make deep editing easier a ctrl click on a parameter could be used to
> jump to the linked module (or something like that).
>
> This parameter choice is not set in stone but I think that it would be
> enough for most casual users to edit their family and holiday pictures.
> However, in a perfect world the choice of parameters could even be
> customized by the user.
>
> Most commercial applications have a similar approach to basic raw
> development and that makes them easy to use for casual users and
> beginners. Most of them never touch advanced parameters at all. What
> these applications don't have is the editing depth of Darktable with
> it's fabulous module selection and it's masking system. The downside is
> that there are so many modules with many parameters that can make
> Darktable difficult to use at times, especially for a novice.
>
> Astripped down view for the important parameters backed by the power of
> the modules could represent best of both worlds.
>
> However, I don't know the internals of DT well enough to estimate how
> hard it would be to actually create something like that.
>
> Best regards,
>
> Rolf
>
>
> Am 08.10.2018 um 11:52 schrieb Bruce Williams:
> > I'm with Jørn!
> > Great ideas, all.
> > Certainly feeling the pain of modules changing size and having to
> > constantly scroll up and down.
> > Cheers,
> > Bruce Williams
> > --
> > Mobile:  +61 41 250 6349
> >
> > audio2u.com 
> > brucewilliamsphotography.com 
> > shuttersincpodcast.com 

Re: [darktable-dev] Darkroom UI refactoring

[Rolf Meyerhoff]

Hi all

I don't think that reordering the modules would change much. The problem
remains the same: Either there are way to many parameters at once on the
screen to keep track of or there is a lot of clicking involved to dive
in and out of the individual modules.

I know that the advanced parameters are needed in many cases but the
defaults for most modules are usually very very good. So in practice
they often are just sitting there taking up precious screen space. Eg
the highlights/shadows module has a lot of parameters to fine tune the
result but most of the time a user will just increase shadows or
decrease highlights.

One solution would be to strip down the modules but I think that any
simplification should begin at a higher level.

What I am thinking of is a kind of a meta module on the first page with
just the essential parameters for raw development (linked internally to
the respective modules). As an example:

White balance temp (with picker)
White balance tint

Exposure level (with picker)
Black level
White level
Shadow level
Highlight level

Crop button that jumps to or opens the crop module

Saturation amount
Contrast amount
Local contrast amount
Haze removal amount

Chroma denoise amount
Luma denoise amount
Lens correction on/off
Defringe on/off

Sharpening amount
Sharpening threshold

To make deep editing easier a ctrl click on a parameter could be used to
jump to the linked module (or something like that).

This parameter choice is not set in stone but I think that it would be
enough for most casual users to edit their family and holiday pictures.
However, in a perfect world the choice of parameters could even be
customized by the user.

Most commercial applications have a similar approach to basic raw
development and that makes them easy to use for casual users and
beginners. Most of them never touch advanced parameters at all. What
these applications don't have is the editing depth of Darktable with
it's fabulous module selection and it's masking system. The downside is
that there are so many modules with many parameters that can make
Darktable difficult to use at times, especially for a novice.

Astripped down view for the important parameters backed by the power of
the modules could represent best of both worlds.

However, I don't know the internals of DT well enough to estimate how
hard it would be to actually create something like that.

Best regards,

Rolf


Am 08.10.2018 um 11:52 schrieb Bruce Williams:
> I'm with Jørn!
> Great ideas, all.
> Certainly feeling the pain of modules changing size and having to
> constantly scroll up and down.
> Cheers,
> Bruce Williams
> --
> Mobile:  +61 41 250 6349
>
> audio2u.com 
> brucewilliamsphotography.com 
> shuttersincpodcast.com 
> sinelanguagepodcast.com 
>
> e-mail  | Twitter
>  | LinkedIn
>  | Facebook
>  | Soundcloud
>  | Quora
> 
> --
>
>
>
>
> On Mon, Oct 8, 2018 at 7:07 PM Jørn Villesen Christensen
> mailto:darktable-...@mettle.dk>> wrote:
>
> 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
>  

Re: [darktable-dev] Darkroom UI refactoring

[Timothy Spear]

If you are going to go through the trouble to refactoring it. Make it data 
driven. Allow for so many tabs, provide default names which can be changed in 
preferences, and have the tab number be an attribute of the module (stored with 
the preferences).

I would reorganize with crop first. No point in fixing blown areas if they are 
not included in the inage.

Get Outlook for Android<https://aka.ms/ghei36>


From: Andreas Schneider 
Sent: Monday, October 8, 2018 6:24:35 AM
To: darktable-dev@lists.darktable.org
Subject: Re: [darktable-dev] Darkroom UI refactoring

On Monday, 8 October 2018 10:06:45 CEST Jørn Villesen Christensen wrote:
> 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...

I think Aurélien his idea is great also this is easy to achieve from a code
point of you. This is also easy for newcomers to understand.

However the search option is an amazing idea with tags associated with
modules. Could also be doable with a few lines of code.

However dynamic lists as you suggest are much harder to implement would need
quite some refactoring and new code.



Andreas



--
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
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

Re: [darktable-dev] Darkroom UI refactoring

[Andreas Schneider]

On Monday, 8 October 2018 10:06:45 CEST Jørn Villesen Christensen wrote:
> 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...

I think Aurélien his idea is great also this is easy to achieve from a code 
point of you. This is also easy for newcomers to understand.

However the search option is an amazing idea with tags associated with 
modules. Could also be doable with a few lines of code.

However dynamic lists as you suggest are much harder to implement would need 
quite some refactoring and new code.



Andreas



-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Bruce Williams]

I'm with Jørn!
Great ideas, all.
Certainly feeling the pain of modules changing size and having to
constantly scroll up and down.
Cheers,
Bruce Williams
--
Mobile:  +61 41 250 6349

audio2u.com
brucewilliamsphotography.com
shuttersincpodcast.com
sinelanguagepodcast.com

e-mail  | Twitter  |
LinkedIn  | Facebook
 | Soundcloud
 | Quora

--




On Mon, Oct 8, 2018 at 7:07 PM Jørn Villesen Christensen <
darktable-...@mettle.dk> wrote:

> 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  > > napisał(a):
> >
> > Hi,
> >
> > On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre
> > 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,
> >
> 

Re: [darktable-dev] Darkroom UI refactoring

[Jørn Villesen Christensen]

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 > napisał(a):


Hi,

On Mon, Oct 8, 2018 at 5:39 AM Aurélien Pierre
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 

Re: [darktable-dev] Darkroom UI refactoring

[Aurélien Pierre]

Thanks Andreas !

So I tried the modifications I have suggested and I agree that the base
tab would be too crowded.

What I did was to split the technical modules in 2 tabs :

  * the I/O and dynamic range ones in the base tab (color profile,
tonemap, exposure, crop etc.)
  * the de-* (denoising, defringing) and color reconstruction in the
correction tab, that is now just after the base one
  * everything else as planned.

The branch is here :
https://github.com/aurelienpierre/darktable/tree/UI-refactor.

Now we have about the same number of modules in each tab.

I think defringe and haze removal are more saturation modules (one 
decreases 
and the other increases saturation) 

No they are truly signal processing algorithms based on optics
equations. It's a bad idea to put them among creative modules, in my
opinion. The core idea of my project is to separate modules you have to
set following rules (signal normalization and restoration) and the ones
you are free to use as you wish.

Le 08/10/2018 à 02:53, Andreas Schneider a écrit :
> On Monday, 8 October 2018 03:06:34 CEST Aurélien Pierre wrote:
>> Hi everyone !
> Hi Aurélien,
>  
>> I would like to propose a lifting for the UI in the darkroom.
> I like the idea. However the crop and rotate module should be in the 'optics 
> handling' subcategory.
>
> Also the corrections group is too big, we need to split it or reduce it. As 
> not everyone has all modules enabled, reducing it a bit might be enough.
>
> I think defringe and haze removal are more saturation modules (one decreases 
> and the other increases saturation) and maybe create a category for noise 
> handling.
>
>
> Best regards,
>
>
>   Andreas
>


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Andreas Schneider]

On Monday, 8 October 2018 03:06:34 CEST Aurélien Pierre wrote:
> Hi everyone !

Hi Aurélien,
 
> I would like to propose a lifting for the UI in the darkroom.

I like the idea. However the crop and rotate module should be in the 'optics 
handling' subcategory.

Also the corrections group is too big, we need to split it or reduce it. As 
not everyone has all modules enabled, reducing it a bit might be enough.

I think defringe and haze removal are more saturation modules (one decreases 
and the other increases saturation) and maybe create a category for noise 
handling.


Best regards,


Andreas

-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Darkroom UI refactoring

[Jason Polak]

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

[Aurélien Pierre]

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

[Dominik Markiewicz]

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

[Jochen Keil]

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

[Aurélien Pierre]

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

[Jason Polak]

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
>   *