So I kinda fell out of love with the effort to create authentic black and white film simulations. It’s fun, has its allure and aesthetics, but I am more drawn to the modern look.
I realized that a lot of what was driving this is that the gray (sic! typo) tab in the color calibration module is an UX dumpster fire. Disagree? Can you tell what color is RGB 125, 70, 22? Most people can’t.
So I vibecoded a better UI in its own module. Does nothing the gray tab can’t, but I believe it is much more intuitive to use. Certainly a keeper for me.
Comes with a full suite of wratten color filter presets.
No it can’t, but I don’t see the need either. It’s already present in ColCal with the a UI that makes sense for it. The color equalizer’s brightness tab is a different UI that basically does the same thing. Not much point copy-pasting either of them here here unless you have a usability improvement in mind
Right, but then if I have to use ColCal for lightness, I can just switch to the gray tab and do the b&w there. I mean, having parts of the control in an already existing module that can also do RGB (without loss of expressivity) reduces the appeal of a dedicated module for it.
I was thinking about a two-slider lightness control consolidating the three channels into a hue, plus a value slider. Like the one that you already have for the color filter, where the “hue” expresses the ratio of the three colors. You would then increase the lightness according to the value slider, distributing it to the RGB channels proportionally to their contribution to the hue.
Okay I can see that I just repeated what you quote. In that case, I’m not sure I understand the question.
But I can offer an analogy as a reply to
Diffuse and sharpen. The same or a very similar argument can be made about the diffuse and sharpen UI: that it exposes controls that are in line with how it works. Yet I think both between more and less prominent members of the community there is an agreement that the UX is less than ideal, to put it mildly.
To make the example concrete: let’s say you select 49%, 27%, 9%, which is RGB8 125, 70, 22. It is kind of a brownish color-red.
What does it tell you about the mapping to grey, intuitively? Not much. It does not necessarily correspond to applying a color filter of that color, since that depends on the passthrough spectrum width.
Fair enough, that might be an argument regarding the presets claiming they are a faithful reproductions of wratten filters. Idk, Was going on about this at length with claude that kept claiming that integrated against/with/whatever the D65 light source the filter data does indeed collapse into these 2 values, but I’d be lying if I said I can verify that claim.
But it’s kinda irrelevant the core idea, the UX rework, which is just a change towards a visual representation of what you do with the RGB sliders on ColCal, not necessarily to be interpreted as “you are putting this color filter on top”
I think even if you are right, this is more intuitive. Might be a matter of taste though, it’s not the kind of question where a single objectively true for everyone answer might exist.
Why not just use the monochrome module? I think it accomplishes what you were after? EDIT: I see now you were trying to do capture based filters, and I think monochrome uses enlarger based filters
Could this be added to the gray tab of color calibration, instead of asking yet another module, however simple and focused it is? It seems like there’s another new module every two weeks.
(sorry, was writing on the phone without glasses, didn’t realise swipe typing mixed some Hungarian into the text…)
For me there is some kind of error in the reasoning.
A colour is represented as 3 dimensions be it RGB, Hue/Saturation/Value, Hue/Chroma/Value, XYZ, or whatever.
You can not express the same information with only 2 dimensions.
What could help in the Color Calibration module, is some way to switch representation: from RGB to a hue/saturation/value representation or something similar with the same values. Just another way to represent the RGB triplet.
No need for a new module, just some UI change in the existing one.
As I understand things, a color wheel (or strip) doesnt make much sense given what the values in the grey tab represent. Y can still be >0, even if one or two grey coefficients are negative.
I would love a proper B&W/monochrome module to do conversions with. Preferably with options for multiple approaches (CIE Y, Decolor, Smith(?), etc) and even incorporating capture and projection filter effects. I dont know how that would even work in a scene-referred context, and would likely be a huge lift given the fact that nobody but Nik has taken on that kind of project. That kind of tooling, however, would be freaking amazing.
B&W is mainstream enough to deserve its own proper module. ColCal is already confusing, and I wouldn’t abuse it even more.
A dedicated module (monochrome) already exists, but it is (1) display-referred and (2) very limited in functionality. If you ask me, darktable deserves a better b&w user experience.
You can, if you preserve luminosity. Which is what the “normalize” tickbox in color calibration does. 3 degrees of freedom makes little sense for this operation, it only has two.
FWIW I don’t think it makes sense to literally duplicate this operation with another UI.
I still think that the premise
is flawed. Sometimes it makes sense to think of 3 values as a color in some RGB space, sometimes it does not. This is one of those cases.
This is a simplification that indeed reduce the number of dimensions. But it also reduces the possibilities you have in the conversion.
It’s perfectly fine to not normalize if you want to darken the image or the other way around, create white zones.
If the UI needs modification it should allow to also set the luminosity (or have the same tick button)
I wonder if just adding the standard CIE Y conversion values for rec709 (i think it is the same for rec2020?), as some sort of default, would be a good idea. IIRC RT does this using the old NTSC values.
Awesome! Since dt’s default working space is rec2020 (iirc) does it make sense to use those coefficients? Honestly there is not a ton of difference in images converted with NTSC vs 709. My guess is that 2020 probably wont exhibit much difference either. So maybe just whatever is easy?
