How to (almost) lossless rotate *.jpg pictures ?

[pstein]

Assume I walk through a series of *.jpg digital fotos in a folder.
Some of them are taken in portrait format.
So I rotate them by 90 deg.
Now I want to save them in rotated format.
As far as I can see there seems to be no LOSSLESS rotation.
Is this true?

So when I go into the Options dialog I can see a slider for Quality.
The initial default is 80%. When I increase this to 100% then the resulting picture is occasionally much bigger than the original. How can I achieve that the resulting rotated image is almost as big as the original?
I want to avoid trial and error. This would be rather unconfortable.

Peter

[MaxSt]

Tools -> Jpeg Lossless ?

[xnview]

You have rotate in the browser (with option/Browser>Misc)

[the_majkl]

Is EXIF "Orientation" field updated when saving rotated image with EXIF data? Or is it possible to remove this (and only this) EXIF field from EXIF data when saving picture? I do not see much sense to have the field untouched after rotating...

[helmut]

When using Tools > JPG lossless Rotation > Rotate based on EXIF value the image will be rotated and EXIF orientation value will be updated. When using the "JPG lossless rotation" dialog by selecting Tools > JPG lossless Rotation > Dialog... you can control whether EXIF value is reset or not.

[NikoBe]

Hello,

I tried the lossless rotation based on EXIF to see if it's really lossless, but my final picture is smaller (in bytes size) than the original. Few bytes have been lost.
Also, the histogram is not exactly the same, which is even more worrying (the histogram is less "smooth").

Is that normal? Do we loss a bit of information when rotating?

Thanks !!

[NikoBe]

Up

[Drahken]

Image content compresses better horizontally than vertically, so simply changing the orientation of the image can indeed alter the filesize somewhat. (This can best be seen by using the gif format. Make an image with vertical stripes & save it as a gif, then rotate the image 90 degrees and save it as another gif, now compare the filesizes. Some newer formats such as png negate this by applying reversible rotation filters when saving.)
I don't know much about histograms, but I'm reasonably certain that reflect colors as they are arranged in the image, thus a horizontal green strip will be reflected differently in the histogram than an otherwise identical vertical green strip.

I am certain however that no data is actually lost in the conversion. There's a very easy way to prove this: Losslessy rotate your image back to it's original orientation, then compare the filesize & histogram to the original image. You will find that it is identical.
(The one exception is if your image's dimensions can't be evenly divided by 8, then enough will be trimmed to make it divisible by 8. This means that a maximum of a 7px strip might be removed from the side and/or top/bottom. However, while the popup warns of this, I don't see how it could actually occur. After all, your original image is also a jpg, which means that the original pic had the same divisible by 8 limitation.)

[DOS386]

A few tiny errors:

Image content compresses better horizontally than vertically

Any image ? I doubt that

Some newer formats such as png negate this by applying reversible rotation filters when saving.)

I'm not aware of such filters. PNG has both horizontal and vertical based filters, also the look-back distance of 32 KiB is usually sufficient to take benefit of vertical structures too

thus a horizontal green strip will be reflected differently in the histogram than an otherwise identical vertical green strip.

Strange. BTW, the histogram feature could be improved: add option "logarithmise the counts" Otherwise such a homogenous green (or any other colour) stripe, irrespective whether horizontal or vertical (or even any other form), ruins the histogram.

one exception is if your image's dimensions can't be evenly divided by 8, then enough will be trimmed to make it divisible by 8. This means that a maximum of a 7px strip might be removed from the side and/or top/bottom.

1. May be 16 instead of 8, depends from subsampling
2. Stripe is lost at right or bottom (of input image) only

don't see how it could actually occur. After all, your original image is also a jpg, which means that the original pic had the same divisible by 8 limitation.)

It can and does Why ? Internally every JPG has the 8 or 16 divisibility criteria, but visible size may be any.

[DOS386]

I tried the lossless rotation based on EXIF to see if it's really lossless, but my final picture is smaller (in bytes size) than the original. Few bytes have been lost. Also, the histogram is not exactly the same, which is even more worrying (the histogram is less "smooth"). Is that normal? Do we loss a bit of information when rotating?

If picture had to be cropped: histogram will change and size too (usually sink).

If no cropping: histogram must remain identical, also the size should remain (almost, not exactly ) same.

[Drahken]

A few tiny errors:

Image content compresses better horizontally than vertically

Any image ? I doubt that

I said image CONTENT, not images. ie, A horizontal stripe compresses better than an identical vertical stripe.

1. May be 16 instead of 8, depends from subsampling

*shrug* The warning popup from xnview states 8, that is what I based that statement on.

If no cropping: histogram must remain identical, also the size should remain (almost, not exactly ) same.

