ArgyllCMS profiles: Black Point Compensation gives composite black when checked

[nertog]

different printers ? - we tested the same L1800 - with ArgyllCMS and I1profiler,

My bad. I was confused by the filename that mentioned XP15000

 

[pharmacist]

I just tried the relative colorimetric intent both with and without black point compensation: with BPC enabled the pure black patches are not as black when BPC is disabled (composite black instead of pure photo black). This is not the case with a profile made with the proprietary Colormunki X-rite software: no difference in blackness whether or not BPC is enabled.

 

[Ink stained Fingers]

Could you please post the two profiles - ArgyllCMS and ColorMunki - you used for the above test, I would do a readout of the black levels as stored in the profile header, different black levels may contribute to the effects you observe - let's see.

 

[Ink stained Fingers]

I think it is a rather complex situation you are trying to sort out - different profile engines , different inks , different options - rendering intent and black point compensation.

Black point compensation seems to be interpreted differently - I see comments that BPC should always be on with the percept. rendering intent - or the opposite.
BPC is described and defined by Adobe

https://www.color.org/adobebpc.pdf

and Adobe states in sect 6.2 :
'Color conversion using Perceptual intent already maps source white to destination white and source black to destination black. Because this mapping preserves the relationships of the shades, it is unlikely that a whole shadow section will be mapped to the same black value. Therefore, BPC should not be necessary.'
It may only be necessary to use BPC if activated together with a malperforming profile.

A rather opposing opinion is posted here

file:///D:/Downloads/black%20point%20compensation.pdf

Another detailed description is given here

http://www.gamutvision.com/docs/blackpoint.html

A more technical view is given in this publication how BPC works together with various rendering intents

file:///D:/Downloads/black%20point%20compensation.pdf


ArgyllCMS is apparently interpreting the rules for a profile at the low luminance range differently to the approach XRite is taking with the ColorMunki and i1profiler generated profiles - who is right or wrong at this point ? Or is it more an issue that you need to find out how the various involved software apps/elements on your computer are working, and that you take the steps which work for you and are not counteracting against each other.

 

[Ink stained Fingers]

There is a little program available by the ICC - ICC Profile Inspector - which gives you a readout of the White point and the Black Point of an ICC profile - but only in XYZ or xy coordinates - you would need a converter to Lab or RGB
like this one

https://www.color.org/profileinspector.xalter

https://www.nixsensor.com/free-color-converter/

 

[nertog]

Hold on a second before this derails further The issue at hand is a difference in maximum printed black with and without BPC enabled, independent of what is defined as max. black in the profile. I have seen this as well whenever an ICC-profile has output curves that are not converging at R=G=B=0. I have not yet seen an X-rite profile that did not converge, but it does happen with ArgyllCMS (see complaint of Pharmacist and my example). Both profile engines follow the ICC specs as there is more than one way to generate those output curves.

BPC is described and defined by Adobe

Adobe is correct: BPC is perceptual mapping of the black level...so it has no effect when using the perceptual col. intent.

I do not understand yet why enabling BPC lightens the max printed black....it shouldn't (I think), but it does happen. An example with the ICC profile shown in post 8:

A near black gradient from Lab = 0,0,0 to 20,0,0

Data sent to printer with relative col. intent, NO BPC. Note the already elevated black levels corresponding to the black point indicated in post 8 - Lab = 26,5,0. The pink tint is the profile trying to correct for the very blue PK ink (6-channel dye printer).

Same gradient with BPC enabled. See how the whole gradient brightens, including max black?

This does not happen with profiles that have output curves converging at RGB=0.

 

[Ink stained Fingers]

Complicating the matter whether BPC should be on or off is Adobe's ambiguous position about PBC - the original spec states that BPC on is not advised unless the icc printer profile is mal-performing - that clearly states that BPC should be off under 'normal' conditions.
Various graphisc/photo editing programs with a print module leave it up to the user to turn BPC on or off via a print parameter menue. But Lightroom does not follow this approach and forces BPC always on which can cause quite some irritations when users print alternatively via Lightroom or Photoshop, you can find plenty of similar postings over the years about this difference like this one

https://www.dpreview.com/forums/post/55109890

Update: BPC is always on for the perceptual rendering intent - no way to deactivate it, but the rel. colorimetric rendering intent in Lightroom apparently provides the on/off option for BPC

http://lightzone.helpmax.net/en/photo-editor/printing/black-point-compensation/

 

[Ink stained Fingers]

I do not understand yet why enabling BPC lightens the max printed black....it shouldn't (I think), but it does happen.

Yes, that appears to be irritating , I think as well that the max printed black should remain. Could it be that the black point is wrong ? I extracted the black points out of various profiles @pharmacist made available to me - there is an interesting effect that the black point registered in the profile header is lighter for the ArgyllCMS created profiles than for the ColorMunki profiles - for the same inks on the same paper

L= 4.69 vs. 6.51 or L=8.78 vs. 11.19

I'm not sure at this point if that's measuring variances or there is another effect in the background.

 

[nertog]

Yes, that appears to be irritating , I think as well that the max printed black should remain. Could it be that the black point is wrong ? I extracted the black points out of various profiles @pharmacist made available to me - there is an interesting effect that the black point registered in the profile header is lighter for the ArgyllCMS created profiles than for the ColorMunki profiles - for the same inks on the same paper

L= 4.69 vs. 6.51 or L=8.78 vs. 11.19
I'm not sure at this point if that's measuring variances or there is another effect in the background.

A profile that follows the ICC specs definitely benefits from BPC when printing with rel. col. intent, otherwise you´ll end up with blocked-up shadows. The deeper your black point, the less benefit BPC will bring...what it shouldn´t do is lighten your starting value. Perceptual intent already does black point mapping, so enabling it there will do nothing (unless your profile is somehow behaving weird). I agree with Adobe´s statement there.

Canon seems to bake-in some black point mapping in the actual rel. col. intent tables of the profile. This is not according to the ICC specs.

The L-value differences you show above are probably resulting from Argyll´s profile engine, and I guess the BPC issues originate there as well. My feeling is that Argyll steers towards a more neutral near-black behaviour, and if your gamut is skewed towards a non-neutral black point and is at the same time quite narrow for dark values it would be impossible to create neutral dark shades. X-rite would then trade-off neutrality for "blackness" in that region.

It would be nice to have @Graeme Gill chime in

 

[Ink stained Fingers]

Let me present another view of the availble data to you about the effect @pharmacist is describing in his opening posting. He made a few profiles available to me highlighting the effect, it's 2 profiles for the SC-P800 printer with the Netbit glossy paper and an Octbestjet K3 inkset - one created with ArgyllCMS and the other with ColorMunki. I mentioned already above that the black point values embedded in the profiles differ - ArgyllCMS seems to use a lighter black than Colormunki for some reason.

I'm displaying here the B/W response curve using Gamutvision for display, it does not provide a display option to overlay several curves but I do it overlaying 2 screenprints of the resp. windows.

This plot shows the 2 B/W curves - L* out over L* in for the rel. colorimetric rendering with BPC off

(Just look to the black curve )

The curves differ at the dark end - the upper curve belongs to ArgyllCMS - it appears at this point that ArgyllCMS is already adding here some BPC effect which raises the output luminance over the input luminance.

This is the plot for the same conditions - but rel. col. with BPC on

The lower curve still belongs to the Colormunki profile - is shows the BPC effect with a slope, the ArgyllCMS curve seems to add an increment to the black point, at the starting point on the L* out vertical axis, and always stays above the Colormunki curve.

it looks quite different if you select the perceptive rendering intent with BPC on,

The ArgyllCMS curve is still the upper curve, much more elevated and starting at a much higher level on the L* out axis, this confirms @pharmacist 's findings that pure black at L* in = 0 prints results in a much lighter black than printing with the ColorMunki profile provides.

I don't know whether there are any parameters in ArgyllCMS which could influence this behaviour for the profile calculation. It is a pretty strong effect as it appears to me, and I'm wondering if that is not mentioned or documented earlier already.

The trend is very similar with another set of profiles but to a smaller amount so that I won't post those plots again.
I'm not an active user of ArgyllCMS but this exercise shows how difficult it is to compare profiles.
I started off some time ago in the ArgyllCMS thread posting a question if there is a simple or convenient tool or method to compare profiles by several parameters - e.g. ARgyllCMS vs. XRite like in this case - or profiles generated with 100 patches or 400 or 3000 patches. It is apparently slightly more complex than I anticipated.

(Detailled explanations about the Black point compensation in Gamutvision are here

http://www.gamutvision.com/docs/blackpoint.html

Please recognize that Gamutvision has BPC always on for the perc. rendering intent - see a note at the bottom of the posting)