Strange dot

[LauraMinter]

Has anybody ever seen a 50% dot structure like this. I know it only reads 48% but I am more concerned about the structure of the dot than the calibration at this stage. It was done on a CTP device, 200lpi, 2400dpi and the platereader is a Lithocam. If we play out a 175lpi, we do not have the same problem. It is definately not a hardware problem because if you play out an internal test page at 200lpi, the dot structure is fine. So it is something to do with the algorithm of generating the dot structure. I am sure that it will not have a bearing on the quality of the print, although at this stage who knows. Any imput will be invaluable.
Kind regards

 

[Green Printer]

Has anybody ever seen a 50% dot structure like this. I know it only reads 48% but I am more concerned about the structure of the dot than the calibration at this stage. It was done on a CTP device, 200lpi, 2400dpi and the platereader is a Lithocam. If we play out a 175lpi, we do not have the same problem. It is definately not a hardware problem because if you play out an internal test page at 200lpi, the dot structure is fine. So it is something to do with the algorithm of generating the dot structure. I am sure that it will not have a bearing on the quality of the print, although at this stage who knows. Any imput will be invaluable.
Kind regards

If you send the same file mutiple times do you get exactly the same results? If you do call the rip manufacturer. Post a PDF of the file used to make the screen. Members of the forum could run it and see if they get the same results.

 

[LauraMinter]

The problem is not with a specific file, but with a specific workflow/rip vendor. We have tried using the same workflow/RIP but output to three different platesetters, and we get exactly the same result. Initially my customer was told that the problem might go away if he upgrades to the latest version, which he has done but the problem is still there. I have also been told that I am being too pedantic as the enlargement on the Lithocam is huge, so you can see exactly the structure of the dot. With most plate readers you will not be able to see the structure of the dot.
We have sent the information through to the RIP vendor and is waiting for a response, but have been waiting for more than a month, which is why I thought of posting in on here too see if somebody else has had this problem. Is it a problem? And if so, how was it fixed.

 

[Lukas Engqvist]

Is it an image that is rastered or is it vector art? The reason I ask is that there are sometimes images with a slight dither or noise, this dither could cause such a problem.

 

[Green Printer]

The problem is not with a specific file, but with a specific workflow/rip vendor. We have tried using the same workflow/RIP but output to three different platesetters, and we get exactly the same result. Initially my customer was told that the problem might go away if he upgrades to the latest version, which he has done but the problem is still there. I have also been told that I am being too pedantic as the enlargement on the Lithocam is huge, so you can see exactly the structure of the dot. With most plate readers you will not be able to see the structure of the dot.
We have sent the information through to the RIP vendor and is waiting for a response, but have been waiting for more than a month, which is why I thought of posting in on here too see if somebody else has had this problem. Is it a problem? And if so, how was it fixed.

Do you see such artifacts at different screen percentages?

In all reality it isn't going to make much difference on the press.

It is much more interesting as why or what is causing it.

Is the rip Adobe based or global graphics based?

 

[LauraMinter]

It is not vector. It is a continous tone that is being rasterised. You can also see it if you run a calibration to the platesetter. To take it further we generated a "Stepwedge" with 5%, 10% to 100% tint values and placed it on a page to image all over the plate. It is more noticable on the 50% because of the square dot patern, but even if you look at the other % dots, it looks the same over the whole plate.

 

[LauraMinter]

Did not see the next lot of questions.

I did not think that it will make a difference on the printing, but the customer has noticed the strange dot and now it is an issue. They are a top class printer and likes everything perfect. I think if they get told that this is normal, they will continue on regardless, but nobody is saying anything.

It is not a PDF RIP although in saying that they have just upgraded to the latest version running APPE. I am not sure if they tried it with APPE.

 

[Lukas Engqvist]

When you say continous tone (excuse my asking) do you mean continuous tone image as in pixel based or smooth blend/gradient? If you hava a plain 50% tone you do not get it? Do you have a workflow that first converts to pixel and then resterises? (eg Dalim)
So you have an application to view raster data before the CTP setts it? Would be interestig, need to know if it is pre-raster, raster, imaging, plate or developing that is causing the artifact.

 

[LauraMinter]

We get it in Continous tone image as well as gradients and tints. So when ever the job gets rasterised it creates the dot that you see on the plate. Again, it is not only in the 50%, it is just a lot more noticeable in 50.
The workflow does not first convert to pixel before it rasterizes.
We have looked at the raster data and it is definately on the raster data, so not preraster.
It is definately not the plate as we tried with four different plate manufacturers plates.
It is not processing as we used 4 different processors. More actually if you take into account that we also tried three different platesetters. The only common dinominator is the workflow that creates the raster data.

 

[maxon]

What RIP is it exactly, after all ?
Wild guess... it's hardly an harlequin because the HPS would chip some dots a little bit in trying to avoid patterning and moire but definitely not in this fashion... would rather affect the corners. If it's an Adobe CPSI, could be you tried some illegal/untested halftone there. Hence the good result at 175.

 

[LauraMinter]

I would rather not say which RIP/Workflow it is as I am not the customer, but only an independant consultant who is doing the customers Colour Management on press and proofing. I can tell you that it is not Harlequin, as we did use a Harlequin RIP to go out the the same platesetters and there the dot structure is perfect. It is also not Fujfilm's XMF (APPE) and Celebrant (Adobe CPSI) as I did tests with this as well and that was fine. So yes, it is an Adobe CPSI rip. The screensets that are used comes standard with the renderer so nothing illegal or funny there.

 

[maxon]

Well then, beats me... never seen such artifacts in 15 years plus in prepress but we're all still learning isn't it.

 

[gordo]

Has anybody ever seen a 50% dot structure like this. I know it only reads 48% but I am more concerned about the structure of the dot than the calibration at this stage. It was done on a CTP device, 200lpi, 2400dpi and the platereader is a Lithocam. If we play out a 175lpi, we do not have the same problem.

Assuming that your RIP does not allow your operators to alter how dots are formed (e.g. old Scitex RIP) You may be seeing the result of a combination of two things. Halftone dots are made of clusters of whole pixels. For a certain unnamed RIP, a 200 lpi screen at 2400 dpi results in a halftone dot cell size of 8.5 pixels. Unfortunately the system cannot image .5 of a pixel - so it has to do something with the data. Either ignore it (missing pixel) or add it to another .5 pixel (now an extra pixel). Either way, accommodating the .5 pixel will be averaged out as much as possible by the screening algorithm. The artifacts may be exacerbated by the RIP's use of "noise" to minimize single channel moiré.

However, at 175 lpi the halftone dot cell size is 9 or 10 pixels (RIP choice due to 175 lpi not being an even divisor of 2400 dpi). Since the cell size does not have fractional pixels - the problem disappears.

best, gordo

my print blog here: http://qualityinprint.blogspot.com/

 

[claude72]

a 200 lpi screen at 2400 dpi results in a halftone dot cell size of 8.5 pixels.

??? sure of that??? 2400 divided by 200 is 12, and the halftone cell is 12 x 12 pixels...

They are a top class printer and likes everything perfect.

The formula to get the number of levels (of gray or cyan or magenta or yellow) at a given screen ruling with a given resolution of the imagesetter is :

(resolution divided by screen ruling) squared + 1

With a 200 lpi screen at (only) 2400 dpi, you'll get (only):
2400/200=12
12 squared = 144
144+1 = 145 levels of gray... it's a little bit to low (especially in gradients) for a "perfect printing"...

With a 200 lpi screen, you should better use a 3600 dpi imagesetter, which can/will give you all the 256 levels handled by the PostScript language... (up to 225 lpi).


And your problem of this strange shape of your dots is also perhaps coming from this lack of imagesetter dots to built the screen dot.


With a 175 lpi screen ruling and a 2400 dpi imagesetter, there are 189 levels... it is not as good as 150 lpi @ 2400 dpi (which gives exactly the 256 levels), but it's less bad than 200@2400.


To fix your issue, you simply need a 3600 (best solution) or a 3000 dpi imagesetter (which gives 226 levels @ 200 lpi).



(sorry for my bad english...)

 

[gordo]

??? sure of that??? 2400 divided by 200 is 12, and the halftone cell is 12 x 12 pixels...
The formula to get the number of levels (of gray or cyan or magenta or yellow) at a given screen ruling with a given resolution of the imagesetter is : (resolution divided by screen ruling) squared + 1
With a 200 lpi screen at (only) 2400 dpi, you'll get (only):
2400/200=12
12 squared = 144
144+1 = 145 levels of gray... it's a little bit to low (especially in gradients) for a "perfect printing"...
With a 200 lpi screen, you should better use a 3600 dpi imagesetter, which can/will give you all the 256 levels handled by the PostScript language... (up to 225 lpi).
And your problem of this strange shape of your dots is also perhaps coming from this lack of imagesetter dots to built the screen dot.
With a 175 lpi screen ruling and a 2400 dpi imagesetter, there are 189 levels... it is not as good as 150 lpi @ 2400 dpi (which gives exactly the 256 levels), but it's less bad than 200@2400.
To fix your issue, you simply need a 3600 (best solution) or a 3000 dpi imagesetter (which gives 226 levels @ 200 lpi).

Yes I'm sure of it. My source is a spreadsheet that is used by RIP developer/engineers.
The formula you used is correct for gray levels for a single halftone dot cell, however, that formula does not apply to modern (since about 1989) supercell screening.
That's explained here: Quality In Print: Halftones and gray levels • Part Two
and here: http://printplanet.com/forums/prepress-workflow-discussion/17111-image-res-line-screen#post106752

best, gordo

my print blog here: Quality In Print

 

[claude72]

OK... I understand our misunderstanding...

For 200lpi@2400dpi the halftone cell is 12 x 12 pixels...

... and at 50% the haltone screen dot is 8,5 x 8,5 pixels.

(I'll read your links tomorrow... today it's late! thanks for them)

 

[gordo]

OK... I understand our misunderstanding...
For 200lpi@2400dpi the halftone cell is 12 x 12 pixels...
... and at 50% the haltone screen dot is 8,5 x 8,5 pixels.

No, that's not what I meant. You cannot simply divide the dpi by the lpi to determine the number of pixels in a halftone cell. It's much more complex than that.

best, gordon p

 

[hagar]

Laura,

Are you able to see the rasterized dot structure on screen prior to output? does it match what you see on plate?

To me it looks a bit like very odd scanline slip, I am guessing that the fast scan line direction is bottom to top.
The fact that it works Ok on internal tests, could indicate issues between the RIP interface and the interface on the device, possibly noise on the cable, or pixel timing clock issue. Such issues are useually very noticable, but I have seen very slight issues like this before.

Regards,

Rolf

 

[maxon]

@ Laura : I presume you've already ruled out the Lithocam, by using a Peak microscope to see the result on plate, isn't it ?
I would ask the RIP supplier to check the RIP configuration again hardware platform included, then reinstall everything from scratch and retest.
@ Rolf : what Laura has there is strictly RIP related.

 

[claude72]

The formula you used is correct for gray levels for a single halftone dot cell, however, that formula does not apply to modern (since about 1989) supercell screening.
That's explained here: Quality In Print: Halftones and gray levels • Part Two

I have read carefully the link to your blog... The part one is exactly what I have learned in the past.

And I understand the part two. Thanks very much for these informations.

(and now I also understand how the Smooth Shading system of Postscript level 3 can work, using the habilities of supercells to give much more levels than the single-cell system, and then much more levels than 256 with a 150 lpi screen @2400 dpi)

No, that's not what I meant. You cannot simply divide the dpi by the lpi to determine the number of pixels in a halftone cell. It's much more complex than that.

OK, but... supercells are based on normal cells, simply "associating" two (or more) basic-cells to built a super-cell whose density is a mean of the densities of each screen dot in each of the 2 (or more) together associated basic-cells...

... and all these basic cells, "before" being associated in super-cells, aren't they built like normal cells, with a screen ruling, with a printer resolution, and with a given number of possible dots horizontally and vertically, and the printer fills the cell, more or less, with the needed number of dots to get the needed density???

and the number of possible dots in each side of the cell is not dpi divided by lpi???

If the screen ruling is 200 lpi, you don't have 200 cells in one inch???
and if you use a 2400 dpi imagesetter, which allows 2400 dots in the same inch, don't you have 12x12 dots for each cell???

and a 50% screen dot is not built with 72 imagesetter black dots and 72 white dots???


Sorry, but this needs more explanations!!!