Moire problem from DCS files

[Tech]

Hi All,
I searched the web and can't find a good answer to our moire problem.

Here's the situation, we have about 2 dozen pages of b/w bitmap images @1200ppi with a clear moire visual on screen and on 1200dpi b/w laser print out. Image files are supplied by an unknown outside scanner, to my understanding these images are scanned from various collections of old films to DCS. Yet, we are supplied with only 1200ppi images and are told these files will run fine on 2400ppi/175 linescren press??? Something is not adding up here and I know our supplier is just being lazy on trying to resolve the issue.

Correct me if I'm wrong, doesn't DCS scans original films at 2400ppi or higher to capture output resolution and thus avoid moires when reproduce again on a different press? Has a new technology been introduced that I'm not aware of regarding saving down DCS files to 1200ppi and still reprint correctly without moires? We can't figure out the advantage on saving down files to 1200ppi except file size?

At this point, we are insisting on getting original DCS files from suppiler, if a 1200ppi image prints to 1200dpi b/w laser and still clearly produces moires, we can't take that leap of faith based on their words.

Adding to the confusion here, files with moires, converted through either Acrobat/Distiller, the print outs are cleaner than outputs from InDesign/Quark. Does this make sense to anyone? What is Acrobat doing that InDesign/Quark isn't?


Any ideas? Thanks!

Edited by: Happy on Jul 8, 2008 11:25 AM

 

[gordo]

Re: Moire problem from DCS files

DCS (Desktop Color Separation) is just a separated file format. The individual files may be either grayscales or bitmaps. A 1200 dpi bitmap should image fine on a 2400 dpi device. If the file to be output has been scaled - i.e. not printed at 100% size then it will moiré. If the bitmaps were originally 2400 dpi and someone has resampled to 1200 dpi they may have introduced a moiré. If you view the bitmaps at 100% and see a moiré - that suggests that the moiré is in the original scan. I don't believe that proofing to an inkjet device will provide an accurate reflection of moiré in the file. If you can, have one of the bitmaps output to positive film - that will show whether there really is a moiré in the file. InDesign/Quark should not be doing anything other than sending each screened plate to output. Resampling/scaling/converting to grayscale will cause moiré.

hope this helps, gordo

 

[Tech]

Re: Moire problem from DCS files

Hi Gordon,
Well, here's the kicker to the problem, we didn't received DCS files even though we know these files has to be scanned from their film archive. We received bitmap TIFs@1200 then EPS@1200 of the same files. We have requested for DCS files from the start, why they didn't provide what we need is a mystery to me.

Files will be output @100% and I do agree majority of files @1200ppi should reproduced correctly on a 2400 dpi device...although, adding conflicting info to this problem is that every pre press file requirements for scanned bitmap/DCS images are stated at 2400ppi by various printers on the web including ours. Neither them nor us have in-house output device that can produce a more accurate proof. They provided no other printed samples that ran with these files. Which is why we can't trust theirs words and go to press with these files as is. Is there no other ways to test moires accurately?

BTW, when viewed @100% on screen bitmap appears cleanly separated as dots and no moires. I feel like concluding we may have gotten over our heads on these files and "perhaps" were wrong and were deceived by optical illusions... but we still need to have printed visual @100% to convince my supervisor and everyone involved as well as a set to travel with press files for our printer. Just because files look okay on our screen may not translate the same once on press running at 2400dpi. It's a big "IF" hanging over our heads.

In short, I do believed they re-sampled all files to 1200ppi and "maybe" introduce moires to 2 dozen or so files that has screens of black. It's the lack of hard proof/evidence that's making everyone uncomfortable with this job. It's an important product, and any screw up could mean someone may be out of a job in coming months.


Edited by: Happy on Jul 8, 2008 7:29 PM; Edit again to make sure I'm making sense...

 

[gordo]

Re: Moire problem from DCS files

