JPEG compression as lossless as possible

[Anika]

1. I just found the programm Better JPEG. The special feature of it is:

However, the JPEG images consist of a number of independently encoded blocks typically 8x8, 8x16 or 16x16 pixels in size, and there is a way to treat these blocks individually without having to recompress the untouched ones. Better JPEG takes advantage of this possibility allowing for partial image editing without total recompression (red eye removal, data/text imprinting, copy/paste, etc.).

How does XnView handle this? Is it possible to implement this? Especially for smaller changes like red eye reduction it would be very useful not to recompress the whole file.

2. Another question: Is it possible to read the compression ratio of a jpeg file and suggest this ratio for the save or save as dialog?

3. Is it possible to add lossless a border around a jpeg? This should work like crop the other way round. Just increase the canvas size by multiples of 8 pixel without recompressing the whole picture.

Just some suggestions, perhaps it is even impossible.
Greets,
Anika

[xnview]

1. I just found the programm Better JPEG. The special feature of it is:

However, the JPEG images consist of a number of independently encoded blocks typically 8x8, 8x16 or 16x16 pixels in size, and there is a way to treat these blocks individually without having to recompress the untouched ones. Better JPEG takes advantage of this possibility allowing for partial image editing without total recompression (red eye removal, data/text imprinting, copy/paste, etc.).

How does XnView handle this? Is it possible to implement this? Especially for smaller changes like red eye reduction it would be very useful not to recompress the whole file.

2. Another question: Is it possible to read the compression ratio of a jpeg file and suggest this ratio for the save or save as dialog?

3. Is it possible to add lossless a border around a jpeg? This should work like crop the other way round. Just increase the canvas size by multiples of 8 pixel without recompressing the whole picture.

Thanks for your suggestions, currently not possible.

[Lostclown]

Is it possible to implement this? Especially for smaller changes like red eye reduction it would be very useful not to recompress the whole file.

Repeatedly encoding/saveing a jpeg image with little or no editing using always the same compression ratio will result in files of almost the same size.
So I believe this will not cause loss of image quality. So the only benefit might be faster encoding after editing, but then saving the file would probably take as much time as before. So benefits of this would be very little, and probably not noticeable for most users (like me ).

2. Another question: Is it possible to read the compression ratio of a jpeg file and suggest this ratio for the save or save as dialog?

To the best of my knowledge this information is not stored in the header or metadata of the file.
But I might be wrong about this, and if I am this would be an interesting feature.

3. Is it possible to add lossless a border around a jpeg? This should work like crop the other way round. Just increase the canvas size by multiples of 8 pixel without recompressing the whole picture.

This might very well be possible for left and top margins.
But part of right and bottom margins would probably fit in an area with the original image data rather than being stored in an independent area.

Just some suggestions, perhaps it is even impossible.

Interesting suggestions, but if they could and would be implemented they would most likely bring minimal improvements.
I think your suggestion in question 2 would bring real benefits though, but the I don't believe it is possible to implement it

Regards,
Lostclown

[Anika]

To 1.
My question was if XnView already uses this method or not. But it doesn't.

Repeatedly encoding/saveing a jpeg image with little or no editing using always the same compression ratio will result in files of almost the same size.

Every recompression will cause loss of information. Just open and save an image to a new file and compare the two. Especially at sharp borders with a special colour I really want to keep the original file.

To 2.
And there we get again to the question how to know the original compression of a file. In my pictures from my digicam it is stored in the EXIF data. XnView shows the compressed bit per pixel as 15099488/3763200. Perhaps it is possible to use this. But I don't know if there even is a standard for compression ratio because every program has its own scala: XnView from 1 (bad) to 100 (best), PSP from 99 (bad) to 1 (best) and so on.

To 3.
I wrote a mail to the programmers of Better JPEG and the say that this is in their plans. Now I know that it is possible and I am looking forward to newer versions.

Thanks for your answers and have a nice day,
Anika

[Dreamer]

