When I try to use Explorer to rotate an image from my 5MP Canon
Powershot A95 camera (2592x1944 px), I get the following warning
message:

"Because of the dimensions of this picture, rotating it might
permanently reduce its quality. Rotating a picture automatically saves
it using the original name. To save a backup copy first, see 'Copy an
image' in Help.

Do you want to proceed?"

I've discovered that Windows will give you this warning if the image
dimensions are not a multiple of 16 pixels in size. This leads me to
believe that Windows usually uses a lossless block transformation when
it can. My question is, what does it do when it can't?

Does it recompress the strip of 8 pixels on the edge of the picture
that couldn't be rotated? Or does it recompress the entire image?
Does anyone know?

Okay, I made a copy of a JPEG, rotated it clockwise 24 times, and
compared it to the original. I figured if they were smart about it,
they'd only recompress the strips along the edges that didn't fit into
16x16 blocks. (Or just trim them off entirely. I don't think I'd miss
a strip of 8 pixels on the edge of the picture too badly.) But as it
turns out, there was obvious quality degradation throughout the whole
image. So they must be decompressing, rotating, and then recompressing
it. A pity they couldn't be smarter about it. I wonder if I can
change the rotate buttons to call into jpegtran or something and do the
job properly?

Another gripe: In the Exif properties for a JPEG, why is "Flash Mode"
always blank?

This is not the way compression works. JPEG compression works on the entire
image and reducing file size is basically done on color information but at
one point you can see deterioration if you open and Save as this file many
times.
The idea that you can see a difference, using a 5 MP image, and rotating it
a few times, your eyes are much much better than mine.
However, rotating it 24 times is a nice experiment to do. At least you know
you can't do this and you learned something, but nothing is lost by rotating
the image once or twice.
If you want to push your experiment further, print the original, number 2,
9, 15 and 24. Then ask some friends to rate them. You could be surprised!
This kind of experiment has been done many times (when digital cameras
started and with much lower resolution) and several results were published
on the internet (now gone for obvious reasons) with 24 the winner (by a few)
but really nothing very distinctive between the original, 2 and almost up to
9. But remember that these experiments were done with 1 and 2 MP cameras
images.

<stanmuffin> wrote in message
news:9810
[..]

> This is not the way compression works. JPEG compression works on the entire
> image

Actually, it works on small blocks of pixels, typically 16x16, and it's
possible to do certain lossless transformations on these blocks:

[url down]

Using this program to rotate an image through N * 4 number of 90 degree
rotations should yield a mathematically identical image to the
original. However, jpegtran does not, as I had supposed previously,
recompress partial blocks in areas around the edge of the image.
Instead, it leaves them completely alone, meaning there will be an odd
strip on the edges of the rotated picture if its original dimensions
were not multiples of 16. The -trim command line option will cut them
off, which is likely worthwhile for big digital camera photos where
there's probably nothing interesting on the edge.

If you use jpegtran. But the jpeg compression idea is to compress using
color information first. Since we don't know (at least I don't) how XP will
do this when rotating the image, it is safer to assume that the entire image
will be compressed again to fit the new orientation and aspect ratio. With a
5 MP resolution I certainly would not worry about it. But really the only
way to know would be to make a copy of the original picture and then play
with it to see what you get.
Can you let us know how this ends up?
<stanmuffin> wrote in message
news:7630
[..]