VVQ Patterns Overview

Shared Conventions

Signal format

Every VVQ pattern is 10-bit narrow-range Y'CbCr: luma 64...940, chroma 64...960 nominal, data range 1...1019. 64 is nominal black, 940 is nominal white, 512 is neutral chroma. Anything below 64 or above 940 is headroom and only survives on a chain that is in full range – so the headroom tiles are simultaneously a range test.

Two Kinds of Element

    • Code witnesses (EncodedCode) are written straight into the 10-bit code space and bypass all conversion: the 1-code rails, sub-black and super-white tabs, PLUGE, the white/black clip ladders, bit-truncation, the field box, chroma siting, and the QR code. They carry byte-identical codes on SDR, HLG and PQ. That invariance is the test - a code witness proves the chain carries the code, not that the chain converted it. If one of these reads wrong, the fault is in quantization, range mapping, or transport, never in color science.
    • Signal-domain elements (NonlinearRgb / SceneLinearRgb / DisplayLinearRgb) resolve through the active signal, so the same declared step is correct on Rec.709 and on Rec.2020 without a second table. The color tiles are in this class.

Motion contract

Position is a pure function of the absolute frame id, and speed is declared in active-screen widths per second, never pixels per frame. So a statement like "at frame 30 the bar is at 1/4 width" is true at any rate and any raster, HD and UHD included, and the same frame ID always yields the same picture – which is what makes these usable as golden captures.

Identity

The footer prints FRAME, EVENT, CONFIG <hash>; the QR encodes the pattern id. The config hash is FNV-1a over the canonical little-endian config bytes. Disable text, capture, and compare the hash to prove a link is bit-exact.

HLG and PQ Variants - What Actually Changes

Only the three canvas designs (Orchestra, Console, Ring) and the Overview have HDR siblings, and they are not "the SDR picture brightened". Each design is drawn from declared domains and converted once through the active signal's own OETF and the Rec.2020 matrix. There is no per-signal special case in the design code – the signal is a parameter, not a variant.

EBU A/V sync, Field Motion and the Motion pair are SDR only – there is no HLG or PQ version of the EBU 1, EBU 2, FieldMotion, VVQ Motion, or VVQ Motion interlaced patterns.

The HDR Transfers are Genuinely Different

The practical consequence: on PQ, a level label is a number of nits you can check against a meter. On HLG, a level label is a signal value, and the brightness you see depends on the display's assumed peak. That is the single biggest difference in how you use the two.

What is Identical, and Why That is the Point

Code witnesses do not change. The 1-code rails, sub-black and super-white tabs, PLUGE, the clip ladders, bit truncation, the field box, chroma siting and the QR code carry the same 10-bit codes on all three signals. The element library states this as the contract: "a code witness must prove the chain carries the code, not that the chain converted it."

Practically: if a code tile differs between your SDR, HLG and PQ captures, you have found a real fault – a range-mapping, quantization or transport bug – not a color difference.

What Does Change

Note the skin tones row specifically: the comment in the element library explains that on HDR these are declared in the signal's own nonlinear domain – "this is a display-referred appearance reference, not a camera rendition, so it must NOT go through the OETF". The result is the same appearance with different 10-bit codes, which is precisely what you want when comparing SDR to HDR rendition.

The PQ Reference-White Trap

kPqRefWhite = 203.0L is the load-bearing constant. The code comments on it directly: PQ levels are absolute, so any element expressed as a fraction needs a declared reference white. Passing the bare fraction would put a "75 % bar" at 0.75 cd/m2 – invisible. "A good illustration of a value that is technically exact and practically useless."

So a PQ 75 % bar sits at 152 cd/m2, not 0.75 cd/m2, and the SDR and PQ versions of the same element sit at comparable relative levels.

How to Analyze the HDR Variants

    1. Code tiles first, and compare across signals. They must be identical. Any difference is a bug, not a transfer characteristic.
    2. Then read the level ladders. On PQ, check each rung against a nit meter within tolerance – the ladder is absolute, so this is a real measurement. On HLG, check the signal code against the 709 ladder and reason about display brightness separately.
    3. Color tiles last. Wide-gamut behavior under a 2020 matrix is what these are for; judge them on a compliant display.

What the HDR Variants are Not

They are signal verification, not display certification. No peak metadata is claimed by the Overview; the canvas designs draw no metadata. If you need to confirm a display's peak brightness or its tone-mapping behavior, that is the HDR Exposure design (2009/2010) - a controlled measurement window with a known exact area, exact nits and a known surround, which is a different job from "prove the chain carries 2020 color correctly".

Choosing the Right Pattern

Cross-Pattern Reference

Audio. The 1020 Hz guard tone at -18 dBFS is on the VVQ SDR overview only. Motion, HDR and Exposure patterns are AUDIO: none by contract – if you hear a tone on them, the source is wrong, not the tone.

Range. Headroom (nominal BT.1886, the default) or full range, selected explicitly per context, and the output is labeled accordingly. Full range is how you verify a chain carries the sub-black and above-white witnesses. Never wrap-around.

Bit depth. 8-bit (v202), 10-bit native (v210), 12-bit (v12c), 4:2:0 at 8/10/12-bit with left or centered siting, and 4:4:4 16-bit (SDR only). The 1-code rails and bit-truncation tiles make quantization and truncation directly visible at each depth.

The bit-exact loop test. Disable text, capture, and compare the printed staticHashHi / configHashHi against a clean re-run of the same context. If they differ, the link is not bit-exact.

What these are not. Not a calibration suite, not a codec scorer, not an A/V offset meter, and not an HDR certification – by design. They give you exact references; the verdicts come from your scopes, meters and eyes.

AV Sync

EBU Digital A/V Sync 1

The Two Patterns

The first pattern is in transmission-alive phase: a wide black bar with a white tick sweeps vertically. The second pattern is the A/V sync phase - two black bars closing in from the edges toward a center flash. Interlaced output halves the per-field travel.

How to Analyze A/V Sync

Watch the marker and listen to the sync tone. The marker's position at the instant you hear the tone gives you the offset directly and visually – no capture rig needed for a direction verdict. EBU 1 gives the sweep; EBU 2 the convergence.

How to fix what you find

    • Marker and tone disagree persistently in one direction -> fixed (non-moving) latency in your chain. Re-check audio path delay and any scaler frame buffering.
    • Marker stutters or reverses -> you are seeing repeated/dropped frames, not a sync problem. Check the cadence setting before touching audio.
    • Bars wrong but marker perfect -> timing is fine; the fault is color (matrix/transfer tagging), not sync.
    • Nothing moves at all -> the pattern is being fed as a still, or the frame counter is not advancing.

EBU A/V Digital Sync 2

Reading the Verdict

    • Flash and tone together -> in sync.
    • Tone late -> audio delayed relative to video. Tone early -> video delayed.
    • Bars never quite meet, or meet off-center -> geometry/scaling fault, not a timing fault; the sync verdict is only valid once they meet symmetrically.

Limitation: this pattern measures direction and rough magnitude of A/V offset by eye. A numeric millisecond figure needs a loopback capture. The VVQ Motion pattern's event ruler gives the same reading on a calibrated scale.

Field Motion

How to analyze it, in order

    1. Frame integrity first. Binary counter vs decimal frame number. Nothing else means anything until this passes.
    2. Cadence. Bars, balls, zone plate and fades all loop on 2 s. If they loop together, timing is intact; if they drift apart, there is a cadence fault.
    3. Bandwidth. The 10/20/30 MHz luma and 5/10/15 MHz chroma tiles.
    4. Scaling. Rocking text and sliding logos.
    5. Noise / temporal. The three static noise squares and the zone plate.

Fixing What You Find

    • Counter skips or repeats -> upstream frame loss or duplication. Fix capture before evaluating anything visual.
    • Logo text frays or smears -> poor motion compensation or an interpolating scaler; bypass the scaler or switch to a sharper setting.
    • Colors wrong on the bars but fine elsewhere -> matrix/transfer mismatch.
    • Noise squares crawling -> temporal NR active when it should not be.
    • Chroma zone plates break up before luma ones -> chroma resolution or chroma subsampling is the limit, not luma detail.

Caveat: this pattern is largely RGBA-based, not code-exact. Several elements use SetColorRGBA/PutPixel (noise squares, orbital balls, color-bar pulse, fading images) rather than the exact Y'CbCr code path, so it is excellent for motion and visual diagnosis but should not be used to verify code values. Use the Overview or one of the canvas designs for that.

BASE SDR/HLG/PQ/Interlaced

There is an interlaced variant, and the difference is structural, not cosmetic. dtp_vvq() renders both fields on every call:

    • Field 0 (even rows, TFF) is sampled at t0 = n * Q/P
    • Field 1 (odd rows) is sampled at t1 = (n + 0.5) * Q/P

So a moving element is correct at two different times within one frame. The footer prints FRAME, FIELD, field order (TFF/BFF) and parity, and the field ID is the event id. Both fields are redrawn every call – the render is stateless, so seeking and parallel rendering are safe.

Components

Percentages are of the raster, 1080p reference.

The Twelve Instrument Tiles

The Caption Contract

Every label band sits outside its sample rect. Nothing is drawn over the samples you are measuring, so each tile stays exactly probeable. This is why the console/orchestra/ring designs were built the same way.

How to Use It

    1. Title line: confirm signal/raster/rate/scan.
    2. Levels container: gain, range, bit depth.
    3. Datum: geometry and registration.
    4. Color container: gamut and matrix.
    5. Response row + instrument bands: filtering, clipping, chroma.
    6. Field box (interlaced): field order.
    7. Footer: capture the config hash for the bit-exact loop test.

Fixing What You Find

    • 1-code rail has missing steps -> your chain is not really 10-bit. Check the output format selection and any intermediate 8-bit node.
    • Headroom tabs clip -> you are in headroom range, not full range. The sub/super-white witnesses only exist in full range.
    • PLUGE patches distinguishable -> display black level is wrong.
    • Field box combs or flips -> field order or deinterlacer issue.
    • Chroma fringing on the datum edges -> chroma not co-sited with luma.
    • Hash mismatch across a link -> not bit-exact; find where it diverges by capturing at each hop.

Console SDR/HLG/PQ

The Hero: Four Jobs in One Focal Point

That combination is the design's central idea: four different failure modes, one place to look.

The Caption Contract

instMake() draws the panel and caption band, then returns the sample rect only - inset, caption excluded. Nothing is ever drawn inside a returned rect except the element itself. That is a hard contract with whoever probes the pattern, and it is why the layout can be dense without corrupting measurements. 

How to Use It

Work left to right, top to bottom, in weight order: hero (geometry + motion) -> wedge and star (spatial) -> levels and codes -> color -> instrument strip -> motion track.

Fixing What You Find

    • Square not square or circle not round -> non-uniform scaling or wrong pixel aspect. This is the fastest geometry check on any of the nine patterns.
    • Converging wedge goes soft before the caption's number -> your chain is low-pass filtering earlier than declared.
    • Spokes stall into a flat disc -> resolution limit reached; compare against the 1-code rail result to separate spatial from quantization limits.
    • Sweep hand judders or reverses -> cadence or field-order fault. The counterweight is what makes a reversal visible.
    • Chroma sweep shows luma movement -> luma/chroma crosstalk in the scaler.
    • Marquee shimmers while the bar is clean -> temporal filter / motion compensation is the culprit, not resolution.

Motion - SDR/HLG/PQ/Interlaced

VVQ Motion

The Core Idea: Static Match vs. Moving Slats

The same three textures appear twice - once frozen, once moving. That pairing is the most valuable thing on the pattern, because it separates spatial filtering from motion-adaptive behavior. A chain can look perfect on the static copy and still fall apart on the moving one, and only this layout shows you both side by side.

The moving fine texture is the timing ruler: because its content is a pure function of position, you can tell exactly how far it advanced between frames.

How To Use It

    1. Cadence cells first – confirm the source-to-output frame ID relationship matches what you configured.
    2. Static match vs moving slats – compare the same texture frozen and moving.
    3. The two shuttles together – this is the chroma-lag test.
    4. F x A tile – find the highest frequency that still shows motion rather than a static pattern.
    5. Event ruler + 1020 Hz tone – A/V offset direction.

Fixing What You Find

    • Static copy clean, moving copy soft -> motion-adaptive filtering or a frame-blending / motion-compensation fault. Not a resolution problem.
    • Chroma shuttle visibly behind the luma shuttle -> chroma lag. Look for 4:2:2 processing, chroma resampling, or a deinterlacer.
    • Cadence cells show HOLD when you expect LIVE (or the reverse) -> the cadence source setting is not what you think it is.
    • F x A tile: high-frequency cells freeze -> temporal aliasing. The low amplitude/high frequency cells are the first to alias, by design.
    • Moving fine texture advances unevenly -> frame repeat or drop. Cross-check against the frame and half-rate cells.
    • Event ruler reads off-center against your tone -> A/V offset; correct the audio path latency, then re-check.

Note on cadence: the cadence source is offered for Motion, progressive only, by design. Interlaced cadence is deliberately not offered, because cadenceSequence semantics over fields are ambiguous. If you need to test interlaced cadence, do it downstream of this pattern.

VVQ Motion Interlaced

What Actually Changes

Everything spatial is identical to the progressive versions: the static-match / moving-slats pairing, both shuttles at 0.125 W/s, the F x A tile, and the event ruler. So the comparison that matters is progressive vs interlaced on the same chain - if interlace introduces an artefact, this pair isolates it.

