High quality images

[Dov Isaacs]

Matt,

To directly answer your questions:

(a) FrameMaker does NOT send the original compressed
referenced file to the printer driver. It decompresses
the image and sends that decompressed image to the 
driver. Thus, the original compression in the TIFF or
JPEG or whatever matters not. The drive gets a
decompressed image.

(b) InDesign does NOT (and NEVER did) any actual
scaling or rotation of placed content before sending
to either PostScript or PDF. It simply sends a 
transformation matrix that is used by the ultimate
RIP / rendering device to do the scaling, rotation,
etc. itself.

(c) Pasting of screen captures into a page layout
program is not reliable, disciplined workflow. Such
assets should be kept separate as a file.

	- Dov
 

> -----Original Message-----
> From: Matt Sullivan [mailto:matt at grafixtraining.com] 
> Sent: Monday, January 29, 2007 3:08 PM
> To: Dov Isaacs; 'Framers List'
> Subject: RE: High quality images
> 
> (1) Actually, with multiple 100+ Mb files and poster-sized or 
> larger output, scaling, rotation, cropping and compression 
> take on a whole new meaning.
> When the size of the cache exceeds that of the RAM on the 
> output engine, it's like running Photoshop on 256Mb 
> RAM...everything goes at the speed of the cache disk.
> 
> (2) But Frame does send the compressed referenced file to the 
> driver to perform calculations there, yes?
>  It's been my understanding that InDesign is the only 
> application that pre-processed scaling, rotation, and 
> cropping before sending to an output device. Is that no 
> longer/not correct?
> I've always understood that all other applications will pass 
> the referenced file to Distiller or the RIP, and that 
> processing occurs there.
> 
> Also, did you have an opinion on the pasting of screen 
> captures vs. saving to disk?
> 
> 
> -----Original Message-----
> From: Dov Isaacs [mailto:isaacs at adobe.com]
> Sent: Monday, January 29, 2007 2:50 PM
> To: Matt Sullivan; Framers List
> Subject: RE: High quality images
> 
> Matt,
> 
> Several observations:
> 
> (1)	There is something drastically wrong with your
> RIP if it is slowing down when faced with compressed images.
> 
> (2)	How an image is compressed in a TIFF file is
> irrelevant in terms of what FrameMaker, the PostScript 
> driver, and if you are using a PDF workflow, what the 
> Distiller and Acrobat's print routines do with the image with 
> regards to compression. Any LZW or ZIP compression in a 
> screen shot (or any other image) imported into FrameMaker is 
> absolutely lost when FrameMaker sends the image data to the 
> PostScript driver!
> 
> 	- Dov
> 
> > -----Original Message-----
> > From: Matt Sullivan [mailto:matt at grafixtraining.com]
> > Sent: Monday, January 29, 2007 2:45 PM
> > To: Dov Isaacs; 'Framers List'
> > Subject: RE: High quality images
> > 
> > Dov, one clarification/question regarding your advice for screen 
> > shots...
> > 
> > In my commercial printing experience, I found TIFF to be a great 
> > option for bitmap files including screen shots.
> > However, I always recommended staying away from the ZIP compression 
> > option. Though a "lossless" format, both compression and scaling 
> > tended to horribly slow down our RIP process.
> > Though not much of an issue for small files, there also isn't much 
> > advantage to compressing such small files, either.
> > 
> > In my experience with large full-color CMYK images, the ZIP 
> > compression saved roughly 15% of the file size. For that 
> smaller size, 
> > the RIP time would often increase by a factor of 4x or 5x. 
> Scaling the 
> > image within the application (with the exception of InDesign) would 
> > also slow the RIP. In each case, the application passes the 
> processing 
> > (decompression, scaling, and rotating) off to the RIP. If we're all 
> > saving to PDF & printing the PDF, then most RIP's will 
> hardly hiccup, 
> > and given the speed of most PDF generation, it's doubtful you'll be 
> > troubled by a (statistically) slower conversion.
> > Lesson: Convert to PDF with appropriate settings prior to printing.
> > 
> > Back to scren shots: From my point of view, if saving to PDF the 
> > compression is unnecessary, as you can choose to compress in the 
> > Distilling process. If sending for commercial print, then the file 
> > savings is likely outweighed by additional RIP
> > (processing) time.
> > 
> > For screen captures, my clients have the best success 
> simply pasting 
> > from SnagIt, or their application of choice. As the files 
> would almost 
> > never be modified in a bitmap editor, but simply re-captured, the 
> > image on disk is a bit redundant.
> > Anyone care to comment on the pro's and con's of simply 
> pasting SCREEN 
> > CAPTURES only?
> > 
> > Matt Sullivan
> > GRAFIX Training, Inc.
> > 888/882-2819
> > 
> > 
> > -----Original Message-----
> > From: framers-bounces+matt=grafixtraining.com at lists.frameusers.com
> > [mailto:framers-bounces+matt=grafixtraining.com at lists.frameuse
> > rs.com] On Behalf Of Dov Isaacs
> > Sent: Sunday, January 28, 2007 12:48 AM
> > To: Sean; framers at lists.frameusers.com
> > Subject: RE: High quality images
> > 
> > I must strongly disagree with ANY advice to resample screen 
> shots at 
> > any stage of the workflow prior to the RIP.
> > Although this might not be intuitive, upsampling a screen shot in 
> > Photoshop (or name whatever tool you like) prior to importing or 
> > placing into FrameMaker (or name your favorite layout program) can 
> > indeed lead to lossiness. Despite what many print service providers 
> > will tell you, all images are resampled at the RIP (whether 
> > downsampled or upsampled) to match the combination of the device's 
> > actual resolution and the screening algorithms in use. And such 
> > resampling is typically of quality comparable to the best 
> you can do 
> > in Photoshop. Since resampling is done at the RIP anyway, doing a 
> > "manual" upsampling prior to the RIP process may cause real 
> content in 
> > your image to be lost. For screen shots, such data 
> lossiness can yield 
> > really crufty results. And such extra resampling prior to the RIP 
> > process violates the "reliable PDF workflow" principles.
> > 
> > 	- Dov
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
>