[argyllcms] Re: Whitepoint and Space Conversion
- From: "Wire ~" <wire@xxxxxxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 16 Oct 2020 10:06:44 -0700
Thanks for taking time to help
Additional questions below
On Thu, Oct 15, 2020 at 20:08 Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
Wire ~ wrote:
Hi,
The profiles say how to get from TRC image to PCS to TRC display. Makes
sense.
What happens with white?
that depends on the intent. The default assumption is that the observers
of the source and destination space are 100% adapted to the white point,
meaning that the white of each device is perceived as perfect diffuse
white.
So if the source and destination whites actually have a different
chromaticity,
a chromatic transform is performed to map the colors, mimicking the
observer
chromatic adaptation.
What would be some obvious effects of display white not being handled
corrected? For example if a TRC defect results in crushed blacks or poor
contrast, a poor white compensation would appear as ... ?
I am devising an experiment to see it for myself later today. But
continuing the thoughts...
Put another way, If I accept the idea of 100% adaptation to a display, why
doesn't vision adaptation account for display white the same way as any
other illumination? Why does color have to be bent to fit? And white
doesn't get bent by the transform, so it has something to do with a scale
for non white.
Do metameric effects of display have something to do with it? (I'm wild
guessing)
Shifting gears, wrt transform applicability: Hoe can a display observer be
assumed to be 100% adapted? The display is a portal in an environment. I
get that if I'm fixed on the display in a very dim or dark environment it's
a preponderance of my experience. A printed page is generally just another
object under environmental conditions. In my experience a display in a lit
room rarely agrees with the color of the space, it's just a matter of how
disturbing the discrepancy. Making controlled room and display agree Is
obvious. So which should the transform account for? ;) I mean clearly what
must be happening is not about visual adaptation at all, but scaling the
numbers between representations (spaces) to prevent introduction of error
when moving data between spaces. IOW whitepoint compensation in CM
protocols is about consistency between maps, not about accommodating visual
adaptation, and so is just like making TRC fit. Just as TRC mapping doesn't
(usually) account for local effects of simultaneous contrast, white
compensation doesn't account for local adaptation, there's almost no way to
express these concerns in the parameters of the CMM.
(I see first-hand how white tuning provides preconditions for gamut and
capacity to differentiate — to see clearly. Is there one white to rule them
all?)
Which makes the idea of rendering intent more interesting to me and
wondering why it's so passive. (Notwithstanding features like mobile
auto-brightness and "nightshift")
In the ICC profiling world, this is the default - every devices white is
by default mapped to PCS 50 white, so when you link two profiles you
get a chromatic adaptation.
IOW The numbers are swizzled to keep scale. I am focusing on this because
it's so difficult for me to separate the control of stimulus from its
effects. ICC is about stimulus mgmt. Chromatic adaptation in the system
avoids stimulus errors that would arise from putting data scaled to one
white under another white.
Note that if you don't do a chromatic adaptation, then you have additional
gamut mismatches that need to be handled somehow (clipping etc.)
OK Yes i follow
What does it mean for Lab to have one reference for white and sRGB to
have another?
It's not clear what you mean by that. L*a*b* is by definition a (white)
relative
space. The conversion does a (wrong Von-kries) chromatic transform from the
specified white point.
In the ICC world PCS L*a*b* can be treated as a pseudo-absolute space if a
D50
white point is assumed.
Should I read this as
"Lab is white relative in a way distinct from RGB spaces"
or
"Lab is white relative as are RGB spaces but Lab is operated as a reference"
?
Superficially, white point shifts color distribution to preserve... ?
Apparent
relationships? It can't be to preserve stimulus because the whole
framework for perception
is shifting under display white and vision is adapting.
That's what Chromatic Adaptation is all about.
Ya I will think about this more.
I'm interested in a distinction between holding color representation steady
under some variation of stable viewing conditions and rendering into a
dynamic environment.
My own environment is poorly controlled due to huge windows and skies
turning to green-cheese from epic forest fires, plus TV / mobile evolution
tech appears headed to the more dynamic rendering.
I am also helping a friend to grok what to expect about white when getting
a hypothetical distributed system of viewing pods aligned to produce a
consistent responses as settings vary
The whole point of CIE / ICC approach is about appearances... So what
does the design of
ICC do with whitepoint?
The default is actually relative colorimetric reproduction, with
appearance/perceptual
and non-relative reproduction being possible, but not as easy.
Yes I have seen this in apps such as Photoshop, and my bias was revealed in
next question...,
Why do printer profiles allow "paper white" simulation, but you can't
simulate working
space white references?
It's not clear what you mean by that. A printer profile is like other
output profiles,
and has no particular facility for simulation of anything. It's the
application that
uses the profile to allow various appearance simulations.
Yes yes I see
My trivial experiments show that no matter what profile is applied to
image data, the data
are rendered according to display white. I can see this doesn't change
from one image
space to another. If I align a display to D50, profile it, and assign
the profile to a D65
display, the neutrals don't change. So what is "white" in the profile
governing about any
conversion.
That isn't so if you choose other intents for profiles with non-native D50
white points
using ArgyllCMS. (Note that ICCV4 display profiles and absolute intent,
and the behaviour
of other CMM's in relation to display profiles and Absolute Colorimetric
is a whole
can of worms.)
Cheers,
Graeme Gill.
Yes cheers to you too
THANK YOU!
Other related posts:
