White hot
The default, and the one to train on. Warm is bright, which matches how almost every published thermal dataset is encoded.
Most things called thermal in a rendering tool are a colour filter: desaturate, lift the contrast, add a glow. That cannot make a cold body bright, because a colour transform never learns which pixels are a body. This is a temperature field instead, built from what the capture already knows about the scene, and it behaves the way a real camera does in the one respect that matters most.
On a hot afternoon, paving stone in full sun runs well above air temperature and a clothed person does not. A thermal camera shows the person darker than the ground they are standing on. After dark the stone has given up its heat, the person has not, and the same person is the brightest thing in the frame.
That reversal is the whole test. A filter applied to a photograph cannot produce it, because the photograph does not change. Here it falls out of holding a person near 33 C while the environment moves around them.

Three things every capture already writes. The identity buffer says which object owns each pixel, so a person can be given a body temperature and a vehicle a warm bonnet. The depth buffer says how far away that pixel is, so contrast decays with distance and the sky is told apart from a surface. The rendered image stands in for how much sun a background surface caught, which is a fair proxy in daylight and a poor one after dark, where a flat ambient is the honest choice instead.
| Modelled | How |
|---|---|
| Class temperature | A clothed person at 33 C, not 37: the camera sees the coat |
| Ambient coupling | Vehicles and bicycles float relative to air temperature |
| Atmospheric attenuation | Contrast decays with distance toward ambient |
| Radiative cooling | Surfaces that see open sky drop below sheltered ones |
| Sensor noise | A noise-equivalent temperature difference, in the 40 to 60 mK a real core quotes |
Two decisions were made for reproducibility rather than for looks. The display range is computed once per run and then fixed, because a real core re-ranges every frame and reproducing that faithfully makes a wall change shade the moment a warm object leaves the picture. And per-object variation is derived from each object’s identity rather than drawn from a generator, so two renders of one capture put the same degrees in the same places.
It is a class temperature table with atmospheric attenuation. It is not radiometric transport, and a corpus built from it will not teach a model the things below. They are listed here rather than discovered later, and the same list ships in a manifest beside the frames so somebody who downloads the images learns it without reading this page.
| Physics | Status | What a real core would show |
|---|---|---|
| Emissivity per material | Not modelled | polished metal reads far colder than its true temperature |
| Reflected sky and sun glint | Not modelled | a real core sees cold sky mirrored in glass and water |
| Spectral response | Not modelled | long-wave and mid-wave cores see different scenes |
| Thermal history | Not modelled | a car parked an hour ago is not a car parked a minute ago |
| Lens and sensor drift | Not modelled | an uncooled core warms up and its offset moves with it |
The practical consequence: this is strong for geometry, occlusion, framing and the labels that go with them, and weak as a substitute for radiometric truth. If you are training a detector to find warm bodies in terrain, it is useful. If you are calibrating against absolute temperature, it is not.

The default, and the one to train on. Warm is bright, which matches how almost every published thermal dataset is encoded.
The same field inverted. Some operators prefer it for people against vegetation, and a model trained on one and shown the other will fail, which is worth knowing before you mix them.
Cold blue through magenta to white. It reads better to a human than either grey scale and is the wrong choice for training, because it spends three channels encoding one number.
