16-bit depth map test: verify the precision, not the label

A PNG stores a bit depth in its IHDR chunk. Sixteen-bit grayscale means each pixel uses 16 bits, with values from 0 to 65,535. That is a statement about the container, not about the information inside it. If the image was created from an 8-bit source, the values still land on 256 steps even though the file has more room.

The honest question is not whether the file is 16-bit but whether it carries more than 256 meaningful levels. A true 16-bit encode from a float field can. A compatibility container derived from an 8-bit preview cannot.

Open the PNG in a tool that reports the IHDR bit depth and color type. A 16-bit grayscale file has bit depth 16 and color type 0. A 16-bit RGB file has color type 2 or 6. If the header says 8, the file is 8-bit regardless of the extension or the marketing copy.

Header inspection is necessary but not sufficient. A 16-bit container can still be filled with 8-bit values. Look at the histogram and the unique value count. If the values are all multiples of 257 (the mapping from 0-255 to 0-65535), the file was upconverted.

A depth map often uses only part of the available range. If the minimum and maximum are close together, the relief will look flat even at 16-bit. Remap the black and white points before judging the precision. A 16-bit file with a narrow range is not more useful than an 8-bit file with a full range.

For a smooth gradient on a large print or a long laser pass, the extra levels can reduce banding. For a small relief with a shallow depth, the material and the machine may not resolve 65,536 steps. Precision that the process cannot use is not a benefit.

Watch for clipping at both ends. If a large block of pixels is exactly 0 or exactly 65535, the range has been clipped and those areas no longer carry height. Clipping the background can be harmless if the background is intentionally flat; clipping the face is not. Inspect the histogram before and after remapping, and keep the original float field so a later revision can recover the lost range.

The best source is a floating-point depth field from the model. The encoder normalizes it, applies the recorded adjustments, and writes 16-bit values. The production manifest should record the source minimum, maximum, finite pixel count, and the fact that the PNG was encoded from raw float.

A preview-derived 16-bit file is still useful for compatibility, but it should be labelled. DepthCarve labels the free compatibility container honestly and reserves the true 16-bit pair for the approved production bundle, so the claim and the file match.

A 16-bit file is only useful if the next tool reads it as 16-bit. Many viewers and some slicers downsample to 8-bit on import. Check the import behavior and the actual levels in the receiving program. If the software displays 8-bit output, the extra precision is lost at the door.

For CNC, the controller and the CAM software may quantize depth steps anyway. For laser, the material response may dominate the tonal resolution. For 3D printing, the layer height limits the thickness resolution. Match the file precision to the process, not to the spec sheet.

A practical resolution test uses a stepped wedge: a series of known height steps that the process should reproduce. Print, carve, or engrave the wedge at the final settings, then measure which steps remain distinct. That result tells you the useful bit depth of the whole chain, not just the file. If the process resolves only 32 steps, a 16-bit source is not the bottleneck.

Read the IHDR bit depth and color type. Count the unique values in the image. Check whether the values are multiples of 257. Measure the minimum and maximum. Import the file into the target program and inspect the levels there. If any step fails, the file is not delivering the precision it claims.

Record the source, the encoder, the bit depth, and the import result with the job. That record is what makes a precision claim reproducible.

Keep a small verification set: one gradient, one stepped wedge, and one real subject. Re-run the set when the encoder, the model, or the downstream software changes. A verification that only ran once is a memory, not a test. Store the verification image and the measured result together so the next run compares numbers rather than impressions. If the set has no stepped wedge, add one; a gradient alone cannot show which steps were lost.