Sign in with
Sign up | Sign in
Your question

Rotating Photos Cause Loss of Resolution

Last response: in Digital Camera
Share
Anonymous
December 31, 2004 9:30:52 AM

Archived from groups: rec.photo.digital (More info?)

Does the rotating of digital photos actually cause a loss of resolution?

I notice that the file size decreases with jpg files.
Anonymous
December 31, 2004 9:30:53 AM

Archived from groups: rec.photo.digital (More info?)

"S. Thomas Lewis" <lewistom@earthlink.net> schrieb
> Does the rotating of digital photos actually cause a loss of resolution?
>
> I notice that the file size decreases with jpg files.
Not for photos straight out of the digital camera. There is of course a
slight change in file size, but this does not affect the original quality in
any way.
The lossless JPEG rotate crops the picture to a multiple of 16x8 (depending
on the color sub sampling, but the common block size is 16 pixel horizontal,
8 pixel vertical). But then the loss in resolution is minimal (max 16/8
pixel).
If you rotate the picture with the default viewer in Windows for example,
the picture is only rotated lossless if the size is a multiple of 16x16. In
any other case the picture is decompressed, rotated and compressed with a
possible loss of quality and a possible significant change in file size.
But a warning is displayed if this should happen.
Is this what happened?

--
Regards
J├╝rgen
http://cpicture.de/en
Anonymous
December 31, 2004 9:44:50 AM

Archived from groups: rec.photo.digital (More info?)

S. Thomas Lewis wrote:
> Does the rotating of digital photos actually cause a loss of resolution?
>
> I notice that the file size decreases with jpg files.
>
Depends on the application.

--
John McWilliams
Related resources
Anonymous
December 31, 2004 10:20:40 AM

Archived from groups: rec.photo.digital (More info?)

Not really but maybe, the original photo will be compressed in the camera
using the manufacturers software that is coded into the camera, when you
import the picture into whatever program you are using it will be
decompressed, if you then rotate it and then save as a jpeg you will be
using the programs compression software and it will be different from what
your camera used. The algorithum used in the camera and in the program will
compress differently. Cameras are normally pretty aggresive in their
compression.

> Does the rotating of digital photos actually cause a loss of resolution?
>
> I notice that the file size decreases with jpg files.
>
Anonymous
December 31, 2004 10:50:31 AM

Archived from groups: rec.photo.digital (More info?)

Depends on the angle of rotation. A ninety degree rotation need not
lose resolution. However, rotation by an angle other than 90 or 180
does lose some resolution, regardless of the file format it is saved
to, since it requires a resampling. 90 and 180 rotations can use a
remapping (coordinate shift) rather than resampling. The loss in
resolution from one or two arbitrary rotations is not usually a serious
loss of resolution, but if you do it a sufficient number of times, you
can degrade it some. When I started in digital pictures, I'd rotate
for things like straightening horizon lines by picking an estimate, and
then by fine tuning with smaller consecutive shifts. I've learned not
to do this- if the initial value doesn't do it, undo to original, and
estimate a new value, so that actual rotation is done one time.
Anonymous
December 31, 2004 4:26:31 PM

Archived from groups: rec.photo.digital (More info?)

"S. Thomas Lewis" <lewistom@earthlink.net> wrote in news:wm6Bd.3125$Cc.1021
@newsread3.news.pas.earthlink.net:

> Does the rotating of digital photos actually cause a loss of resolution?

The resolution in number of pixels is (probably) preserveed while rotating.
It is probabaly only quality that is affected.

It is possible to rotate JPEG without any loss in quality/information
if the size is a multiple of the JPEG square size. Some applications
can do this - and in camera rotation I assume always do it. Not 100%
sure about the latter though.

It is also possible that rotation loses quality. And this is a loss
even if the file size gets larger. If you import a picture into a
photo editor, rotate and then save - you will probably lose quality.
The same goeas for just importing and then saving (without any
manipulation at all).

> I notice that the file size decreases with jpg files.

If it is by a small amount - then it might be because the lossless
compression works better for the rotated pictures.


/Roland
Anonymous
December 31, 2004 4:26:32 PM

Archived from groups: rec.photo.digital (More info?)

Roland Karlsson <roland_dot_karlsson@bonetmail.com> writes:

> "S. Thomas Lewis" <lewistom@earthlink.net> wrote in news:wm6Bd.3125$Cc.1021
> @newsread3.news.pas.earthlink.net:
>
> > Does the rotating of digital photos actually cause a loss of resolution?
>
> The resolution in number of pixels is (probably) preserveed while rotating.
> It is probabaly only quality that is affected.
>
> It is possible to rotate JPEG without any loss in quality/information
> if the size is a multiple of the JPEG square size. Some applications
> can do this - and in camera rotation I assume always do it. Not 100%
> sure about the latter though.

In camera rotation is done by setting the EXIF Orientation tag to 6 or 8
depending on which way you rotate. It is up to the download software to
properly interpret this. As others have said, some software can do this
without loss (I believe they rotate the headers and not the actual data).
Note, the picture must be a multiple of 8 or 16 on each dimension, depending on
how the JPG is encoded. Under Linux, I use jpegtran to do the rotation, and
jhead with the -autorot to automatically do the conversion and reset the
Orientation tag.

--
Michael Meissner
email: mrmnews@the-meissners.org
http://www.the-meissners.org
Anonymous
December 31, 2004 8:43:46 PM

Archived from groups: rec.photo.digital (More info?)

"S. Thomas Lewis" <lewistom@earthlink.net> writes:

> Does the rotating of digital photos actually cause a loss of resolution?

Not if properly done. It is possible, and much software supports
this, to *lossly* rotate a jpeg of some sizes (multiples of 8 pixels
in both dimensions, I believe) in increments of 90 degrees without
loss.

> I notice that the file size decreases with jpg files.

I'd find that suspicious too. But it could be stripping out various
header or other information or something, too. Since it's NOT
uncompressing and recompressing, it can't just be different
compression results.
--
David Dyer-Bennet, <mailto:D d-b@dd-b.net>, <http://www.dd-b.net/dd-b/&gt;
RKBA: <http://noguns-nomoney.com/&gt; <http://www.dd-b.net/carry/&gt;
Pics: <http://dd-b.lighthunters.net/&gt; <http://www.dd-b.net/dd-b/SnapshotAlbum/&gt;
Dragaera/Steven Brust: <http://dragaera.info/&gt;
Anonymous
January 1, 2005 12:06:32 AM

Archived from groups: rec.photo.digital (More info?)

S. Thomas Lewis wrote:
> Does the rotating of digital photos actually cause a loss of resolution?
>
> I notice that the file size decreases with jpg files.
>

A good program should not lose any resolution by rotation. The saving
of a jpg that has been rotated correctly shouldn't change, but it might,
if recompressed.


--
Ron Hunter rphunter@charter.net
Anonymous
January 1, 2005 1:44:42 PM

Archived from groups: rec.photo.digital (More info?)

David Dyer-Bennet <dd-b@dd-b.net> wrote in news:m2d5wqav9p.fsf@gw.dd-b.net:

> Since it's NOT
> uncompressing and recompressing, it can't just be different
> compression results.
>

Oh yes it can.

When you rotate losslessly you have to do a lossless decompress and
a lossless compress of the rotated picture. The new lossless
compression might be different.


/Roland
Anonymous
January 1, 2005 1:47:44 PM

Archived from groups: rec.photo.digital (More info?)

Ron Hunter <rphunter@charter.net> wrote in news:exoBd.9424$qR1.1356
@fe07.lga:

> A good program should not lose any resolution by rotation.

It hs nothing to do with the "goodness" of the program.
Photoshop is a good program. I don't think it supports
lossless rotation of JPEG. You need any program (good or
not) that supports lossless rotation of JPEGs.

> The saving
> of a jpg that has been rotated correctly shouldn't change, but it might,
> if recompressed.

A JPEG is both lossy compressed and losslessy compressed.
The JPEG will surely change if it is lossy recompressed.


/Roland
Anonymous
January 1, 2005 3:58:00 PM

Archived from groups: rec.photo.digital (More info?)

Roland Karlsson wrote:
> David Dyer-Bennet <dd-b@dd-b.net> wrote in
> news:m2d5wqav9p.fsf@gw.dd-b.net:
>
>> Since it's NOT
>> uncompressing and recompressing, it can't just be different
>> compression results.
>>
>
> Oh yes it can.
>
> When you rotate losslessly you have to do a lossless decompress and
> a lossless compress of the rotated picture. The new lossless
> compression might be different.

Are you sure that's true? I though that the whole point of lossless JPEG
90-degree rotation was that no decompression or recompression took place.
You simply swapped the X and Y coefficients (in simple terms).

Cheers,
David
Anonymous
January 1, 2005 3:58:01 PM

Archived from groups: rec.photo.digital (More info?)

David J Taylor wrote:
> Roland Karlsson wrote:
>
>>David Dyer-Bennet <dd-b@dd-b.net> wrote in
>>news:m2d5wqav9p.fsf@gw.dd-b.net:
>>
>>
>>>Since it's NOT
>>>uncompressing and recompressing, it can't just be different
>>>compression results.
>>>
>>
>>Oh yes it can.
>>
>>When you rotate losslessly you have to do a lossless decompress and
>>a lossless compress of the rotated picture. The new lossless
>>compression might be different.
>
>
> Are you sure that's true? I though that the whole point of lossless JPEG
> 90-degree rotation was that no decompression or recompression took place.
> You simply swapped the X and Y coefficients (in simple terms).
>
> Cheers,
> David
>
>
As I understand it, this only works if the original picture was
compressed on 8 bit boundaries.
Anonymous
January 1, 2005 9:45:50 PM

Archived from groups: rec.photo.digital (More info?)

Ron Hunter wrote:
> David J Taylor wrote:
>> Roland Karlsson wrote:
>>
>>> David Dyer-Bennet <dd-b@dd-b.net> wrote in
>>> news:m2d5wqav9p.fsf@gw.dd-b.net:
>>>
>>>
>>>> Since it's NOT
>>>> uncompressing and recompressing, it can't just be different
>>>> compression results.
>>>>
>>>
>>> Oh yes it can.
>>>
>>> When you rotate losslessly you have to do a lossless decompress and
>>> a lossless compress of the rotated picture. The new lossless
>>> compression might be different.
>>
>>
>> Are you sure that's true? I though that the whole point of lossless
>> JPEG 90-degree rotation was that no decompression or recompression
>> took place. You simply swapped the X and Y coefficients (in simple
>> terms). Cheers,
>> David
>>
>>
> As I understand it, this only works if the original picture was
> compressed on 8 bit boundaries.

Sorry, I was taking that as read! Any camera-original JPEGs out there
which are /not/ multiples of 8 pixels in width or height?

Cheers,
David
Anonymous
January 1, 2005 9:51:03 PM

Archived from groups: rec.photo.digital (More info?)

David J Taylor wrote:

> Roland Karlsson wrote:
>
>>David Dyer-Bennet <dd-b@dd-b.net> wrote in
>>news:m2d5wqav9p.fsf@gw.dd-b.net:
>>
>>>Since it's NOT
>>>uncompressing and recompressing, it can't just be different
>>>compression results.

It is uncompressing the losslessly compressed JPEG coeficients,
transposing them into a different order and then recompressing them
again. The zig-zag order is different after transposing the matrix so
that the compression will not necessarily be the same.
>>
>>Oh yes it can.
>>
>>When you rotate losslessly you have to do a lossless decompress and
>>a lossless compress of the rotated picture. The new lossless
>>compression might be different.
>
>
> Are you sure that's true? I though that the whole point of lossless JPEG
> 90-degree rotation was that no decompression or recompression took place.
> You simply swapped the X and Y coefficients (in simple terms).

Lossless rotation works in JPEG coefficient space. It avoids the lossy
step into image space of DCT and IDCT with its potential quantisation
errors.

However, with Digicams and odd 2x1 chroma subsampling you can also get a
curious situation where some decoders do not handle the resulting 1x2
subsampled rotated data quite right. The image rotation was truly
lossless, but the decoders don't all decode the rotated file exactly the
same way.

The test to do to show that the rotation is lossless is obvious enough.
Expect small differences though in some software if you decode the
losslessly rotated image and then rotate that decoded image back to
subtract off the original.

Regards,
Martin Brown
Anonymous
January 1, 2005 10:23:45 PM

Archived from groups: rec.photo.digital (More info?)

