Rotating photo changes file size.??? Newbie question

Toke Eskildsen wrote:
> David J Taylor wrote:
[]
>> That's because of the way JPEG works, encoding the image into blocks
>> of 8 or 16 pixels sqaure, it is not a defect of the Windows XP
>> pitcure rotation.
>
> Yes it is. You will notice that I wrote 16, not 8. Windows XP cannot
> losslessly rotate JPEGs that are, for example, 32x24 pixels, no matter
> how the blocks are specified in the JPEGs.
>
> You could also call it a severe shortcoming, if you don't like the
> description "bug".

Well, it depends (to me) on how it is documented. If the description says
"will rotate images which are a multiple of 16 in size" then I would call
it a "limitation" or "constraint". If the documentation says "multiple of
8" then I would agree it's a bug.

>> If you "losslessly" rotate an image which does not have that size,
>> then the edge pixels in the resulting image will have been subject
>> to lossy rotation. Perhaps that won't be noticeable as it will
>> affect a small band of 8 or 16 pixels near the image edge.
>
> It is my experience that it is quite visible on most pictures.
> I definitely prefer to throw away the non-losslessly-rotatable pixels.

So you would crop before rotation? Or let the program do that. It sounds
a good approach to me.

>> There are also programs which can losslessly crop as well - again
>> in 8 or 16 pixel steps.
>
> Actually the cropping is a bit more flexible, as it is only the upper
> left corner, that needs to be a multiple. The lower right corner is
> free from these constraints.

I haven't looked at the maths enough to know whether that's true or not
(the part about allowing an arbitrary size when cropping). My gut feeling
is that it doesn't sound right, but perhaps an expert like Dave Martindale
will spot this thread and comment.

David
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

QX wrote:

> Does the group concur? or is there a better program to use?

David has explained the reason. However, I would recommend using a
program with support for lossless rotation of JPEGs that isn't Windows
XP. Windows XP rotate has a bug, so that it requires the dimensions of
the JPEG to be dividable by 16, in order to perform lossless rotation.

IrfanView, with the plugin pack, supports lossless rotation of JPEGs.
A long list of programs can be found at
http://sylvana.net/jpegcrop/losslessapps.html
--
Toke Eskildsen - http://ekot.dk/
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

Toke Eskildsen wrote:
> QX wrote:
>
>> Does the group concur? or is there a better program to use?
>
> David has explained the reason. However, I would recommend using a
> program with support for lossless rotation of JPEGs that isn't Windows
> XP. Windows XP rotate has a bug, so that it requires the dimensions of
> the JPEG to be dividable by 16, in order to perform lossless rotation.
>
> IrfanView, with the plugin pack, supports lossless rotation of JPEGs.
> A long list of programs can be found at
> http://sylvana.net/jpegcrop/losslessapps.html

You cannot rotate losslessly /unless/ the JPEG has a size which is a
multiple of 8 or, more likely 16, pixels. That's because of the way JPEG
works, encoding the image into blocks of 8 or 16 pixels sqaure, it is not
a defect of the Windows XP pitcure rotation. If you "losslessly" rotate
an image which does not have that size, then the edge pixels in the
resulting image will have been subject to lossy rotation. Perhaps that
won't be noticeable as it will affect a small band of 8 or 16 pixels near
the image edge.

There are also programs which can losslessly crop as well - again in 8 or
16 pixel steps.

David
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

David J Taylor wrote:

[Toke: Windows XP ... requires ... dividable by 16 ... lossless]

> You cannot rotate losslessly /unless/ the JPEG has a size which is
> a multiple of 8 or, more likely 16, pixels.

That is correct. It ties to the chroma subsampling. As fas as I
remember, it is even possible to construct JPEGs, where the dimensions
needs to be multiples of 32. But that's not something one would
normally do.

The the vast majority of digital cameras produces JPEGs where the width
needs to be a multiple of 16 and the height a multiple of 8, in order
to be losslessly rotated. Fortunately the same majority of cameras
produces such images with dimensions that fit that description.

> That's because of the way JPEG works, encoding the image into blocks
> of 8 or 16 pixels sqaure, it is not a defect of the Windows XP
> pitcure rotation.

Yes it is. You will notice that I wrote 16, not 8. Windows XP cannot
losslessly rotate JPEGs that are, for example, 32x24 pixels, no matter
how the blocks are specified in the JPEGs.

You could also call it a severe shortcoming, if you don't like the
description "bug".

> If you "losslessly" rotate an image which does not have that size,
> then the edge pixels in the resulting image will have been subject
> to lossy rotation. Perhaps that won't be noticeable as it will
> affect a small band of 8 or 16 pixels near the image edge.

It is my experience that it is quite visible on most pictures.
I definitely prefer to throw away the non-losslessly-rotatable pixels.

> There are also programs which can losslessly crop as well - again
> in 8 or 16 pixel steps.

Actually the cropping is a bit more flexible, as it is only the upper
left corner, that needs to be a multiple. The lower right corner is
free from these constraints.
--
Toke Eskildsen - http://ekot.dk/
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

David J Taylor wrote:

> So you would crop before rotation? Or let the program do that.

jpegtran can do both: Automatically crop or leave the non-rotatable
pixels.

However, it is not very often I encounter an image that requires this.

Toke:
>> Actually the cropping is a bit more flexible, as it is only the
>> upper left corner, that needs to be a multiple. The lower right
>> corner is free from these constraints.
>
> I haven't looked at the maths enough to know whether that's true
> or not (the part about allowing an arbitrary size when cropping).
> My gut feeling is that it doesn't sound right, but perhaps an
> expert like Dave Martindale will spot this thread and comment.

No need. Fetch jpegtran and try it out:
jpegtran -crop 123x123+16+8 in.jpg out.jpg
produces an image of ... 123x131 pixels?

