maintaining image quality when reducing size

[bsmyth]

When creating documentation primarily intended to be read online, is it an inevitability that reducing the size of an image--and by size I mean vertical and horizontal length in pixels--will lead to a bit of fuzziness in the resulting smaller image? Especially when you're looking at type?

Here's what I mean. This first image below is a sample of this screen captured with SnagIt, at the original size.



(You might have to keep clicking on the image to get to the original, crisp image at its original size.)

This second image is the same image reduced to 980 pixels across in width, which is the size I want to use. You see how the typeface is a bit more fuzzy? (Click through to the original as needed.)



There are so many factors involved in changing image size--pixel size, pixels per inch, monitor resolution, algorithm used to resize the picture, compression, image format (jpg, png), etc. etc., that I'm getting confused and don't know what to concentrate on.

So I thought I'd start with a basic question: am I expecting too much to have a resized, downsized image have the same sharpness as the original?

Resizing an image to a size LARGER than the original is whole other ballgame and not what I'm asking here. I understand that there's a more inherent problem in that scenario since you can't add information that's not originally there.

Any thoughts would be greatly appreciated--thank you!

[RamonS]

I don't have any specifics, but downsizing means reducing the amount of data. Every time you take something away you get less, which in case of an image results into this fuzziness. Even when the dimensions remain the same, but you reduce the resolution the tool you use needs to make a decision which pixels it keeps, which it throws away, and which one it redos to mix two or more together.
That said, you can't expect the quality to be the same after processing, although you as anyone else would love that. I do agree that the handling of images in help both on screen and in print is a ridiculously tedious task that usually delivers less than satisfying results, although I find printed output to be more forgiving than on screen output.

What you may want to try is to reduce the size of the images to begin with. Rather than capturing an entire dialog capture individual parts of it. That way the original will fit and you have less work with better quality. Alternatively, you can throw the entire screen shot idea overboard and use screen portraits instead, which are easier to resize, rescale, reduce, or re-something-else. Fellow MVP Andy Robertson wrote an nice article about it, which by now is probably a tech writing classic. See here: http://techwritetips.wordpress.com/2006 ... portraits/

There is nothing wrong with circumventing the issue.

[SteveS]

I also find certain percentages (or set sizes) work better than others.

It may well be forcing a resize to 980 is blurry because of the process used to reduce the image. For example, a one pixel wide line from the original image is always going to be relatively bigger in a resized (smaller) image which will create bluriness.

[RamonS]

I also find certain percentages (or set sizes) work better than others.

I agree, and my experience is that the quality is better when the downsizing/scaling is done by an even fraction. That way the process doesn't have to make e.g. 5 pixels out of 8, but an even 4.

[Cecily]

I don't have any other answer, but a couple of workarounds that I use are to have some graphics either drop-downs or thumbnails. Not quite what you want, but you get more text per screenful and users can choose whether to expand the images.