Why does the Page Color Type Report report RGB as black and white?

[yosimo]

Hello,

I want to use my action list to determine whether my digital press is accounting for black and white or color prints.
So I have three questions about this:

Why does the Page Color Type Report confirm black and white even though the PDF contains a neutral RGB Black? A neutral RGB Black (where the R, G, and B values are equal) is seen as color by the _original_ DFE and costs a 4-color click and not a black and white click.

Our DFE is a PRISMAsync from Canon and accounts for a 4color click when outputting such neutral RGB, not black and white.
Since Enfocus/PitStop provides the Page Color Type Report specifically for DFE users like me, that should be corrected.

If I can't rely on the result, then the preflight report "Page Color
Type" or even the action "Gather page color type" is completely useless.

It would be desirable that neutral RGB is recognized and reported as color, just as it is interpreted by the DFE! Because then I would also have the possibility in advance to correct the print data in time.

I have already contacted the enfocus support. In their reply, they unfortunately do not explain why rgb is reported as black:

...
To explain more about the Page Color Type Chapter in the Preflight Report was created specifically for DFE (Digital Front End) customers who pay a different amount for color pages than for black and white pages.
This reports on the Color Type of a Page, with three possible options that will be reported: Empty, Black and White, or Color. The report emulates a DFE and has the following specific handling:
Neutral RGB = Black and White
K only = Black and White
...

Perhaps someone here can explain to me what the point is of reporting neutral RGB as black and white in the Page Color Type Report, when the same RGB is billed as a color on the original DFE of the printing press.

Regards yosimo

[loicaigon]

Hi,

The logic behind reporting Page Color Type is that type is determined by rendering the page to CMYK, with colour management and anti-aliasing disabled. Therefore, PitStop emulates a DFE behaviour using PostScript conversion formulas with colour management off. Neutral RGB should then be converted to Black in that context, hence our report that the page is "Black and White" in that case.

If this logic is not applicable to your DFE, then you can take advantage of our Default Action "If it looks Black and convert to Black" that you can attach to the Preflight Profile (See Extra/Action Lists/Changes). And Neutral RGB will consequently converted to pure Black and you shouldn't get false positives after that.

Hope that helps,

Loic

[yosimo]

...PitStop emulates a DFE behaviour using PostScript conversion formulas...

Yes, this emulates a behavior that is perhaps not at all common in practice.
I don't want to convert the neutral RGB to black and white. I just want to be told that my DFE will print a color page for such RGBs. A neutral RGB printed in color mode may also look different than if it is only output in black and white mode. But that's fine and what our customers want.

In fact, I would like to recognize before printing which pages will actually trigger a black and white click and which pages will trigger a colour click. However, this does not seem to be reliably possible with the Color Type Report.

That's why the Color Type Report with its behavior is unusable for me.

yosimo

[freddyp]

PitStop does not know what each and every DFE will do to modify the color content of a file. The only thing the report can tell us is what it theoretically should be ... without any additional transformations.

The correct approach is that you should apply the same (or at least similar) transformations to the file as the DFE does before running the report. You could attach an ICC profile to the RGB data making it non-neutral and convert it to CMYK. The resulting CMYK values may not be the same as what the DFE calculates, but at least the report will be correct.

Now, this will "destroy" your file so you have to build the flow a bit differently: you let the original PDF go in two directions, one into PitStop Server to get the report, one that bypasses PitStop Server to join up with the report that is created by PitStop Server, either with an Assemble job or an Opaque pickup. You can throw away the preflighted PDF.

[yosimo]

If PitStop does not know how each individual DFE changes the color content of a file, why does it interpret neutral RGB as black and white? DFEs do not do that.

...the report can tell us is what it theoretically should be ... without any additional transformations.

But that's not what happens: it transforms the rgb color space (with neutral rgb) to black and white. That's not right.

And thank you for your recommendation, but I can't take it seriously: I should bend the customer data so that the report reflects what my DFE outputs without data manipulation? And I'm supposed to run the process in two directions?

Why make it so complicated? It would be more logical to correct the report and program it so that it reports neutral RGB as the color.
After all, RGB is a color space and not a b/w space.
Of course, I can put together a preflight or action list that makes this more reliable. But then what is the Page Color Type Report for?

A color with identical halftone values in the CMYK channels is also reported as a color, so it should be the same with RGB, if there are the same values in all the rgb channels.

Precisely because PitStop does not know how each individual DFE behaves, it would be advisable for the Page Color Type Report to report exactly what is actually contained in the print file: color as color and black and white as black and white.

regards yosimo

[freddyp]

I was a bit puzzled by the last part of your your statement:

If PitStop does not know how each individual DFE changes the color content of a file, why does it interpret neutral RGB as black and white? DFEs do not do that.

but not being familiar with all settings of all DFEs out there I have been asking around. I have confirmation that the PRISMASync DFE has a setting to keep pure black. The same is true of the Fiery DFE, HP, Caldera, Onyx.

In other words, as I expected DFEs do give you a choice so you have to make sure PitStop interprets it in the same way considering that the default behavior is to keep pure black. I agree that not keeping pure black requires a bit of a trick and that it would be nice to have an option for the creation of the report.

[yosimo]

Hi freddyp

is there a misunderstanding here?
I know about the setting on the DFE to preserve pure black. However, pure black refers to the CMYK black from the black channel, not the RGB black.
This setting refers to the conversion from CMYK to CMYK with the help of icc color profiles.
It prevents the black from the CMYK black channel of the source color space from being converted into the color channels of the target color space and thus being retained in the black channel of the target color space.
In addition, this setting affects the entire print job. But how do you set the DFE so that only selected pages of a multi-page PDF are printed in black and white?

...pure black...

In this context, I consider pure black is then black if the DFE triggers a black-and-white klick.
I'll say it again: the Page Color Type Report would be useful and correct if it reliably tells me as a DFE user which pages are billed by the DFE as color or black-and-white.
And since the DFE from Canon as well as the Fiery RIP (both of which I have available here) trigger RGB black as color, the Page Color Type Report should also report this.

...a bit of a trick...

I don't know what you mean by that: it is the default state of the DFE that it interprets RGB black as a color. What trick should you use here and how?

Just try printing a PDF with an RGB black object and then check what the DFE has accounted: a 1-color click or a 4-color click. If it has triggered a 4-color click, then it proves that the Page Color Report has reported incorrectly.

Regards yosimo

[freddyp]

Yes, there is a misunderstanding. On your part. I have just received feedback from Canon which confirms what I thought: "Preserve pure black" also applies to equal values of RGB. Here is the feedback:

Screenshot 2024-01-23 at 15.37.54.png (159.18 KiB) Viewed 35163 times

I'll say it again: getting a correct page color type report requires knowledge of the behavior of the output device settings and may therefore require some tweaking on the PitStop side. As I explained in a previous reply: if you want to force the interpretation of neutral RGB as color you can tag RGB objects with an ICC profile and convert them to CMYK. And as I also wrote: it would be nicer to have an option/toggle/checkbox in the "Gather page color type" Action, but that does not invalidate the need to align PitStop with whatever settings you are using on the DFE side.

[yosimo]

Thank you for this very interesting information. I was not aware of this before. I cannot find these settings on our PRISMAsync DFE.
I have therefore sent a request to our Canon Integration Specialist and am still waiting for an answer.

I could only find this on our DFE:

ReinesSchwarzErhalten.png (18.26 KiB) Viewed 33682 times

Get pure black is already activated and still our DFE clicks an RGB black as color.

...to force the interpretation of neutral RGB as color you can tag RGB objects with an ICC profile...

That's not necessary, our DFE already interprets it as a color anyway. Before printing, I want to know which pages will cause a black and white click and which pages will cause a color click, just like a simple preflight.
But I don't want to reconfigure the DFE so that the print settings match the Page Color Type Report. It should rather be the other way around.
Therefore I agree with you, if you could configure the action Gather page color type: for RGB black report colored or black-white page type, depending on how the DFE interprets it.

[yosimo]

Hello,

I have finally received feedback from Canon: he confirms that the PRISMAsync DFE on the Canon C810 does not offer a pure black option.

Preserve pure black is only available in the (PostScript) printer driver, where you can select this option when printing from the open application to the digital printer via the print menu.
https://oip.manual.canon/USRMA-3522-zz- ... |dGmJ|!CAE

However, if the print PDF is copied directly into the print spooler of the PRISMAsync DFE using drag and drop, there is no option to preserve pure black.