Lighting and Color Rendering Engineering: From Impressionism to Ray Tracing

1. Introduction: From “Light and Color” to Light Computation

In the late nineteenth century, a group of French painters moved their easels outdoors and directly depicted natural scenes under daylight. They later became known as the Impressionists. One of the most representative figures is Claude Monet (1840–1926), often regarded as a leading figure of Impressionism. Works such as Impression, Sunrise, Haystacks, Rouen Cathedral, and Water Lilies contain extensive explorations of light and color.

These explorations can be summarized in three points:

• Light changes: The same cathedral or haystack appears in completely different tones in the morning and at dusk, or under sunny and cloudy skies. Therefore, Impressionist painters often returned to the same position and viewpoint to record light at different times.
• Colors influence each other: The inherent color of an object is tinted by reflected light from the surrounding environment. Even shadows can contain cool skylight.
• Color comes from observation: What the human eye perceives is light, not the intrinsic color of an object.

From an engineering perspective, what painters faced was essentially a chain: scene geometry → light energy propagation → human perception → reproduction through pigments or display media. Modern game engines, visual effects, industrial visualization, virtual simulation, and image or video processing systems solve the same problem: how to realistically reconstruct lighting under limited computing power and deliver it to displays with correct color.

This article follows that chain and covers:

1. Physical and perceptual fundamentals of light and color;
2. The rendering equation and common solution methods;
3. Scene linear workspace and color management;
4. Tone mapping and display encoding;
5. Sampling, denoising, and anti-aliasing;
6. Performance budgets and image quality evaluation;
7. Engineering implementation checklists and common pitfalls.

2. Overall Framework: The Scene-to-Display Pipeline

Stage	Input	Key Processing	Output	Typical Problems
Input	Textures, models, HDR environment maps	Decoding, format conversion	Linear floating-point scene data	sRGB textures sampled without proper linear decoding
Geometry	Vertices, meshes	Transformation, clipping, rasterization or ray intersection	Visible surfaces, depth	Insufficient depth precision
Lighting	Materials, light sources, ambient light	Direct light + indirect light	HDR radiance buffer	Energy conservation errors, excessive noise
Tone mapping	HDR radiance	Exposure, compression, local contrast	[0,1] display reference encoding	Mapping in gamma space causing desaturation
Display encoding	Linear [0,1] values	sRGB/PQ/HLG encoding	8/10/12-bit frame buffer	Banding, high-saturation color shifts
Compression and transmission	Frame buffer	Chroma subsampling, transform quantization	Bitstream	Incorrect color space or matrix configuration

Each stage affects the final “color.” If any link in the chain is wrong, the final image may show color casts or banding that are difficult to localize.

3. Physical and Perceptual Foundations of Light and Color

3.1 Light and Radiometry

Visible light is electromagnetic radiation with wavelengths of approximately 380–780 nm. Light may travel directly from a source to the eye, or it may undergo multiple reflections, refractions, absorption, and scattering before reaching the eye. Therefore, the essence of rendering is to compute the radiance arriving at the camera along each viewing direction.

Common radiometric quantities include:

• Radiant flux, Φ, in watts (W): total energy emitted or transferred per unit time;
• Irradiance, E, in W/m²: power received per unit area;
• Radiance, L, in W/(m²·sr): radiant flux per unit projected area per unit solid angle along a direction;
• Solid angle, in steradians (sr): the solid angle of an entire sphere is 4π sr.

The unknown quantity in the rendering equation is radiance, L, because the response of photoreceptors in the human eye is proportional to the radiance entering the pupil. This is also the physical quantity that displays reproduce.

3.2 Spectra and Color Matching

Light reflected by an object has a continuous spectral distribution, S(λ). The human retina contains three types of cone cells, sensitive to short, medium, and long wavelengths. These responses can be approximated by three spectral response curves. They compress a continuous spectrum into three values, known as the tristimulus values in the CIE 1931 standard colorimetric system:

X = k ∫ S(λ)·x̄(λ) dλ
Y = k ∫ S(λ)·ȳ(λ) dλ
Z = k ∫ S(λ)·z̄(λ) dλ