IMHO, you have three choices.
1) Find your ugliest employee. Give him/her a baseball bat and have them pay a visit to your client. (prepress meets the Sopranos)
or
2) Fire the customer. Let your competition lose their shirts
or
3) Express your concerns to your customer and have then provide a person to press check. Because these are bitmapped files - what they gave you is what they will get. Your digital hands are tied. Your only job is to print those bitmaps as accurately as possible. Too much dot gain? Their problem. Moiré? Their problem.

sorry, gordo

 

[Tech]

Re: Moire problem from DCS files

Haha, you just put a smile on my face... we already tried#3, #2 is not an option--since the same people will provide source files that are tied to two more similar products (I'm not looking forward to them)... and I like to pick choice#1!

TBH, I believe we are in the rights, but again regardless what we know as facts (1-bitmap images should match device output resolution to avoid moire), we are not getting what we are requested.

 

[rich apollo]

Re: Moire problem from DCS files

Have you considered sending the questionable files out for an Approval or Final Proof?

 

[Tech]

Re: Moire problem from DCS files

Yeah, we did finally sent files out for test... if we knew these folks would be so difficult in providing exactly what we request for, we would have done it earlier.

The saga continues...

 

[michaelejahn]

Re: Moire problem from DCS files

I became very suspicious after reading your first sentance...the part where you feel you can actually do a visual quality control check using your screen (monitor) or some "printer" that you might "think" is at 1200 ppi (it probably is close, but more likely an emulated / interpolated 1200 ppi, often with a marking engine having a different addressable resolution in width and length...

The fact is, you cant tell if something will moire on a computer monitor, and you can't really expect a device to "simulate' things like a moire. If you image on a device with the exact same resolution as will be used to make your digital plates, then you can (as you discovered when you pulled a Kodak Approval.

Yes, that is a tricky type of problem you were handed and of course you used all the tools that were available to you, but none of these tools really gave you the feedback you need to check and see if things were okay.

Copydot scans are always tricky, but honestly, most of the ones I have come across were made from film that was scanned and you just have to trust the files.

Let me ask you this - what exactly would you do if the file proofed with a moire - not much you can do with a set of 1 bit tiff files !

 

[Ricketysmurf]

Re: Moire problem from DCS files

Happy

Moire is caused by two colours clashing together, you said your DCS's were black and white. Therefore this is purely a resolution problem.

Shot in the dark here but what I think the problem is is one of RIP resolution. The Rip used to make the files would be set at one particular resolution, whilst yours is set at another, which if one looks at the settings, is correct, however often there is a slight difference between yours and theirs, this can often be the difference between imperial and metric conversions written into the software.

Some rips were originally coded in imperial and have Metric conversions in page set ups which will be slightly different when actually Ripped.

I once had to set a resolution at 1199 instead of 1200dpi to get rid of the pattern.

The resolution of a DCS scan is whatever you set it to on the scanner but generally commercial machines are set to 2400 and newspaper scanners are set to 1200.

Also open the DCS in Notepad or Wordpad and see what the resoloution is according the the code.

The only other solution would be to use Creo's software that will revert the images to contone again and allow you to re rip through your own systm. The name evades me but I'm sure Gordo will oblige with the correct epitaph.

Regards

Andy

 

[ar17]

Re: Moire problem from DCS files

the software name from creo is CTK, copydot toolkit. it could well be a resolution problem which causes the file to create artifacts. need to check the resolution of the imagesetter and the file...

 

[alang66]

Re: Moire problem from DCS files

Copydot Toolkit is good software, it wouldn't produce a moire. I don't think anybody has mentioned the fact that the film may have had a moire or was not registered well enough. In Renaissance, their is a module called Integrity which rotates and positions the bitmaps to register them to each other. This is done partly automatic and partly user interaction. As far as I know, these are at 4000 dpi at this stage.

You cannot scan at 1200 DPI with Renaissance you can only output from Integrity at 1200DPI. A 1200DPI bitmap should output with no moire when output at 100% scaling with no distortion anywhere in the workflow.

The key question is, what kind of moire is occuring? A screen problem moire only appears when multiple screens are printed together whereas with copydot files, if you scale or resample, the moire will be apparent on a single plate and will be large well defined squares not soft edged square moire like screen clash. Copydot systems reproduce film exactly. If the film was shit, it will reproduce the shit prefectly - screen clashes and all!
Logically, I would do the following (in this order):
a) measure angles and rulings of the different screens in the DCS from existing outputs. Are there any of these angles clashing and are there any dark colours on the Yellow angle as Yellow intentionally has a moire. If it is not a CMYK file, it is very easy to get moires. A 5+ colour screened job is difficult to do without screen clashes on AM screening.
If it does there is a problem with the screening on the original film and cannot be fixed
b) Check a single plate when run at 100% scale. Does this have the moire?
If it does then either 1) the resolution must be incorrect or mismatched from the output device. or 2) there is some scaling being applied somewhere prior to final RIP.
If this is the case, complain to supplier as they need to supply at correct resolution for output.

