scopes (histogram, waveform, rgb parade, vectorscope) improvements -- catch-all

[dtorop]

There's been a chat/thought about improving the scopes (histogram, waveform, rgb parade, vectorscope). So ideas do not get lost, here's a list, cross-referenced to other issues if possible. There is no guarantee that anything on this list is necessarily a good idea, much less will actually make its way into darktable.

Code internals

• Refactor/modularize scopes module, in progress, see refactor/modularize scopes module (histogram.c) #20367 and modularize scopes (waveform, vectorscope, histogram, rgb parade) #20449
• make sure GTK4 ready and no changes break a GTK4 transition, scopes: updates to be GTK4 ready #20465

GUI/Design

Features

• Add split mode which shows two scopes side by side (Allow for showing vectorscope and waveform at the same time #20338)
  • Split mode with waveform and vectorscope (scopes: add waveform/vectorscope split mode #20349)
  • Split mode with RGB parade and vectorscope side by side
  • Flexible split mode which can allow arbitrary side-by-side scopes. UI could be to choose a mode by clicking its button, then control-clicking on the second mode to bring it up side-by-side in split mode.
• Improve "restrict scope to selection" colorpicker option for histogram and waveform with point sample: show full image scope (dimmed slightly), with the picked point emphasized on it, as with vectorscope
• Allow for moving scopes to a second monitor
• Implement scope modes (histogram, waveform, vectorscope) as a notebook/stack-style interface (while still not eating up vertical space with tabs)
• Update the utility modules UI (libs/lib.h) to allow side-by-side and/or notebook-style (overlayed) placement of modules, move each scope to a separate module, and rely on the utility modules UI to support side-by-side modules and mode switching
• Multi-scope tiling (horizontal and vertical) interface, either internal to scope module or for all utility modules
• Make vectorscope scalable or autoscale -- and this could mean zooming in/out or adjusting the logarithm base

Tweaks

• Move the RYB color harmony chooser to the right side of the scope, with other per-mode options (scopes: move RYB color harmony chooser to the right side #20500)
• Split mode improvements
  • Move the option buttons for each scope to the top right of that scope, rather than to the top right of the whole utility module (split scope: move options for each scope to top right of that scope #20672)
  • Make the divider between the two scopes draggable, rather than fixed at 50%
  • Make the vectorscope always square in split mode, and the waveform take up the remainder of the space
  • Add a bit of space between the two scopes, ideally via CSS
• Dragging scopes to change exposure can be laggy on slow systems. To give immediate feedback, dim the scope when it is out of date and move the highlight representing exposure or black point.
• Merge RGB parade into waveform scope, it becomes an option of waveform
• Use comboboxes instead of 3-way buttons (e.g. for switching between vectorscope options *u*v, a_zb_z, and RYB)
• Make the on/off state of checkbox-style buttons (e.g. RGB channels) noticeable in the button
• Consider making the linear/logarithmic scale 2-way buttons be checkbox-style (logarithmic on/off, when off it is linear)
• Move the RYB color harmony chooser into a combobox instead of a bespoke scrolling set of buttons
• Pack the RGB channel buttons vertically, not horizontally, to save space

Scopes

New Scopes

• CIE scope
• 3D scope, show in 3-axis colorspace

Scope Options

• luminance-only waveform (scope: add option for luma display in waveform & histogram #20704)
• add more colorspaces (which?) to the vectorscope
• raw histogram (and/or waveform?)
• just as dragging waveform/histogram changes exposure, dragging vectorscope changes hue/chroma

Happy for thoughts regarding more to add to this list (or refine/cull).

[SilvioGrosso]

Hello @dtorop

Just out of curiosity...
Have you considered to also add an option to "easily" move the scopes (once refactored) to a different (2°) monitor?
Since advanced color grading is usually performed by more "sophisticated" users it is quite likely that these people do own a secondary monitor. For instance, one monitor for the tools and the other to visualize the whole image while editing.

In addition, but this goes without saying, I suppose, all changes should be "GTK4 ready" in order to be future-proof.

In conclusion, it all looks like a lot of work to do which is both enticing and frightening 😯

[dtorop]

Have you considered to also add an option to "easily" move the scopes (once refactored) to a different (2°) monitor? Since advanced color grading is usually performed by more "sophisticated" users it is quite likely that these people do own a secondary monitor. For instance, one monitor for the tools and the other to visualize the whole image while editing.

It's a good idea. Would this be an ideal improvement for the overall utility modules code (which manages the left/right panels)? Would a user want to move a bunch of other modules to a second monitor as well (e.g. history, image information, etc.)? And if so, does that become part of a 2nd image window, or is this its own thing? Regardless, adding to the list so as not to lose this.

In addition, but this goes without saying, I suppose, all changes should be "GTK4 ready" in order to be future-proof.

Yes, good point. The scopes code now uses GtkGesture, which is one step. I'm not sure what other pieces are needed. My memory is that something about overlaying button widgets on a drawable (as done in scopes) isn't strictly supported in GTK3, so the code is a bit delicate there. I'm not sure what would happen with GTK4. It may be that the GSK would eventually help with scopes and some other bits of dt which push the widget metaphor.

In conclusion, it all looks like a lot of work to do which is both enticing and frightening 😯

Yes... So good to notate this all, as when/if it happens quite uncertain.