Re: Black Point Compensation (BPC) - another track
Re: Black Point Compensation (BPC) - another track
- Subject: Re: Black Point Compensation (BPC) - another track
- From: "tl" <email@hidden>
- Date: Thu, 12 Feb 2009 08:05:55 -0500
Hi Graeme,
I wanted to comment on some of your points. It is rare that I disagree with
you technically, but in this instance, I think we depart.
The problem with the V2 spec was the total lack of a specification for an
encoding black point in the PCS. 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
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. 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.
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.
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
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.
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.
Regards,
Tom Lianza
Message: 5
Date: Wed, 11 Feb 2009 10:09:07 +1100
From: Graeme Gill <email@hidden>
Subject: Re: Black Point Compensation (BPC) - another track
To: ColorSync <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
Wilma Kay wrote:
> Continuing on this black point
> compensation thing, but on another track, I had a close look at two ICC v2
sRGB
> profiles on the ICC's www.color.org site. These MatTRC profiles are named
sRGB_IEC61966-2-1_noBPC.icc and
> sRGB_IEC61966-2-1_withBPC.icc.
I've taken a close look at both of these in the past, and in my opinion
they are both faulty, and not compliant with the ICC V2 spec.
The sRGB_IEC61966-2-1_noBPC.icc profile doesn't appear to represent
the colorimetic behaviour of the IEC61966-2.1 space.
According to the ICC V2.4 spec, table 20 page 19,
a display profile using a matrix should represent colorimetric
information. 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.
The sRGB_IEC61966-2-1_withBPC.icc profile correctly produces
XYZ 0 for RGB 0, but its black point tag is inconsistent
with this, and contains a non-zero value. The causes
a problem in the dark areas when this profile is gamut
mapped to an output space, where the gamut mapping
is relying on the black point to be truthful.
I'm not sure what the idea of the sRGB_IEC61966-2-1_withBPC.icc
profile is in any case. BPC is a gamut mapping technique,
and is therefore only applicable to perceptual or saturation
intents. Given that a matrix profile can only contain
one intent, and it has to be colorimetic, trying to
create an sRGB matrix profile with BPC would seem to be
non compliant with the ICC V2 spec.
If such a profile is wanted, then it should be a Lut based
profile, so that the BPC effect can be encoded in the
perceptual table, leaving the colorimetic information
in the colorimetric table.
I note that neither of these profiles is consistent with the
standard sRGB profile released by Microsoft and HP
on the www.srgb.com website and also distributed
with various copies of Microsoft Windows (the "sRGB Color Space Profile.icm"
file) thereby sowing considerable confusion about what sRGB actually is.
> They fix the D65 MWP problem of the
> old sRGB profile that Adobe applications aptly ignore but bring up some
> questions that don't seem to be well answered by the associated ICC
committee descriptions
> (I think ICC folks sometimes obfuscate instead of clarify).
I'm unaware of any practical issued with the official sRGB profile as
distributed
by Microsoft. It behaves very sensibly as far as I can see. There is a
subtle
incompatibility if it is used with a CMM that employs the "Wrong Von Kries"
chromatic adaptation to recover absolute colorimetric behaviour, but on
the other hand it gives better color reproduction for the much more
commonly used relative colorimetric intent than a display profile created
using "Wrong Von Kries".
> So if, as consensus seems to have it
> from the Forum, BPC is a CMM operation, how could these sRGB source
profiles
> have properties related to BPC and be so named. Why would I want to have
a "flare" factor added to my images
> with the ..noBPC profile? How would one
> actually use the noBPC profile?
I wouldn't recommend using either profile.
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