One last thing - you are right about the 1200 DPI for 2400DPI output - it wouldn't produce a moire but the quality would be less than a 2400DPI. 1200DPI is ok for screens up to 120# but not to produce decent tones at 175#. The 4000DPI scans won't be available probably now (this is the reason for CTK - to resample/reformat copydots after output from Integrity). The 1200 DPI scans cannot be fixed without re-scanning and I feel this is the reason you are not getting much joy and just getting excuses out of your supplier. Insist that the copydots need to be 2400 DPI. You are quite within your rights as the DCS is not fit for purpose.

Edited by: Alan Guest on Jul 10, 2008 5:03 AM

Edited by: Alan Guest on Jul 10, 2008 5:06 AM

 

[Andy]

Re: Moire problem from DCS files

Hi Michael.

> The fact is, you cant tell if something will moire on a computer monitor

Being someone who I've noticed has posted a number of technically accurate things, you're not someone I'd like to contradict, but I have to disagree with your statement there. The ability to visibly detect moire between plates and on a single plate is something you can do on a monitor and something we promote all the time with our product. I do it all the time when I demo FirstPROOF and did so dozens of times every day at Drupa recently.

There are three types of moires you can get and detect on a monitor. There is a fourth type we currently can't detect (screen mesh moire - actually I don't think any s/w currently can), but we're working on adding it to FirstPROOF.

1. screen/halftone moire between separations - this moire is easy to detect and see.
This moire is caused by interference patterns between the different halftone dots in the separations. To eliminate (reduce) these (to a rosette), you need to use the same freqeuncy in all the screens in all the separations and make sure your angles are all 30 degrees apart (other than the Yellow).

Our product FirstPROOF Pro has a "View Black" Tool which was designed/added explicitly for this purpose. Select any number of separations (>1 ), find an area of overlapping halftone and enable this tool (whilst viewing at 100% - Actual Pixels as we call it). You will immediately see if there is any moire between the separations. If you have the Yellow separation mixed in with any others and are using AM screening, you will see moire. Since you always ignore (to some extent) the moire produced by the Yellow separation, we always recommend you disable this separation when checking for moire.

Note that if you just view the separations in color and don't use our "View Black" Tool you will not see any moire.

Also, if you then want to see why you have screen/halftone moire you can use our Auto-Screen Tool to automatically measure the halftone frequency/angle to see what caused it - as said before, the screens should all have the same frequency and be 30 degrees apart (apart from the Yellow, given a normal screening set).

2. content moire within a separation.
This is the sort of moire that is being described here by the original poster. It is usually caused by scanning a 1-bit image and downsampling it somehow, either by scaling the image down, or RIPping it at a lower resolution. If the original scans were done at 2400 dpi and downsampled to 1200 dpi then this process can introduce moire. It's to do with the sampling ratio being used (2x2 in this case) interacting with the halftone screen periodicity/pixels.

