The user does a perfectly natural thing — goes to the white balance module and attempts to set the WB from an area. Then they see the “white balance applied twice” warning, even though they know they did no such thing.
Then they have to figure out they need to hover the warning to see a tooltip that tells them they need to go to another module and do something.
Think about it: from a user’s POV, a perfectly logical thing to do turns out to be VERBOTEN and requires extra fiddling and learning a whole different module.
Then some people here claim this:
Recommended practice is to leave the white balance module alone and make any adjustments in color calibration.
If that is correct, it means that something that is supposed to just work doesn’t actually just work, is still exposed in the UI, and is considered inferior to a much more complicated module.
yes, but doing something without knowing how the used tool is working, isn’t the best idea Those kind of users aren’t targeted audience for darktable. There’s no absolute UX - it’s related to the target users.
You have to pay - with money or time to learn your tool …
We will unnecessarily complicate the use of the program.
We will force people to read the documentation, where reading the documentation is usually not required.
We will discourage the use of the program for people who just want to get things done.
Lovely plan! How is it working for you? Do you love participating in discussions where people get stuck with the simplest of actions — setting white balance?
i prefer darktable with giving full control to users who are able to value that.
I don’t waste too much time to reason with users who doesn’t value it. I let them head over to different tools that might fit their demands in a better way …
Well I figure that the OP had a sensible approach of asking a forum for advice. I hope he has found the answer he is looking for here. The user manual is not always straight forward to get an answer from. The CC module is very unique to DT as far as I know. Other programs just have white balance so the question asked by the OP was sensible. Hopefully the answers were too.
I think Kofa is working on something to make it more clear. Renaming “White Balance” to something like “preliminary white balance” would also clean things up IMHO as it mostly acts serves that exact purpose. Or hiding most of it’s UI while “colour calibration mode” is active.
I agree…I was just indicating that it’s understandable, given the wording of the messages, that a user might think they can’t use both WB and CC when they get error messages the instant that they activate CC.
if you follow the scenario I described, when you activate CC, CC shows a message “white balance module error”. It’s certainly not normal to use the word “error” in a warning message.
Reviewing this thread (and I know there are plenty of others too!), I think a lot of the issues come down to wording. I don’t think the actual functionality of either WB or CC needs changing.
That comes over as trying to pick a fight with users who are still trying to work things out rather than encouraging them to best use the tool. A user who’s confused that a concept they’ve understood for years works differently here is not automatically someone who doesn’t value darktable. They’re someone who’s trying to figure it out. Going in hard and hostile just drives people away who could otherwise have been happy users with a little consideration.
To have two modules cooperate to white-balance an image is unusual, but is technically superior to simply adjusting the WB multipliers in white balance. The error messages are confusing and cryptic (and the ‘invalid’ CCT in color calibration also sounds scary).
Once my PR is merged, you’ll be able to pick white balance in white balance, and tell color calibration to use settings from that module (currently, you can set it to use as shot in camera, but there’ll be a new setting as set in white balance). For simple cases users will never have to touch color calibration, but the flexibility (masking etc.) will remain, if needed. It’s just not top priority.
Kofa with this change could you see also being able to remove the reference values setting to remove some confusion…old edits could now just use the reference values in the wb settings, much the way it had to be done for camera’s with bad reference values before as-shot came out. It would seem that with your changes this could be achieved and then DT has a legacy option (as shot by default or with picked or manually changed values) or it has the modern hybrid with wb using as-shot or user values early in the pipeline and then the CAT portion kicks in later as it does now…Reference seems like an orphan now and only kept for backward compabitilty but I think it could be incorporated as an option within the changes you are proposing and this could simplify things esp for new users and others that have not followed along with the module evolution???
Those kind of users aren’t targeted audience for darktable. There’s no absolute UX - it’s related to the target users.