treatment record

glitch-09

The whole published pass as ONE continuous render: 10,571 frames, 7.3 minutes, 67 windows. Segmentation contours and id boxes merged with pose skeletons, composited 'under' so the blockouts cut and carry the HUD.

status: preferred, full length
upstream: pass-02 frames 1–10,571
evidence: A lossless frame sequence was written and manifested; the video is derived from it.
gallery: image channel · 441 sampled stills

frame 1 · 0:0021,600 · 15:0043,200 · 30:00

glitch-091–10,571

Its window on pass 2's full 43,200-frame axis.

what it looks like · 12 frames

Sampled from this treatment, one still every 24 frames. The wall has all 441.

departs from the baseline

Supersedes glitch-06 + glitch-08 + glitch-07, which tile the same range in three pieces. They are NOT equivalent to this: render_chunked's block offsets count from frame 0 of the clip it is given, and each of those three is a separate clip. Within a run, window seams are hidden by rendering a 124-frame lead-in and discarding it; across runs there is no lead-in, so the displacement schedules reset at pass frames 6,252 and 9,132. Concatenating them would restart the glitch rhythm twice. This has one continuous schedule end to end.

Upstream

pass: pass-02
frames: 1–10,571
source: regenerable: hstack of passes/pass-02/{frames,text} 1-10571 (image left, text right)
source sha256: e06ce9cd4a09

Regenerating the source

ffmpeg -framerate 24 -start_number 1 -i frames/frame_%06d.png -framerate 24 -start_number 1 -i text/frame_%06d.png -frames:v 10571 -filter_complex '[0:v][1:v]hstack=inputs=2' -c:v prores_ks -profile:v 4 -pix_fmt yuv444p10le source.mov

Render

composite: under
device: cpu
frames: 10,571
clip length: 7 m 20 s
time to render it: 2 h 36 m
chunking: 160-frame windows, 67 of them, 124-frame lead-in discarded
overlay draws: box, mask, skeleton, face_mesh
overlay hold: 1 frame
stroke / bracket / label floor: 5 / 56 / 4,800 px²

Displacement layers

grid	max offset	angle	sparsity	jitter	hold	stagger	seed	envelope
4×3	32	90°	0.5	0.8	8	0.6	5	none
8×7	22	0°	0.8	0.8	6	0.5	9	none
20×18	14	0°	0.93	0.8	4	0.8	13	none

What the detector found

model: yolo11n-seg.pt + yolo11n-pose.pt
confidence floor: 0.15
detections: 4,268
per frame: 0.404

label	detections
person	1,242
train	445
bench	415
refrigerator	217
clock	213
car	152
truck	148
suitcase	139
traffic light	124
airplane	91

Outputs

file	frames	geometry	runtime	bytes	sha256
`previews/glitch-09.under-contours-skeletons.f000001-010571.mp4`	1–10,571	1536x1344	7 m 20 s	2.2 GB	`e5a3b4436185`

Named and hashed, not hosted. Nothing in this repository is a master.

Frame sequence

directory: frames/
files: 10,571
bytes: 14.8 GB
geometry: 1536x1344
lossless: yes
manifest: frames-manifest.json

The treatment's record, the same way a pass's frames are its record. preview.mp4 is derived from these, not the other way round — extracting frames back out of it returns the codec's opinion of the pixels.

Provenance

no task id

This treatment was run as a local process rather than dispatched through the mesh, so it has no task id, no lease and no event trail. That is a gap in the record, and it is recorded as one.

Note

Rendered as a local process, before glitch_treatment existed as a capability. It therefore has no task id, lease or event trail — unlike glitch-10, which was dispatched through the mesh. Kept as-is rather than re-rendered: three hours of correct work is not worth discarding for a provenance field.

← glitch-08 all treatments glitch-10 →