v0.1.0

A camera tube, as an FFGL effect for Resolume Arena and Avenue, shown as SW Plumbicon. It is not a filter that adds smear and bloom. It is a photoconductive target that stores charge: light charges it, an electron beam reads it by discharging it, and the beam can only take so much per pass. Lag, the comet tail behind a moving highlight, blocked-up highlights and burn-in are all what that one limit leaves behind, and nothing draws a tail. A smear changes colour because the store is per channel. Two Fields doubles the tail, and it twitters on motion and only on motion.

Plumbicon, Vidicon, Saticon and Image Orthicon are the same model with different constants. This is the camera, not the screen: put old-cathode after it for the monitor. Time is counted in fields, so the look depends on the composition's frame rate, as a real camera's does. Fixed at release: Type = Custom now starts from the Plumbicon row (Target Capacity 0.45 and Lag Amount 0.22, where they were 0.865 and 0.18), so switching to Custom no longer jumps the tail from about two fields to about five.

What is verified

By tools/verify.sh on an M4 Max, macOS 26.4, on 2026-09-23:

• A saturated highlight switched off reads 1.000 for four fields, 0.2769816 on the fifth against 0.2769813 predicted, then exactly zero, at 64×36 and 320×180. The discharge is linear, not exponential, and it stops dead.
• Two Fields runs the tail for 12 fields against 6, with adjacent rows following the alternating recursion to 2.6e-7.
• A 64 px highlight at 4 px/field leaves a tail of 16 px against 16 predicted, at 320×64 and 1280×128.
• Patches at 10× and 100× capacity both read 0.115470044, which is capacity × gain exactly. A patch at a quarter of capacity reads 0.0288675167, so the check is not passing on a constant.
• Burn tracks its closed form to 2e-7 over 400 fields of rise and after 300 fields of recovery.
• A beam above capacity is the identity to 5.96e-8, against an 8e-6 tolerance derived from the GLSL specification's accuracy for pow. Alpha passes through bitwise.
• All 19 swept parameters measurably change the picture, and all 6 shaders compile through glslc, including the four assembled at run time.
• oxbow instantiates it and renders 120 frames with GL error 0x0, as SW Plumbicon, PB01, effect.
• Render cost 0.580 ms/frame at 720p, 1.245 at 1080p and 4.545 at 4K. These are macOS figures only. The memory matters more than the time: the target is two RGBA32F buffers, 28 MB at 720p, 63 MB at 1080p and 253 MB at 4K, and Two Fields doubles that.
• The Windows x64 DLL compiles with MSVC in CI.
• The five physics checks also run in CI on GitHub's GPU-less macOS runner, using Apple's software renderer. Its first run put the 100× patch one ULP off the value this Mac gives. The --capacity tolerance (2.4e-7) now comes from how the final mix is implemented, not from what either machine printed.
• Windows, in Resolume Arena 7.27.1 (win-lab, Mesa llvmpipe, no GPU, 2026-09-23): a CI build of this source loads from Extra Effects, registers as SW Plumbicon / PB01 / effect, all 25 host parameters match the declaration, it renders and Arena's log stays clean — 8 of the fleet gate's 9 checks. The ninth is controls: 18 of 20 moved the picture, and Recovery and Burn Rate read dead because the gate holds a still picture for about a second and those two act only on motion and over many fields. The harness sweep proves both live. Software rendering says nothing about a GPU or about speed.

What is not

• Never loaded into Resolume on macOS. How six groups of controls present in the inspector is untested.
• The tube-type constants are judgement calls, not values taken from a data sheet. The burn time constants are faster than a real tube's (a 200-field rise, about three seconds at 60 fps) so that the effect can be shown in a single take. The halation is two Gaussians rather than a measured point-spread function. The Image Orthicon's halo is the one term that is drawn rather than derived.
• Field Mode models the scan cadence, not an interlaced signal. The output is progressive.
• It advances one field per rendered frame, so a host that renders the same frame twice (two outputs, or a preview plus a record) advances the target twice.
• The CI physics runs on a software renderer. That proves the tolerances hold on a second rasteriser and says nothing about speed.
• No OpenFX port, no browser demo, and no factory presets beyond Type. There is a user guide at https://stoatworks-labs.com/software/plumbicon/guide/.

The macOS build is signed and notarised; the Windows build is unsigned, so SmartScreen warns once.