Here, x̄, ȳ, and z̄ are the CIE 1931 2° standard observer color matching functions. Chromaticity coordinates can be derived as:

x = X / (X + Y + Z)
y = Y / (X + Y + Z)

When all monochromatic spectra are mapped into the (x, y) plane, the result is the familiar horseshoe-shaped CIE 1931 chromaticity diagram. All colors possible in nature fall within this curve and its interior. A device gamut corresponds to a triangular region inside this area. Y is directly related to luminance and is central to subsequent luminance and tone mapping calculations.

Real-time rendering cannot integrate over every wavelength. The common industrial approach is to approximate spectral operations with three RGB channels, while distinguishing usage contexts:

• Algorithmic use: lighting calculations use linear RGB;
• Storage use: textures use gamma-encoded sRGB to match the human eye’s greater sensitivity to dark tones, reducing banding in shadows at the same bit depth;
• Display use: final output is sent to an sRGB or HDR display.

This is the core meaning of “color space”: the same color has different numerical values under different primaries and transfer functions.

3.3 From Intrinsic Color to Environmental Color: Physical Reflection Models

Lighting computation must answer: given incident light, how much energy does a surface reflect in each direction? The industry uses the bidirectional reflectance distribution function, BRDF, to describe this:

f_r(ω_i → ω_o) = dL_o(ω_o) / dE_i(ω_i)

It represents the reflected radiance produced per unit incident irradiance in each direction.

The simplest model is ideal diffuse reflection, also known as the Lambert model. It assumes uniform reflection in all directions and uses a constant BRDF:

f_r = ρ / π

Here, ρ is albedo. Dividing by π satisfies energy conservation: integrating f_r·cosθ over the entire hemisphere yields exactly ρ.

Real materials commonly use the microfacet model in physically based rendering, PBR. The surface is treated as being composed of countless microfacets, and the BRDF is generally written as the product of three terms:

f_r = D(h)·F(v,h)·G(l,v,h) / [4·(n·l)·(n·v)]

• Normal distribution function D: describes the statistical distribution of microsurface normals. The GGX/Trowbridge-Reitz distribution is common; roughness controls the sharpness of highlights.
• Fresnel term F: often approximated with Schlick’s formula, F = F0 + (1 − F0)·(1 − cosθ)^5, expressing the fact that reflection becomes stronger as the viewing angle becomes more grazing.
• Geometry term G: describes mutual occlusion and self-shadowing between microfacets.

The microfacet model also explains phenomena observed by Impressionist painters:

• Surfaces contain both diffuse components that scatter in many directions and specular components that vary with viewing angle.
• Water surfaces and wet stone surfaces show significantly stronger Fresnel reflection at grazing angles.
• Outdoor shadows are not pure black. The sky acts as a huge area light, so shadows contain cool diffuse skylight, often mixed with reflected light from the ground and nearby objects.
• This is what offline rendering commonly calls “global illumination.”

3.4 Color Temperature and Atmospheric Scattering

The color of blackbody radiation depends only on temperature, measured in kelvin, K. Approximate color temperatures of common light sources are:

• Candlelight: about 1850–1900 K, with an orange-red tone;
• Direct sunlight at sunrise or sunset: about 2000–3000 K;
• Midday daylight: about 5500–5800 K;
• Overcast or cloudy sky light: about 6500–7500 K, cooler in tone;
• Pure skylight on a clear day can reach 8000–10000 K or even higher, with an obvious blue cast.

The D65 reference white point in sRGB corresponds to daylight of approximately 6504 K.

Atmospheric scattering is mainly divided into two types:

• Rayleigh scattering: scattering intensity is approximately inversely proportional to the fourth power of wavelength, roughly ∝ 1/λ⁴. Short-wavelength blue and violet light is scattered much more than long-wavelength red light, which is why a clear sky appears blue.
• Mie scattering: produced by particles such as aerosols and water vapor whose sizes are comparable to the wavelength. It is less wavelength-dependent and is associated with the milky white appearance of fog and haze.

When the sun is near the horizon, sunlight must pass through a longer atmospheric path. Blue light is scattered away substantially, leaving direct sunlight dominated by red and orange components. The entire sky acts as a huge light source covering the dome. This is why outdoor rendering often simulates the sun with a directional or parallel light and simulates the sky with an environment map or an analytic sky model.

