Playing around with Histograms / Scopes in RV

[nigelsumner]

Hey there,
I was playing around with implementing a Histogram and noticed that there was existing (although deprecated) code for a simple histogram. Riffing off this i mocked up a few scope options based off similar tools i have used in Resolve.

I'd love to get input from the community on whether this might be useful, how it might be better implemented, etc.

RV_scope_ideas_720p.mov

Video Scopes for Open RV

GPU-accelerated histogram and waveform overlays for Open RV, inspired by DaVinci Resolve.

Scope Modes

• Histogram — combined RGB overlay on a single panel
• Histogram Parade — stacked R, G, B panels
• Waveform — chromatic composite (binned by luminance, coloured by pixel RGB)
• Waveform Parade — side-by-side R, G, B with Resolve-style white-peaking at high density

Accessible via View → Scopes menu, with adjustable overlay opacity (25%–100%).

How It Works

A single ScopeIPNode sits at the end of RVColorPipelineGroup (after RVColor), controlled by two properties:

• node.scope (int 0–4) — off / histogram / histogram parade / waveform / waveform parade
• node.opacity (float) — overlay transparency

Data path: OpenCL kernels bin the source image into a data texture (histogram: 256×1, waveform: sourceWidth×256) using local-memory atomics with soft binning. A GLSL merge shader then visualises the data as an overlay composited on top of the original image.

Three kernel variants per scope type (16k/32k/48k) adapt to the GPU's available local memory.

Questions for the Community

1. OpenCL dependency — The bin accumulation uses OpenCL. Given Apple's deprecation, should we provide a Metal compute or GLSL compute shader alternative? Or a CPU fallback?
2. Pipeline placement — Scopes are in the colour pipeline (post colour-correction, pre display transform). Should they instead be in the display pipeline to show final display-referred values?
3. Per-source vs global — Each source currently gets its own scope. Should there be an option for a single scope on the final composited output? Should it be implemented as a visible node that can accept inputs?
4. Waveform resolution — Waveform data is sourceWidth × 256. For 4K+ sources, should we downsample the input first (as we do for histograms)?
5. Additional scopes — Vectorscope? False colour? Docked panel rendering vs overlay?
6. Placement - Full image coverage (as this is) or placed in corner over the image?

I've only compiled this on MacOS for now, but will test on other platforms soon. I'm not a developer, just a user with an interest in making stuff. cheers.

[cedrik-fuoco-adsk]

Hello @nigelsumner! Great work, it looks awesome! I haven't read everything yet, but you could post this in the ASWF slack channel #ori-openrv-discussion. You might have more/different eyes on it there.

[nigelsumner]

hey @cedrik-fuoco-adsk unfortunately i dont belong to a domain that allows me access to that slack group. I'll contact admin to see if i can get an invitation. but glad you liked it. cheers.

[nigelsumner]

@cedrik-fuoco-adsk

I posted to the ASWF channel, thanks for the heads up on that one. :)
I also just posted an updated test of a viewable "scope" node, leveraging the move_manip.mu on screen controls for interactive placement with a few presets as well. The existing colour pipeline implementation still sits in there in parallel but it seems like having both is unnecessary. I'm thinking the viewable scope is more useful and user friendly than the inline implementation.

OpenRV_scope_viewable_720p.mov