If the DCS files were not DCS files but say TIFF files, then you could load those TIFF files into FirstPROOF and again by viewing (individual separations) at 100% with the View Black Tool you can see if there is any moire there. In this case though, it does take a little bit of training for someone to be able to know what they are seeing and so notice the moire. So it's not as easy as in the first case. But it it do-able.

3. fabric moire within a separation.
This moire is caused by something such as the weave in a fabric, or the pattern in a fabric (e.g. a nurse's uniform, or chef's uniform) interacting with the halftone screen. Again this can be detected by viewing at 100%, possibly with the use of the View Black Tool in FirstPROOF, although this case is harder than the previous one of content moire. Again this case needs a little training. In fact with this case I have samples from a printer that asked us how to use FirstPROOF to detect this type of problem, which I helped them with.

However, I do agree with Michael that you have to be careful when you are looking to see if there is moire if you start re-sizing (resolution wise) the original data. If you use FirstPROOF and zoom out, then this process (of resampling) can introduce moire. Similarly, if you load the original data into Quark and it re-sizes it when it display it, that too can introduce moire. If you print it any any resolution and any re-sizing is involved, then again that too can introduce moire.

However, if the printing only tranfers "pixel for pixel " that data from the original data to the print (e.g. if they both are at the same resolution - as is what effectively happens in FirstPROOF when you view at 100% - Actual Pixels), then you will be able to see if there is moire or not. So if your printer is 1200 dpi and the DCS is 1200 dpi and there is no resampling going on in the rasterisation process (mind you that's not always easy to know) when outputting your 1200 dpi DCS to your 1200 dpi printer, then you could use the print to check this. I did this many a time when I was at Harleqiun so know from having done it that it can be done.

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com

 

[Andy]

Re: Moire problem from DCS files

Hi Happy,

To give you some direct info your problem:

1. If the 1200 dpi scans have no moire in them, then they should output fine at 1200 dpi.

2. If the 1200 dpi scans have no moire in them, then they should output fine at 2400 dpi. That's because each 1x1 source pixel will get scaled up to exactly 2x2 pixels.

3. If the 1200 dpi scans have moire in them, then they will output with moire at 1200 dpi.

4. If the 1200 dpi scans have moire in them, then they will output with moire at 2400 dpi. That's because each 1x1 source pixel will get scaled up to exactly 2x2 pixels and the moire will be preserved.

5. If the original films were printed at 2400 dpi and scanned at 1200 dpi then you might get moire in your scans. This is going to depend on the halftone frequency/angle of the original films. If the halftone frequency were such that the halftone cell size used were 'even' (at say 0 or 45 degrees), then you should be able to get a 1200 dpi scan with no moire. But, if the halftone frequency were such that the halftone cell size used were 'odd', then you could get some moire. So in some cases a scan will be fine and in others it won't, depending on the halftone screen frequency/angle in the original print.

So if you are seeing moire when viewing on screen (assuming you are viewing 1200 dpi 1 (1200 dpi DCS pixel) to 1 (96 dpi screen pixel) actual pixels and not those 1200 dpi pixels scaled down to 96 dpi or whatever resolution your monitor is) and when printing at 1200 dpi, you will get moire when printing at 2400 dpi.

And again here I have to possibly disagree with Michael - if you are seeing moire on your 1200 dpi printer (and it is a true 1200 dpi printer, not interpolated in any way) from your 1200 dpi DCS files then you will see moire on your 2400 dpi output.

The above are general statements. Note though that sometimes you will not see moire on one device compared to another due to the 'sharpness' of one device vs another. E.g. a device that exposes pixels with 'soft-edges' (low exposure) might not show moire (quite so much), but a higher-end device with 'sharp-edges' (better focused exposure) might show moire (more). Ironically, this can be a case where better is worse - e.g. your very expensive output device with a sharply focused dot can show moire where a lower end device with a more badly focused dot might not.

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com

Edited by: Andy Cave on Jul 10, 2008 11:43 AM

 

[Tech]

Re: Moire problem from DCS files

@Michael,
You are correct, there is indeed NOTHING we can do if these 1200ppi files in question do proofed with moire... supplier refused to re-scan and gone as far as having their pre press swear by the quality of their files and still without providing any printed material to backup that claim. This translates to someone biting the bullet if they are wrong... not really the best solution/option if you ask me.

@Everyone,
I apologize for confusing OP and truly appreciate all the feedbacks. A.Cave's last detailed post confirms what I have concluded as well. I just can't write as eloquently as he does! >_<.

Same supplier had previously provided us with 2400ppi DCS files, a handful of those had moire problems when proofed and were replaced, this is why I don't trust them nor their pre press. Sadly, we are stuck with these 1200ppi files now (due to laziness as far as I can tell on their part) and must move forward somewhat blindly.


Thanks All!

 

[Andy]

Re: Moire problem from DCS files

Hi Happy,

I guess when you say you will have to move forward blindly, you will go to plate/print. I'd be interested in knowing how it goes (even if I'm right or wrong).

