JPEG degradation

On Jan 26 2007 1:13 AM, Ron Hunter wrote:


You can open a JPG file as many times as you want without degrading it
in any way.

What degrades it is saving it back to the same file after doing ANYTHING
to the image data that causes recompression. It is the recompression
step that introduces cumulative degradation.
Anyone who tells you different just doesn't know what he is talking about.

Ron is absolutely correct. I think people are getting confused between
opening the file to VIEW it, then CLOSING it (without saving) vs. opening
a file, then SAVING it.

If you open a jpeg to view it and then close it there will be no
degradation. It's that simple.
Now, if you open a jpeg and save it, regardless if you've done any edits
or made any changes, the file gets re-compressed and the file will degrade.

Think about it - if you're viewing a jpeg image that is on a
non-rewritable CD then the image can't change can it? The disc can't be
writen to. But, if you open the image and then save it to your hard disk
then it's being re-compressed even if no changes have been made. Why?
Because the process of saving the file as a jpeg means a compression
algorithm is being used to save it as a jpeg.

I can't believe this thread is this long. It's a very easy concept to
grasp.

Rob-L

----*
: the next generation of web-newsreaders : http://www.recgroups.com

Toke Eskildsen wrote:
David Dyer-Bennet wrote:

I made a short article, exhibiting the two versions of the file
and a visual map of the differences between them (very small, but
definitely present). The article is at
http://dd-b.net/dd-b/Photography/Articles/resaving-jpeg/.

To be truly pedantic, of course, this only demonstrates that in
one particular case an image is changed by resaving a JPEG.

While I can second your overall conclusion, you do have one faulty
claim on the page: "In fact, it isn't necessary to modify the image;
simply uncompressing the JPEG into an image and recompressing that
image into a new JPEG does additional damage to the image, despite the
exact same algorithm being applied both times.".

As Martin Brown demonstrates, images tend to converge, so that there
will be no further degradation after some decompress/recompress cycles.

To me, that's a special case; in the general case, when deciding whether
the use jpegs as an intermediate form in a workflow, the key point is
that they generally degrade when saved. The fact that, if saved
sequentially without other alteration, they sometimes converge to a
stable form, isn't key; you can't count on that happening in any given
case, you don't know how many saves it take to converge, and it depends
on other alterations NOT happening.

il barbi wrote:

"Paul Mitchum" ha scritto nel messaggio
...
cut

There's one exception, though: Lossless rotation. Some math dude came up
with a way to preserve all the data in a JPEG while rotating it 90
degrees (or multiples thereof).

I'm interested in that because I was just rotating a jpeg 1251K large with
Photoshop and it prompted me to resave it with quality 8 and optimized
progression - I did so and the resulting jpeg occupies only 787K. By
curiosity I tried with quality 9-10-11-12 and I got
1021K-1379K-1759K-2558K (!). In all cases the rotated jpeg showed the same
number of pixels In the contrary it is interesting that Windows XP viewer
does not modify the dimension of jpeg image when it rotates it, so
perhaps it uses some lossless algorithm such as you quoted. Maybe this is
why the jpeg is automatically saved after it is rotated - there is no loss

When I say 'lossless rotation,' what I mean is that some smart guy
figured out a way to rotate an JPEG image clockwise or counterclockwise
without recompressing it. So performing a rotation in this way won't
degrade the image. There's a bunch of software based on this principle,
but the place to start looking is jpegtran:
http://sylvana.net/jpegcrop/

Doing the rotation in Photoshop will degrade the image, because it
doesn't do this fancy math on the file itself, but on the image data in
memory.

To me, that's a special case; in the general case, when
deciding whether the use jpegs as an intermediate form in a
workflow, the key point is that they generally degrade when
saved. The fact that, if saved sequentially without other
alteration, they sometimes converge to a stable form, isn't
key; you can't count on that happening in any given case, you
don't know how many saves it take to converge, and it depends
on other alterations NOT happening.

I almost always copy the original JPG's over and if I'm doing any
editing that I want to keep in a non-final form, I leave it in
Paint Shop Pro file format. But sometimes I start with the
original, make the changes, crop it and save it to another name
as a JPG file to post on the web. In that case, where interim
steps are not hard to reproduce and do not need to be saved, I
don't bother with saving anything in the PSP format.

When I say 'lossless rotation,' what I mean is that some smart
guy figured out a way to rotate an JPEG image clockwise or
counterclockwise without recompressing it. So performing a
rotation in this way won't degrade the image. There's a bunch
of software based on this principle, but the place to start
looking is jpegtran: http://sylvana.net/jpegcrop/

Doing the rotation in Photoshop will degrade the image,
because it doesn't do this fancy math on the file itself, but
on the image data in memory.

