add RGB parade and vectorscope as histogram alternatives

[dtorop]

Is your feature request related to a problem? Please describe.
Video software tends to have an "RGB Parade" and "Vectorscope". Would these be useful for darktable? They would provide alternate ways to visualize color/lightness data besides the regular and waveform histogram.

Describe the solution you'd like
An "RGB Parade" would be trivial to implement as a generalization to the current waveform histogram code. There would be no changes needed to the pixelpipe math, only an additional type of drawing in libs/histogram.c. It should be fast to draw.

A Vectorscope would require more code in develop/pixelpipe_hb.c and would use a bit more memory for a buffer. It would involve adding a bit of code to libs/histogram.c. The polar coordinate math wouldn't be too slow so long as the scope was somewhat lo-res. It should be fast to draw once the color counts are calculated out to a buffer.

With that many histogram/scope alternatives, it would make sense to add keyboard accelerators to choose a specific scope, or to cycle through scopes.

The current histogram widget is a bit squashed for waveforms (or rgb parade), much less a circular vectorscope. It might make sense to allow the widget to resize vertically via the GUI, or to make it automatically resize depending on its contents.

I'd be happy to work on an RGB parade or vectorscope if it were of interest and there was some clarity about a good design.

Alternatives
The waveform histogram already has essentially the same data as an RGB parade, though it may take selecting/deselecting color channels to understand how a particular channel works.

A vectorscope came up in #2140 as a way to visualize how to balance color. It's possible that a home for a vectorscope would be in some sort of interactive color balancing iop, rather than in the histogram widget. Though I'd imagine the readout would be useful as a reference when using a variety of iops.

I'm also curious about whether a "power editor" would want to see multiple scopes at once, e.g. both waveform and vectorscope.

Additional context
Some articles about using scopes:

• https://www.cinema5d.com/primary-colour-correction/
• https://waondering.com/2015/05/18/continuity-of-colors-matching-exposure-and-color-balance/
• https://www.premiumbeat.com/blog/rgb-parade/
• https://www.bhphotovideo.com/explora/video/tips-and-solutions/introduction-waveforms-scopes-and-exposure
• https://thevideoproguys.com/read-histogram-vectorscope-color-correcting-tools/

There appears to be vectorscope code in qctools (https://github.com/bavc/qctools/wiki/Vectorscope). This could be helpful as a model.

I'm unclear if YUV is the standard/only vectorscope color model, or if there is one which is more preferred/useful as so much has happened since analog TV. I'm also not certain if the primary/secondary color targets on the vectorscope are that useful for photographers, except as a guidance to orient their sense of the graph.

There is also even more esoteric scopes, such as YC Waveform and YCbCr Parade. It would be interesting to hear if anyone has substantial experience with these, RGB parade, or vectorscope, and has a vision of how they might or might not be useful.

[chhil]

I miss the RGB parade and vectorscope. A lot of times I convert my raw to dng and edit/color grade it in resolve.

[GrahamByrnes]

Just a naive comment: these sort of tools seem very video-centric, since they display column-average intensities. That may be great when the frequency of portrait-mode cinema is about 1/10^7, the width to height ratio quite big and the story is in some sense laid out across the frame... but is it really useful in portrait mode?
At present, I find the waveform just a wasted step when changing from linear to log histogram. So if someone has time to implement this, great... but it would be nice to have a preset to include it or not in the set of histogram alternatives. Or, reduce the histogram to just linear & log histograms, and move this stuff into a new module.

[dtorop]

A lot of times I convert my raw to dng and edit/color grade it in resolve.

This is good to hear -- that someone uses these tools for still images!

video-centric, since they display column-average intensities

It's a fair point. It would be trivial to make row-average intensities, though it may confuse people used to the "classic" tools. A question is whether it would be better to implement the classic video forms of these, or imagine what the right added visual information could be for photographers.

preset to include it or not in the set of histogram alternatives

This would also be (fairly) trivial. Keyboard shortcuts to choose a scope could also help here.

[dtorop]

One other thought would be to add a "scope" iop. It would default to being at the end of the pixelpipe. Chances are it would be used in lieu of the histogram in the right panel (cf. hide the histogram window via ctrl-shift-h).

The interesting things about this could be:

• The iop could be duplicated, in case the user wished to see a variety of scopes.
• The iop could be dragged earlier in the pixelpipe, in case the user wished to get a sense of the output in intermediary steps, or even to get a sense of the initial raw file (as an alternative to the "raw overexposed indication").
• The iop could have a drop-down/buttons/accels to determine the type of scope (or alternately, there could be different iops for different sorts of scopes).
• The iop widget dimensions could be appropriate to different sorts of scopes, e.g. a vectorscope which looked better square, or a waveform which might benefit with more y-axis space).
• As it's a generalized version of the histogram panel, at some point it could replace this panel, or be displayed/treated specially to appear where that panel appeared.

The troubling things would be:

• It's a hack on the iop/pixelpipe, which is intended to change the image, not give readouts on the image.
• And, indeed, running the iop (even if it was a no-op everywhere but the preview pipe) would still require allocating an output buffer and copying data to it, and using cache space for that buffer, unless there was a further hack to make the pixelpipe treat readout-only iops in a special manner.
• Darkroom mode (depending on config darkroom/ui/single_module etc.) tends toward only one module open at a time, so there'd need to be another hack (or fiddling with config) to keep the scope iop open.
• There are iops such as the various curves which already show a background histogram when needed, and infrastructure to generate these in the pixelpipe. A quick implementation would end up duplicating some of this (though maybe there's some way to use some of that infrastructure).
• As the iop could be at an arbitrary spot in the pipe, the scope would probably need to be able to handle raw, Lch/Lab, and RGB.
• This is a lot of plumbing when the normal case is just to want to get a sense of the final output data.
• From what I can see, https://discuss.pixls.us/t/processing-that-sucks-less/13016 is trying to allow for output "taps" at various points in the pipeline. Better a system designed from scratch to do that well, rather than retrofit it.

[aurelienpierre]

I think an all-purpose scope IOP is a bad idea for the current pixel pipe. It's not only a matter of colour space (RGB/Lab) or data layout (mosaiced raw/demosaiced pic), but also of reference encoding (display or scene).

Just do that at the end of the pipe in display-RGB space.

[dtorop]

Just do that at the end of the pipe in display-RGB space.

Yes, that sounds wise. Anything else is over-engineering.

Maybe it's really a UI/usage problem: What sort of visualization do people need to tune an image? Are the existing visualizations (histogram/waveform) enough? Do more specialized visualizations interfere with the work of people who want the "classics"?

[aurelienpierre]

My understanding of the vector scope and waveform for video is they are primarily designed to help aligning different footages/rushes that might be shot from different cameras/angles at different exposures, in a way that doesn't create inconsistent exposure and colour grades bump over the duration of the video.

We don't have the same constraints in photography, although some photographers work on series (or books, catalogues, etc.) where visual consistency between pictures can be a goal and a challenge. In that case, a vector scope, for example to align skin tones, could be a real advantage.

But for that use case, that also triggers the need to be able to compare the scopes between 2 images (at least).

[dtorop]

But for that use case, that also triggers the need to be able to compare the scopes between 2 images (at least).

Yes, that's interesting. I hadn't thought this out that way. In which case, a vectorscope may be, er, out of scope for the project... I do find myself using the waveform -- I like having a spatial clue to where clipping is happening. Plus, it looks great.

I'm continually fascinated by the tools digital video people have which haven't yet made their way into still photography.

[GrahamByrnes]

As Aurelian said, matching skin tones can be important in a sequence... but that seems something I can better relate to doing with a color-picker, since eg a face is going to be surrounded by other things (clothes, furniture etc) which will typically change between images. That brings me back to the issue of column averaging (or row averaging): that would seem to make matching skin more rather than less challenging. For clipping, isn't that already taken care of with the two clipping indicators? To go further in that sense would seem more likely to involve soft-proofing for the display device, to capture out-of-gamut colours. Le jeu. 23 janv. 2020 21:40, Dan Torop <notifications@github.com> a écrit :

…

But for that use case, that also triggers the need to be able to compare the scopes between 2 images (at least). Yes, that's interesting. I hadn't thought this out that way. In which case, a vectorscope may be, er, out of scope for the project... I do find myself using the waveform -- I like having a spatial clue to where clipping is happening. Plus, it looks great. I'm continually fascinated by the tools digital video people have which haven't yet made their way into still photography. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4149?email_source=notifications&email_token=AN2X2RQUI3LFYKBDLJKT5K3Q7H6EVA5CNFSM4KI3G6C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJYYYCA#issuecomment-577866760>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2X2RUT6YNGOK7GOTARTS3Q7H6EVANCNFSM4KI3G6CQ> .

[dtorop]

@GrahamByrnes All true. An option to select a portion of an image to produce a histogram could help with color-matching just a portion of an image (e.g. face). But as you write, color-picker works well already. Using an appropriate iop/mask could also selectively produce a histogram/waveform for the relevant portion of an image, though this is more awkward.

[aurelienpierre]

Color pickers show you the average, but not the distribution of hue/saturation/lightness. It's more limited than a vectorscope.

[chhil]

I use the RGB parade more often than the vectorscope.

In DT one can do the things with equivalent modules but with some effort.
e.g.
I prefer aligning the parade for white balance using individual RGB components to align it,
Just seeing the individual channels that make the waveform seems more beneficial to grasp the scene and move the sliders to adjust and keeping luminosity at 0 to not make other colors vary.

[dtorop]

Good to hear that RGB parade has some fans.

Here's a UI thought: Replace the single "type" button on histogram (which now cycles logarithmic -> linear -> waveform) with two buttons. A "type" button cycles histogram -> waveform -> vectorscope. Then a "mode" button cycles, depending on the type:

• histogram: logarithmic -> linear
• waveform: waveform -> RGB parade
• vectorscope: no-op, or YUV -> YCbCr -> etc. or 75% -> 100%, or to turn on/off overlays

Or alternately:

• histogram: as above
• waveform: column-binned -> row-binned
• RGB parade: column-binned -> row-binned
• vectorscope: as above

This would mean:

• people who only use histogram don't have to cycle through a bunch of other scopes to switch from logarithmic->linear
• there'd be room to experiment with variations for each scope type

The option to selectively show R/G/B channels could remain for all scope types, even if it is most useful for histogram users. Or the channel selector buttons could disappear unless the type is "histogram", and other buttons (e.g. 75%->100%) could appear as needed for each scope.

[kikoucalou]

I believe that the border between the technical processing of the still image and that of the industry of movies is held.

Resolve this powerful video editor with nodes used for color gradding was mentioned. It has a very interesting interface with many tools that could be implemented in Darktable for those who would like to use them, like vectorscope.

Vectorscope is certainly a very interesting and complementary tool to other analysis tools like parade ...