Fred Miranda
Offline
Admin
Upload & Sell: On
|
 p.3 #10 · From Cobalt, Leica M vs world. | |
Raamiel wrote:
@RustyBug@
Thank you for the thoughtful response. I agree that examining performance under different illuminants is valuable. However, three different things are being treated as interchangeable here: **consistency between white-balance numbers, colourimetric accuracy, and the sensor’s spectral response.**
They are not equivalent, and distinguishing them resolves the apparent contradiction between Overgaard’s table and our measurements.
The article also contains several technical and scientific inaccuracies, particularly concerning blackbody radiation, colour temperature, and Tint. I have included a technical summary below, but first I would like to address the software architecture and explain how our sensor measurements actually work.
1. What does “6500 K in the camera = 6500 K in the software” demonstrate?
It demonstrates agreement between two numerical representations of white balance. **By itself, it does not demonstrate the accuracy of the reproduced colours.**
A camera’s manual Kelvin setting is not an independent measurement of the light. In the DNG architecture, the selected white balance can be encoded as a camera-neutral coordinate, rather than simply as a Kelvin number that every application must reproduce unchanged. The converter interprets this coordinate through its camera characterisation.
This is particularly important in Lightroom and Camera Raw, where the relationship between camera-neutral values and Temperature/Tint depends on the camera profile.
Adobe’s own DNG Profile Editor documentation states:
> “The mapping of camera neutral values to white balance settings (i.e., temperature/tint values) depends on the camera profile.”
The ColorMatrix data are part of that mapping. Schematically, using the notation of the DNG specification:
XYZtoCamera = AnalogBalance * CameraCalibration * ColorMatrix
White_XYZ = inverse(XYZtoCamera) * CameraNeutral
White_XYZ -> white-point chromaticity -> Temperature and Tint
Here, AnalogBalance is represented as a diagonal matrix. For multiple-illuminant profiles, the relevant matrices are interpolated, and deriving the white-point chromaticity from camera-neutral coordinates generally requires an iterative solution. This process is explicitly described in Adobe’s DNG specification.
Consequently, **the same RAW file, with the same camera-neutral values, can receive different Temperature/Tint values when interpreted through profiles with different underlying colour matrices or white-balance calibration.** The camera, the exposure, and the physical illumination have not changed; the model interpreting them has changed.
This does not mean that every profile selection necessarily changes the readout. Profiles can share the same underlying matrices while differing in their colour-rendering tables. Changing a creative look is not necessarily changing the white-balance characterisation. Adobe’s documentation distinguishes these profile components and their functions.
Overgaard’s categorical statement that the Lightroom colour profile does not influence the Kelvin/Tint output therefore cannot be accepted as a general description of the system.
The temperature value is intended to relate to colour temperature; it is not meaningless. But **a profile-dependent estimate is not an independent physical reference against which the camera can automatically be judged.**
A matching number can coexist with colour errors. A different number can coexist with an accurate neutral balance and accurate colour reproduction. To establish accuracy, we need an independent reference and a defined comparison—not just matching labels in two interfaces.
That is also why I would not define Spectre’s accuracy as its ability to reproduce the manufacturer’s Kelvin numbering. The relevant question is how accurately it reconstructs colour under specified conditions.
2. Our sensor characterisation does not begin by photographing something under D50 or A
There is a misunderstanding about how the spectral measurements are obtained.
We use a monochromator to scan the visible spectrum in **10 nm steps**. The light source feeding the monochromator is simply a source of radiation. The monochromator selects a narrow wavelength band, and that selected band illuminates the sensor.
At each step, the sensor produces a hardware RGB response:
lambda_1 -> R_1, G_1, B_1
lambda_2 -> R_2, G_2, B_2
lambda_3 -> R_3, G_3, B_3
An ideal monochromatic sample would be a spectral spike at one wavelength. A real monochromator produces a narrow band with finite bandwidth; the 10 nm sampling interval and the instrument’s bandwidth are distinct quantities.
In a chromaticity diagram, ideal monochromatic stimuli lie on the **spectral locus**, the monochromatic boundary of the diagram. This is not the Planckian locus, which describes blackbody chromaticities. We are therefore not restricting the measurement to a succession of warmer or cooler whites: we are probing the sensor wavelength by wavelength.
There is an important radiometric qualification: the RGB outputs must be related to the radiant exposure delivered at each wavelength. Otherwise, the measured curves would mix the sensor’s sensitivity with the lamp spectrum and the monochromator’s transmission.
Conceptually:
s_R(lambda_i) ~= (R_i - R_dark) / H_i
s_G(lambda_i) ~= (G_i - G_dark) / H_i
s_B(lambda_i) ~= (B_i - B_dark) / H_i
Here, `H_i` is the incident radiant exposure for that wavelength band, with the acquisition gain accounted for. Spectral responsivity is, by definition, detector output relative to the incident radiation—not simply the unnormalised output at each wavelength. NIST uses monochromator-based measurements for precisely this kind of detector characterisation.
Collecting the measurements gives the three spectral sensitivity functions, or SSFs:
s_R(lambda)
s_G(lambda)
s_B(lambda)
From these functions, the sensor response to a specified illuminant can be calculated by integration. For a non-fluorescent reflecting object, ignoring a common exposure and geometry factor:
R = integral E(lambda) * rho(lambda) * s_R(lambda) d_lambda
G = integral E(lambda) * rho(lambda) * s_G(lambda) d_lambda
B = integral E(lambda) * rho(lambda) * s_B(lambda) d_lambda
`E(lambda)` is the illuminant’s spectral distribution, and `rho(lambda)` is the object’s spectral reflectance. For direct illumination, rather than a reflecting sample, the reflectance term is omitted.
With sampled data, the calculation becomes a numerical integration, schematically:
R ~= sum_i E(lambda_i) * rho(lambda_i) * s_R(lambda_i) * delta_lambda
The same operation applies to G and B. Wavelength sampling and integration accuracy must be accounted for; the ICC itself provides colourimetric weighting data for D50, D65, A, and other illuminants at 10 nm intervals.
**D65 can therefore be evaluated from the same measured SSFs.** So can other specified spectra, within the measured wavelength range and the accuracy allowed by the sampling, instrument bandwidth, and measurement uncertainty.
We do not need to begin with physical D65 illumination to discover the sensor’s spectral response. We first measure that response, then apply the desired illuminant mathematically.
3. D50 and illuminant A are not “partial-spectrum” alternatives to a uniquely complete D65
This is another fundamental point.
**D50 is not D65 with part of the visible spectrum removed.** Both are broadband daylight distributions. Illuminant A is also broadband: its standard spectral distribution is based on Planckian radiation at approximately 2856 K. A warmer distribution has different relative energy at different wavelengths; “warmer” does not mean “missing part of the spectrum.”
Likewise, D65 is a particular defined spectral distribution, not a universal “unskewed” spectrum against which every other light is physically defective. A lamp labelled “6500 K” does not necessarily reproduce the D65 spectrum: matching a correlated colour temperature is much less restrictive than matching an entire spectral distribution.
We chose D50 as a reference because of its role in colour reproduction and colour management. In the conventional **ICC.1 architecture**, the Profile Connection Space, whether encoded as PCSXYZ or PCSLAB, is referenced to D50. Source and destination conditions can differ, with chromatic adaptation used to connect them through that common reference.
To be precise, this does **not** mean that CIE XYZ or CIELAB are intrinsically restricted to D50, or that every colour-management architecture must use it. It means that the conventional ICC PCS uses D50. The ICC also provides XYZ profiles for data referenced to D55 and D65.
That makes D50 a relevant, reproducible reference for our evaluation—not the only illuminant worth examining, but certainly not an inherently invalid starting point.
For a colourimetric comparison under a given illuminant, the reference values must be computed for that same illuminant:
X_ref = k * integral E(lambda) * rho(lambda) * x_bar(lambda) d_lambda
Y_ref = k * integral E(lambda) * rho(lambda) * y_bar(lambda) d_lambda
Z_ref = k * integral E(lambda) * rho(lambda) * z_bar(lambda) d_lambda
Here, `x_bar`, `y_bar`, and `z_bar` are the standard observer’s colour-matching functions, and `k` is the chosen normalisation factor. Calculating reference tristimulus values from the specified spectral distribution is the basis of CIE colourimetry.
Changing the illuminant changes the physical stimulus and its reference values. **It does not automatically introduce an error into a comparison that uses those same conditions consistently.**
Your red-light/white-paper example illustrates this distinction. Under red illumination, the reflected stimulus is red. A valid reference calculation accounts for that. Whether a photographic workflow subsequently attempts to render the paper neutral is a separate white-balance and adaptation decision; it is not recovery of spectral information that the illumination never supplied.
There is also a distinction between **colourimetric accuracy** and **spectral reconstruction**. Colourimetry uses a standard observer by definition; that does not make it an aesthetic preference or a film-emulation choice. An ordinary RGB sensor, meanwhile, records three spectral integrals—not the entire spectrum. Three numbers cannot uniquely recover an arbitrary spectral distribution, even under D65.
An illuminant-dependent ranking could change under D65. That would be useful additional information. It would not invalidate a correctly specified D50 or A result, just as a D65 result alone would not establish performance under every other illuminant.
The problems with blackbody, CCT, and Tint in the article:
A blackbody is defined by its physical properties, not by being a piece of metal that changes colour
A blackbody is an ideal thermal radiator that completely absorbs incident radiation, regardless of wavelength, direction, or polarisation. In thermal equilibrium, its spectral radiance is determined by its thermodynamic temperature through Planck’s law.
L_lambda(lambda, T) = (2*h*c^2 / lambda^5) / (exp(h*c / (lambda*k_B*T)) - 1)
Here, `T` is the actual thermodynamic temperature, `h` is Planck’s constant, `c` is the speed of light, and `k_B` is Boltzmann’s constant. With SI constants, `lambda` is expressed in metres.
The important consequence is that a blackbody emits a **broad continuous spectrum**. Increasing its temperature changes the relative distribution of that radiation. It does not turn the source into a monochromatic blue spike. The progression towards bluish-white appearance must not be confused with the spectrum narrowing to blue.
Colour temperature and correlated colour temperature are not the same as spectral identity
Colour temperature is the temperature of a Planckian radiator having the **same chromaticity** as the stimulus being described. It is a chromaticity match, not necessarily a match of spectral distributions.
For a stimulus near, but not on, the Planckian locus, correlated colour temperature—CCT—identifies the nearest Planckian chromaticity using the specified colourimetric distance convention.
Using CIE 1960 UCS coordinates, conceptually:
CCT = argmin_T {
[u_source - u_Planck(T)]^2
+ [v_source - v_Planck(T)]^2
}
The choice of coordinates matters: this is the CIE 1960 `u,v` metric, equivalent to using `u', (2/3)*v'`, not ordinary unweighted distance in CIE 1976 `u',v'`.
Therefore:
Same CCT does not imply the same chromaticity.
Same chromaticity does not imply the same spectrum.
The second statement follows directly from metamerism: different spectral distributions can produce the same standard-observer tristimulus values.
A “6500 K” LED is not physically at 6500 K. Its CCT describes a chromaticity relationship to a thermal reference; it does not mean the LED emits a blackbody spectrum, nor does it establish that its spectrum is D65.
Tint is not a universal physical scale, and zero is not a universal accuracy target
The article repeatedly treats `Tint = 0` as the ideal and nonzero Tint as evidence of an artificial correction for a deficiency. That conclusion is not justified.
Temperature/Tint controls are part of a software-defined interpretation of white balance. Adobe explicitly documents their dependence on the camera profile. A numerical Tint value cannot be treated as an application-independent physical unit.
A standard colourimetric description of departure from the Planckian locus uses a signed distance, commonly written `Duv`. Schematically:
Duv = signed_distance(
source_chromaticity,
nearest_Planckian_chromaticity
)
That distance is conceptually distinct from a particular application’s Tint slider. Furthermore, CCT alone does not eliminate this second chromaticity coordinate: the source can genuinely sit away from the Planckian locus. There is therefore no physical rule that the correct white-balance interpretation must always display zero Tint.
The central distinction is this: **Overgaard’s table reports numerical agreement between camera settings and software readouts. Our spectral characterisation concerns how the sensor responds to radiation at different wavelengths. These are different measurements.**
A system can maintain excellent numerical consistency while still having particular spectral limitations. Conversely, a converter can display a different Kelvin value without that difference demonstrating inaccurate colour reproduction.
There is consequently no requirement that one of the two sets of observations must be wrong. The problem arises when numerical consistency is presented as proof of spectral or colourimetric accuracy.
For Spectre, the meaningful comparison is the reconstructed colour against an independently defined reference under stated conditions—not whether two interfaces happen to display the same Kelvin number....Show more →
You sound like Elon Musk for colorimetry. 
So see if I understood this correctly: That score of around 95 isn't an arbitrary ceiling caused by using the wrong light bulb or test lighting like D50 instead of D65...software can simulate any lighting condition instantly from raw sensor data. Instead, that 95 limit reflects the actual, physical boundaries of how a camera sensor captures light using just three basic color channels (Red, Green, Blue) rather than a full spectrum.
Also, getting Lightroom to spit out a matching Kelvin number doesn't mean your colors are scientifically accurate; it just means the software is reading the metadata consistently, which is why color engines like Spectre focus on true spectral measurement rather than matching interface labels.
|