Let's see...
jpegtran -crop 123x115+16+8 in.jpg out.jpg
produces an image of 123x123 pixels.

Seems like there is a little bug in the Windows version. Anyway, the
conclusion is the same: Cropping does not have the constraints on size.


(okay, this is not a proof, since there could be recompression
involved. But to my knowledge, jpegtran isn't capable of doing a full
recompression)
--
Toke Eskildsen - http://ekot.dk/
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

Toke Eskildsen wrote:
> David J Taylor wrote:
[]
>> I haven't looked at the maths enough to know whether that's true
>> or not (the part about allowing an arbitrary size when cropping).
>> My gut feeling is that it doesn't sound right, but perhaps an
>> expert like Dave Martindale will spot this thread and comment.
>
> No need. Fetch jpegtran and try it out:
> jpegtran -crop 123x123+16+8 in.jpg out.jpg
> produces an image of ... 123x131 pixels?
>
> Let's see...
> jpegtran -crop 123x115+16+8 in.jpg out.jpg
> produces an image of 123x123 pixels.
>
> Seems like there is a little bug in the Windows version. Anyway, the
> conclusion is the same: Cropping does not have the constraints on
> size.
>
>
> (okay, this is not a proof, since there could be recompression
> involved. But to my knowledge, jpegtran isn't capable of doing a full
> recompression)

I'll wait for Dave M's comments, before drawing any conclusions from what
may be a flawed program or implementation.

David
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

David J Taylor wrote:
> Toke Eskildsen wrote:
> > David J Taylor wrote:
> []
> >> I haven't looked at the maths enough to know whether that's true
> >> or not (the part about allowing an arbitrary size when cropping).
> >> My gut feeling is that it doesn't sound right, but perhaps an
> >> expert like Dave Martindale will spot this thread and comment.

It is correct. The strict requirement for lossless JPEG cropping is
that the top left corner of the image must start on an exact boundary
of both the luminance and chroma blocks. This usually means a multiple
of 16 in horizontal and a multiple of 8 in vertical for a digicam
image.

There is no restriction on the bottom right corner position for
cropping. The resulting file will contain all the information needed to
create an image up to the next nearest multiple of 16 and 8 pixels
respectively, together with a header that tells the codec how much of
it to display.
> >
> > No need. Fetch jpegtran and try it out:
> > jpegtran -crop 123x123+16+8 in.jpg out.jpg
> > produces an image of ... 123x131 pixels?
> >
> > Let's see...
> > jpegtran -crop 123x115+16+8 in.jpg out.jpg
> > produces an image of 123x123 pixels.
> >
> > Seems like there is a little bug in the Windows version. Anyway, the
> > conclusion is the same: Cropping does not have the constraints on
> > size.
> >
> >
> > (okay, this is not a proof, since there could be recompression
> > involved. But to my knowledge, jpegtran isn't capable of doing a full
> > recompression)
>
> I'll wait for Dave M's comments, before drawing any conclusions from what
> may be a flawed program or implementation.

The only gotcha is that a JPEG with image dimensions that are not exact
multiples of the intrinsic JPEG block size cannot be losslessly rotated
within the existing JPEG spec.

It would in principle be possible to losslessly rotate any JPEG file
with the addition of a couple of new JPEG tags to tell the decoder how
much to crop off the top and left of an image.

Nothing is actually lost when an image with an irregular size is
rotated losslessly. But it must be rounded up to the next suitable size
first. It is just that there will be a boundary of unwanted (previously
undisplayed) pixels along the left and/or top of the desired image
(depending on the actual rotation performed).

The simplest tweak for this is to round up the dimensions to the next
exact block multiple and then provide new tags to crop the unwanted
data off so you can have perfect lossless rotation or cropping for any
size of JPEG.

Decoders that do not understand the new cropping tag will see an image
16n x 8m pixels in size with a tatty border (upto 15 pixels wide) along
the top and/or left edges. Compliant decoders will see an image 16n-x x
8m-y suitably rotated.

There was a thread about this topic here not long ago titled
"irfanview lossless jpg rotation" and x posted to alt.comp.freeware
some key parts of the thread are only in a.c.freeware

Irfanview is a pretty good (free) choice for lossless JPEG operations.

Regards,
Martin Brown
 >> Stay informed about: Rotating photo changes file size.??? Newbie question 

Martin Brown wrote:
> David J Taylor wrote:
[]
>>>> I haven't looked at the maths enough to know whether that's true
>>>> or not (the part about allowing an arbitrary size when cropping).
>>>> My gut feeling is that it doesn't sound right, but perhaps an
>>>> expert like Dave Martindale will spot this thread and comment.
>
> It is correct. The strict requirement for lossless JPEG cropping is
> that the top left corner of the image must start on an exact boundary
> of both the luminance and chroma blocks. This usually means a multiple
> of 16 in horizontal and a multiple of 8 in vertical for a digicam
> image.
>
> There is no restriction on the bottom right corner position for
> cropping. The resulting file will contain all the information needed
> to create an image up to the next nearest multiple of 16 and 8 pixels
> respectively, together with a header that tells the codec how much of
> it to display.

Many thanks for the explanation, Martin.

[]
> Irfanview is a pretty good (free) choice for lossless JPEG operations.
>
> Regards,
> Martin Brown

Many thanks also for the clarification about the limits on lossless
rotation. I read what you say as: "Given a change to the JPEG spec we
could handle arbitrary size rotation, but not right now".
I haven't used IrfanView for that (as I have other software), but if it's
as good at lossless rotation as at everything else it does, I can believe
you!

Cheers,
David
 >> Stay informed about: Rotating photo changes file size.??? Newbie question