PS When you say b/w, I presume[d] you mean[t] these are all 1 color, single separation Black pages/jobs (being printed with only Black ink).

Thanks,

Andy.

 

[Tech]

Re: Moire problem from DCS files

Hi Andy,
Yes, the scans we have are 1-bit black plate files. We will go to print with these files as is, although I won't be able to give you guys an update for weeks to come. I'm not as worry anymore since someone else basically put his/her head on the chopping block, not that I wish this person ill. I would rather have correct files and proofs as we have requested.

I'm sure the consensus/evaluation here is correct, moire due to change in resolution/original film screen rather than "I said so" by this person without providing original scan info/film conditions or printed materials using same files.

 

[michaelejahn]

Re: Moire problem from DCS files

@ Andy Cave,

I am but a traveler and a student of life - everyday I learn more about what I do not know.

They other day, I discovered that if you are fishing for your keys in your motorcycle jacket and while walking down the stais, and you trip, you really cant get your hands out of your pockets fast enough.

Up to today, my experience - as well as 6 years with AGFA as a product marketing manager - has brought me to this way of thinking;

Besides the several press related issues such as mis-registration, slur, doubling that might (and often are) the cause a press side morie, since no system can predict that - morie is simply always there, somewhere, on every sheet - sometimes it is more noticeable than other times, unless you you are using FM screening - so, while investing large sums of money into detecting something like a "oh crap!" predictor might make sense when taking in "free range" files form the great unwashed, this moment normally if solved with a quick "who sold this job, lets fire him immediately" sorts of action.
.
Common wisdom (?) -- (remember, this comes from a man too stupid to know about that "hands in the pockets = BAD)...

-- unless your monitor has the ability to display a 2400 ppi file at 100% - that is, unless you a monitor that can resolve 2 (two) distinct spots that are 1/2400 of and inch in height and width and display them (i suppose you would then need a Loupe to then see if they are are distinct )

- I do not see how you could somehow display the same moire as I might see on a press sheet.

That being said, all I have seen with my tired old eyeballs is AGFA PrintDrive and Creo CopyDot tool kit (that comes with a viewer) - neither of which ever claimed to "predict moire" or "display moire" or even sing "Ava Morie"

Andy - claim that you can "simulate" a moire at "100%" - using some preview tool on screen - (i think i have that right) -- after reading your post several times I am pretty sure I am understanding that this would mean that on a 96 pixel per inch, that "view at 100%" would mean that I would be looking at what - about 1inch of the page at any given time ?

And while all would agree that displaying a 2400 ppi file at "100%" would be possible, you are suggesting that if I were to look at a 1 inch section of something like a small part of a face on a model - that I could see a moire (if there was one)...

Simply amazing - please send screen captures to [email protected] - and I will prepare the right sized pot with boiling water that would accommodate a hat, as it would seem that I may be having hat for dinner.

 

[Andy]

Re: Moire problem from DCS files

Hi Michael,

I think we all learn something new everyday; I certainly like to, hence why I like to question what people write, even my own posts.

I don't know about hands in pockets, but to explain my background for those that don't know, I was the original founder of the Harlequin RIP division at Harlequin (when it had three divisions, of which the RIP division was one) 21 years ago. I worked there for 12+ years as the Chief Designer. Amongst many of the things I invented and coded in the Hqn RIP (Output Controller, PGB compression, a lot of the interpreter, the display list architecture, color conversion engine, image handling engine,...) I also wrote the original screening (RT) engine and also invented/designed/coded HPS (all self taught by the way here). One of the key things when creating HPS was clearly the aim of eliminating moire from halftoned screened areas that were imaged, the original RT screening that I wrote having (by virtue of the maths involved) moire. To do this required getting equal frequencies in each separation, along with accurate angles. However, this was only half the story, as anyone who has tried this will tell you that you are left with moire (patterning) problems inside individual halftone screens which you must remove. The later work I did on HPS (which you can see in the Hqn RIP by virtue of the HPS2 checkbox) went further than I'd originally gone in eliminating moire (patterning) problems inside individual halftone screens. There were also many things that were tried in working on this problem, some with very interesting results that were never taken to completion, or abandoned part way through development for alternative ideas or ideas that seemed to have more potential. For the many weeks/months that I spent developing HPS and HPS2 the main tool I used for this was the ROAM in the Hqn RIP (painful in comparison to FirstPROOF, but that's all I had at the time). In addition to that, over the many years I worked at Harlequin we had the odd bug come in, which required jobs to be ripped and inspected for the bug, which would then need resolving. Again, it should come as no surprise to you that the main tool that I used was the ROAM in the Hqn RIP. It was that experience over those many years of looking at jobs with halftones in roam that partly led to the development of FirstPROOF and the knowledge/experience I have of how you can detect moire on screen.

