# Shutter Desk

> A frame is not a moment. On a rolling-shutter sensor the rows are read one after
> another, so the bottom of the picture is a later instant than the top - and the gap
> between them is the readout time, which is not the shutter speed, not the frame rate,
> and on no slate.

https://shutter-desk.skillsafe.ai/

## What it is

Five lanes over one shot - a sensor, a geometry, a light and a list of things that are
moving - plus a **free browser-side engine** that computes the whole frame from a stated
readout time. The engine costs nothing and needs no account. Writing the report costs
credits.

## The arithmetic

Two multiplications carry the whole model:

    displacement across the frame = image velocity x readout
    bands across the frame        = flicker frequency x readout

The first is a **lean** when the motion is horizontal and a **stretch** when it is
vertical - the same number wearing two names, which is why they are one fault and not two.
The second is why banding looks the way it does, and the shutter appears nowhere in it.

## Figures that are exact, and surprising

- A 16 ms readout over 2160 rows is **7.41 microseconds per row**. Row 1080 is exposed
  8.004 ms after row 0, in the same frame.
- An ordinary **130 degrees-a-second whip on an ordinary 16 ms sensor leans every vertical
  in the frame by 5.07 degrees** - 192 pixels between the first row and the last.
- **A longer lens makes it worse.** More pixels per degree means the same rotation
  displaces more picture: the same whip on a 20-degree lens leans 10.38 degrees. The lever
  that helps is a wider lens, not a longer one.
- **The shutter angle cannot change how many bands there are.** 100 Hz light across a
  16 ms readout is 1.6 bands, and nothing about the shutter appears in that product. What
  the shutter changes is their depth.
- **172.8 degrees is arithmetic, not a convention.** At 24 fps it is 20 ms exactly, two
  whole cycles of a 100 Hz light, and the banding cancels to zero. At 180 degrees the same
  shot bands at 3.95%.
- **Fewer than one band is not banding.** It is a brightness ramp down the frame that
  changes frame to frame, and it gets blamed on the lighting.
- **A flash shorter than the readout cannot light the whole frame.** A 0.2 ms flash at a
  1/500 shutter on a 16 ms readout lights 13.75% of the picture. That is a sync speed, on
  a camera with no physical shutter in it.
- **Run it backwards and the artefact measures the sensor.** readout = bands / flicker
  frequency. Three bands under a 100 Hz lamp is a 30 ms readout, measured on the body in
  front of you rather than looked up.

## The sheet

    SHOT
    sensor  | mirrorless          a class, or give `readout | N ms` directly
    rows    | 2160                required, and has no default
    width   | 3840
    hfov    | 40                  width and hfov turn a rotation into pixels
    fps     | 24
    shutter | 180                 an angle, or a fraction like 1/50
    mains   | 50                  50 or 60; doubled to get the light's flicker
    flicker | 100                 overrides mains, for a lamp not on mains
    flash   | 0.2 ms
    scan    | up                  for a sensor read from the bottom

    MOVES
    w1 | pan 130 deg/s   | the whip to the door
    w2 | track 1200 px/s | the forklift crossing
    w3 | rise 900 px/s   | the pallet going up behind

A move row is `id | kind value | description`. The kind is one of:

- `pan` - the camera rotating horizontally, in deg/s; positive is to the right
- `tilt` - the camera rotating vertically, in deg/s; positive is up
- `track` - something crossing the frame horizontally, in px/s; positive is right
- `rise` - something crossing the frame vertically, in px/s; positive is up

**The kind decides what the number means.** A `pan` is degrees and a `track` is pixels,
and converting between them needs a lens. A move whose kind is not one of the four is
reported as unread rather than guessed at, and a `pan` on a sheet with no `hfov` is
reported as unconvertible rather than as a lean of zero.

## Lanes

- `plan` - decide what the sensor can take, before anything is shot
- `check` - what the frame is actually doing (primary)
- `readout` - the clock nobody wrote down, and how to measure it from a frame you have
- `light` - whether the light and the sensor agree
- `deliver` - as shot, fix on the day, or needs a different sensor

## What it cannot do

It is a timing model of a sensor and it **has not seen the footage**. The readout is an
input rather than a measurement: where a sheet names a sensor class instead of a number,
the figure used is representative of a kind of sensor, and every result scales directly
with it. The flicker model is a sinusoid, so a PWM-dimmed LED is outside it. Electronic
stabilisation, which warps the frame after the readout has happened, is not modelled at
all. The thresholds for what is visible are conventions written down so they can be argued
with, not laws of perception.

## Links

- App: https://shutter-desk.skillsafe.ai/
- API: https://shutter-desk.skillsafe.ai/api.html
- Source skill: https://github.com/steipete/clawdis (not affiliated or endorsed)