[argyllcms] Re: relativ volume of gamut -- vrml comparison?
- From: Gerhard Fuernkranz <nospam456@xxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 06 Jan 2008 17:40:14 +0100
Graeme Gill wrote:
> Gerhard Fuernkranz wrote:
>> Before talking about your particular numbers, IMO the basic question
>> is, what's your understanding of a "camera's gamut"? How do you
>> define the gamut of an _input device_, like a camera or scanner?
>
> In one sense a camera may have a gamut, and that is the range of CIE
> values representable by the full range of combinations
> of it's device values. In this sense, a camera gamut could be computed
> in the same fashion as a display gamut, if the camera response is
> modelled by shaper curves and a matrix.
Yes, but I'm not sure, whether I would call this "gamut of the camera"
then, but rather "gamut of this particular matrix model". It's basically
the model, which limits the set of CIE values, which can be returned
after applying the profile. The camera can possibly "see" colors outside
this set as well, but the model/profile eventually remaps all colors
which can be seen by the camera to colors inside the "model's gamut".
Btw, even a matrix model for an input device can of course have "virtual
RGB primaries" with chromaticities outside the spectral locus ( i.e.
outside the "horseshoe"), so that even a matrix model may map some
colors inside the full RGB cube to invalid CIE colors (negative XYZ
numbers, or outside the visual gamut).
> There is no guarantee though, that this "gamut" can actually be
> reached by any possible real world input spectrum.
Of course, see my remarks below.
> A LUT based input profile can't be used in the same way though, since
> it will be extrapolating (usually badly) outside the
> range of CIE values using in the characterization chart.
The characterization chart is is indeed one limit. But IMO it is also
important to point out, that in the RGB space of a camera/scanner there
exist per se RGB triples which are _never returned_ by the
camera's/scanner's sensors, irrespective of the spectrum being captured
(one reason is that usually the spectral sensitivities of the sensors
overlap, so that at some wavelengths even monochromatic light is unable
to stimulate only one of the three channels, w/o stimulating one of the
other channels too). So already in the RGB device space of a
camera/scanner (at least in its "raw" device space), not every RGB
triple inside the full RGB cube is valid!
But by convention, the profile needs to provide a device -> CIE mapping
for the whole RGB cube, including the invalid RGB triples. However, for
the invalid RGB triples, the corresponding CIE numbers can only reflect
an extrapolation of the model, and one should therefore not expect that
applying the profile to the invalid RGB triples would result in useful
or valid CIE numbers.
This should be always kept in mind, if an input profile is applied to an
image created by timage (i.e. to a full RGB cube), before drawing any
conclusions from the conversion results.
Regards,
Gerhard
Other related posts:
