Question: is rotating by 90, 180, 270 destructive

[areohbee]

i.e. is there quality loss when rotating "orthogonally"?

I understand it's inevitable when rotating by other "non-orthogonal" amounts, but theoretically, an image could be rotated without data loss when rotating by multiples of 90 degrees.

Can anybody confirm or deny how Image Magick works in this regard?

Thx,
R

[GreenKoopa]

There is no quality loss when you begin and end with a lossless format. If you use a lossy format, such as jpeg, there can be loss simply by loading and saving an image. This is true for most image processing applications. A jpeg image that meets certain requirements can be rotated losslessly using specialized tools.

[areohbee]

Subject format: jpeg.

So, if I understood you correctly, Image Magick will "re-jpeg the jpeg" when rotating by say 90 degrees, rather than "transposing" the data losslessly. i.e. it is not a "specialized tool" as per your definition.

Is that correct?

If so, do you know of such a specialized tool for windows (and/or mac-nix) command-line?

Rob

[snibgo]

IM decodes the jpeg into pixels, rotates, and codes into jpeg. This coding is always lossy. A lower-level tool that understands jpeg more intimately will twiddle the jpeg data to do the rotation. jpegtran is one such tool.

Code: Select all

%IM%convert rose: rose.jpg

%IM%convert rose.jpg -rotate 90 r1.jpg
%IM%convert r1.jpg -rotate 90 r2.jpg
%IM%convert r2.jpg -rotate 90 r3.jpg
%IM%convert r3.jpg -rotate 90 r4.jpg

%IM%compare -metric RMSE rose.jpg r4.jpg NULL:

jpegtran -rotate 90 rose.jpg r1.jpg
jpegtran -rotate 90 r1.jpg r2.jpg
jpegtran -rotate 90 r2.jpg r3.jpg
jpegtran -rotate 90 r3.jpg r4.jpg

%IM%compare -metric RMSE rose.jpg r4.jpg NULL:

Four rotations in IM gives a difference of 2172.36 (0.0331481), ie 3.3%.

Four rotations in jpegtran gives a difference of 0.

[areohbee]

Awesome - thanks! (and I dunno why I didn't think to do the 4 rotation test - good thinking ).

[snibgo]

But beware. I've just seen that the results r2.jpg and r3.jpg from jpegtran are wrong! It self-corrects for r4.jpg.

My copy of jpegtrans is rather old. Maybe the problem has been fixed in more recent versions.

[areohbee]

Thanks again snibgo.

I am using the latest version of jpegtran (Windows .exe) and it seems to rotate OK, I think (?), but loses the icc profile in the process .

ICC profiles seem to be particularly problematic for many softwares, still, even in this supposedly modern age .

Cheers,
Rob

[fmw42]

There have been bugs with jpg and icc profiles. You can search the forum with the link above for "jpg icc" in the bugs forum and find out. Here is one that was only recently fixed. viewtopic.php?f=3&t=23756&p=100831&hili ... cc#p100831

You do not say what version of IM you are using or I missed it. You should always identify your IM version and platform when asking questions. Also search the forum if you are having trouble.

[GreenKoopa]

I am using the latest version of jpegtran (Windows .exe) and it seems to rotate OK, I think (?), but loses the icc profile in the process

Try -copy all to keep profiles, etc.

convert rose: rose.jpg

rose is 70x46, which is not divisible by a 8 or 16 pixel jpeg block size. This makes it a bad test case. I think IM defaults to chroma subsampling resulting in a 16x8 block size.

[fmw42]

see http://www.imagemagick.org/Usage/formats/#jpg_write for the IM defaults and options for -sampling-factor for JPG

[areohbee]

Try -copy all to keep profiles, etc.

There we go - thanks GreenKoopa.

And thanks to everyone - you've been most helpful.

PS - I'm using IM v6.7.3 - 16 bits (win7/64) now, but I may upgrade soon if icc difficulties are all sorted out.

Cheers,
Rob