It's interesting you mention other press related issues that can lead to moire. We have had a number of customers that have asked us to add a mis-registration tool to FirstPROOF. Of course in that case the tool can't predict if moire will occur (due to mis-registration), but can only give you an indication of what it will look like if it does occur.

I think you've misunderstood what I wrote in my post regarding how the 2400 dpi image is displayed on the monitor. I did try. What I was trying to say (by Actual Pixels as opposed to Actual Size) is that you display the 2400 dpi image pixel for pixel at the screens 96 dpi - so no downsizing or resampling is occuring (which is important as this will introduce moire of it's own). So the image is much larger, 25 times in fact. But if you do this, you can see moire; sometimes easily, although sometimes it takes an understanding of what you're seeing and knowledge of how that will end up on film/plate/print., something I had to develop when I was working on HPS[2].

> That being said, all I have seen with my tired old eyeballs is AGFA PrintDrive and Creo CopyDot tool kit (that comes with a viewer) - neither of which ever claimed to "predict moire" or "display moire" or even sing "Ava Morie"

I guess here again is where experience counts, or to be more precise relevant experience. I spent enough time at Harlequin looking at screen ROAMs (vs film/prints) containing halftones and seeing moire that I knew how to - one of the key things we always used to do here was change all the separations to view as black, as this greatly aided in seeing moire (hence why FirstPROOF has a View Black Tool). The Creo guys probably spent a lot less time doing this and so didn't realise what they could do. Interestingly, they did realise that you can spot front-to-back alignment issues when viewing a front and back page using the viewer in CopyDot tool kit and applied for a patent on it (since lapsed).

Anyway, if you don't (want to) believe me, go try for yourself. Download FirstPROOF, get some TIFF files with moire in the CMK seps and try it in FirstPROOF (using the View Black Tool).

You can also see this if you go to http://www.hamillroad.com/main/products/firstproofguide.htm and download one of the Guides on the left hand side (I suggest you download the Medium compressed version). On page 9 of the "FirstPROOF Guide to PrePress Soft-Proofing" you'll clearly see two screen shots of a job - one with moire and one without, clearly shown. In this case the moire shown is between separations, but I could just as easily add into the guide another case of moire within an individual separation and show how to detect that. In fact that's a good idea which I'll look to do some time.

