Choose a codec for grayscale machine vision video files

Uncompressed AVI is the default output of many lab and production capture chains, and it buries you in data: a modest 768 × 484 grayscale stream at 10 fps writes about 223 MB every minute, and two lab streams at that size and pace fill a 1 TB drive in roughly 20 hours. You get the file-size arithmetic for 8-bit and 16-bit streams, the codec decision that keeps every gray value bit-exact, the encode throughput a recorder must sustain, and a benchmark method that runs on your own footage rather than on review charts. The final section commits to a recording set-up for each stream type, from the 10 fps lab camera to a 12 MP inspection recorder.

How much disk does an uncompressed grayscale stream burn?

A 768 × 484, 8-bit stream at 10 fps writes 371,712 bytes per frame, about 223 MB per minute and 13.4 GB per hour; the 1280 × 1024 stream at 8 fps writes about 629 MB per minute and 37.7 GB per hour. The arithmetic is linear in resolution, bit depth and frame rate, which is why uncompressed folders grow so fast:

One 8-bit gray pixel is one byte; 16-bit gray is two; decoded color is three. If the inspection only needs luminance, converting color frames to one gray channel before encoding cuts the file to a third immediately — converting RGB frames to grayscale in vision software shows the standard conversion.

A current inspection camera multiplies the problem rather than changing it. The LS-CMR-0166 streams 4000 × 3000 at 30 fps. That is 12,000,000 gray bytes per frame and 360 MB/s — 21.6 GB every minute, or 1.30 TB per hour, straight to disk before compression does anything.

Why does an AVI marked 30 fps hold only 10 real frames per second?

The 30 fps in the AVI header is a playback constant, not what you captured: the file stores the 9-11 frames per second your loop actually wrote, so it plays roughly three times too fast and the header rate changes nothing about the stored pixels. The AVI header carries one fixed playback rate for the whole file, frames are appended as the acquisition loop delivers them, and the container stores no per-frame timestamps to fall back on. Two clean fixes exist. Set the header rate to the measured capture rate: a loop that sustains 9-11 real fps should head its files at 10. Or record into a timestamped container such as Matroska (MKV), which stores each frame's capture time and plays irregular rates at true speed.

File size follows the frames actually stored, not the header number — at 10 fps, 223 MB per minute lands on disk regardless of the 30 in the header. Size limits bite too: legacy AVI writers stop at 2 GB, which stream 1 reaches in about 9 minutes and stream 2 in about 3. When a player or vision library then refuses a file, diagnosing AVI open errors with capture backend fallback maps the failure stage by stage, and reading a stream's real frame rate explains why header queries mislead.

Which codec keeps every grayscale value bit-exact?

Use a lossless codec: FFV1 for archival recordings and a lossless H.264/HEVC configuration for long temporal recordings both decode to pixels identical with the source and typically shrink noisy 8-bit footage by 2:1 to 4:1, or up to about 10:1 when the scene barely changes. Lossless means the decoded file reproduces the source pixels bit for bit; lossy trades permanent gray-level error for size. The working choices:

FFV1 is an open, documented codec designed for archival: it compresses each frame on its own, so any frame decodes without its neighbours, and it embeds integrity checksums in the stream. Lossless H.264/HEVC adds temporal prediction, which pays most on a locked-off camera watching a quiet scene. The wider field is surveyed in the comparison of video codecs. If the recorder is an embedded platform with a hardware encoder, check its lossless mode before relying on it — selecting lossless encoding for grayscale video walks that exact decision.

These ratios assume real sensor noise, which entropy coders cannot squeeze; synthetic or thresholded content compresses far harder. Measure on your own clip before promising a number — the method comes two sections down.

When is a lossy codec safe for an inspection recording?

Lossy compression is safe only when the smallest feature you must judge stands far above the artifacts it introduces: for review clips watched by people, high-quality lossy encoding at 10:1 to 50:1 is fine, while anything you measure, threshold or train on stays lossless. Lossy encoders shrink the file by discarding gray-level information, and DCT-based ones do it in 8 × 8 blocks, which shows up as blocking and ringing on precisely the smooth gradients a grayscale inspection cares about.

A working rule keeps artifacts under a third of the smallest feature contrast you must judge: a defect that reads 10 gray levels over a background carrying ±3 levels of sensor noise tolerates 1-2 levels of codec error, and high-quality lossy settings usually stay inside that for a human reviewer. They rarely stay inside it for an intensity measurement, a sub-level threshold check, or training data whose labels depend on faint contrast. The commit: anything you or a model decide from stays lossless. Lossy copies are derivatives rendered afterwards from the lossless master when someone needs a small file to watch — never the recording itself. If a review copy is genuinely all a recording will ever be, still ask whether next year's algorithm might want the master; disk is easier to add than a measurement is to re-take.

What changes when the camera outputs 12 bits?

