How V3KTR works
How V3KTR actually works — the real algorithms behind the effects, the mask system, and what it does with your GPU.
Real algorithms, not filters
No presets cosplaying as effects. The JPEG glitch runs a real 8×8 DCT — forward transform, quantise against actual JPEG tables, inverse — so the artefacts are real because the compression is. A CRT modelled to the shadow-mask, down to the Trinitron’s damper wires. Gray–Scott reaction–diffusion growing Turing patterns out of your image. True per-span pixel-sorting, datamosh on feedback buffers, film grain on real stocks.
And a handful that only work because they read depth. Point Cloud rebuilds your photo as a real 3D point cloud — every pixel lifted into space with true depth-buffer occlusion, sortable, scatterable, lit from above. Pixel-sort along the scene’s depth instead of flat rows. Depth DOF focuses exactly where the depth is, not behind a flat radial fake. Stack ASCII under Depth Shatter and the characters scatter along the depth, not the flat grid. Our own builds, from the method up — and built to stack.
Masking and layers
Every effect takes its own masks — up to four on a layer, combined with add, subtract or intersect, drawn from five sources: radial, linear, gradient, luma and depth. The depth one is the one nothing else has. A spanning Mask FX layer shapes a whole stack in one move, and masks animate: Reveal, Iris, Wipe, Depth Sweep, Travel.
Around that sits the boring stuff that decides whether a tool is actually usable. Reorder and blend layers freely. Lock a layer you like and keep rolling the rest. Undo anything. Save a look and it carries its motion with it. Sign in — free — and your looks follow you across devices. Exports come out at full resolution, with no watermark on any tier.
Performance and requirements
V3KTR runs on WebGPU — the browser’s modern graphics API. That means a current Chrome, Edge or Safari, on a machine with a working GPU driver. If WebGPU can’t start, you’ll get told so on a full screen, up front, rather than watching something look quietly broken. Whether your browser can run it is measured live on the compatibility page.
It measures your machine instead of assuming the worst. The preview resolution is on a live control loop: it steps down when a render runs past its GPU time budget and climbs back only once there’s comfortable headroom, with a cooldown so it doesn’t flutter while you’re dragging a slider. You can also pin it — full, 50%, 25% — if you’d rather decide yourself.
Exports aren’t quietly softened. The export resolution scales with the GPU you actually have, measured, rather than a flat floor set for the weakest card imaginable. On the weakest machine in the test rack, 6, 10 and 12-layer 4K exports all render at native resolution; on a mid-range desktop card a 24-layer 4K stack renders native without dropping the device. A file that says 4K has 4K in it.
The work goes where it belongs. Most effects are shaders on the GPU. A strictly serial one — error-diffusion dithering scans pixel by pixel and can’t be parallelised — runs on the CPU in a worker instead, where it’s roughly nine times faster, can’t hang the renderer, and doesn’t freeze the tab while a big image exports. Depth is inferred once per image and cached, so toggling and tuning depth effects never pays for it twice; the model is 99 MB, fetched on first use, then cached by your browser on desktop; iOS evicts that cache, so on iPhone and iPad it re-fetches a smaller quantised build (about 27 MB, on the CPU) after the browser restarts.
Touch devices start cautious. They have far less GPU headroom, and the auto-scaler is reactive — it can only pull back after it’s seen a heavy render, which is one render too late. So on a tablet it starts capped rather than climbing. It also respects reduced-motion preferences, and the whole interface has a density control if the default is too big or too small for your screen.
That cap is a mitigation, not a fix. This paragraph used to end “rather than climbing into a crash,” which our own device testing doesn’t support: an iPad Pro and an iPhone SE both load V3KTR and both genuinely process effects, and both still hit graphics-driver resets under load. Starting capped helps. It isn’t yet enough.
It’s a desktop-class app — it wants a real screen and a pointer. A tablet will run it, unreliably; a phone will run it too, at a size the interface wasn’t drawn for. Calling either one supported would waste your time, so neither is, until the stability work is done.