3.5 Human Perception and the Weber-Fechner Law

Human perception of brightness approximately follows the Weber-Fechner law: a geometric increase in stimulus corresponds to an arithmetic increase in perceived intensity. In other words, the human eye can distinguish finer brightness differences in dark regions.

Three engineering conclusions follow:

• 8-bit linear encoding wastes many code values in bright areas and causes visible banding in shadows. Therefore, a transfer function with an approximate 2.2 power curve is needed to redistribute code values.
• Tone mapping should simulate the human eye’s compression of highlights: bright areas should gradually approach pure white without harsh clipping.
• Image quality evaluation should use perceptual metrics rather than purely numerical error metrics.

4. Rendering Equation and Common Solution Methods

4.1 The Rendering Equation

The rendering equation proposed by Kajiya in 1986 is the theoretical foundation of global illumination. In its general form, it unifies all types of scattering, including diffuse reflection, specular reflection, and refraction:

L_o(x, ω_o) = L_e(x, ω_o) + ∫Ω f_r(x, ω_i, ω_o)·L_i(x, ω_i)·(ω_i·n) dω_i

• L_o: radiance leaving surface point x in direction ω_o;
• L_e: radiance emitted by the point itself, such as an emissive material;
• f_r: BRDF;
• L_i: radiance incident from direction ω_i;
• n: surface normal; (ω_i·n) is the cosine of the angle between the incident direction and the normal, representing the geometric term;
• Ω: the hemisphere centered on the normal.

The equation is difficult to solve because L_i itself depends on outgoing radiance from other surfaces, creating recursive mutual dependence. The integration domain covers the entire hemisphere, including both direct and indirect light in the scene. Except for a few idealized cases, there is no analytical solution, so engineering solutions must be numerical. Common methods include:

Method	Principle	Advantages	Limitations
Path tracing	Random ray bouncing from the camera with Monte Carlo estimation	Physically accurate; handles complex materials well	Noisy and computationally expensive
Bidirectional / photon mapping methods	Trace photons from lights and rays from the camera	Good for indirect light and caustics	Complex implementation; may introduce bias
Irradiance probes / volumes	Precompute indirect lighting and interpolate it	Low cost; stable indirect lighting	Loss of detail; difficult for dynamic scenes
Irradiance maps / lightmaps	Bake static lighting into textures	Near-zero runtime cost	Only suitable for static scenes
Screen-space approximations	Reuse existing screen buffers to estimate reflection and occlusion	Low cost	Missing off-screen information; unstable results
Real-time ray tracing	Use hardware-accelerated structures for ray intersection	Balances real-time performance with global effects	Limited per-frame budget; requires denoising

Three practical points are widely accepted:

• Direct light: Light traveling directly from a source to a visible point usually involves a single bounce. It is suitable for explicit sampling and has low variance.
• Indirect light: Light arriving after multiple bounces is the main source of noise.
• Importance sampling: Sampling directions should be chosen according to material properties rather than uniformly over the entire hemisphere.

4.2 Monte Carlo Integration and Importance Sampling

The hemisphere integral in the rendering equation is commonly estimated using Monte Carlo methods: sample directions ω_k within the hemisphere and estimate the integral by averaging the product of BRDF and geometric terms divided by the sampling probability density.

∫Ω g(ω) dω ≈ (1/N)·Σ g(ω_k) / p(ω_k)

Here, p(ω) is the probability density function of the sampled directions.

For a Lambertian material, cosine-weighted sampling is proportional to cosθ:

p(ω) = cosθ / π

Substituting into the estimator:

f_r·L_i·cosθ / p(ω) = (ρ/π)·L_i·cosθ / (cosθ/π) = ρ·L_i

Cosine-weighted sampling naturally cancels the 1/π in f_r and the geometric cosine term. This significantly reduces variance and simplifies per-sample computation. For specular materials, importance sampling should be performed around the reflection direction. For area lights and the solar disk, light sampling can be used, directly sampling the light source area rather than uniformly sampling the hemisphere.