Oh and for anyone who doesn't know much about screening et al, there's a Dot Gain Invention White Paper I wrote at http://www.hamillroad.com/main/products/firstproofpro.htm, which gives some useful / relevant background info on screening in the introductory section (although it doesn't go into patterning problems within a single halftone screen).

PS I've tried to keep what I wrote 'simple' and 'short' (difficult for such a complex subject), but there is a method I've devised where you can zoom in/out to check moire and tell if the moire is inherent in the image, or introduced by the zooming in/out. But that would have made what I posted even longer, so am leaving out.

PPS I think you're safe on your Hat Soup, as I think you just misunderstood what I posted.

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com

 

[michaelejahn]

Re: Moire problem from DCS files

you wrote;

I think you've misunderstood what I wrote in my post regarding how the 2400 dpi image is displayed on the monitor. I did try. What I was trying to say (by Actual Pixels as opposed to Actual Size) is that you display the 2400 dpi image pixel for pixel at the screens 96 dpi - so no downsizing or resampling is occuring (which is important as this will introduce moire of it's own). So the image is much larger, 25 times in fact. But if you do this, you can see moire; sometimes easily, although sometimes it takes an understanding of what you're seeing...."

1. No, I fully understood what you said originally - as i wrote this;

Andy - claim that you can "simulate" a moire at "100%" - using some preview tool on screen - (i think i have that right) -- after reading your post several times I am pretty sure I am understanding that this would mean that on a 96 pixel per inch, that "view at 100%" would mean that I would be looking at what - about 1inch of the page at any given time ?

you said "So the image is much larger, 25 times in fact" I said ""view at 100%" would mean that I would be looking at what - about 1inch of the page at any given time ?"

- we are more or less saying the same thing...

I will (however) dispute that one can "see" moire - as some moire will not be 'see-able' over such a small area. Yes, page 9 shows two (2) plates - ah, if we were all so lucky - most mories are when three plates are involved.

Anyway, nice sparing, but I am left largly convinced that I was right - until I am using the same screening as the platesetter, with the same marking engine - i can't predict a morie on a physical dot proof, and I certainly can't 'view' that in color on a 96 ppi monitor.

So, we shall disagree here, but I will take the time to download and test.

 

[Andy]

Re: Moire problem from DCS files

Hi Michael,

OK - seems like we are talking about the same thing then.

The moire on page 9 that is shown, is as a result of 3 plates, not 2 as you say.

One of the other tools in FirstPROOF that also helps with detecting moire is the Dot Gain Tool. With that we can simulate the dot gain of a CtP device (or film) and in some cases that too can indicate moire that otherwise one would not easily have seen. The main thing that I said is turning the colors black with the View Black Tool.

I can also see individual moire within separations (as per this posting) using FirstPROOF - in some cases this can be emphasised and so more easily seen using the Dot Gain Tool.

I would have to agree with you that there are some cases which it's hard to detect on screen and it's possible that there are some cases which you couldn't easily detect on screen (or possibly not detect) due to the size of the moire, but in my experience, a lot of moire's you can. In fact large moires across the page you can 'see' by virtue that the rosette structure on the screen that you see with FirstPROOF drifts in/out from a clear centered to a dot centered rosette - in fact one of the demo files I was showing at Drupa was exactly this case.

With FirstPROOF working on the RIPped data, we do use the same screening as the platesetter, and with the Dot Gain Tool we can simulate the output of the marking engine. I guess this is important, as every other s/w or h/w or printer that does a dot proof, whether it be soft or hard, does not have a tool such as our Dot Gain Tool, which physically emulates an output device (be it film or CtP) something which is unique to FirstPROOF (and we've applied for a patent on).

Not sure what you mean about sparing; I've jut been writing down my experience as to what I've done in the past and do now.

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com