Anika, your suggestions are good, I like them but xnview is mainly image viewer, browser and converter (taken from the homepage), not editor so maybe you coud ask the author of the very nice image editor - PhotoFiltre easy to use and free (hope it's not against the forum rules )

Edit: Also there are many things to do now so I think, more important is to solve/fix bugs and maybe add some "more viewer" features first...

[Lostclown]

To 1.
My question was if XnView already uses this method or not. But it doesn't.

Repeatedly encoding/saveing a jpeg image with little or no editing using always the same compression ratio will result in files of almost the same size.

Every recompression will cause loss of information. Just open and save an image to a new file and compare the two. Especially at sharp borders with a special colour I really want to keep the original file.

Ehhemm...
You are absolutely right.
My assumption that almost equal file size results in no data loss is very inaccurate at best. Sorry
I understand your concerns of repeated encodings.
Handling parts of the image as you describe can considered specialized handling and is perhaps best done by a specialized program like BetterJPG.

The best solution would however be to let a digital camera store images in a lossless format. But then one might have storage problems.
This is however much more practical today than say 4 years ago.

To 2.
And there we get again to the question how to know the original compression of a file. In my pictures from my digicam it is stored in the EXIF data. XnView shows the compressed bit per pixel as 15099488/3763200. Perhaps it is possible to use this. But I don't know if there even is a standard for compression ratio because every program has its own scala: XnView from 1 (bad) to 100 (best), PSP from 99 (bad) to 1 (best) and so on.

Yes, there is no standard way of storing this.
So this would always be application specific. But still useful.

Thanks for your interesting questions.
Lostclown

[Guest]

Every editing stage in a .png! Is there anything else?

[Olivier_G]

Every editing stage in a .png! Is there anything else?

Huh??? And when you want to save the final file into jpeg to save space... how do you proceed?

I support Anika's great suggestions. They may not be of ultimate importance - as others have mentionned - but they would be useful.

Olivier
PS: it may be interesting to share a wish/to-do list with priority in order to track those suggestions... No?

[Guest]

"Huh??? And when you want to save the final file into jpeg to save space... how do you proceed?"

By saving it as a .jpg, of course.

Might I suggest a program such as XnView? [/quote]

[Olivier_G]

By saving it as a .jpg, of course.

Huh??? (bis... )
But then you do not take advantage of what Anika proposes, which is to avoid COMPLETELY any new compression for unmodified areas of the picture while editing/saving jpeg file. Therefore your proposal (intermediate .png + finale .jpg) does not answer Anika's first point, and is a bit... err... out of topic.
(Otherwise, I agree that it is the way to go when you want to make several modifications with intermediate savings in order to avoid several jpeg compressions' effects. But this has nothing to do with Anika's suggestion...)

Olivier

[bingouly]

Hello, I know it is an old topic, but I think this option could be great.

[Drahken]

As a note; It is currently possible in xnview to save a pic with original compression (at least approxiamately).
Tools->options->read/write->jpeg->"use original quality". It should be noted though that a low quality setting on the slider will override this. ie If the original pic was saved at 80% quality and you have the slider at 85% or more, xnview will estimate the original quality & use that, usually resulting in a setting of around 85% (regardless whether you had the slider at 85, 90, 100, or anything else in the upper end). (Based on filesize comparisons, the estimated quality setting usually winds up about 5% higher than the original image.) However, if the original pic was 80% and you set the slider to 70%, then it will get saved at 70%.

[XnTriq]

The problem with this setting ...

• Tools » Options » General » Read/Write » Write » JPEG » Parameters » Use estimated original quality if possible

... is that XnView only takes the compression level (“Q factor”) into account, ...

By far the biggest contributor to the error (ie. file size savings) in the JPEG algorithm is the quantization step. This is also the step that allows tuning by the user. A user may choose to have a slightly smaller file while preserving much of the original (ie. high quality, or low compression ratio), or a much smaller file size with less accuracy in matching the original (ie. low quality, or high compression ratio). The tuning is simply done by selecting the scaling factor to use with the quantization table.

... but ignores other criteria such as chroma sub-sampling.

The act of rounding the coefficients to the nearest integer results in a loss of image information (or more specifically, adds to the error). With larger quality scaling factors (ie. low image quality setting or high numbers in the quantization table), the amount of information that is truncated or discarded becomes significant. It is this stage (when combined with the Run Length Encoding that compresses the zeros) that allows for significant compression capabilities.

There are other contributors to the compression error, such as the color space conversions, but the quantization step is the most important.

See also: Save JPG At 'Original' Quality

[bingouly]

Thanks for the reply, I have begin to read the Save JPG At 'Original' Quality[/quote] and found some links interesting.

I have started a program (in php) but it can only read information about the jpeg for the moment (dimensions, huffman tables, quantization table(s), etc..) but not decoding the data (Start of scan)

[XnTriq]

Lossless .jpg re-saving

RealWorld Photos avoids the incremental quality loss caused by repeated .jpg re-saving.

Unchanged areas of a photograph are not re-compressed during saving. They are taken directly from the original image. The whole process is completely transparent to the end user. It just works! You can even use layers and save the intermediate result in .rli format and still get the benefits of lossless re-saving when producing the final .jpg.

Lossless .jpg re-saving beats the .jpg -> .psd -> .jpg sequence by avoiding the one .jpg re-saving step that is present in that sequance.

The JPEG codec used in RealWorld Photos applications since version 2008.1 supports lossless and partially lossless operations with a JPEG image.

JPEG compression

JPEG compression was designed to be lossy, which means the encoded image is not saved exactly, but at a relatively very high compression ratio. The small loss of quality outweighs the high compression ratio if the image in question is a photograph. Unfortunately, when a JPEG image is repeatedly modified and saved, the loss caused by the compression accumulates.

Lossless processing

A JPEG image is divided into tiles (called MCUs - minimum compression units) and each tile is processed separately. The size of the tiles is 8x8 pixels, but JPEG can save chrominance (hue) information at smaller resolution and therefore a 8x8 pixels of chrominance information can effectively affect for example 16x16 pixels.

The JPEG codec in RW apps detects which tiles were not changed since the original JPEG image was opened and if such tiles are found, they are copied from the original image without any loss.

Practical usage

To modify your JPEG images losslessly, no special care needs to be taken. If you for example watermark an image and save it, only the portion affected with the watermark will be re-encoded. When cropping or extending the canvas, make sure to make the cuts on tile (MCU) boundaries if you want to have the image saved losslessly. To simplify this task, the crop tool supports tiled mode that only allows you to crop at 16 pixel boundaries.

Limitations

• If you convert a PNG to JPEG, the JPEG will NOT be the same as the PNG, the lossless saving only works from JPEG to JPEG.
• The lossless operations are only supported for standard YCbCr JPEGs (these are the most common JPEGs - every digial camera produces these JPEGs), it is NOT supported for Adobe RGB, grayscale, or CMYK JPEGs.