The standard deviation of a Monte Carlo estimator decreases proportionally to the inverse square root of the number of samples. To halve noise, the number of samples must increase by a factor of four. Common practical strategies are therefore:

• Use a moderate number of samples to control the noise floor;
• Use denoisers and spatiotemporal reuse to handle residual noise;
• Avoid simply increasing samples per pixel without limit.

Illustrative code:

#include <cmath>
#include <random>
struct Vec3 {
    float x, y, z;
};
// Cosine-weighted hemisphere sampling in local space; returned vector is normalized
Vec3 sampleCosineHemisphere(float u1, float u2) {
    float r = std::sqrt(u1);                       // radius distribution ensures area uniformity
    float phi = 2.0f * 3.14159265f * u2;
    return Vec3{r * std::cosf(phi),                  // local x axis
                r * std::sinf(phi),                  // local y axis
                std::sqrt(std::max(0.0f, 1.0f - u1))}; // local z axis, aligned with the normal
}
// Build a local coordinate system with normal as the z axis (illustrative; production code must handle degenerate cases)
void buildBasis(const Vec3& normal, Vec3& tangent, Vec3& bitangent) {
    Vec3 up = (std::fabs(normal.z) < 0.999f) ? Vec3{0, 0, 1} : Vec3{1, 0, 0};
    tangent = Vec3{up.y * normal.z - up.z * normal.y,
                   up.z * normal.x - up.x * normal.z,
                   up.x * normal.y - up.y * normal.x};   // up × normal
    // Normalize tangent
    float len = std::sqrt(tangent.x * tangent.x + tangent.y * tangent.y + tangent.z * tangent.z);
    tangent = Vec3{tangent.x / len, tangent.y / len, tangent.z / len};
    bitangent = Vec3{normal.y * tangent.z - normal.z * tangent.y,
                     normal.z * tangent.x - normal.x * tangent.z,
                     normal.x * tangent.y - normal.y * tangent.x}; // normal × tangent
}
// For cosine-weighted sampling, BRDF * cosθ / pdf equals albedo exactly
Vec3 cosineSampledDiffuseRadiance(const Vec3& albedo, const Vec3& Li) {
    return Vec3{albedo.x * Li.x, albedo.y * Li.y, albedo.z * Li.z};
}
// Direct lighting estimate in path tracing (illustrative)
Vec3 estimateDirectLighting(const Vec3& albedo, const Vec3& radianceFromLight, int N,
                            std::mt19937& rng) {
    std::uniform_real_distribution<float> dist(0.0f, 1.0f);
    Vec3 sum{0, 0, 0};
    for (int i = 0; i < N; ++i) {
        Vec3 local = sampleCosineHemisphere(dist(rng), dist(rng));
        // Here, local must also be transformed into world space with the normal as the z axis,
        // and a shadow ray should be tested for occlusion between the shading point and the light.
        (void)local;
        Vec3 contrib = cosineSampledDiffuseRadiance(albedo, radianceFromLight);
        sum = Vec3{sum.x + contrib.x, sum.y + contrib.y, sum.z + contrib.z};
    }
    return Vec3{sum.x / N, sum.y / N, sum.z / N};
}

This is CPU-side illustrative code used to explain the sampling idea. In real projects, it is usually implemented in shaders or compute kernels, with the number of samples controlled according to the frame budget.

5. Scene Linear Workspace and Color Management

5.1 Why Computations Must Be Performed in Linear Space

Light accumulation, material reflection, and Fresnel effects all follow linear physical laws. If sRGB-encoded values are treated as linear values and used directly in lighting calculations, significant errors occur.

For example, averaging color values in encoded space can bias the result toward the brighter side. Averaging 0.1 and 0.9 directly in sRGB space gives 0.5. If the values are first decoded to linear space, 0.1 corresponds to approximately 0.010 and 0.9 corresponds to approximately 0.787. Their average is approximately 0.399, which encodes back to approximately 0.665 in sRGB.

This issue appears in lighting and texture blending, blurring, and translucent composition. Common symptoms include blends that appear washed out or dark areas being lifted when emissive elements are combined.

5.2 The sRGB Transfer Function

