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. |
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.