Saving 12-bit camera images without losing intensity data

A recording can look correct on screen while losing the intensity differences needed for measurement. This happens when acquisition software converts camera samples into display pixels before writing them. Changing a grayscale palette does not restore the missing values.

For inspection developers logging monochrome or raw color frames, the reliable starting point is a verified unsigned 16-bit image sequence. Keep that measurement archive separate from any viewing video. You can then choose an encoder, document pixel alignment, estimate storage requirements, and prove that reading the files returns the original samples.

Choose the measurement archive before the preview

Treat recording as two outputs with different acceptance criteria:

A 12-bit sample has 4,096 possible codes. A 16-bit unsigned container provides enough room to retain every code without rescaling. The extra capacity does not create additional sensor precision; it simply provides a convenient storage representation.

An AVI extension alone does not establish recording bit depth. The input array, writer API, encoder, decoder, and reading application must all support the intended representation. Some paths convert input into 8-bit or color display data, even when the acquisition buffer contains higher-bit-depth samples.

If opening or selecting a video backend fails, use the video capture backend diagnostic. That is a separate problem from proving numerical preservation.

Establish how the samples occupy their container

Before selecting a file format, determine what the camera API actually delivers. Record the negotiated pixel format, decoded array type, dimensions, and sample alignment. Do not infer these from a preview window or a camera's nominal bit depth.

Common representations include packed samples, low-aligned samples in 16-bit words, and high-aligned samples in 16-bit words. Packed data requires format-specific decoding before ordinary image writers can interpret it correctly. The packed Bayer conversion guide covers that boundary; storage validation starts after the samples have been decoded correctly.

For a genuine unsigned 12-bit value, the two common word alignments are:

Both alignments can preserve the original information. Problems arise when the writer, reader, or analysis code assumes the other convention.

Converting known high-aligned words to low alignment means shifting right by four bits. Apply this only after confirming the format definition. If the source is actually full-range 16-bit data, the same operation discards valid information.

A dark-looking image does not prove that the values are wrong. A viewer displaying low-aligned values against the entire 16-bit range may show little contrast. Adjust the display mapping, not the measurement archive.

Select a format and verify the writer

Unsigned 16-bit grayscale TIFF and PNG are useful starting points for image sequences. PNG compression is lossless. TIFF supports multiple compression methods, so select an uncompressed or explicitly lossless mode and verify the result.

Format capability is not a guarantee about a particular library. Check that your chosen writer accepts an unsigned 16-bit single-channel array without silently converting it. Check the reader independently: some convenient image-loading functions return display-ready color arrays instead of the stored samples.

For each candidate path, establish:

• Whether the output remains single-channel rather than becoming an RGB rendering.
• Whether its stored sample type and bit depth match your intended container.
• Whether compression preserves every decoded sample.
• Whether the reader applies normalization, orientation changes, or color conversion.
• Whether a multipage file can be read frame by frame without skipping pages.

A grayscale palette controls how indices are displayed; it does not increase the number of values stored in an 8-bit index. Expanding a palette therefore cannot preserve thousands of distinct measurement codes in an 8-bit indexed image.

For video, require documented support for the intended high-bit-depth representation throughout the complete encoding and decoding path. If that evidence is unavailable, use an image sequence as the measurement archive and create a separate preview video.

For integration choices, consult camera acquisition software compatibility before committing to a writer that your acquisition environment cannot supply reliably.

Calculate archive size with a worked example

Storage estimates should use the decoded array you intend to save, not just the camera's nominal sample depth. An unpacked unsigned 16-bit monochrome image consumes two bytes per pixel before file overhead or compression.

Consider an illustrative acquisition containing 2,000 × 1,500 pixels at 10 frames per second:

That is 6 MB per frame, 60 MB/s, and 3.6 GB for the image payload, using decimal units. Allow additional space for headers, metadata, previews, temporary files, and operating margin.

Do not budget around an assumed compression ratio. Sensor noise and scene texture can substantially change lossless compression results. Benchmark representative images, but retain an uncompressed estimate when checking capacity.

There is no need to accumulate the entire recording in memory before saving it. Use a bounded acquisition queue and report write failures explicitly. For sustained acquisition and buffer sizing, continue with high-speed recording without dropped frames; throughput and value preservation require separate tests.

Save the metadata needed to interpret the values

An image array can survive storage perfectly while becoming difficult to interpret later. Save a recording manifest and per-frame records alongside the images. Use explicit field names, units, and a versioned metadata structure.

At minimum, retain:

• File name, sequence index, and camera frame identifier where available.
• Camera timestamp, its units, and its clock domain; record host receipt time separately if useful.
• Width, height, channel count, unsigned container type, and valid sample bit depth.
• Source pixel format, decoded alignment, and any deliberate alignment conversion.
• Exposure, gain, and black-level settings, including their units or documented conventions.
• Region-of-interest offsets, binning, decimation, and relevant processing settings.
• Color-filter arrangement and mosaic phase when storing raw color data.
• Writer version, compression setting, and any processing performed before storage.

Camera timestamps and host timestamps are not automatically interchangeable. A monotonically increasing sequence index is useful even when clock synchronization is unavailable.

Use the exposure and gain units explanation when raw setting values need interpretation. A number without its unit or scale may not reproduce the original acquisition conditions.

For raw color images, cropping can change which color filter occupies the first stored pixel. Preserve the crop offsets or updated mosaic phase. A demosaiced image is a processed derivative, not an exact substitute for the original sensor samples.

Prove preservation with independent read-back tests

Validate a small recording before running an unattended job. Use a synthetic unsigned test image to isolate the storage path from camera behavior. Include boundary values, adjacent codes, a gradient, and known pixel coordinates.

For example, include 0, 1, 15, 16, 255, 256, 2048, and 4095 in a low-aligned test. These values expose common clipping, byte-order, scaling, and truncation errors. Follow that test with actual camera frames, including a dark scene and a bright scene below saturation.

Compare the decoded reference array immediately before writing with the array returned after reading:

Perform subtraction in a sufficiently wide signed type. Unsigned subtraction can wrap and conceal the direction or magnitude of an error.

Check dimensions and channel count before comparing values. A reader returning a color rendering is not returning the original single-channel array, even if its preview looks similar. Where practical, read with a second independent implementation to expose matching assumptions in your writer and reader.

A histogram, minimum, or maximum alone cannot prove equality. Rearranged pixels can have an identical histogram. Likewise, values divisible by sixteen suggest high alignment but do not establish it without the pixel-format definition.

Test failure handling as well. Interrupt a short recording deliberately, simulate a write error in a controlled test, and confirm that incomplete files are identifiable. Mark a frame complete only after the writer reports success. Temporary filenames followed by a same-filesystem rename can help distinguish unfinished files, but do not by themselves guarantee survival of a power interruption.

Check hardware and software before ordering

The camera's advertised resolution and interface do not establish which high-bit-depth modes your application can record. Check the exact model, firmware, supported pixel formats, API delivery types, and writer behavior together.

The LS-CMR-0053 is a cataloged GigE area scan camera candidate.

The LS-CMR-0166 is a cataloged USB3 area scan camera candidate.

These are interface comparison candidates, not confirmed high-bit-depth recording configurations. Their supplied catalog entries do not identify supported sample bit depths or pixel-format alignments. Obtain those details before treating either as suitable for the intended recording task.

Compare area scan cameras through the camera finder after defining the required pixel format. If you use vision controllers, verify the installed acquisition runtime and image-writing libraries rather than assuming the controller determines file fidelity.

Ask for confirmation of the complete path: camera output, decoded array representation, file writer, and analysis reader. A successful camera connection only proves the first part of that chain.

Create the preview without changing the archive

Generate an 8-bit preview from a copy of the measurement array. For low-aligned 12-bit samples, a simple full-range preview can use integer division by sixteen. This maps 0 to 0 and 4095 to 255, intentionally discarding fine differences.

For adjustable viewing contrast, use an explicit black point and white point:

This mapping is a display operation, not a calibration. Keep its parameters in the preview metadata. A fixed mapping makes brightness changes easier to compare across frames; automatic per-frame stretching can hide those changes.

The usual 16-bit image-sequence answer is not always the whole solution. Long recordings may justify a verified lossless high-bit-depth video path. Applications requiring original transport bytes may need raw binary storage with documented stride, packing, byte order, and frame boundaries. Software requiring calibrated physical units may also need a separate processed dataset.

In every case, retain a clearly identified reference representation and test the complete round trip. A more convenient container is acceptable only when its output meets the measurement requirement.

Use this release checklist before a full recording

• Confirm the source format. Record valid bit depth, packing, alignment, and channel interpretation.
• Inspect the writer input. Verify that preview scaling, demosaicing, and automatic contrast have not entered the archive path.
• Run the numerical test. Require exact equality for the selected reference representation after decoding.
• Check every frame identifier. Detect missing, duplicate, or reordered images independently of file names.
• Exercise error handling. Report disk-full and writer errors without silently substituting preview files.
• Retain interpretation metadata. Keep units, acquisition settings, crop offsets, and processing history with the recording.
• Label derivatives clearly. Make the 8-bit video visibly distinct from the measurement archive in filenames and manifests.

Start with the camera configuration step once you know the required output format. For an existing system, send a pixel-format description, sample array details, and proposed file format through technical support before committing to a long recording.