sRGB encoding is defined by IEC 61966-2-1 and consists of a linear segment and a power-law segment. The decoding EOTF is:

V ≤ 0.04045 :  L = V / 12.92
V > 0.04045 :  L = ((V + 0.055) / 1.055)^2.4

The encoding OETF is:

L ≤ 0.0031308 : V = 12.92·L
L > 0.0031308 : V = 1.055·L^(1/2.4) − 0.055

The threshold 0.04045 is the encoded value of the linear-segment endpoint 0.0031308. The two segments are continuous and have the same slope at the endpoint.

Illustrative code:

// GLSL illustration: sRGB decode/encode per channel
float srgbToLinear(float c) {
    return (c <= 0.04045) ? (c / 12.92)
                          : pow((c + 0.055) / 1.055, 2.4);
}
float linearToSrgb(float c) {
    return (c <= 0.0031308) ? (12.92 * c)
                            : (1.055 * pow(c, 1.0 / 2.4) - 0.055);
}

Most graphics APIs support sRGB render targets and textures. Hardware can automatically decode during sampling and encode during writing, which is the recommended approach. When performing conversions manually, process each channel separately; do not apply the power function to an entire RGB vector at once.

5.3 A Unified Color Management Workflow

A recommended color management workflow consists of three stages:

• Input: Color textures, such as albedo, should be tagged as sRGB or another specific color space and decoded to linear space during sampling. Data textures such as normals, roughness, and metallic values should be read as linear data and must not be decoded.
• Intermediate: All lighting, blending, and blur calculations should be performed in linear floating-point buffers. Intermediate results should use at least 16-bit half-precision floating point; HDR scenes should preferably use floating-point formats.
• Output: Exposure and tone mapping should be applied first, followed by encoding into the target display color space.

Illustrative code:

// Post-processing illustration: exposure → tone mapping → sRGB encoding → dithering
uniform sampler2D uHdrColor;      // scene linear HDR buffer
uniform vec2  uTexelSize;
uniform float uExposure;
uniform float uWhitePoint;        // normalized white point, e.g. 1.0–4.0
out vec4 fragColor;
void main() {
    vec3 hdr = texture(uHdrColor, gl_FragCoord.xy * uTexelSize).rgb;
    vec3 x = max(vec3(0.0), hdr * uExposure);
    // Extended Reinhard operator: normalize to the white point, then compress
    vec3 mapped = x * (1.0 + x / (uWhitePoint * uWhitePoint)) / (1.0 + x);
    mapped = clamp(mapped, 0.0, 1.0);
    // Encode to sRGB
    vec3 srgb = mix(mapped * 12.92,
                    1.055 * pow(mapped, vec3(1.0 / 2.4)) - 0.055,
                    step(vec3(0.0031308), mapped));
    // Add dithering to suppress banding in 8-bit output
    float dither = fract(sin(dot(gl_FragCoord.xy, vec2(12.9898, 78.233))) * 43758.5453);
    fragColor = vec4(srgb + (dither - 0.5) / 255.0, 1.0);
}

5.4 Gamut Conversion and Color Adaptation

When moving from narrow-gamut displays, such as sRGB monitors, to wide-gamut displays covering nearly the BT.2020 gamut, common approaches are:

• If the content is authored in a narrow gamut, perform gamut expansion on wide-gamut devices.
• If the content is authored in a wide gamut, perform gamut compression, also known as gamut mapping, before displaying it on narrow-gamut devices. Otherwise, highly saturated colors outside the display gamut may be clipped directly, causing hue shifts and loss of detail.

Practical recommendations:

• Clearly specify the authoring gamut and reference white point of assets.
• During rendering and compositing, use a display-independent reference space, such as CIE XYZ or linear BT.2020.
• Perform one explicit conversion for the target device at output time.

In industrial visualization and virtual simulation, input assets often come from different sources, and missing or inconsistent color space annotations are a common cause of “colors not matching.”

6. Tone Mapping and Display Encoding

6.1 Why Tone Mapping Is Needed

The dynamic range of real-world scenes is extremely large:

• Moonlight scenes are around 0.001 cd/m²;
• Typical indoor scenes are around 100 cd/m²;
• Overcast outdoor scenes are around several thousand cd/m²;
• Scenes under direct midday sunlight can reach tens of thousands or even hundreds of thousands of cd/m².

SDR displays typically peak at several hundred cd/m², and encoded values can only represent the range [0,1]. Tone mapping compresses high-dynamic-range radiance into a displayable range while preserving as much tonal and color relationship as possible.

6.2 Common Operators

• Global operators use the same mapping curve for all pixels in a frame. They are fast and stable and are the mainstream choice in real-time rendering.
• Local operators adapt based on local pixel brightness. They preserve detail better but may introduce artifacts such as halos and are computationally expensive.
• Perceptually driven operators perform compression on a luminance metric that more closely matches human visual response.

Classic global operators include:

• Reinhard, simple form: L_d = L / (1 + L). It is simple and smooth but reduces saturation overall and can make high-dynamic-range scenes look gray.
• Extended Reinhard: L_d = L·(1 + L/L_white²) / (1 + L). It introduces a white point parameter, allowing highlights to extend toward white.
• Fractal or polynomial fitted curves: A common industry approach is to use polynomial fits to approximate film response characteristics, with both input and output expressed in sRGB-encoded values. These curves have smooth shoulder transitions and are less likely to produce hue shifts in saturated highlights.

An easily overlooked detail is that tone mapping should be performed in linear space, followed by unified encoding. If compression is applied directly in gamma space, different channels are compressed differently, which can cause highlight desaturation or hue shifts. For example, a bright pure red highlight such as (10, 0, 0) may become pink or orange after channel-independent compression in a non-linear space.

6.3 Exposure, White Balance, and Color Grading

A complete post-processing chain usually includes more than tone mapping:

• Automatic exposure: Estimate an appropriate exposure value from average scene brightness or histogram information. Temporal smoothing can be used to avoid brightness jumps.
• White balance: Estimate the light source color temperature and compensate for ambient color casts, such as correcting 7000 K cool light toward neutral.
• Color grading: Similar to film color grading, adjust shadows, midtones, and highlights separately to create a unified visual style.
• Local contrast enhancement: Improve detail visibility, but avoid excessive sharpening.

These steps must also be performed in the correct color space.

7. Sampling, Denoising, and Anti-Aliasing

7.1 Sources of Aliasing and Countermeasures

Aliasing is essentially caused by insufficient sampling frequency, which produces aliasing in high-frequency signals. It can be divided into several types:

• Geometric aliasing: Incomplete pixel coverage at object edges.
• Shading aliasing: Rapid subpixel changes in highlights or specular reflections.
• Temporal flickering: Changing sampling patterns across frames during camera or object motion, causing shimmer.

Common countermeasures:

Method	Principle	Advantages	Limitations
Supersampling, SSAA	Render at a higher resolution and downsample	Effective for all aliasing types	High fill-rate cost
Multisampling, MSAA	Multiple coverage samples per pixel; shading once per pixel	Good for geometric edges; moderate cost	Ineffective for shading aliasing such as highlights
Post-process anti-aliasing	Detect and smooth edges in the final image	Low cost	May blur detail
Temporal anti-aliasing, TAA	Reproject historical frames and accumulate samples	Good cost-performance balance; also helps with temporal noise	May cause ghosting and detail blur
Temporal accumulation upscaling	Reconstruct a higher-resolution image from accumulated samples	Balances resolution and sample count	Depends on accurate motion vectors; prone to artifacts

Two engineering suggestions:

• Translucent materials do not follow the normal MSAA path and require a separate transparency anti-aliasing solution.
• Subpixel flickering in specular highlights can be reduced by increasing effective roughness based on the rate of normal change. This widens the BRDF distribution before sampling, making the integrated highlight smoother.

7.2 Noise in Ray Tracing and Spatio-Temporal Denoising

Noise in path tracing mainly comes from three sources:

• Direct lighting sampling;
• Indirect bounce paths;
• Light sampling.

A mainstream real-time approach is “few samples + spatio-temporal denoising”:

1. Temporal accumulation: Reproject the current frame into the previous accumulated buffer. The correspondence between frames is determined by motion vectors. Neighborhood clipping removes outliers in historical samples to avoid ghosting.
2. Spatial filtering: Filter noisy pixels using neighboring pixels, assisted by albedo, normal, and depth buffers to judge pixel similarity and avoid cross-edge blurring.
3. Temporal weighting: Adjust the filter radius based on the effective number of samples. More historical data allows more reduction of spatial filtering.

More advanced methods perform importance resampling across space and time, reusing illumination samples found by neighboring pixels and historical frames to improve the information utilization of each ray.

7.3 Dynamic Resolution and Frame Rate Stability

When scene load fluctuates, rendering resolution can be adjusted dynamically within the target frame time:

• Fixed budget: Preset rendering resolution levels, lower the level when frame time exceeds a limit, and raise it when frame time is below a threshold.
• Closed-loop control: Adjust based on frame-time feedback, with smoothing to avoid abrupt resolution changes.
• Combine with upscaling: Low-resolution rendering plus temporal upscaling can restore detail with relatively small quality loss.

A key principle is that upscaling must maintain a consistent order relative to TAA, motion vectors, and tone mapping. If motion vectors are computed in the wrong space, reprojection will be misaligned, causing ghosting or flickering.

8. Performance Budget and Image Quality Evaluation

8.1 Frame Time Budget

Common target frame rates correspond to the following single-frame budgets:

• 30 FPS: about 33.3 ms;
• 60 FPS: about 16.7 ms;
• 90 FPS: about 11.1 ms;
• 120 FPS: about 8.3 ms.

In interactive scenarios such as VR, cloud gaming, and cloud rendering, this budget must cover rendering, encoding, and network round-trip time. Therefore, the pipeline should reserve margin rather than allocating the entire budget to image quality.

It is recommended to build performance profiling views by stage and record:

• GPU time;
• Copy and bandwidth usage;
• Encoding time;
• Network latency.

First identify the bottleneck stage, then decide the optimization direction.

8.2 Common Optimization Techniques

• Geometry: Frustum culling, occlusion culling, LOD, mesh instancing, GPU-driven indirect drawing.
• Shading: Reduce branches and dynamic loops, reduce instruction count, and merge materials to reduce pipeline state changes.
• Bandwidth: Texture compression, reasonable mipmap usage, G-buffer compression in deferred rendering, and lower-bandwidth formats where possible.
• Parallelism: Run work independent of the main rendering queue, such as physics and post-processing, in parallel with the graphics queue.
• Sampling: Allocate sampling budget by importance, for example increasing samples only in high-frequency regions.

8.3 Image Quality Evaluation

Relying solely on numerical metrics such as PSNR and MSE is not reliable enough. Two images with very small numerical differences may look significantly different to the human eye. Conversely, a denoised image may have a relatively large numerical error but look better perceptually.

Common evaluation dimensions include:

Dimension	Method	Main Concern
Fidelity	Full-reference metrics such as PSNR and SSIM	Inconsistent with perception; does not reflect temporal stability
Perceptual difference	Visual-model-based difference metrics	Complex implementation; sensitive to parameters
No-reference quality	Scores based on natural image statistics	Requires calibration for content type
Temporal stability	Frame-by-frame differencing, flicker energy statistics	Lack of unified public standards; custom benchmarks are needed

Engineering practice usually uses both objective metrics and subjective evaluation:

• Regression testing: Render benchmark sequences with fixed seeds and camera paths, save reference frames, and automatically compare after rendering pipeline changes. Set thresholds and trigger alerts when exceeded.
• Subjective evaluation: Conduct blind tests on target display devices, covering highlights, shadows, skin tones, sky gradients, and other typical scenes.
• Temporal stability: Analyze frame-to-frame brightness fluctuations to locate flicker regions.

9. Engineering Checklist and Common Pitfalls

9.1 Implementation Checklist

• Color space tagging: Every texture and render target should have an explicit color space. Color data is decoded; data textures are not decoded.
• Linear computation: Lighting, blending, and blur must be performed in linear space.
• Floating-point buffers: HDR pipelines should use at least 16-bit floating point to avoid intermediate truncation.
• Exposure and tone mapping: Apply exposure first, then tone mapping, then encoding. The order should be fixed and configurable.
• Output format: Choose SDR or HDR output according to device capabilities. HDR output must correctly pass metadata such as MaxCLL and MaxFALL so the terminal can match brightness.
• Compression chain: Video encoding color space, transfer function, and matrix coefficients must be configured correctly to avoid color shifts.
• Automated testing: Establish benchmark frame comparison and performance baselines, and make changes traceable.

