Welcome to Photo.net: A Community of Photographers

Community > Forums > Digital Darkroom > Software>File Formats > Software that minimally...

Software that minimally degrades JPEG files upon saving?

Mike Morgan , Jan 10, 2004; 03:04 a.m.

It is often said that if you open a jpeg file and edit it, and save it, the entire image will be degraded.

Having, once upon a time, ported the IJG JPEG source code to an embedded processor, I doubted that this was true. I reasoned that if you edit one section of an image (say using a rubber stamp tool) that only that section of the image would need to be recalculated.

So tonight with some time on my hands I did a little experiment. I opened a tiff file, cropped a 128x128 pixel section, and saved it as 0.jpg.

I then copied 0.jpg to 1.jpg, opened 1.jpg, and used the pencil tool to put a single black pixel near the center of the lower right quadrant. I then saved and closed 1.jpg.

I then copied 1.jpg to 2.jpg. Opened 2.jpg, and drew another single black pixel near the center of the lower right quadrant, and saved it.

And so on and so forth for 3.jpg.

Each in turn for 0, 1, 2, and 3.jpg, I opened them up, cropped to the upper left quadrant (64x64 pixels), and saved each result as a .bmp file.

So, if my theory was correct, every .bmp, 0.bmp to 3.bmp, should be identical with a command fc command.

However they were not.

So, based on this experiment, I conclude one of the following is true:

1. The largest MCU used by photoshop 5.5 exceeds 64x64 pixels. 2. Photoshop 5.5 programmers weren't clever enough to keep a score card of edited MCUs and only calculate the DCT for those MCUs.

I fear option 2 is true, and the adage that opening, editing, and resaving jpegs corrupts the entire image. Clearly, I think this is unnecessary.

If they used a simple score card method and only calculated the DCT of the MCUs that changed, unedited MCUs would be unaffected even after repeated .jpg saves.

Does any image editing software package (perhaps a later version of Photoshop) use a scorecard? Or is there some other factor I am not considering in this edited MCU scorecard idea?

Note: Image degradation results if you don't use a scorecard for edited MCUs because for a given MCU, say MCUx, MCUx!=DCT(IDCT(MCUx)) primarily or entirely due to round off errors (I should spend more time to make a more precise statement).

However, if an MCU hasn't been touched, and you keep track of this, you can just use the original DCT(MCUx) as stored in the .jpg file when you opened it. Using this scorecard idea, it is absolutely possible, at least with everything in my mind, to keep unedited MCUs *exactly* the same through multiple file saves of JPEGs.

This seems pretty obvious to me. If not, I release this idea to the public domain.

Unless there is some obvious reason this wouldn't work.

It has been awhile since I looked at JPEG compression source code, so please be polite if you need to correct some of the assertions I've made.

Responses


    1   |   2     Next    Last

Mike Morgan , Jan 10, 2004; 03:25 a.m.

Response to JPEG handling Flaw in software

To illustrate what I am talking about, I'm going to attempt to attach a .gif illustration of a 640x512 image, with 80 MCUs. Each MCU has 64 Y 8x8 DCTs, each representing 8x8 pixel blocks, and 1 each of a U and V 8x8 DCT, each representing 64x64 pixel blocks. (Crude, but I think it would comply with the JPEG standard--but again, it's been awhile).


Attachment: mcu_dct.gif

Sean De Merchant , Jan 10, 2004; 04:42 a.m.

Response to JPEG handling Flaw in software

The problem I am hearing with your reasoning is not that it could not work, but that it is too low level of an approach to the problem. I have seen references to JPEG editing software that achieves this type of result, but it is of limited use as it only works on jpegs and no professional with any integrity would send jpegs to press if they can avoid it.

Next you are assuming that when PS (Photoshop) opens a JPEG that it retains the fact that the data came from a JPEG. Why would you do this when your final output data type is unknown (TIFF, TGA, PSD, EPS, ...) and may not even be a JPEG? So far as I can tell, PS only tracks enough data to create any valid output type. Hence, once an image is loaded the only data stored is that about the image itself and not about a specific compression method. This is changing with the introduction of EXIF data, but even that extra data is about the image and not about how it is stored.

As a result, I think you are looking at this problem from the wrong direction. The only time we wish to retain the extraneous details about JPEG compression is when we are dealing with the JPEG directly. Otherwise we just wish to deal with the image data. Hence every time PS's JPEG compression algorithm comes into play it assumes it is dealing with uncompressed data and starts from scratch.

On top of that, there is the issue of the quantization tables used by various JPEG implementations. To retain the data you wish to retain, every implementation must use the same quantization tables even though this is an implementation defined feature. Plus, not all quantization tables are created equal. Some quantization tables may be better suited to certain image classes (say photos of feathers or photos of gemstones). Hence tracking this info when the original file is using quantization tables good for gemstones may be a very bad idea if your user is working on photos of horses may be an awful idea.

I am sorry if this is not 100% clear, but without body language to see what you understand this is a tough thing to explain. Most of the reasoning behind this that I can ferret out is based on higher level decisions regarding software architecture.

In short, JPEG is a way of storing images. All JPEGs are images. But not all images are JPEGs. PS is a program for manipulating images. Hence it would be very silly to calculate these changes to the jpeg when they alreasy have a 100% accurate map of the changes in their internal representation of the image itself.

hope this helps,

Sean

Gordon Richardson , Jan 10, 2004; 12:21 p.m.

