I wouldn’t say it saved my life. But shortly after I learned reading, I read one Karl-May book per day until my dad told me how to read and write punch cards…
Teehee, yes! Because what users say they want is based on their interpretation of what your program does under the hood, which may be wrong. What developers think users want is based on what they think about users, and what they themselves would want for the stuff they do with the software (have I ever fallen into that second trap…). It sometimes helps to discuss things in terms of what users want to achieve (or which part of the current setup does not work, and why) rather than how they’d like to do it, because it’s hard for them to imagine how the software could work differently, but it’s hard for the developer to know in what environment and to what end the user is using the software, i.e. which implementation works for them and which does not.
I like to believe that after some >5 years working on one piece of software I got to the point where most of the stuff the which users did not get was simply due to no time being available to implement it – but each new feature still had a design iteration planned in because either there’d be some misunderstanding about how it needed to work to fit into their workflow, or about what’s technically possible.
What I’m not getting is why people think they should be a math expert to use a module.
I get it,those people don’t really understand what the module is doing or why it is doing it. But why is the module wrong then?
There are sooo many sliders in darktable (and other tools) that I’m sure people don’t understand and do something they didn’t expect.
What you then do is play around with the sliders, and learn. Or move on and try a different module.
You don’t go saying the module is wrong and you’re (patiently at least)awaiting a replacement.
I’m sure a lot of people coming from lightroom see the shadows and highlights module and think ‘yay,a shadows slider’ and are then disappointed
You then think ‘well this is not what I was looking for’ and you try finding a different way… Without understanding what was happening. This is good.
So… The color balance thing. It is something different to what people expect. Or they tweak sliders and something different happens. Accept it does something different. It doesn’t work on plain rgb values, it is not usable as a plain simple channel swap. Move on.
Now, for the people that don’t get it and want to learn it. Welcome, I think I’m one of you :).
And yes, aurelienpierre’s explanation goes over my head. Maybe because my sleep deprived head in lockdown with kids around the house :s.
Anyway, I’m loving what the first tab does. I’m loving the simple gamut compression and what it enables for filmic. I guess I have no need yet for the other tabs :).
If you use it in channel mixer mode (there’s a preset for that, and also for the channel swaps), it’ll work without adaptation, in working space RBG (e.g. Rec.2020).
The implementation in 3.4 had bugs, see:
- 1st bug: Color calibration - colorfulness - #3 by neuralyzer
- 2nd bug: Color calibration - colorfulness - #42 by flannelhead
And Aurélien has also added a whole new algorithm that improved the module a lot, plus further improvements and fixes: - Color calibration - colorfulness - #81 by anon41087856
- History of the module on GutHub
I’ve read that, and that the bugs are fixed is always good.
… but it still does something different from what most people seem to expect, and after the reported bugfixes there are still quite some posts about people talking about how it is too complicated, and how it should be possible to understand it. And I don’t think that’s right.
there’s no shortcut in learning complex things. Of course the appearance of complexity can be reduced - thats why there’s such thing like a “green rectangle” on your cam.
but do you really expect this in darktable?
Im’ not even sure the new modules are all that more complex than the set of old modules they replace.
It looks a lot more complex, with the several tabs per module, but that’s (partly) a different way of organising things.
I think the problem is the learning anew something they expect to know already: how much time was spent on learning the other editors they use(d). Retraining is always harder than training, as you have to unlearn old habits.
(“Why doesn’t this work like Lightroom” is telling in that respect. Answer: because it isn’t Lightroom )
if that was in reply to me, please read my first post. I’m absolutely against making things too simple or removing complexity just because people don’t understand what’s happening behind the scenes.
it’s not the complexity of the module, it’s the complexity of the stuff the module tries to control. You need to learn how to control this stuff, then you’re able to define which tools are appropriate for you.
- I think that even if the underlying logic is the same, it may not make sense to have the RGB tabs when the module is performing adaptation (it’s not working in RGB, after all).
- Conversely, does it make sense to offer channel mixing in non-RGB? Is there a reason to mix some X into Y? (Mixing is done in working space RGB or in XYZ or in one of the LMS spaces, depending on the adaptation setting).
- Finally, brightness and colorfulness are done in LMS or RGB (in
luma_chroma
), never in XYZ – still, the sliders are labelled the same as on the mixer tabs, but they act on different quantities.