9.2 Common Pitfalls

Symptom	Possible Cause	Investigation Direction
Overall image appears gray with low contrast	Lighting or blending performed in gamma space; tone mapping without white-point normalization	Check buffer formats and sampling decoding
Banding in sky gradients	8-bit output without dithering; insufficient intermediate precision	Use floating-point intermediate buffers and output dithering
Highlight hue shift or whitening	Tone mapping performed in encoded space	Compress in linear space first, then encode
Highly saturated red appears orange on a narrow-gamut display	No gamut compression	Add a gamut mapping step
Loss of shadow detail or visible noise	Insufficient sampling; excessive denoising; insufficient exposure	Analyze the noise floor and adjust sampling and filter strength
Ghosting on moving objects	Incorrect or missing motion vectors; insufficient historical sample clipping	Check velocity buffers and reprojection logic
Video stream colors differ from the source	Incorrect encoding matrix, color space, or bit-depth configuration	Verify color description metadata
Large frame-rate fluctuations on mobile	Limited bandwidth and fill rate; overly long post-processing chain	Lower resolution, compress G-buffer, and simplify post-processing

10. Rendering and Image Quality Pipelines in the Cloud

Cloud rendering and pixel streaming move rendering workloads from local terminals to the cloud and then transmit the resulting frames to end devices. A layered design approach is useful:

• Compute layer: Use elastic cloud hosts or bare-metal services with GPU rendering and hardware encoding, scaled according to task demand.
• Storage layer: Store models, textures, and intermediate results in object storage, and use a content delivery network, CDN, to accelerate asset distribution.
• Task layer: Use message queues to asynchronously queue and distribute rendering tasks. This is suitable for offline rendering, batch transcoding, and replay generation.
• Scheduling layer: Use container platforms to orchestrate rendering nodes and ensure reproducible images and dependencies.
• Operations layer: Use logging and monitoring/alerting services to collect metrics such as frame time, dropped frame rate, encoding latency, and terminal decode success rate, with automatic alerts for anomalies.

If deploying this architecture on Baidu AI Cloud, the relevant general cloud and AI infrastructure capabilities may be referenced:

• Elastic compute: Baidu Baige AI Heterogeneous Computing Platform, suitable for model training, inference, and rendering workloads;
• Object storage: Baidu Object Storage BOS, used for assets and intermediate results;
• Delivery acceleration: Baidu AI Cloud CDN, used for frame and asset acceleration;
• Monitoring and alerting: Cloud Monitoring BCM, used for performance metric collection and alerting.

Specific specifications and billing are subject to the official documentation. Architecture design should focus on three types of cost:

• Compute cost: Determined by resolution, sample count, and target frame rate.
• Bandwidth cost: Determined by encoding bitrate and the number of concurrent sessions.
• Latency cost: Determined by network round-trip time, which limits interactivity.

11. Conclusion: From “Impression” to Measurable Image Quality

Returning to the question raised by the Impressionist painters: light changes, and color changes with light. Modern engineering practice decomposes this observation into computable, measurable, and reproducible steps:

1. Correctly model light propagation and surface reflection at the physical level;
2. Perform all lighting computations in linear space;
3. Use exposure, tone mapping, and display encoding to map wide dynamic range to the target display device;
4. Use sampling and denoising to control noise;
5. Use perceptual metrics and benchmark testing to prevent quality regression.

For developers, the key is not to pursue a single “most advanced” technique, but to understand the physical and perceptual principles behind each step and make reasonable trade-offs among quality, performance, and cost.

A useful diagnostic principle is: whenever a color anomaly appears in the image, first determine which stage of the pipeline it occurs in—input decoding, lighting computation, tone mapping, display encoding, or compression and transmission. Most “color problems” are caused by incorrect use of color space, not by insufficiently advanced algorithms.