I wrote an article on Jpeg Compression (http://www.photo.net/learn/jpeg/index.html) that covers most of the issues you mention. As to why commercial software doesn't do this - your guess is as good as mine...

Bas Scheffers , Jan 10, 2004; 04:58 p.m.

In theory, nice. But in reality, the reason I open and edit images in Photoshop is to asjust the whole colour balance of the image, then resize and save again. So the whole image changes and I doubt many people _just_ edit parts of images, in which case that part would still degrade.

Mike Morgan , Jan 10, 2004; 05:07 p.m.

Thanks for the responses.

Sean De Merchant wrote:

>I have seen references to JPEG editing software that achieves this >type of result, but it is of limited use as it only works on jpegs >and no professional with any integrity would send jpegs to press if >they can avoid it.

I agree that it is of limited use to professionals. But it is of great value to the millions of non-professionals who are buying P&S digital cameras and using their old computers with limited storage capacity. It is also of value to people who inadvertently resave a .jpg file from their digital cameras. Do you recall which software does this? I'd like to experiment with a demo version if available.

>Next you are assuming that when PS (Photoshop) opens a JPEG that it retains the fact that the data came from a JPEG.

This is a safe assumption. When I hit <cntrl>-s, it automatically saves an open jpeg as a jpeg (unless I've done something fancy like add layers). It recalculates a whole slew of DCTs unnecessarily, too, considering that for a given unedited MCU, its DCTs are already in the original .jpg file. Using a scorecard would reduce these unnecessary calculations (you probably wouldn't notice the speed up compared to FILE I/O bottlenecks) and may increase the amount of memory used.

>Hence, once an image is loaded the only data stored is that about the image itself and not about a specific compression method.

Yes, I think this is how they handle it, and I suspect other image editing software packages do the same, but it is not the most clever way of handling it. Or maybe it is...

Mr. Richardson wrote:

>As to why commercial software doesn't do this - your guess is as good as mine...

Since the original post, I was thinking/guessing that one valid reason might be that they don't want higher quality MCUs stored in an image with degraded MCUs, which might become annoying to users and/or technical support. Better to degrade the whole image than just the section touched by the tool (PS, etc.). Who knows.

Anyway, I've made another more realistic .gif image of MCU mappings in JPEG. See attached.

Sean De Merchant , Jan 10, 2004; 08:52 p.m.

For jpeg editing take a look at:

http://www.pegasusimaging.com/jpegwizard.htm

As for other issues. Yes, PS does resave a JPEG as a JPEG, but this info is retained at file level. A TIFF is implicitly resaved as a TIFF.

As for disk space, you can pick up a CDRW for about $20 US on sale and 50 blank CDRS for another $10 US on sale. This gives you an additional 35 GB of storage for about $30 US. After spending $600+ US on PS, this is a drop in the bucket. I know I have many many GB of images on CD and I am contemplating the upgrade to DVD+R or getting a high capacity tape backup. But for now my $20 US 52X CDRW will do the job.

enjoy,

Sean

Gordon Richardson , Jan 11, 2004; 12:27 a.m.

Most Jpeg coders and decoders are nearly symmetrical (IJG are), and so the loss in repeated saves is minimal. It is not necessary to go down to such technical level - it is sufficient to keep the same quantisation tables (and chroma subsampling). This can easily be done using the IJG program CJpeg.Exe with the "-table" parameter, which then reproduces the original Jpeg almost exactly.

There is also a program called JpegCrop.Exe (from http://www.jpegclub.org/) which can loslessly rotate and crop Jpeg's by rearranging the encoded bits.

It is not clear what problem you are trying to solve, other than the trivial one of opening and closing a Jpeg without making any changes? Editing a Jpeg is not a good idea in principle (although it practice it is not as harmful as it seems), so encouraging this concept is probably counterproductive. A popup warning when overwriting an existing Jpeg might be more constructive.

Gordon Richardson , Jan 11, 2004; 01:13 a.m.

Here are some sample 8X8 quantisation tables (luminance only). The tables from any given Jpeg can be extracted with the program JpegDump.Exe (mentioned in my article).

Photoshop 5.5 quality 6
        8     6     6     8    12    14    16    17 
        6     6     6     8    10    13    12    12 
        6     6     7     8    13    12    12    12 
        8     8     8    14    12    12    12    12 
       12    10    13    12    12    12    12    12 
       14    13    12    12    12    12    12    12 
       16    12    12    12    12    12    12    12 
       17    12    12    12    12    12    12    12 

Paint Shop Pro 7 quality 15:
        5     3     3     5     7    12    15    18 
        4     4     4     6     8    17    18    17 
        4     4     5     7    12    17    21    17 
        4     5     7     9    15    26    24    19 
        5     7    11    17    20    33    31    23 
        7    11    17    19    24    31    34    28 
       15    19    23    26    31    36    36    30 
       22    28    29    29    34    30    31    30 
Clearly these packages use different tables, but the IJG cjpeg.exe program can accept either table as input (or any table you care to define). Using exactly the same table each time will result in minimal quality loss. Using differing tables when repeatedly resaving an image can result in significant quality loss.

Mike Morgan , Jan 11, 2004; 02:14 a.m.

Well, I don't edit and save as JPEG. I have a 10D now, and I shot raw and extract tiffs.

However, many many people would be intimidated by all of the steps I take.

Specifically, people like my parents. They have a computer, but they still think solitare is pretty cool, and really don't use it for much other than solitare, surfing the web occassionally, and now digital photography. And they wouldn't know how to install a CDRW drive. And they probably wouldn't want the hassles of burning and archiving the files on CD.

For people like my parents, the simplier the better.

Also, the only photoshop they would be likely to use would be if it came as a stripped down version with a digital P&S camera.


    1   |   2     Next    Last

Back to top

Notify me of Responses