Clearly not correct. I ran some tests before making my previous post. When I rotated an image 90 degrees & then compared the histograms, there was a very small change. I then rotated in 90 degrees in the opposite direction (making it the same as when I started) and compared the new histogram to the original, the 2 were absolutely identical. (Similarly, the filesize increased slightly when I rotated it, then returned to exactly the same as the original when I re-rotated it to it's original orientation.)
This test proved that the histogram does change slightly when the image is rotated.
This test also proved that said difference was not due to cropping. If it had been cropped, then rotating it again would not have restored it to it's original state.

[NikoBe]

Thanks for your help guys, it's really helpful (and one can see that you master this domain )

[DOS386]

FYI, as I deprecate rumour and prefer hard facts, I did some tests and here are the results:

Download testsuite now: JPGLOSSY.ZI7 (1 MiB | 7-ZIP file)

1. JPG lossless / histogram

Clearly not correct. I ran some tests before making my previous post. When I rotated an image 90 degrees & then compared the histograms, there was a very small change.

I can reproduce the problem. The so called "lossless JPG transformation" is in fact lossy, check "JPG400A.JPG" , "JPG400B.JPG" , "BMP400A.BMP" , "BMP400B.BMP" , "BMP400C.BMP" - "A" and "C" should be identical but aren't. This is an implementation BUG / flaw and had been already discussed here: t=19014 "Lossless JPEG rotation only lossless at 360 degrees?" As the output image has tiny bitmap differences (by +/-1 per pixel channel), the histogram also is different. Because the histogram MUST be identical if the rotate / mirror transformation is lossless.

2. JPG cropped by 8 or 16 ???

*shrug* The warning popup from xnview states 8, that is what I based that statement on.

I can reproduce the problem, see ^^^ shot. The crop can be up to 15 pixels, pick "JPG415.JPG" and test, you'll quickly find out that it crops down to 400, not 408. The message is faulty in multiple ways, there are no "unused pixels" removed, it should say:

JPEG lossless operation will directly modify original file(s) on storage media, and if the size is not an integer multiple of 16, it may unrecoverably crop away up to 15 pixels at right and bottom of original picture.

See also : http://newsgroup.xnview.com/viewtopic.php?t=20032 "JPEG Lossless Join"

3. GIF vs PNG / horizontal vs vertical

I said image CONTENT, not images. ie, A horizontal stripe compresses better than an identical vertical stripe.

Yeah indeed shots with text compress worse if rotated making the text vertical, see "CROPMESH.GIF" , "CROPMESV.GIF" , "CROPMESH.JPG" , "CROPMESV.JPG" , "WISTAH.JPG" , "WISTAV.JPG" , "CROPMESH.PNG" , "CROPMESV.PNG" , "PPHOT24H.PNG" , "PPHOT24V.PNG" , "WISTAH.PNG" and "WISTAV.PNG". This is primarily a problem of GIF (bloat increase by factor 1.38), less of PNG (increase factor only 1.19), and almost no problem for JPG (unsurprisingly, considering the transformations included in JPG compression). You can also see that GIF is 4.8 x worse than PNG on "CROPMESV" bitmap, and no GIF's at all are provided for "WISTA" bitmaps (consider 13'215 colours). Apparently there are good reasons why I deprecate GIF . OTOH the "WISTA" bitmaps do show that JPG can be much smaller than PNG, but looks very crappy then (quality value was 30), with quality value of 94 the JPG size egalizes PNG, and there is still noise in, although barely visible without zoom-up.

[marsh]

I tried the lossless rotation based on EXIF to see if it's really lossless, but my final picture is smaller (in bytes size) than the original. Few bytes have been lost.

If there isn't already an Exif field to update, it rotates the image instead. Changing only the orientation flag would leave image unaltered.

For those who haven't looked at it recently, this old option has been reworded:
Options... Browser>{Misc}>[x]Change EXIF orientation ONLY when possible (JPEG)

If non-conforming blocks were not trimmed away, a result (with DOS386's sample) could look like this:

[XnTriq]

2. JPG cropped by 8 or 16 ???

*shrug* The warning popup from xnview states 8, that is what I based that statement on.

Minimum Coded Unit blocks and lossless editing of JPEGs:

• Wikipedia
  • JPEG » Lossless editing
• ImpulseAdventure
  • JPEG Minimum Coded Unit (MCU) and Partial MCU
  • JPEG Lossless Rotation or Flip with Partial MCU
• Intel
  • IPP Reference Manual » Image and Video Processing
    • Image Color Conversion » Image Downsampling
• Better JPEG
  • Lossless rotation of JPEG images: There's more than one way to rotate a cat
• Ammara
  • Lossless JPEG Rotation » JPEG MCU “HotSpots”

• XnView Forum
  • Rotation, sans perte
  • Lossless JPEG transformations
  • Lossless Transformation
  • Hello! Newbie questions