Colour proofing 1-bit tiifs

[RVNG]

Strange question… does anyone produce Epson proofs from 1-bit Tiffs? It seems to me this is a very strange way to work. Would there not have to be de-screening involved? And wouldn’t the Epson proof suffer in overall quality because of the de-screen?

It seems to me Adobe PDF renders have always handled rendering to proof and rendering for plates separately without issues… meaning the proof always represents what is rendered on plates without question. Thoughts?

 

[claude72]

Strange question… does anyone produce Epson proofs from 1-bit Tiffs? It seems to me this is a very strange way to work. Would there not have to be de-screening involved?

No. AFAIK, proof generated from the 1-bitt TIFF outputted by the RIP are:

- either FPO low-res proof: "FPO" means For Placement Only, and are used only to check the good placement of all the element of the page: check if all the texts are correct, no words or letters missing, no special signs missing (like the euro symbol, which is often tricky), no thin lines missing or looking strange because of screening, no white elements missing because of a white overprint error, no strange colors appearing because of a bad overprint handling, etc.
In this case, you don't need a quality proof: it's only for placement control... so there is no use of a descreening, and in fact the screening is even needed because it shows some flaws that wouldn't have been visible without the screening, like the bad effects of the screening on thin lines, or on rasterized contone texts/logos (instead of vector texts/logos)... and a de-screening would improve the "quality" of the proof to make it look nicer for the customer, but would erase some flaws that are important to be seen by the printer.

- or color proofing: in this case the proofing has to be made from the exact rasters that will be printed by the press, to be able to show the exact rendering of the screened pictures on the paper.
In this case, a de-screening would modify the repartition of the screen-dots, and then modify the colors.

It seems to me Adobe PDF renders have always handled rendering to proof and rendering for plates separately without issues… meaning the proof always represents what is rendered on plates without question.

No: if you haven't (yet) seen issues, it's only because you are lucky... (or a little bit blind)... but they exist:

First, Acrobat is not your RIP. In an ideal computing world, this shouldn't be an issue...
... but in the real world, bugs exist, and they are different in Acrobat and in your RIP, meaning that Acrobat can mis-render some element that your RIP will handle perfectly, and, more serious, an element that had been perfectly rendered by Acrobat (letting you -and your customer- believe that everything will be fine), can be completely butchered by your RIP.
Using the 1-bit TIFF rasters outputted by the RIP to make proofs allows you to be sure that the proofs are an exact match of what will be on the plates.

Second, Acrobat settings can change the rendering of a PDF...
The most known exemple are the overprint issues: your are a printer, so, of course, your Acrobat is set to simulate the overprint display... but your customer isn't a printer, he doesn't know what an overprint is... so his Acrobat is not set for per-press use, it is set as Adobe set it by default, and when you send a proof as a PDF to your customer, you cannot be sure that your customer will see on his screen the same things that you see on yours.
Using 1-bit TIFF rasters prrofs, which are simple dot-matrix pictures, having no possible re-interpretation, meaning having no possible mis-interpretation, makes you sure that your customer sees on his screen exactly the same that you see on yours.

And third, Acrobat displays on an RGB additive monitor and your press prints on paper with CMYK soustractive inks: no need to say that such a difference in color processing brings huge differences between the computer display and the printed paper...
... but, beyond the obvious difference of color processing between display and press, there is a bigger problem: the number of levels: a computer monitor is able to display 256x256x256=16777216 color's levels, although your press can only make 8 colours, and without any levels... as a result, the press has to use the screen to simulate different levels of colors using only 4 solid inks and the white of the paper.
As a result, the press cannot print exactly what is displayed on the computer's display, and the computer's display cannot simulate what will be printed on the paper... using 1-bit TIFF rasters to make proofs (paper or digital) allows to keep on the proofs and show to the customer (on the paper proof and/or on a computer display) all the differences due to the screening.

 

[Puch]

It's not about Epson or any inkjet printing engine, but the software driving the printer (RIP). Standalone high-end proofing systems (GMG & EFI) have modules (paid options) to handle 1-bit TIFFs and render them very precisely, retaining most of the screen attributes and reproduce color to meet the ISO proofing standard delta E differences. I believe that prepess workflow systems (Apogee, Prinergy, XMF, etc.) have the same modules outputting the TIFFs to capable (=very high resolution) inkjet proofers.

Adobe PDF renders: can you elaborate more? If you meant Acrobat: that software tries to be faithful to the PDF but for practical reasons there is a limit what can be done in real-time to display a document correctly. People won't wait 15 seconds for a screen refresh, therefore engineers had to cut corners. The most glaring example of that is the "hairlines" phenomenon, when you see fine white lines on the page where graphic elements meet each other. Of course, these lines are usually not present in the final printed piece, because the CTP RIP has dozens of seconds to render the page, instead of milliseconds on the desktop.

If you're talking about differences between RIPs and rendering engines: most high-end systems now incorporate Adobe's genuine rendering module called APPE, which will produce the same results in very different environments and on different output engines, even if the PDF has layers, unflattened graphics, tagged images. Some proof software manufacturers don't rely on APPE (or Adobe technology at all), rendering the pages with other proprietary of free imaging engines, like Harlequin or GhostScript.

 

[Laurens]

I believe that prepess workflow systems (Apogee, Prinergy, XMF, etc.) have the same modules outputting the TIFFs to capable (=very high resolution) inkjet proofers.

Apogee Prepress indeed offers both options. The Adobe APPE can render a contone proof for an Epson or other inkjet device. Alternatively a separate module can take the 1-bit data rendered for plate output and repurpose those data for output on that same proofer. Most customers render plates and proofs as two separate tasks and the Adobe APPE makes sure both results are identical. There is however a significant part of our user base who prefer to repurpose 1-bit TIFF data for output on a proofer. The descreening takes more resources and leads to a bit of quality loss but on the other hand the proof is always 100% consistent with the plate output. I guess the choice depends on how comfortable people are with their setup and what the cost of a difference between a proof and plates would be. For a print run of a million catalogs, the consistency of proofs is more important than for five hundred flyers.