Jpeg lossless rotate, file size decreases 10%

[jepjep]

I have thousands of jpgs, all of which were taken with the auto-rotate tagging function of the camera on. I am now migrating from iPhoto to either Lightroom or Aperture, but none of them are capable of doing lossless rotation, so I have to rotate the jpgs before importing.

I downloaded Xnview MP v.0.39 beta Mac x64 and did Tools -> Jpeg lossless transformations -> rotate base on exif value. This resulted in files that were roughly 10% smaller smaller than the original. Does this mean that the rotation was lossy after all (I have read several threads regarding lossless rotation, but I did not understand the technical details nor did I actually find out whether smaller file size equals lossy rotation)?

If so, could you help me find a solution (correct settings, older Mac version of Xnview, or even a different program).

Additional information:
- I was in browser view (I think),
- I did not touch any of the settings,
- I only tested jpegs with dimensions that are divisible by 16,
- I am running Mac Os X Lion,
- I did not save the image after rotation,
- I do not have access to Photoshop or other recommended software suitable for comparing original and rotated files.

Furthermore, are there any known problems in this beta that are relevant to what I am trying to do, such as:
- the thumbnail is not rotated,
- the auto-rotate tag is not removed,
- pixel values (width x length) are not switched accordingly in exif data,
- other exif data is unnecessarily changed or removed,
- etc.?

Thank you in advance!

[marsh]

I suspect browser rotate always uses optimize.

Tested by rotating jpeg two full turns in browser by 90 degree steps:

21,338 Bytes; 552x176 (original)
+90(cw)
16,136 Bytes; 176x552
+90(cw)
16,354 Bytes; 552x176
+90(cw)
16,144 Bytes;
+90(cw)
16,334 Bytes;
+90(cw)
16,136 Bytes;
+90(cw)
16,354 Bytes;
+90(cw)
16,144 Bytes;
+90(cw)
16,334 Bytes; 552x176 (end)

Mp Setting:
[Save]
JPEGOptimizeHuffmanTable=false
- Changing this option made no difference in result. It should have, if used. So the question would be whether it optimizes or not. It does:

Compared to the Win32 v.1.98's Metadata>Clean...>Optimize function. Its end result was 16,334 Bytes (matching numbers above). And their md5 file signatures matched also.

[XnTriq]

Similar discussion: JPEG Lossless question. Why is the file size smaller?

[marsh]

BTW, MP's clean metadata function can un-optimize an image. I don't think the v.1.9x(Win32) version can do this.