Converting 12-bit frames to 8-bit before saving collapses 4,096 gray levels to 256 and is irreversible, so record the native depth when levels matter: 8-bit halves the file against 16-bit, a 16-bit container doubles it, and no codec recovers discarded bits. Bit depth is bytes per pixel: 8-bit gray is one byte, 12-bit data carried in a 16-bit container is two. Convert to 8-bit first when 256 levels already separate the features — with exposure and gain set, most defect detection lives comfortably in 8 bits. Keep the native depth for photometric measurement, high dynamic-range scenes, and training sets you cannot afford to re-shoot.

A 16-bit decision carries two costs. Files double: the 1280 × 1024 stream becomes 2,621,440 bytes per frame, about 1.26 GB per minute at 8 fps. And the display path changes, because some viewers and toolchains crash or render garbage on 16-bit gray — resolving grayscale U16 display crashes covers that failure. For the recording pipeline itself, recording a 12-bit grayscale video file without dropping to 8 bits walks the encode path, and saving 16-bit grayscale camera images reliably handles the still-image side.

How do you benchmark codecs on your own streams?

Benchmark on your own footage, not on review charts: encode a representative one-minute clip with every candidate codec, record encode time, output size and a pixel-for-pixel decode comparison, and keep any codec whose encode rate clears your stream rate with 30% headroom. Many vision development environments ship a ready-made comparison example that compresses a sample recording with every codec installed on the machine and reports compression time, quality and final file size; where yours has one, run it on a minute of real footage before writing any decision logic. Where it does not, the same three measurements cost an afternoon of scripting:

1. Encode speed. Compress the clip with each codec, record bytes in and seconds out, and divide for an encode rate to compare against the stream rate.
2. Size. Same clip, same frames: note output size and the ratio against raw.
3. Reversibility. Decode every result and compare each pixel against its source frame; one differing pixel disqualifies the codec for measurement work.

Use footage with your real noise, motion and exposure changes — a ratio measured on a clean test chart overstates what a live sensor stream reaches. One run yields encode rate, ratio and a pass or fail on bit-exactness, which is everything the next two sections need.

How fast must the encoder run to keep up with acquisition?

The encoder must sustain at least 1.3 times your stream's byte rate or frames pile up and drop: stream 1 asks barely 5 MB/s and any lossless codec manages, while a 12 MB frame at 30 fps asks 360 MB/s, which needs NVMe-class storage and a benchmark first. An encoder sustaining exactly the stream rate has nothing left for scheduling delays, disk hiccups or a burst of scene change; the symptom is shorter files rather than an error message. The ladder, using this article's own streams:

The first two rows are trivial: lossless encoders reach tens to hundreds of MB/s on a current core, so both clear with a wide margin. From the 200 MB/s row upward, storage becomes the second gate — a spinning disk at 150-250 MB/s cannot take 360 MB/s, a SATA SSD works at its limit, and NVMe is the realistic target. The wire follows the same arithmetic. The MV-CS200-10UM captures 20 MP mono frames over USB3.0. At 10 fps such a sensor writes about 200 MB/s, which saturates a single GigE link outright; the frame grabbers page holds the multi-port capture cards.

A single GigE link carries about 118 MB/s of usable payload — enough for stream 2 with a wide margin — and a dual-port PoE NIC handles two such links:

When the symptom is already dropped or delayed frames, fixing the gap when acquisition outruns processing separates capture limits from processing limits, and planning data rates for high-frame-rate recording runs the same arithmetic at a far larger scale.

What should you record each of your streams with?

For the two lab streams, record FFV1 or lossless MJPEG at the measured frame rate — about 223 and 629 MB per minute raw become roughly 56 to 112 and 157 to 315 MB per minute lossless — and move to lossy encoding only for review copies. The decisions, case by case:

• 768 × 484, 8-bit, 10 fps lab stream. FFV1 or lossless MJPEG, header rate set to the measured 10 fps, timestamp in the file name. Raw 223 MB per minute becomes roughly 56-112 MB per minute lossless, and every gray value survives for measurement or training.
• 1280 × 1024 stream at 8 fps. Decide bit depth first. If 8 bits separate the features, use the same codec and expect 157-315 MB per minute; if the 12-bit levels matter, record 16-bit lossless at about 1.26 GB per minute and plan the display path accordingly.
• A 12 MP, 4000 × 3000, 30 fps recorder. Budget 21.6 GB per minute raw. Use a temporal lossless codec such as lossless H.264/HEVC on a multi-core machine, confirm with the benchmark that encode sustains 360 MB/s, and give the writer NVMe. Where several such cameras share one recorder, put capture on 10GigE:

• Review copies. Render lossy derivatives from the lossless master at 10:1-50:1 for anyone who only needs to watch.

Whatever the codec, decode-and-compare one full file before the first production run: one verified lossless recording beats any ratio promised on a chart. If sizing the capture chain behind the files is the open question, the area scan cameras catalogue and the cameras finder narrow by interface and resolution, the system configurator builds the chain step by step, and the systems topic page collects the rest of the recording and streaming checks.