Radiometric jpg thermal images: saving 16-bit temperature data

You captured the thermal frames through your own acquisition code, saved them as JPEG, and weeks later the temperatures are gone: every pixel is an 8-bit gray level with no way back to degrees. This guide explains what a radiometric jpg thermal image actually is — a normal-looking JPEG preview wrapped around the camera's 16-bit counts and its calibration constants — why an ordinary JPEG cannot carry that data, and the two save paths that preserve it. It is written for engineers building capture and recording pipelines around industrial thermal cameras. By the end you can pick the right file for each job, and size the link and disk that the raw stream needs.

What a radiometric jpg thermal image actually is

A radiometric jpg is not a special image codec. It is a container: a standard 8-bit JPEG preview that any viewer opens, plus a metadata block from the camera vendor that holds the real payload — the raw detector counts and the calibration constants. The counts are what the sensor measured, before any palette, rescaling or compression for display. Vendors describe the format as a JPEG with the temperature data embedded in each pixel, readable by their reporting and R&D software.

Inside the wrapper the payload is stored either as raw values or as PNG-compressed data; both carry the full counts bit-exactly. Raw values in this camera class are 16-bit integers: a frame of a scene near ambient can carry counts such as 31399 or 31436 — numbers that mean nothing as brightness and everything as temperature once the calibration is applied.

Why a plain 8-bit JPEG cannot hold temperature

The JPEG file format stores 8-bit samples: 256 levels per pixel, with lossy block compression on top. The original standard's extended profile allows 12-bit samples, but decoders for it are rare, and neither form has room for 16-bit counts. So when an image library writes a jpg from a thermal frame, it must first rescale the counts into 256 levels, and that step is where the measurement dies.

The arithmetic makes the loss concrete. Take a scene span of 100 K, say a process running between 20 and 120 °C:

• 8 bits: 100 K ÷ 256 levels = 0.39 K per level. Counts inside one 0.39 K band become indistinguishable.
• 16 bits carries 65,536 levels, and scaled raw outputs of this kind sit near 0.01-0.1 K per count.
• Ratios: 0.39 K ÷ 0.01 K = 39× finer; 0.39 K ÷ 0.1 K = 3.9× finer.

So 8-bit storage throws away a factor of 4-40 in temperature resolution before JPEG compression adds block-level loss on top. A saved jpg is a picture of the data, not the data.

From counts to temperature: what the file must carry

Counts are not temperatures. Conversion needs calibration constants, and those travel in the file's metadata. In the simple linear case:

Here m is the count scale in K per count and c the offset in K, both read from the calibration metadata. Many cameras use a nonlinear, Planck-based calibration instead, and the vendor converter applies it; either way the constants, not the software, hold the measurement. The metadata also carries the scene parameters the conversion assumes: emissivity, reflected apparent temperature, optics transmission, atmospheric transmission, distance and humidity. Change any one and the same counts convert to a different temperature — which is why they must be written at capture time, not reconstructed later. The full conversion chain is worked through in Raw thermal counts to temperature: calibration essentials.

The capture path decides what you can save

Two routes put counts into a file, and they are not equivalent.

Route 1 is the camera SDK's own capture-to-file method. Many SDKs expose a save call whose parameter selects the payload: a 16-bit jpg with the radiometric data embedded, the same counts compressed losslessly as PNG inside the wrapper, or the radiometric data alone without a preview. The camera writes counts and the calibration snapshot in one step, in its own container — exactly what its analysis software reads back. Vendors state it directly: the analysis tool reads a 16-bit file with the header embedded, and frames you grabbed yourself cannot be turned into that container afterwards.

Route 2 is grabbing frames yourself, through a frame grabber or the streaming API, into your own buffer. You hold the counts, which is all your own code needs, but there is no vendor container to write and no automatic constants snapshot. If the save call is then a generic image-library JPEG writer, you get the 8-bit loss of the previous section.

So the deliverable decides the route: if the files must open in the vendor's analysis software, design around route 1 first. If your code owns the analysis, route 2 is fully under your control — see Export high bitdepth grayscale images from thermal cameras and How to save 16-bit grayscale camera images reliably.

Worked example: sizing a 640 × 512, 50 Hz raw stream

The example sizes the stream of a current 640 × 512, 50 Hz GigE thermal camera:

Inputs, and where each comes from:

• 640 × 512 pixels and 50 Hz — the camera's printed streaming specs.
• 2 bytes per pixel — 16-bit counts, the raw width of uncooled microbolometers in this class.
• 1,000 Mb/s — the GigE line rate from the Ethernet standard, not a camera spec.

Rule in words: an uncompressed raw stream moves pixels × bytes per pixel × frames per second; the link carries it if the payload sits well under the line rate, and the disk needs payload × recording time.

Arithmetic:

• Pixels per frame: 640 × 512 = 327,680.
• Bytes per frame: 327,680 × 2 = 655,360 B = 640 KiB.
• Stream rate: 655,360 B × 50 /s = 32,768,000 B/s = 31.25 MiB/s.
• On the wire: 32,768,000 × 8 = 262,144,000 b/s ≈ 262.1 Mb/s.
• Share of the GigE line: 262.1 ÷ 1,000 = 26%, a 3.8× margin.
• Disk: 31.25 MiB/s × 60 s = 1,875 MiB = 1.83 GiB per minute.

Result: 31.25 MiB/s of raw counts, 262 Mb/s on the wire, 1.83 GiB per recorded minute.

Decision: one GigE link carries this stream uncompressed with a 3.8× margin, so no interface step-up is needed at 640 × 512 and 50 Hz. Use half the line rate, about 500 Mb/s, as the working threshold: below it, protocol overhead and retransmits stay invisible; above it, move to a faster interface or drop the frame rate. At 1.83 GiB per minute, size storage from the recording length before committing to uncompressed capture.

What sits in the metadata block

The values worth checking, because each moves the converted temperature:

• Emissivity of the measured surface.
• Reflected apparent temperature — the surround the surface sees.
• Optics transmission: a lens swap changes the calibration, which is why thermal and SWIR lens selection belongs in the calibration record, not just the mechanical design.
• Atmospheric transmission, distance and humidity.
• Camera-side values such as the calibration range and camera identity.

Tag names differ by vendor, so treat the file as the only source of truth. When you need the constants as numbers for your own conversion or an audit, read them out of the file, as covered in Thermal image metadata export: from JPEG to text.

When you must write the file yourself

If the SDK offers no radiometric save, or the frames reach you through a grabber the vendor's writer never sees, write the counts and constants yourself:

1. Take the frame as 16-bit mono — the format the camera streams — and write it to a 16-bit TIFF or a raw binary file. Do not let any library rescale it to 8 bits on the way.
2. Log the calibration constants to a sidecar (JSON or CSV) written at the same moment as the frame, one set per image, not one per session.
3. Convert to temperature in your own code from those constants, with the formula above or the vendor's published conversion.
4. Keep a palette-mapped display copy as a separate file for viewers; Save a thermal colormap TIFF for reliable viewing covers that file's mechanics.

The limit of this route is tooling: the vendor's analysis software will refuse your container, so where that software is the deliverable, route 1 is the only answer.

Which file to save for each job

Read the table by deliverable, not preference. A client who opens files in the vendor's software is served only by route 1; your own analysis code is served best by route 2; pure display stops at 8 bits and saves the storage. Size the link with the same rule — pixels × bytes × frame rate — before fixing the interface: the camera finder filters thermal models by interface, and the thermal cameras category lists the current line-up.

Three current LWIR options:

The LS-IRC-0016 is a 640 × 512 module on USB3, the LS-IRC-0026 a 0.5 MP GigE camera, and the MV-CI003-GL-N25 a 0.3 MP GigE camera with a 25 mm lens.

Checks before you commit the pipeline

• Capture one file through the SDK's save method, open it in the target analysis software, and read a spot value on something with a known temperature — ice water at 0 °C or a blackbody setpoint. A reading within about a kelvin confirms the container carries counts plus constants correctly.
• Grab the same scene through your own path and compare counts pixel-for-pixel. A mismatch means something in the chain is rescaling.
• Check the camera's wire format is set to 16-bit mono; an 8-bit stream cannot be repaired downstream — the same mechanism behind ADC bit depth vs pixel format: why 10-bit sensors ship 8-bit images.
• Confirm constants are written per image: save two files from one session with a changed emissivity between them, and each file must carry its own value.
• Size the disk from the worked example before the first long recording, and measure the PNG ratio on a ten-minute test capture, keeping the uncompressed figure as the worst case.

The cameras topic page collects the rest of the capture-and-storage guides. If you are matching a camera and SDK to a recording requirement, the camera configurator walks the choice step by step, or contact us with the requirement and we will size the link and storage with you.