It’s more important to process images with our eyes than with histogram. Histogram in darktable is mostly done to be better viewed when hovering it. The idea of darktable UX is to first let most place to the image, so by brightening histogram, that adds a possibily distracting thing for eyes. If you hover histogram, you will see it better.
But you’re right for those who use histogram, it could be brighter. Personally, I process my images with my eyes and the histogram is just here to check some things, so as it is, it’s good for me. Histogram in previous versions was way too oversaturated.
Just put those lines in CSS editor in preferences, then you can changes settings (for example, increasing highest number in each line will increase related rgb color. Decreasing lowest ones will also boost by contrast color related line.
Be careful to not change too much those lines and be sure to balance all changes between them to avoid having strange colors.
I tried as a normal user under Manjaro Linux. The new setting seems to be saved since I can see the CSS codes I entered after restarting darktable. Yet, the histogram colors do not change. (Ver. 3.2.1)
Don’t know why it’s not changing. I wish there’s easier way to adjust contrast as other software do. Hovering doesn’t show intense color. It shows white line overlay which makes it more harder to see.
Also Every theme darktable has doen’t give enough contrast. the font weight is thin. My eyes have to work a lot just to read some text.
Contrast is a big concern for me as well for waveform and RGB parade. There are tweaks to the code in v3.4 (outside of CSS-set colors) which should give better contrast, but I’m sure there’s more work to be done.
I also agree …I would prefer the contrast so I can see the graph I really don’t care about the accuracy of the colors in any way. I could always collapse the panel if need be. RT has a small slider to adjust this now and certainly Davinci has nice controls including one that smooths the lines the simplify the graphs…sadly to my eyes the ones in DT are just smears of red green and blue so I rarely use them but I would if I could adjust them
Adding more UI to adjust the display will need to wait: the histogram UI currently has a lot of handcoded elements, so it’s pretty brittle. I’ve been wanting to port it to GTK widgets (I think that this is a good idea…). This could make it more fluid to add more UI-visible ways to adjust the output. But it’s also important not to clutter the UI, and to have good defaults (hence this thread, yes).
For now, modifying the CSS is what we have… The rationale is that – despite the CSS colors nominally being in sRGB, they’re actually going to be output in whatever your display colorspace is. The “standard” colors v3.4 should look OK across a variety of colorspaces, but adjusting them for your particular display may be helpful. One of my priorities was to make the blue more visible, as on wide gamut displays 100% blue can be quite hard to see. I’d be quite interested what colors generally work for people, if people are modifying their CSS.
darktable max RGB is not really max RGB. Same Number in Krita shows brighter color.
That’s true. The colors are being drawn with a 50% alpha. This is “tradition” for darktable look. It’s always possible to revisit this. (And this also makes a color such as 100% blue even harder to discern.)
The davinci screenshot does look fabulous. Part of their trick seems to be that very high numeric values don’t just saturate the colorchannel, but edge into white.
How does RT do it I wonder?? I would not say it is a nice looking or as flexible as Davinci but it certainly boosts the default in their histogram displays?? I don’t know the basis of the UI elements in RT vs DT ??
Oh! Happy to see that this UI issue is known and it will be dealt with soon. At present, the blue of the histogram is practically invisible at night in a mildly lit room especially for people over 50 with age related lens changes (that is essentially yellowing).
Blue should be better now. If not, making it more pastel via CSS is the way to go. Try CSS theme tweak, a start:
@define-color graph_blue rgb(55,65,255);
I think there’s two different concerns going on in this thread.
Make the data in the waveform & rgb parade more visible. This is particularly so in rgb parade, as there the channels never overlay to make a brighter image. A simple fix may be to draw rgb parade with less transparency. There may also be an improvement to the “gamma” transform to waveform pixels which accentuates dim pixels, without flattening out the bright pixels.
Make the UI look more like the UI of other successful programs. I understand that it makes sense to look at other programs to see that other solutions are possible. And that part of what makes darktable good is its mix of extant open source algorithms, academic research papers, and industry best practices. But I’m concerned about cloning a look or feature from commercial software. Is it legal (much less ethical) to use the intellectual property of a commercial software firm? And: good open source projects (with limited #'s of coders involved) seem at their best when they find their own ways of doing things (cf Krita, or even darktable’s minimalist UI and exposed pixel pipeline).
I believe this is the main purpose, just to show a nice solution rather than something that has to be cloned. Let’s just call it inspiration.
FWIW, I would also like a much clearer waveform view. My eyesight is less than perfect and some of us rely more on graphs, scopes and histograms than is perhaps “recommended”.
My wishlist would also include being able to expand the waveform/histogram more (I have an ultrawide monitor so have more real estate than traditional monitors), clearer indication of clipping in the waveform view, and having a vectorscope.
