Normalized RGB Values Can Still Be Nonlinear

Separate numeric range, storage type and color encoding

An input description such as normalized float RGB leaves a consequential question unanswered: what do the channel values represent? Here range normalization means scaling unsigned channel codes to 0–1. It does not mean every operation that a software provider might call normalization.

Consider a stipulated 8-bit sRGB code of 128. Casting it to floating point represents the code as a float. Dividing it by 255 gives 128 / 255, approximately 0.501961. Neither operation applies the sRGB transfer function. A later calculation would still be using encoded components unless a separate conversion changed that representation.

This guide concerns declared sRGB components between 0 and 1, with no alpha channel or intervening gamut conversion. An RGB label alone does not establish that an image is sRGB. The source encoding must be identified before the following equations apply.

References: [C1]

The piecewise transfer is the conversion that scaling omits

The reference is W3C's CSS Color Module Level 4 Candidate Recommendation Draft dated October 20, 2026, a work in progress. Sections 10.2 and 10.3 distinguish encoded sRGB from linear-light sRGB while retaining the same primaries and D65 white point. Section 19 supplies informative sample conversions.

Let c be one encoded component in the stated nonnegative range and L its linear-light counterpart. For c <= 0.04045, L = c / 12.92. For c > 0.04045, L = ((c + 0.055) / 1.055)^2.4.

For the reverse conversion, when L <= 0.0031308, c = 12.92 × L. Above that threshold, c = 1.055 × L^(1 / 2.4) - 0.055.

These equations operate on each color component. They are not a luminance formula or a camera-calibration result. The CSS reference establishes the color representation; the selected vision application establishes its own preprocessing requirements.

References: [C1]

SRGB-2: averaging before and after decoding gives different results

Original fictional example SRGB-2 contains two equally weighted neutral samples. Their encoded RGB triplets are exactly (0, 0, 0) and (1, 1, 1). Neutral means the three channels are equal. These are continuous numerical examples, with no quantization or rounding during the calculation, rather than measured camera pixels.

Path A computes the arithmetic mean of the encoded components. Each output channel is (0 + 1) / 2 = 0.5, so the encoded output triplet is (0.5, 0.5, 0.5). Decoding one of those components gives ((0.5 + 0.055) / 1.055)^2.4, approximately 0.2140411405 in linear light.

Path B decodes each input component first. The endpoints decode to 0 and 1, so their mean is (0 + 1) / 2 = 0.5 in linear light. If this result must be returned as encoded sRGB, re-encoding gives 1.055 × 0.5^(1 / 2.4) - 0.055, approximately 0.7353569831 per channel.

At a common encoded output boundary, A therefore returns 0.5 per channel and B returns approximately 0.735357 per channel. At a common linear-light boundary, their values are approximately 0.214041 and 0.5 respectively. Moving the decoding step across the mean changes the result.

Both paths calculate an arithmetic mean in their declared representation. The power branch makes decoding and averaging noninterchangeable in this example. Nothing here selects an input for a particular model or predicts model accuracy, visual appearance or inspection quality.

References: [C1]

Keep continuous values separate from 8-bit output codes

An optional final quantization step can make the difference visible in code values. Stipulate multiplication of the final encoded component by 255 and rounding to the nearest integer, with a half rounded upward. Path A gives 0.5 × 255 = 127.5, rounded to 128. Path B gives approximately 187.516, rounded to 188.

Those integers are quantized outputs of the example. In particular, 128 / 255 is approximately 0.501961, not exactly 0.5. The earlier decoded value of approximately 0.214041 belongs to exact encoded 0.5, not to the rounded code 128. Keeping the rounding step last prevents a code-value illustration from silently changing the continuous calculation.

References: [C1]

Compare the representation at the operation and at the handoff

Suppose two fictional software offers each describe a normalized RGB average supplied as a float. Offer A uses SRGB-2's encoded-component mean. Offer B uses its linear-light-component mean. Each can report a numeric result of 0.5, yet the two reports name different quantities. A float value and its shape do not settle the comparison.

If the required handoff is an arithmetic mean in linear-light components, offer A's encoded mean does not supply it. Decoding A's final 0.5 afterward gives approximately 0.214041; it cannot substitute for averaging the decoded inputs. Offer B supplies 0.5 linear-light under the example's assumptions.

If the receiving path instead specifies the encoded-component mean, A addresses that operation. B's linear-light mean is a different transform, and re-encoding it produces approximately 0.735357 rather than A's encoded 0.5. A conversion should not be inserted merely because linear-light arithmetic sounds preferable.

A comparable proposal identifies the source color encoding, any range scaling, the representation in which the operation occurs, and the required output representation. Ask the software owner to connect those stages to the receiving model's documented input path and the implementation revision being offered. Where the word decode is used, distinguish unpacking an image file from applying the color transfer function.

That description resolves the actual purchasing question: are the offers performing the same specified transformation and supplying the same kind of input? Agreement on three channels, 0–1 range or floating-point storage alone leaves that question open.

Keep sample provenance and patch counts with their own guides

The related Bayer-versus-RGB guide explains how directly sampled filter values differ from derived RGB components. Once RGB values are supplied, the present decision concerns their numerical encoding and the arithmetic applied to them.

The related vision-transformer guide follows supplied image channels into patch embeddings and sequence positions. A patch count does not identify the transfer function of the values within those patches. Use the three guides at their respective input boundaries rather than treating sample provenance, color encoding and encoder positions as interchangeable descriptions.

Scope a physical equipment installation separately when needed

If the selected vision-computing equipment also needs receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service provides a route to discuss that physical scope. Use the related service and project inquiry with a nonconfidential equipment, site, connection and handoff outline to establish requirements and availability.

Color processing, model preprocessing and application acceptance remain with the appointed imaging and software providers.

References: [L1]