There is this app which appears to do a lot of stuff in lossless
mode:

www.betterjpeg.com

Plus there is Irfanview plugins.

Seems a smart way to do it. I wonder why it's not an option in
all the major apps.

Toke Eskildsen wrote:

Paul Mitchum wrote:

Try it. Make and save an image with some text in it (text
compresses poorly under JPEG). Open it and save it again at
quality level 6 or so. Open the newly saved version and save it
again. Do this a few times. You'll see it degrade as you go. I say
to use quality level 6 because the effect will show up more
quickly that way. The highest quality settings work the same way,
just not as drastically.

My own tests says that it is the other way around and the JPEG FAQ
seconds that: http://www.faqs.org/faqs/jpeg-faq/part1/section-10.html

Lower quality settings means lesser degradation between saves.

That may be, but if you do the experiment you'll find that the
degradation isn't as obvious per generation at higher quality settings.

Paul Mitchum wrote:

Toke Eskildsen wrote:
My own tests says that it is the other way around and the JPEG
FAQ seconds that:
http://www.faqs.org/faqs/jpeg-faq/part1/section-10.html

Lower quality settings means lesser degradation between saves.

That may be, but if you do the experiment you'll find that the
degradation isn't as obvious per generation at higher quality
settings.

I have done my own experimentations: http://ekot.dk/misc/recompress/

By looking at the images in more detail, it seems clear that the
sampling-factors are very important (Martin also mentions this).

Lower quality yields less degradation/gen.
Coarser subsampling increases the degradation/gen.

A lot of tools hides the subsampling for the user, so that there is
only one scale. Maybe that's what you've experienced? Turning down the
quality and passing the cutoff point where the tool changes the
subsampling?
--
Toke Eskildsen - http://ekot.dk/

"Toke Eskildsen" wrote in message
. ..
David Dyer-Bennet wrote:

I made a short article, exhibiting the two versions of the file
and a visual map of the differences between them (very small, but
definitely present). The article is at
http://dd-b.net/dd-b/Photography/Articles/resaving-jpeg/.

To be truly pedantic, of course, this only demonstrates that in
one particular case an image is changed by resaving a JPEG.

While I can second your overall conclusion, you do have one faulty
claim on the page: "In fact, it isn't necessary to modify the image;
simply uncompressing the JPEG into an image and recompressing that
image into a new JPEG does additional damage to the image, despite the
exact same algorithm being applied both times.".

As Martin Brown demonstrates, images tend to converge, so that there
will be no further degradation after some decompress/recompress
cycles.
--
Toke Eskildsen - http://ekot.dk/

While it is true they will converge over time, I have found easier
ways to obtain a neutral grey test card .... :-)

mikey

Keith Sheppard wrote:
in most programs (those written by a competent programmer), 'saving' a
file that hasn't been changed will simply be skipped without comment by
the program.
Here, here (see my other posting). I have just one niggling doubt, speaking
as a professional software developer myself. I wish I were as confident as
you that "most" programs are written by competent programmers. There's a
heck of a lot of garbage out there, a lot of it from respected manufacturers
who ought to know better.

Keith


There certainly is, but a careful user should be able to avoid the bad
stuff. The program should, at least, warn that no image data was
changed, and ask if the user really wants to degrade his image.

Floyd L. Davidson wrote:
Ron Hunter wrote:
But with JPG, each time you save the file, the entire image is
altered, and each time it is edited, the entire image is
processed and saved. It's not limited to specific "colors" or
a range of pixels in specific areas, I believe, so degredation
always occurs.
Bad thinking, indicating little knowledge of programming, or
computers in general.
A properly written program will keep track of any changes to the
image data, and will retain a copy of the original data,

That just isn't true. No such copy is going to be retained, nor
is it needed or useful.


Your program lacks 'revert', and 'undo'?


unmodified, and if no changes are made, will either skip the
actual writing of the data to disk, and merely 'touch' (update
modified/written data) the file on disk, or simple rewrite the
original data.

It might do nothing other than change the file data, or it might
actually re-write the entire file. But it isn't oging to re-write
the original data.

If you have a program that actually recompresses
and rewrites a file you didn't edit, then ditch it and get one
written by a competent programmer.

That isn't true. Consider, for example, that the default
compression for any given program would of course be a
configuration option... and if it is different than the
original file, then a "save" operation would be *expected* to
recompress the entire data set, even though no "edit" or other
data change has taken place. In such a case the sequence of
reading in and displaying and image, and then (with no editing
at all) a "save" will in fact change the entire file.

I am glad you aren't doing any programming for me. You have the wrong
orientation.