Martin Brown wrote:
[]
> Lossless rotation works in JPEG coefficient space. It avoids the lossy
> step into image space of DCT and IDCT with its potential quantisation
> errors.
>
> However, with Digicams and odd 2x1 chroma subsampling you can also
> get a curious situation where some decoders do not handle the
> resulting 1x2 subsampled rotated data quite right. The image rotation
> was truly lossless, but the decoders don't all decode the rotated
> file exactly the same way.

Thanks for that note - I can imagine that some JPEG decoders might not
handle "unusual" JPEGs correctly.

Cheers,
David
Anonymous
January 1, 2005 10:23:46 PM

Archived from groups: rec.photo.digital (More info?)

David J Taylor wrote:
> Martin Brown wrote:
> []
>
>>Lossless rotation works in JPEG coefficient space. It avoids the lossy
>>step into image space of DCT and IDCT with its potential quantisation
>>errors.
>>
>>However, with Digicams and odd 2x1 chroma subsampling you can also
>>get a curious situation where some decoders do not handle the
>>resulting 1x2 subsampled rotated data quite right. The image rotation
>>was truly lossless, but the decoders don't all decode the rotated
>>file exactly the same way.
>
>
> Thanks for that note - I can imagine that some JPEG decoders might not
> handle "unusual" JPEGs correctly.
>
> Cheers,
> David
>
>
Quite true. Some cameras refuse to display a picture that has been
edited and replaced on the card. They make assumptions about various
parameters in order to keep the code small and fast.


--
Ron Hunter rphunter@charter.net
Anonymous
January 2, 2005 12:24:14 AM

Archived from groups: rec.photo.digital (More info?)

Ron Hunter commented courteously ...

> Quite true. Some cameras refuse to display a picture
that
> has been edited and replaced on the card. They make
> assumptions about various parameters in order to keep
the
> code small and fast.

Well, that explains why neither my old Fuji or new Nikon
5700 will read a JPEG I put on the card, even if all I did
was change the file name.

It makes sense that they'd optimize their code but I've
been deprived of being able to display my pictures on my
big screen TV because the blinkin' camera things the card
is empty (actually, my 5700 says "no images" but does note
that the space is taken up).

--
ATM, aka Jerry Rivers

Delete the reverse SPAM to reply by E-mail
Anonymous
January 2, 2005 12:51:57 AM

Archived from groups: rec.photo.digital (More info?)

"David J Taylor" <david-taylor@invalid.com> wrote in
news:33nl2pF3nlat1U1@individual.net:

> Are you sure that's true? I though that the whole point of lossless
> JPEG 90-degree rotation was that no decompression or recompression
> took place. You simply swapped the X and Y coefficients (in simple
> terms).

Hmm - not 100% - but ...

The blocks are huffman coded, which is a lossless encoding.
You have to huffman decode, rotate and then huffmen encode
again. This operation is totally lossless.


/Roland
Anonymous
January 2, 2005 1:20:44 AM

Archived from groups: rec.photo.digital (More info?)

"David J Taylor" <david-taylor@invalid.com> writes:

>> As I understand it, this only works if the original picture was
>> compressed on 8 bit boundaries.

>Sorry, I was taking that as read! Any camera-original JPEGs out there
>which are /not/ multiples of 8 pixels in width or height?

Actually, the limit is usually a multiple of 16 pixels. JPEG uses 8x8
blocks in the DCT steps, but in most JPEGs the chroma is also
downsampled by a factor of 2 before compression. So a 16x16 block of
input pixels yields four 8x8 blocks of luminance data plus two 8x8
blocks of colour difference data (two colour components) which are then
DCTed and further processed.

If you tell the JPEG encoder not to downsample chroma, then you're right
about the multiple of 8.

Dave
Anonymous
January 2, 2005 1:28:42 AM

Archived from groups: rec.photo.digital (More info?)

"David J Taylor" <david-taylor@invalid.com> writes:

>> When you rotate losslessly you have to do a lossless decompress and
>> a lossless compress of the rotated picture. The new lossless
>> compression might be different.

>Are you sure that's true? I though that the whole point of lossless JPEG
>90-degree rotation was that no decompression or recompression took place.
>You simply swapped the X and Y coefficients (in simple terms).

