Re: Black Point Compensation (BPC) - another track
Re: Black Point Compensation (BPC) - another track
- Subject: Re: Black Point Compensation (BPC) - another track
- From: Graeme Gill <email@hidden>
- Date: Tue, 17 Feb 2009 17:37:16 +1100
Hello Tom,
my analysis of the situation with regard to matrix
profiles is that while there may well be practical
issues in using them with typical CMMs in common
workflows, the attempts to cure these problems have
been in a direction that cuts across the ICC specification,
adds confusion, and lessens the utility of profiles (the
cure is worse than the original disease!).
The problem with the V2 spec was the total lack of a specification for an
encoding black point in the PCS.
I don't actually see any issues in that regard. It has the a tag
to record the black point. If you're gamut mapping (as you
have to if quality is of interest), it matters little if
the black point is L* = 0 or L* = 3, either will be taken
into account, as one has to in mapping between two
different gamuts. A matrix profile by definition is colorimetric
(see table 20 on page 19 of the V2.4 spec., which shows that a
matrix table represents only colorimetric intent for a display profile),
so it represents the behaviour of the device/colorspace. If
the space has a zero black, it has a zero black. That's
how it is, and that's what the colorimetric information is
there to represent.
Another interesting point is that the
transfer function for a display specified in the original spec was specified
as "canonical". This was a point that I and many other authors of profiles
missed. The implication of this word is that the lut is a peak normalized
representation of the "real life" transfer function which implies that IT
NEVER SHOULD REACH ZERO. The question of how one would invert such a
profile was never dealt with and herein lies one of the greatest mis-steps
at the beginning of the ICC
I'm not really following you. I don't see any issues with inverting
a behaviour that hits zero, or doesn't hit zero. That sort of
thing is common in color management - all devices have a limited
gamut.
Now with respect to sRGB spec, you wrote:
"The IEC61966-2.1 space is defined as having
XYZ value of 0 for RGB 0, while the sRGB_IEC61966-2-1_noBPC.icc
profile produces a non-zero XYZ for a zero RGB."
First and foremost, sRGB spec is an encoding specification not a profile.
The spec is quite clear that there is an assumption of 1% flare in the
signal AS VIEWED.
Right, but the V2 spec. is quite clear that display profiles are encoded
as flareless. See the V2.4 spec., Section D.3, page 80 and 81.
The colorimetric information is that from a contact measurement
instrument, which must be corrected to have no flare.
sRGB, being an idealized device, has a zero black point, and "measured"
without flare it will have a value of zero.
I don't expect the colorimetric information to encode viewing conditions -
they are perceptual effects, and belong (if at all) in a perceptual
intent table. The 1% flair due to the viewing conditions should
be allowed for along with all the other viewing condition parameters
in the gamut mapping that anybody that cares about exact appearance
will apply, or in a perceptual table that may be generated in
a similar manner.
While it is clear from the math that a zero will
reproduce as zero, it is also clear that in an sRGB image, there should
never be a zero. The authors of the sRGB specification suggested setting
the black level to zero in the encoding but acknowledged that this was a
simplification (see equations 1.3 and 1.4 in the spec). On one hand the
authors of the sRGB spec specified a level of flare in the encoding and in
the mathematical description of the transfer, they specifically ignored it.
This seems perfectly reasonable to me. The first describes the "device"
behaviour (it's colorimetric behaviour). The second describes assumed
viewing conditions that should be used to derive typical appearance
values.
A major advantage of keeping these things separate is that
the same device characterisation can be used when the device
is placed in, or used under different viewing conditions.
If these two are mashed together, you're stuck with a profile
that is considerably less useful.
They did this for a very good reason, if you took the spec seriously, the
viewing flare would have to be SUBTRACTED from the input signal, if the
signal was already dark corrected this would result in negative values.
Black was never properly defined or handled in the sRGB specification.
I disagree. It is perfectly possible to handle this by assigning it
to its correct place, in a color appearance model. It seems to me
that a lot of these issues are a result of trying to hack
appearance model issues into places they don't belong (colorimetric
measurement information). One can always apply color appearance
models to known measurement, but the reverse is rather difficult
if the exact nature of the appearance model applied and all
its parameters isn't known.
The first responsibility of a color profile is to unambiguously
convey the behaviour of the device. Modifying the measurement
data to be relative, or worse to include viewing effects
all in the pursuit of expedience in certain workflows, has
been a poor choice in my opinion, and the root of many
interoperability issues.
In the late 90's and early 2000's we were left with two specs (sRGB and ICC)
that had what appeared at first glance to be a "minor" error, which would
later be the prime cause of major interoperability issues. During this
I haven't seen such issues with the original sRGB profile. I have seen
issues with at least one of the the profiles claiming to be V2 sRGB profiles
on the ICC website.
period, Adobe and other vendors introduced BPC to try to manage these
issues. BPC takes places in the CMM, not the profile. Different vendors of
CMM's used different methods and thus we had not only issues with profiles,
we had issues with CMM interpretations. In 2006, Adobe published their BPC
spec and I believe that CMM vendors were encouraged to embrace it. It took
15 years to get to the point of applying an anachronistic band-aid to subtle
mistake made at the start of the process.
I disagree this is a band aid to a problem. It is assigning it to
it's correct place, as a link time (luminance axis only) gamut
mapping.
There are of course other possible alternatives to dynamic
gamut mapping, and treating the black point more like
the white point in regard to the conversion from instrument
readings to relative colorimetric/perceptual may have been another alternative,
although for some reason the ICC didn't pursue this course until
V4 and the PRMG. I don't see any issues with there being more
than one "BPC" algorithm - it after all is a cut down implementation
of gamut mapping, an area that is still the subject to much research,
and something that crosses over into artistic as well as technical considerations.
Now within the ICC, we didn't do anyone any favors in our naming convention
for the sRGB profiles. When using the profile with the "noBPC" in the name,
you need to turn on BPC. If BPC is turned on, either profile should provide
the same output. In any event, all vendors should use BPC when displaying
an image to the screen. This one small change would clear up a lot of
problems in soft proofing issues between applications.
Maybe both profiles produce the same output with Adobe's BPC, but
the IEC61966-2-1_withBPC.icc is simply dangerous, because it's
black point tag is lying. People use this, and wonder where
their black detail has gone, because zero RGB in produces a black
that is blacker than the black point tag, and will therefore
be clipped during gamut mapping.
As far as I can determine (and I've quoted chapter and verse at
each point), neither profile is compliant with the V2 spec.,
and therefore shouldn't be offered.
cheers,
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden