scope: add option for luma display in waveform & histogram#20704
scope: add option for luma display in waveform & histogram#20704dtorop wants to merge 3 commits intodarktable-org:masterfrom
Conversation
In waveform scope can now either show RGB channels or luma. When luma option is on, make the RGB channel buttons insensitive. Note that this is luma (Y') not relative luminance (Y). Until add an option to display linearized RGB data, it doesn't make sense to show linearized Y, not least as the jump from seeing non-linear RGB channels to linearized relative luminance is disconcerting. Calculate either RGB channels or luma waveform, not both. This makes sure that RGB waveform calc is as fast as it was before luminance calculation added. Luma calculation is ~15% faster than RGB calculation. This does require reprocessing the pixelpipe when turn on/off the luma option. Future improvements could be: - Add option to show linearized waveform (and rgb parade) data - When linearized option is on, show luminance rather than luma - Add option to show luma/luminance in addition to RGB channels in RGB parade mode - Show luma/luminance in histogram Also: - Rename vs_prof parameter to profile in non-vectorscope _process() functions. The vs_prof name was a result of copying the name from vectorscope process. - Update some comments and general tidying.
|
@Donatzsky @VBK7 You both mentioned interest in a luminance waveform display, so curious how this seems. Caveats:
And a query: Is luma/luminance display helpful for determining clipping? Is there ever a case one wants to be sure that luminance rather than individual channels are clipped? |
ralfbrown
added
feature: new
Make the "luma" channel work for histogram scope to match the behavior of waveform scope. The same toggle button affects both scopes. Fix bug in prior commit where switching between rgb parade to waveform could show junk data when luma toggle is on. This is because rgb parade and waveform so far have shared the same data. Fix this by: - Not marking parade as up to date when update luma waveform. This forces a reprocess when switching from luma waveform to parade. - Store if current waveform data is rgb or luma. - Force a reprocess if switching from parade to luma waveform. Also: - fix (inconsequential) bug in dt_histogram_helper() where would always calculate max of histogram - shorten the DT_SCOPES_CHANNEL_* constants to DT_SCOPES_CH_* - note why skip first bucket when count histogram max
dtorop
changed the title
|
After a test it seems to me that I would have dissociated the luma button on histogram and waveform. That is, a way to keep a different state for histogram and waveform. Was this intentional? Maybe I'm missing something? |
As with linear/logarithmic (where histogram and vectorscope have separate states), the luma display can be different in histogram of waveform.
That makes sense. I added a commit that does this. I was trying to think out whether luma was closer to RGB channels state (which histogram or waveform share) or linear/logarithmic (for which histogram and vectorscope can hold separate states). |
The difference is very low and I'm wondering if this adds any real value for a photographer. But I'm not against this, it does not take lot of UI space and is optional. Just wondering. |
Yes, I've been wondering that too. I added the luma histogram this week because I was showing darktable to someone who isn't used to digital photography editing, and even the RGB-channel histogram was a bit overwhelming. So there's an argument for it as an introductory feature.
As luma emphasizes green, it can help understand that areas with a red/blue shift don't change the overall brightness as much as the RGB-channel scopes suggest. It can be particularly suprising to change the blue channel of an image, and see how small a luma change this is compared to what RGB channels show. It makes me wonder how often I adjust an image in terms of what an RGB scope tells me, compared to what my eyes see. But conversely, a luma display will looks quite close to RGB for a neutral image, and does lose the ability to tell if an individual channel will clip. The two people I tagged who requested this never wrote back about this PR, but my understanding is that a luminance waveform has been a longstanding request, and is something, like vectorscope, that exists in capable video software.
UI space is definitely scarce, especially in split mode... I was imagining this as a step in filling out scope options, some more advanced (raw histogram or CIE scope) and some more basic. Another option would be to hide this in conf, but that loses the value of quickly seeing if/how luma/RGB differ. |
|
Thinking through this a bit more: this allows a luma + chroma view, e.g.: 
This is more complementary than a RGB + chroma via. It's a way to understand an image not via how it will be stored (discrete RGB channels) but by how it is perceived. Going down that route, the next question would be whether to add an option to graph, for example, Jz data... |
|
Also: another UI possibility would be, instead of having a luma button, to turn show luma data when all three RGB channels are toggled off. Advantages:
Disadvantages:
There could be a gesture such as double-clicking on a channel or click-dragging across all three channels which would flip between RGB and luma, so the user wouldn't actually have to click all three channels to show luma data. |
|
I'm not fond of the last proposal, seems to me that to avoid a button we make the UI/UX more complex. |
Good use case indeed.
I don't understand this part, can you clarify? |
True! Having an empty scope (RGB channels all toggled off) has always seemed weird to me, but hiding a UI option in it is probably not the fix.
Yes, this is one that's intriguing for me too.
The conversion from RGB to luma is easy math, and the RGB <-> luma transition looks "right", as they are so visually close, especially, in neutral areas. But if the goal was really to understand luma and chroma as complements: we already have a nice chroma display in vectorscope, with thought as to what colorspaces we use to show chrominance. There could be better colorspaces to understand luminosity compared to deriving it from compressed RGB. For example, if the vectorscope is graphing the AzBz channels of JzAzBz, why shouldn't the waveform scope graph the Jz channel? I fiddled a bit initially with using the L channel of Lab, but haven't spent much more time on it. This could be work for a future PR, of course... |
3 participants
Allow waveform and histogram scopes to show either RGB channels or luma. When luma option is on, make the RGB channel buttons insensitive.
RGB channels
Luma
Note that this is luma (Y') not relative luminance (Y). Until add an option to display linearized RGB data, it doesn't make sense to show linearized Y, not least as the jump from seeing non-linear RGB channels to linearized relative luminance is disconcerting.
Calculate either RGB channels or luma waveform, not both. This makes sure that RGB waveform calc is as fast as it was before luminance calculation added. Luma calculation is ~15% faster than RGB calculation. This does require reprocessing the pixelpipe when turn on/off the luma option.
Future improvements could be:
Also:
src/common/histogram.csuch that it wouldn't flag when asked to calculate unimplemented raw max code.