JPEG compression is a complex beast. The data is first converted to
luminance and chroma colour representation, downsampled in chroma
(typically), then a DCT is done on each 8x8 block. The DCT coefficients
are quantized to a smaller number of bits, and some discarded entirely -
this is the lossy portion of the encoding. The remaining bits are then
losslessly compressed by Huffman encoding.

When a JPEG image is losslessly rotated, the Huffman coding is decoded
and the data unpacked back into DCT coefficients. Then each 8x8 block
of coefficients is rotated (well, not exactly rotated, but rotating the
input to a DCT modifies the output of the DCT in a well-defined way, and
this is what is computed). The order of the 8x8 tiles is also changed
to correspond with rotation. Then the DCT coefficients are compressed
again by Huffman encoding.

Now, since the lossy step has not been repeated, and all of the DCT
coefficients are copied from the input file to the output, there is no
further loss of image information. But the Huffman encoding step
doesn't necessarily give exactly the same number of bytes of output,
because it is encoding the data in a different order the second time
around.

Also, the initial Huffman encoding may have been done using a
single-pass algorithm, with some default Huffman encoding tree. The
second encoding may have been done by a two-pass "optimized" Huffman
encoding, which can losslessly store the same data in fewer bits by
optimizing the encoding tree to that particular image.

Dave
Anonymous
January 2, 2005 1:28:43 AM

Archived from groups: rec.photo.digital (More info?)

Dave Martindale commented courteously ...

Dave, I'm not hijacking this thread, I just chose your
post to reply to, which is why I snipped the entire
thought you had (which I agree with, BTW).

I've been following this thread for some time and learned
quite a lot about the JPEG spec and its implementation as
well as some good do's and don't's about rotating images
in general (e.g., successive small angle rotations can
wreck an image).

The OP's question had to do with a loss of resolution as I
recall, not so much damage to the image caused by
resampling the bits on a non-lossless rotation. Or, am I
screwed up here?

Unless everyone's been talking about working on the bits
within the actual JPEG file itself with some software I'm
not familiar with, once a raster image is brought into an
editor, such as Paint Shop Pro, it is just a large mass of
pixels without any specific format. I'm ignoring layers,
vector data, EXIF, etc. for simplicity, and just
concentrating on the pixel stuff affected by a rotation.

The only way I see an actual "loss" of resolution is that
all images are rectangular by definition and lossy
rotations cause the picture part to be cocked within the
canvas area. The loss of resolution occurs when you have
to crop the result back to some finite rectangle. Am I OK
with this belief?

If the real discussion going on here is about damage to
images resulting from the necessary resampling of the
pixels due to a lossy rotation, then I'll quietly slip out
the back door and go back to sleep...

--
ATM, aka Jerry Rivers
Anonymous
January 2, 2005 3:01:10 AM

Archived from groups: rec.photo.digital (More info?)

All Things Mopar <usenetMAPS123@comcast.net> wrote in
news:Xns95D1BBD555425ReplyToken@216.196.97.131:

> The OP's question had to do with a loss of resolution as I
> recall, not so much damage to the image caused by
> resampling the bits on a non-lossless rotation. Or, am I
> screwed up here?
>

Nope - you are not screwed up. I added such a caveat to
my first post. It would be very good if the OP told us
what he meant. As a matter of fact, with regard to the OP,
it is not meaningful to go on discussing lossless and
lossy rotations before we know. It is nice for us JPEG
nerds though :) 

So - OP - can you kindly tell us if you really mean resolution,
i.e. number of pixels.


/Roland
Anonymous
January 2, 2005 3:01:11 AM

Archived from groups: rec.photo.digital (More info?)

Roland Karlsson commented courteously ...

[snip]

> It is nice for us JPEG nerds though :) 

Hi, Roland.

By Jove, I believe I said what you did! <grin> I thought I
"knew" JPEG but boy was I wrong! That's a big reason why I
did a nuclear sub and went deep and quiet and just soaked
up the useful knowledge.

That's fine for us gearheads, but what about the OP?
He/she (forget which) probably went 10-7 days ago...

--
ATM, aka Jerry Rivers
Anonymous
January 2, 2005 1:16:13 PM

Archived from groups: rec.photo.digital (More info?)

