Handle Linear Light and Display Encoding
A team averages two display-ready photographs and gets unexpected tones.
Read the full lesson and open its transcript below. A narrated video will be added after production.
What you will learn
A team averages two display-ready photographs and gets unexpected tones.
A practical question
The satellite team averages two photographs, but the halfway tone looks unexpectedly dark. The word average sounds simple, yet we have to ask what the stored numbers represent. Display-ready images often use nonlinear encoding. A midpoint between two encoded values is not necessarily half the physical light.
The useful idea
For an operation intended to model light, decode the values using their known color encoding, work in linear-light values, and encode the result for display. If you're averaging for a different visual effect, state that choice. Don't guess a transfer function simply because one result looks attractive on a monitor.
Work through the example
Compare a dark and a bright patch using both methods. Keep the input images identical, and note where the resulting middle tone differs. Remember that clipping and camera processing may have changed the stored pictures before you received them, so linearizing a display file does not turn it back into untouched sensor measurements. Numbers stored for display often do not increase in direct proportion to physical light. Averaging those encoded numbers can differ from averaging light itself. Decode to a linear-light representation, do the calculation there, and encode a separate viewing copy. Compare both results around a bright-dark boundary. The difference may be subtle, yet it matters when a pipeline claims to model light or combine measurements rather than merely make a preview look pleasant. Use this case to test your understanding: Decode, average corresponding light values, then encode a viewing copy. Here is the limitation to watch for: Blind arithmetic on gamma-encoded pixels can change physical and perceptual meaning. This supports a careful conclusion: Display encoding is nonlinear, so operations modeling physical light should use linear-light values. Compare an average made from display values with one made after decoding to linear light. A different middle tone is expected; keep the calculation tied to the quantity you meant to combine.
Limits and next step
Record the color profile and conversion. Next, we'll extend this care to sensors with channels beyond red, green, and blue.
Worked example
Decode, average corresponding light values, then encode a viewing copy.
Quick check: test your understanding
Try it yourself: Consider this case: Decode, average corresponding light values, then encode a viewing copy. Explain how you would check the result. In your answer, address this limitation: Blind arithmetic on gamma-encoded pixels can change physical and perceptual meaning.
Check the reasoning
Display encoding is nonlinear, so operations modeling physical light should use linear-light values. Blind arithmetic on gamma-encoded pixels can change physical and perceptual meaning.
What is the main idea behind handle linear light and display encoding?
Display encoding is nonlinear, so operations modeling physical light should use linear-light values.
How is it used in the example?
Decode, average corresponding light values, then encode a viewing copy.
What limitation should be checked?
Blind arithmetic on gamma-encoded pixels can change physical and perceptual meaning.
Further reading
Digital Image Processing, 4th edition — Rafael C. Gonzalez and Richard E. Woods.
Original ToolsInVision teaching examples. Editorial approach · Suggest a correction
Accessible referenceLesson 54 transcript327 words · Narration ready for the upcoming videoOpen transcript
The satellite team averages two photographs, but the halfway tone looks unexpectedly dark. The word average sounds simple, yet we have to ask what the stored numbers represent. Display-ready images often use nonlinear encoding. A midpoint between two encoded values is not necessarily half the physical light.
For an operation intended to model light, decode the values using their known color encoding, work in linear-light values, and encode the result for display. If you're averaging for a different visual effect, state that choice. Don't guess a transfer function simply because one result looks attractive on a monitor.
Compare a dark and a bright patch using both methods. Keep the input images identical, and note where the resulting middle tone differs. Remember that clipping and camera processing may have changed the stored pictures before you received them, so linearizing a display file does not turn it back into untouched sensor measurements. Numbers stored for display often do not increase in direct proportion to physical light. Averaging those encoded numbers can differ from averaging light itself. Decode to a linear-light representation, do the calculation there, and encode a separate viewing copy. Compare both results around a bright-dark boundary. The difference may be subtle, yet it matters when a pipeline claims to model light or combine measurements rather than merely make a preview look pleasant. Use this case to test your understanding: Decode, average corresponding light values, then encode a viewing copy. Here is the limitation to watch for: Blind arithmetic on gamma-encoded pixels can change physical and perceptual meaning. This supports a careful conclusion: Display encoding is nonlinear, so operations modeling physical light should use linear-light values. Compare an average made from display values with one made after decoding to linear light. A different middle tone is expected; keep the calculation tied to the quantity you meant to combine.
Record the color profile and conversion. Next, we'll extend this care to sensors with channels beyond red, green, and blue.