JPEG Lossless question. Why is the file size smaller?

[djboshh]

I noticed that when i took an original 7MB JPEG and applied a simple lossless operation like flip 180 degrees, the resulting file size after the lossless save is actually about 1MB lower than the original. Can i ask why it would be so much lower if the operation is lossless?

I tried it on other JPEG's and the same thing happens the 1st time i lossless save them too. However, it doesn't happen on any subsequent lossless operations after that.

[marsh]

One possible explanation: a lossless operation writes directly to file. Saving it afterwards (according to quality settings) would be an unnecessary step.

[djboshh]

One possible explanation: a lossless operation writes directly to file. Saving it afterwards (according to quality settings) would be an unnecessary step.

The lossless operation writes directly to file yes, and when i examine the file size afterwards it's 1MB smaller. I happened to notice too that if i perform another lossless operation on the same image again, the file size that time stays almost the same. I'm not doing ordinary saving or 'save as' operations, just lossless.

[XnTriq]

JPEGs whose dimensions are not divisible by 16 are cropped by XnView during “lossless” operations like rotating or flipping.

In general, all of the lossless transformation commands rely on the fact that the widths, heights as well as X & Y offsets are all multiples of the MCU size. In other words, all corners of the rectangles shown in the diagram above will line up on the boundaries of the JPEG MCU (Minimum Coded Unit) blocks.

In general, these blocks are 8x8 pixels, but can be 16x8, 16x16 or 8x16, depending on the chroma subsampling being used.

To be on the safe side, it is recommended that you try to select dimensions and offsets that are multiples of 16 pixels. In other words, W, H, X and Y should all be multiples of 16.

One cannot truly perform a lossless rotation on a JPEG whose dimensions are not an integer multiple of the MCU size. In other words, a photo that is 501 x 483 pixels cannot be properly rotated or flipped losslessly!
Please read my article that explains partial MCU and lossless rotate / lossless flip operations.

As described on the JPEG Lossless Rotation page, it is not possible to rotate some images losslessly. Images that have dimensions that are not a multiple of the MCU dimension (typically 8x8 pixels) will not be rotated or flipped losslessly. This page explains the reasons why.

[...]

Many programs will crop the partial MCUs instead of cropping pixels & shifting or extending, as this avoids the reduction of image quality.

• ImpulseAdventure: JPEG Lossless Rotation Test
• XnView Forum: Free file comparison utilities

[djboshh]

Hi all

I think I may have found the answer to this mystery:

My images are 4000 x 3000 and so are perfect multiples of 8 pixels. so that shouldn't of been a problem for the lossless operations. What I think may be going on is something called the Huffman codes. Huffman coding is an encoding algorithm used for lossless data compression and is used to reduce the size of the file i.e optimized. I think my camera probably doesn't optimize the file sizes of it's images when it's produces them (JPEG's), in other words un-optimized. I think XnView probably does optimize the file size when it saves JPEG files (both lossless & lossy) and thus the resulting file size becomes smaller. This would also explain why the file size reduction is only happening on the 1st lossless operation and not any any further lossless operations on the same image after that. Before I realised about Huffman coding I just thought that XnView had a simple lossless operation to perform and saved the file with the same code that was previously there (all be it rotated or cropped etc), but i now think XnView re-encodes the file, still lossless in quality but optimized in size.

http://www.impulseadventure.com/photo/j ... oding.html

[XnTriq]

Related information / discussions:

I noticed that sometimes optimise (huffman table) function increases filesize instead of making it smaller. There whuld be a way to check if that option actually optimised filesize and if not, optimising whuld be undone and only rest of cleaning options whuld be applied.

Optimise is not to reduce file size, but optimize the huffmann code

I would like to suggest to Pierre to keep the original JPEG coding in lossless rotations and croping, that is, if a file is progressively coded, it should remain progressively coded after rotation or croping. Ideally, the choice may be let to the user to change or keep the inital type of coding when performing a lossless rotation or croping, as in jpegcrop.exe, the program made by the independant JPEG group.

IMHO, the default settings should be:

• Optimize Huffman table = activated
• DCT Method = Float (best but slowest)

• Differences in nconvert&xnview jpeg compression
• More explanations for simple users

[vanyagor]

Related information / discussions:

I noticed that sometimes optimise (huffman table) function increases filesize instead of making it smaller. There whuld be a way to check if that option actually optimised filesize and if not, optimising whuld be undone and only rest of cleaning options whuld be applied.

Optimise is not to reduce file size, but optimize the huffmann code

I would like to suggest to Pierre to keep the original JPEG coding in lossless rotations and croping, that is, if a file is progressively coded, it should remain progressively coded after rotation or croping. Ideally, the choice may be let to the user to change or keep the inital type of coding when performing a lossless rotation or croping, as in jpegcrop.exe, the program made by the independant JPEG group.

IMHO, the default settings should be:

• Optimize Huffman table = activated
• DCT Method = Float (best but slowest)

• Differences in nconvert&xnview jpeg compression
• More explanations for simple users

Thanks a lot for this explanation. The last link is empty, can you fix that?

Do I understand correctly that the following behavior I observe is explained by the above (optimization):

I'm using XnView Media Detector v1.7.0 on Windows 7 to download pictures from an SD card. When AutoRotate is set to on, I observe file size decreased for all JPGs (including the ones which do not need to be rotated), and not the RAW files (in my case Pentax RAW file = PEF). Also the JPGs which were done by the camera TOGETHEER with a RAW file, do not get reduced in size, apparently the camera does optimize the JPGs produced in RAW+JPEG shooting mode.

Does this make sense?

Also could you please explain what am I missing (if anything at all) when I download the files "optimized" compared to just downloading the file the way it is in-camera?

Thanks again.

[XnTriq]

Welcome to the forum, vanyagor.

The last link is empty, can you fix that?

Done

I'm using XnView Media Detector v1.7.0 on Windows 7 to download pictures from an SD card. When AutoRotate is set to on, I observe file size decreased for all JPGs (including the ones which do not need to be rotated), and not the RAW files (in my case Pentax RAW file = PEF). Also the JPGs which were done by the camera TOGETHEER with a RAW file, do not get reduced in size, apparently the camera does optimize the JPGs produced in RAW+JPEG shooting mode.

Since I'm not really a photographer, I never used MediaDetector (or any other program of that sort) myself.
This sounds like a bug to me is a bug

A problem with the MediaDetector 1.7.0 (xnview 1.97.6):

Problem: The imported file are modified by the MediaDetector:
Original file size: 854.768 Bytes
New file size: 846.079 Bytes (new file is smaller !)

What I do:
I activate the Option: [x] Auto rotate JPEG images.
The file have already the Exif-Oriatation=1

So there is nothing to do, the file is not to rotate.

The bug is: MediaDetector modify the file, even though the file were not to rotate.

With out the feature "[x] Auto rotate JPEG images" the new and the old file are identical.

I'll contact Pierre (the developer of XnView) and ask him to take a look at this.

@admins: I think MediaDetector should have its own (sub-)section in the forum:

• Import function for WIA incompatible DEVICEs
• Transfert photos depuis APN vers Xn View
• XnView doesn't react to USB connection
• XnView Media Detector
• XnView Media Detector Link
• transfering mov-files with mediadector
• Xn View Media detector
• XnView Media Detector
• XnView Media Detector: Turn off Preview
• Download from memory Card with Rename Function
• Shutter count - Comptage obturateur et XnView Media Detector
• Generating file signatures in Create_File_Listing
• Project/Job Title in Mediadetector Import
• Downloading .AVI from camera
• Media Detector - Imports RAW Only
• Media Detector as ReName
• XnView Media Detector & IPTC Import
• XnViewMediaDetector - multiple issues
• About Xnview Media Detector
• MediaDetector: Skip files that allready exist
• MediaDetector: Use shooting date? (Online-Help?)
• Can I download photos from my digital camera?

[xnview]

I'm using XnView Media Detector v1.7.0 on Windows 7 to download pictures from an SD card. When AutoRotate is set to on, I observe file size decreased for all JPGs (including the ones which do not need to be rotated), and not the RAW files (in my case Pentax RAW file = PEF). Also the JPGs which were done by the camera TOGETHEER with a RAW file, do not get reduced in size, apparently the camera does optimize the JPGs produced in RAW+JPEG shooting mode.

Could you send me JPG samples?

[Grand Titus]

Since it is my first post on this forum, I want to congratulate the authors of XnView. This is really a wonderfull software

Now I will share with you my own experience:
-I have a Sony Alpha 700
-output picture size is 2848x4272
-when I use "JPEG Lossless transformation"/"Rotate based on EXIF value", file size always decreases of about 500ko
-I tried other softwares to do this operation (e.g. JPEG Lossless Rotator http://annystudio.com/software/jpeglosslessrotator/) with exactly the same results

On the web (like on this post), I saw everywhere that if the picture dimensions are multiple of 16, the rotation is really lossless.
This is the case of my pictures: 2848/16=178 and 4272/16=267
Thus, "why is the file siez smaller?"

After reading the wonderfull JPEG tutorial of ImpulseAdventure http://www.impulseadventure.com/photo/j ... ssion.html, I installed JPEGsnoop (http://www.impulseadventure.com/photo/jpeg-snoop.html).
This tool explores a JPEG file and exposes all details of its compression.

I compared 2 JPEGsnoop logs: the fisrt coming from a camera picture and the second coming from the 'XnView rotated' picture
Among all compression details, the main difference I discoveredis this section that exists only on the fisrt log:

*** Additional Info ***
NOTE: Data exists after EOF, range: 0x002CBB6D-0x003492AF (513858 bytes)

I still don't know what are these "Data after EOF" (probably some Sony's metadata), but it seems that they are dropped during the lossless operation.
I am reassured: the rotation is not so "lossless" but it doesn't decrease the quality of the picture.

I hope that it can help someone else.

[XnTriq]

Welcome to newsgroup.xnview.com, Grand Titus.

Could you try to rotate your test photo with Jpegcrop and check the result with JPEGsnoop?

The Jpegcrop Windows Application was initially developed to provide a convenient interactive user interface for the new jpegtran -crop feature.
It has now developed to a nearly complete user interface replacement for jpegtran, and furthermore for demonstration of the new djpeg and jpegtran -scale features.

The JPEG functions are based in part on the work of the Independent JPEG group

Jpegcrop v2012 uses the latest version of IJG's library including jpegtran, and it would be interesting to know if your reported problem is a bug in jpeglib.

• Lossless JPEG transformations
• JPEGsnoop — JPEG File Decoding Utility

[Kadilov]

Hi guys,

I can confirm that size changes with my 2816 x 2112 photos from cheap Canon A495 when I use lossless rotation based on EXIF (even if the photo is not actually rotated). Checked on the latest XnView 2.00 downloaded as zip.
Did you come to some conclusion?