Dave Martindale wrote:
> "David J Taylor" <david-taylor@invalid.com> writes:
>
>>> As I understand it, this only works if the original picture was
>>> compressed on 8 bit boundaries.
>
>> Sorry, I was taking that as read! Any camera-original JPEGs out
>> there which are /not/ multiples of 8 pixels in width or height?
>
> Actually, the limit is usually a multiple of 16 pixels. JPEG uses 8x8
> blocks in the DCT steps, but in most JPEGs the chroma is also
> downsampled by a factor of 2 before compression. So a 16x16 block of
> input pixels yields four 8x8 blocks of luminance data plus two 8x8
> blocks of colour difference data (two colour components) which are
> then DCTed and further processed.
>
> If you tell the JPEG encoder not to downsample chroma, then you're
> right about the multiple of 8.
>
> Dave

I forgot about the chroma sub-sampling! Thanks.

David
Anonymous
January 2, 2005 1:19:53 PM

Archived from groups: rec.photo.digital (More info?)

Roland Karlsson wrote:
> "David J Taylor" <david-taylor@invalid.com> wrote in
> news:33nl2pF3nlat1U1@individual.net:
>
>> Are you sure that's true? I though that the whole point of lossless
>> JPEG 90-degree rotation was that no decompression or recompression
>> took place. You simply swapped the X and Y coefficients (in simple
>> terms).
>
> Hmm - not 100% - but ...
>
> The blocks are huffman coded, which is a lossless encoding.
> You have to huffman decode, rotate and then huffmen encode
> again. This operation is totally lossless.
>
>
> /Roland

Yes, we agree - the lossless huffman encoding decoding may be repeated
(and even done better as Dave points out), but the lossy part of the
process is not repeated.

Cheers,
David
Anonymous
January 2, 2005 1:23:07 PM

Archived from groups: rec.photo.digital (More info?)

Ron Hunter wrote:
[]
> Quite true. Some cameras refuse to display a picture that has been
> edited and replaced on the card. They make assumptions about various
> parameters in order to keep the code small and fast.

My TVwriter program may sort that for you:

http://www.satsignal.net/ => Image Utilities, TVwriter

Cheers,
David
Anonymous
January 2, 2005 1:23:52 PM

Archived from groups: rec.photo.digital (More info?)

All Things Mopar wrote:
[]
> Well, that explains why neither my old Fuji or new Nikon
> 5700 will read a JPEG I put on the card, even if all I did
> was change the file name.
>
> It makes sense that they'd optimize their code but I've
> been deprived of being able to display my pictures on my
> big screen TV because the blinkin' camera things the card
> is empty (actually, my 5700 says "no images" but does note
> that the space is taken up).

My TVwriter program may sort that for you:

http://www.satsignal.net/ => Image Utilities, TVwriter

Cheers,
David
Anonymous
January 2, 2005 1:23:53 PM

Archived from groups: rec.photo.digital (More info?)

David J Taylor commented courteously ...

> http://www.satsignal.net/

Thanks, Dave. I downloaded it and will give it a try!

--
ATM, aka Jerry Rivers
Anonymous
January 2, 2005 3:21:32 PM

Archived from groups: rec.photo.digital (More info?)

All Things Mopar <usenetMAPS123@comcast.net> wrote in
news:Xns95D1E35A289DAReplyToken@216.196.97.131:

> That's fine for us gearheads, but what about the OP?
> He/she (forget which) probably went 10-7 days ago...

Hmmm .. I am not sure ... but it looks like a Troll.
Someone that asks a question that he knows will
start a thread. But he never bothers to write again.
The lack of useful information in the original
question might either hint at a Troll or a Newbe.


/Roland
Anonymous
January 2, 2005 3:21:33 PM

Archived from groups: rec.photo.digital (More info?)

Roland Karlsson commented courteously ...
>> That's fine for us gearheads, but what about the OP?
>> He/she (forget which) probably went 10-7 days ago...
>
> Hmmm .. I am not sure ... but it looks like a Troll.
> Someone that asks a question that he knows will
> start a thread. But he never bothers to write again.
> The lack of useful information in the original
> question might either hint at a Troll or a Newbe.

You could be right, Roland. At least this thread didn't
break down into a flame war against allegedly stupid
people. If the OP was a troll, he's grinning; if a newbie,
they've must not want to know very badly or they'd have
clarified their query a long time ago.

--
ATM, aka Jerry Rivers
!