[argyllcms] Re: The right way for device input profiles and artificial light sources?
- From: Stephen T <stwebvanuatu@xxxxxxxxxxxx>
- To: "argyllcms@xxxxxxxxxxxxx" <argyllcms@xxxxxxxxxxxxx>
- Date: Mon, 16 Dec 2013 03:45:10 -0800 (PST)
Thanks Gerhard,
Firstly, performing CAT to convert XYZ for illuminant A to D50 was a mistake.
The adapted A and D50 XYZ are essentially the same. Ignore the adapted A.
This leaves two options:
A) Profile with XYZ for illuminant A. The raw photo application would then have
to recognise the non-standard profile white point and apply a chromatic
adaptation transform from XYZ_A to XYZ_D50 or whatever. I'm not sure mine does!
B) Profile with XYZ for illuminant D50.
There is more to this than colour management. Like dcraw and most others, there
are two steps before the "device RGB" is output from the raw photo application:
1) White balance by scaling raw photo RGB ("native RGB").
2) Interpolation (giving "device RGB").
I remember reading somewhere that demosaicing is more succesful for white
balanced images.
Because the device RGB are approximately white-balanced, I think profiling
option B is appropriate (i.e. the illuminant A effect has been corrected by
reducing the R channel gain and increasing the B channel gain, I can see this
in the dcraw multipliers). Do you agree???
Now, if the RGB white-balance was perfect then:
RGB_n * scaling = RGB_s
where RGB_n is native RGB, which is then multiplied by white-balance scaling
coefficients, and RGB_s is the RGB response for sunlight for example (a
"standard" light source for camera profiling and fairly close to D50). Then
only one profile is required, since:
XYZ_D50 = RGB_s * M_s = RGB_n * scaling * M_s
where the matrix profile M_s has been computed with D50 reference data, it
converts RGB_s to XYZ_D50.
In reality, the white-balance scaling is imperfect. For example, I compared
white-balanced RGB_A versus RGB_s from .ti3 files and found the red and orange
patches in RGB_A relatively weak in the R channel. The white and neutral grey
patches agreed within 1 or 2%, so the white balance was OK in both images. When
the M_s profile is applied to the scaled RGB_A data, red and orange colours are
weak, as I had noticed in some of my photos. I have tried playing around with
white balance and found no satisfactory solution. It's much easier to use a
custom profile for illuminant A:
XYZ_D50 = RGB_n * scaling * M_A
where M_A converts scaled RGB_n to XYZ_D50 and corrects the white balance
problems.
I expect the "standard" sunlight profile is satisfactory only for light sources
near D50. For very warm light, very cool light, fluorescents etc., with spectra
very different to sunlight, white-balance scaling of native RGB will be less
successful and custom profiles will help to correct the errors.
Stephen.
________________________________
From: Gerhard Fuernkranz <nospam456@xxxxxx>
To: argyllcms@xxxxxxxxxxxxx
Sent: Sunday, 8 December 2013 3:08 AM
Subject: [argyllcms] Re: The right way for device input profiles and artificial
light sources?
Well, the basic question is: What kind of reproduction is
intended? For the standard use case "reproduce the colorimetry of
a scene illuminated by a custom illumination source", the _actual_
illumination source spectrum should be used for
1. capturing the target,
2. capturing the scene,
3. and also for computing the XYZ reference data of target's patches
from their reflectance spectra
if color constancy of the colors in the scene under changing illumination
source is _not_ granted.
If color constancy were granted, then using D50-based reference
data instead should not make a difference (as long as the
resulting profile is applied with a whitepoint-relative intent),
since the color change under different illumination sources would
follow a chromatic adaptation then.
Also keep mind that even a perfect colorimetrically correct
reproduction does not necessarily preserve the _color appearance_
as well, since the latter depends vastly on the viewing
conditions/environment. Note for instance that the _appearance_ of
the same scene under rather dim tungsten light is per se warmer
than under bright daylight, even if color constancy were granted
and thus the relative colorimetry were the same. So if the
reproduction (e.g. on a monitor) does not "look" like the original
scene, the reason could also be a color appearance issue...
[ And still all limitations of input device profiling do apply,
e.g. cameras are partially color bind wrt. the human vision, so it
is generally not possible to build a profile which is correct for
_all_ possible colors; the target may not be sufficiently
representative for the captured scene, etc. ]
Best Regards,
Gerhard
Am 07.12.2013 11:26, schrieb Stephen T:
Hello,
>
>Tungsten + D50 XYZ is not equal to Sunlight + D50 XYZ. The
sunlight profile performs very poorly for photos taken with warm
lighting.
>
>I was wondering which of the following is most nearly "correct":
>1) Tungsten + D50 XYZ?
>2) Tungsten + A XYZ?
>3) Tungsten + adapted A XYZ?
>
>I think most people profile with option 1) but this doesn't seem
right because the XYZ changes when the illuminant changes.
>
>
>
>Stephen.
>
>
>
>
>________________________________
> From: Gerhard Fürnkranz <nospam456@xxxxxx>
>To: argyllcms@xxxxxxxxxxxxx
>Sent: Wednesday, 4 December 2013 4:31 AM
>Subject: [argyllcms] Re: The right way for device input profiles and
>artificial light sources?
>
>
>
>Shooting the target under say tungsten light while using D50-based reference
>data is basically supposed to result in a profile which reproduces the shot of
>a tungsten-lit scene as if the scene were lit with D50 instead of tungsten
>light (within the various limits of the camera profiling process, of course).
>--
>Best Regards,
>Gerhard
>
>
>
>
>Stephen T <stwebvanuatu@xxxxxxxxxxxx> schrieb:
>Hello,
>>
>>I have been playing around with camera
profiles for tungsten and fluorescent
lighting.
>>
>>As I understand, there are 2 things that
happen when the light source changes:
>>1) Device RGB changes (what the camera
sees).
>>2) XYZ changes (what the standard observer
sees).
>>
>>I have made simple matrix profiles. There
are 3 different profiling strategies I have
tried:
>>1) Profile with D50 reference data (ignore
changes in XYZ).
>>2) Profile with XYZ computed for the CIE
illuminant most closely matching the light
source (non-standard profile white point).
>>3) Take XYZ from step 2 and perform a
chromatic adaptation transform to D50
(standard PCS white point).
>>Which of these is recommended?
>>
>>
>>Profiling errors with the 3 different XYZ are similar (a good fit doesn't
>>mean the results will be sensible in practice however). Options 2 and 3
>>produce exactly the same rXYZ, gXYZ and bXYZ, only the WTPT is different.
>>Options 2 and 3 produce identical images in my workflow and I guess the
>>non-standard white for option 2 is being accounted for?
>>
>>For real photos in warm light, I have found
all 3 tungsten profiles are similar. The D50
reference data produces slightly warmer
reds.
>>
>>
>>There are greater differences in photos with fluorescent lighting, where the
>>D50 reference data produces a warmer, more pleasing image. Options 2 and 3
>>look a bit greenish. Perhaps this is because I profiled with a light source
>>approximating F5 daylight and the test photos were shot with inferior, lower
>>colour temperature lights?
>>
>>
>>
>>Compared to daylight profiles, the artificial light profiles do produce more
>>realistic colours. I haven't done any quantitative tests yet.
>>
>>It's strange that the D50 reference data
seem to be useable, as the colorimetry of
the target does change and the rXYZ, gXYZ,
bXYZ tags can be very different. Here are
some colour differences I calculated after
CAT:
>>Mean DE94 between D50 and illuminant A after
CAT to D50 = 1.5.
>>Mean DE94 between D50 and illuminant F5
after CAT to D50 = 2.4.
>>
>>Appreciate any tips, advice.
>>
>>Stephen.
>>
>
>
Other related posts:
