Link This | Email this | Blog This | Comments (2)

Ansel would not approve, part II
October 25, 2007

Apologies to you readers for my gigantic faux pas on the JPEG blog of last week. JPEG is a bad thing for images, but I illustrated downsampling, which is another subject altogether.

Theat illustration should have looked like this:



I learned several years ago that JPEG compression is visibly harmful to every image it touches. I got an assignment from Boys’ Life magazine (published by the Boy Scouts of America). The terms of that assignment required me to deliver my photos as Camera Raw images. I had never used Raw, so I changed the setting on my camera, and did the assignment. When I was finished shooting that story, I did a test shooting both Raw and JPEG (at Highest quality) on the same camera. The results startled me, and since then I have never used the JPEG setting on the camera again.

I could see in first-generation JPEG images (converted in the camera to JPEG) visible artifacts in saturated blue skies that were not visible in the same photo taken and saved as Camera Raw. It took only one good test to prove this to me.

I will never knowingly apply JPEG compression to a high-quality image in any work flow.

Now, let me discuss downsampling... Adobe’s Distiller settings default to bicubic downsampling of images that are twice your chosen output resolution. This is usually a moot point, because few if any images come in at greater than twice the chosen pixels-per-inch resolution (and that’s twice the halftone frequency, typically). So, if you ask for 300 ppi in the PDF file, Distiller won’t downsample any images unless they arrive at greater than 600 ppi. Even images at 599 ppi won’t be touched, so I guess it’s unimportant to worry about this setting.

And, bicubic downsampling will not likely result in any visible damage in images. It’s the best way to do it – if you have to do it at all.

I have seen only one circumstance where downsampling (using bicubic) caused any visible harm. That situation was computer screen captures, whose component parts are square pixels in solid colors. Bicubic made the thin (pixel-wide) lines in the screen captures look blurry, and made these captures appear out-of-register. If you need to do this, use “nearest neighbor” downsampling instead. Or don’t downsample at all.

I had an imagesetter once with a pretty slow RIP upstream. It was running on a 68000 Motorola chip at some extravagant rate like 16.7 KHz. When overly-high resolution images were sent to that RIP, boy did we notice! Sometimes it would take whole days to image jobs, taking all the profit out of our service bureau operation. I responded by carefully resizing images that were excessively high in pixel resolution. This saved time on the RIP, making output more profitable, and allowing us to run more than one job a day.

Today’s RIPs are so amazingly fast that I never even notice bottlenecks caused by high-resolution images. I have run some pretty big files to Prinergy, Apogee and Xitron RIPs, and none of these machines seems to be fazed by the excessive resolution. They churn through the data at incredible speed, and they deliver plates in minimal time.

So, I am turning off JPEG and downsampling. Even if the chance of harm is small, the chance is too great for me.

Posted by Brian Lawler on October 25, 2007 | Comments (2)