How to Analyze It

    1. Field parity ribbons – the ribbons must alternate in the correct order for the declared field order. A repeated or swapped ribbon is a field-order fault visible without any instrument.
    2. Field rate shuttle smoothness – the shuttles are sampled per field, so watch them at field rate, not frame rate.
    3. Field flip at the shuttles – does the shuttle appear to step backwards once per field? That is field-rate judder, invisible in progressive.
    4. Y/C shuttle parity – the chroma shuttle against the luma shuttle, exactly as in image 6. Interlace makes chroma lag worse, so this is the most sensitive tile on the interlaced pattern.
    5. Moving slats – oblique edges are the worst case for field-based interlacing; comb artefacts appear here first.

Fixing What You Find

    • Shuttle steps backwards once per field -> field-rate judder. Look at frame-rate conversion rather than the display.
    • Comb on the oblique slats only -> classic interlace on diagonal detail. A motion-adaptive deinterlacer is the fix; a static one will not do it.
    • Chroma shuttle lags further here than in 2005 -> chroma is being subsampled per field. Check for chroma resampling on the interlace path.
    • Ribbons repeat or swap -> field order is wrong (TFF vs BFF), or a field was dropped upstream.
    • Moving fine texture advances unevenly -> field repeat/drop, same as progressive but now at field rate.

Orchestra - SDR/HLG/PQ

Components

The Zone Plates

Two of them, one luma and one chroma, each an exact 60-frame loop (phase advances by exactly 2*pi/60 per frame, so the loop is bit-exactly periodic). The luma disc is a true 2-D zone plate cos(2*pi*k*d^2) with k = 1/(4r), which puts DC at the center and the Nyquist limit exactly at the rim – one element, the whole 2-D MTF. The chroma disc holds luma at Y=502 and swings Cb/Cr in quadrature, so it is a true rotating chroma vector rather than luma-modulated color.

How To Use It

Treat it as a survey: it tells you which faults exist. When one tile flags a problem, switch to the Console view or the Overview and measure it there with room to work.

Fixing What You Find

    • Hairline grid fringes in color -> 4:2:2 chroma siting is off. This is the grid's actual job, and it is very sensitive.
    • Castellation rings at the top/bottom edge -> overscan or a soft scaler edge.
    • Ring target judders while the datum is rock steady -> motion sharpness or cadence, not geometry. The two jobs are deliberately separated.
    • Corner burst goes flat with an accent band -> that is the designed "past the limit" marker, i.e. this tile's frequency is genuinely unresolvable at this size. Not a fault.
    • 16-bit counter stalls or repeats -> frame integrity; fix that before anything else.
    • 1-pixel crawl tile shows color speckle -> expected on 4:2:2: one luma pixel carries no chroma at all. The speckle is the measurement.

RING - SDR/HLG/PQ

Why a Circle

The design argument is that a circle carries information a square cannot. It is the only element that reveals non-uniform X/Y scaling, scaler anisotropy and pixel-aspect error simultaneously with the spatial-frequency sweep around its edge. The Overview has a square only.

The cost is honest: the raster corners are used inefficiently, and a viewer at a distance reads shape before content, making this the least efficient of the three for a working engineer.

Geometry: the Ring is the Master Dimension

rOuter = min(W,H) * 40/100, rInner = rOuter * 78/100. The two satellite columns are then sized to exactly fill the space the ring leaves (colW = (W/2) - m - rOuter - gap). Deriving one from the other is deliberate: in a 16:9 frame a circle plus two five-deep column stacks cannot both be generous, and sizing them independently is what produced an earlier collision.

The Three Motion Tiles

How to Use It

    1. Is the circle round? If not, you have non-uniform scaling or wrong pixel aspect – the fastest geometry verdict of all nine patterns.
    2. Walk the disc outward from the center and note where the rings stop resolving. That is your 2-D MTF limit.
    3. The graduation labels let you confirm the ring is not rotating when it should be static, and confirm the sweep hand's 4 s period.
    4. Left column for levels and codes, right column for color and acuity.

Fixing What You Find

    • Circle is an ellipse -> non-uniform X/Y scaling or wrong pixel aspect. Nothing else on the card diagnoses this as directly.
    • Rings break up well before the rim -> the rim is the Nyquist limit by design; breaking up earlier means your chain is low-pass filtering inside the resolvable band.
    • Graduation labels unreadable but satellites fine -> the labels are 1-px scale text, the finest detail on the pattern. If they alias, expect the 1-px line gauge to fail too.
    • Sweep hand not completing 4 s -> cadence or frame-rate conversion fault.
    • Rings show color fringing at the outer edge -> chroma resolution is the limit, and the wide-gamut primaries push chroma harder than luma.