Return to Digital Photography Articles
JPEG Compression Quality from Quantization Tables
DQT / Quantization Matrix / JPEG Compression Quality tables for Digital Cameras and Digital Photography Software.
Index of Quantization Table Sources
Would you like to compare two quantization tables?
Want to extract a quantization table or detect a forged/edited photo??
Background Material
For some background on quantization tables and their use in JPEG compression, please see my JPEG compression article.
For examples and description of the breakdown of an image into 8x8 blocks, please see my article on the JPEG Minimum Coded Unit.
In JPEG compression, the quantization step is performed just prior to the JPEG Huffman Coding.
Example of a Quantization Table
The following diagram shows a typical luminance DQT found in a high-quality digital photo. Note that the numbers increase in magnitude as one approaches the bottom-right corner, which describes the amount of compression (loss) applied to high-frequency image components. Numbers towards the top-left corner (low-frequency & "DC") decrease as we typically don't want to discard this image information as the human visual system will tend to notice "errors" here.
Comparison of Quantization Tables
In trying to evaluate the differences between different software packages and their "quality settings" when saving to JPEG, I have extracted the quantization tables used in each case. In order to do this, I have used my JPEGsnoop utility which locates the offset of the JFIF marker tags within each image, and then extracts the linear stream of bytes from this marker, recreated the zig-zag representation of the quantization (DQT) coefficient matrix and have presented the results here.
In each of the following examples, when I make a reference to "better quality" it is meant in the sense of less quantization error (compression error / loss) and therefore better resulting image quality. The converse is true for "worse quality". The baseline for each of these "better / worse" comparisons is the original digital camera photo as produced by my Canon 10d digital SLR in Fine JPG mode. This helps give one an idea of a comparable quality setting to that used from the camera itself.
Compare JPEG Quality of Digicams and Software
Please check out my JPEG Compression Quality comparison page, where you can interactively compare the quantization tables of different sources!
JPEG Standard
These are the quantization table / matrix coefficients that are recommended / suggested in the Annex of the JPEG standard.
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Photoshop CS2
The JPEG quality range for Photoshop CS2 runs from 1-12. It is expected that this range was used to give the user an idea that 10 is really the most anyone should use, and that 11 and 12 are there purely for experimental reasons (not much gain in quality for a large increase in file size).
Note that the quantization tables generated from a save within Photoshop CS are concatenated together into a single quantization table of length 132 instead of the 2 x 67 that we see in other software programs and the digital camera itself.
- One should realize that none of Photoshop's quality settings in the Save As dialog box will match any digital camera's JPEG compression tables. Therefore, you cannot avoid recompression error when resaving an image from a digicam in Photoshop!
Photoshop CS2 Chroma Subsampling
Note that Photoshop changes its use of chroma subsampling depending upon the image Quality setting in the Save dialog. Photoshop CS2 uses 1x1 (no chroma subsampling) in Quality 7-12, but 2x2 (chroma subsampling in both horizontal and vertical directions) in Quality 0-6. Note that this use of chroma subsampling throws away significantly more image information than the subsampling used by most digital cameras (except some basic digital Point & Shoot digicams).
Photoshop only offers 2x2 or 1x1 (none) chroma subsampling. Most digital cameras use 2x1 chroma subsampling. Therefore, you will have to either choose to over-compensate in the color channels (by doubling the horizontal color resolution of the original source) or discard (by eliminating / averaging the color resolution in the vertical component). I don't know why Adobe didn't choose to provide a saving option that would be closer to what digicams use — better yet, a choice in chroma subsampling, like IrfanView.
Don't use Photoshop Quality 7!
What many people don't know is that there is a quirk in the way that Photoshop defines its quality range. As mentioned earlier, Quality level 6 is the last point in which chroma subsampling is used. At Quality level 7 and higher, no chroma subsampling is used at all. With the amount of color information encoded now doubled, the file size would have naturally increased significantly at this level versus the previous level.
However, it is likely that Adobe decided to allocate the various quality levels with some relationship to the final compressed file size. Therefore, Adobe chose a poorer luminance and chrominance compression quality (i.e. higher level of compression) in Quality level 7 than Quality level 6!
- What this means is that the image quality of Quality level 7 is actually
lower than Quality level 6.
This fact has been confirmed with subjective MOS scores against various images at both quality levels.
The only advantage of image quality 7 over quality 6 is that the chrominance detail hasn't been subsampled. So, there is perhaps some degree of benefit to the ability to resolve color information over the previous level, but this benefit is also diminished somewhat by the higher-compressed chrominance table.
You can see the above juxtaposition in the JPEG Quality comparison list.
Photoshop CS2 Quality vs File Size
The following graph shows the relationship between the file size of a typical 6 megapixel photo (from a Canon 10d) and the quality setting selected within Photoshop CS2.
NOTE: There are many reasons why one should not take file size as any indication of a quality comparison. The most important reasons being: different quantization tables, different huffman tables / optimization, orientation differences and additional metadata stored within the JPEG JFIF file.
- With Quality 10, the level of compression is "worse" than that used in the digital camera.
- Using Quality 12, results in "better" quality than the original Canon 10d digital camera photo.
Canon Digital Cameras
- Canon 1Ds Mark II - This camera uses the least amount of JPEG compression (and thus highest quality) of any of Canon's digital SLRs.
- Canon 1D Mark II - Not surprisingly, this camera uses the second to least amount of JPEG compression of any of Canon's digital SLRs.
- Canon 5d - There are extremely small differences in the luminance table in the Canon 5d versus the 30d/20d.
- Canon 30d, Canon 20d, Canon 10d (Fine Mode)- All of the prosumer line uses the same set of tables. One can see that the degree of quantization rounding used in Fine mode is quite minimal, ie. there is not much compression loss at this setting.
- Canon 30d, Canon 20d, Canon 10d (Normal Mode) - In Normal mode, the quality suffers quite significantly, putting it at worse compression than just about any other digicam's Fine mode.
- Canon PowerShot S3 IS - The Canon PowerShot S3 IS has comparable luminance compression as to the Canon 10d, but considerably worse chrominance compression. However, it is still much better than the Canon PowerShot SD400 in this regard.
- Canon PowerShot SD400 - Typical for a point and shoot digital camera, the JPEG compression quality is lower than the digital SLR counterparts.
Sony Digital Cameras
- Sony DSC H9 - Interestingly enough, it appears that the Sony DSC H9 is one of the first cameras that I have come across that use automatic / variable image compression. The quantization tables are selected at exposure time by the camera, rather than relying on a couple-position user level setting. This has some very interesting implications. I am currently in the process of analyzing images from this camera to understand the reasoning and algorithm that is being used. Please see the Variable JPEG Compression page for more details on this camera's feature.
Sigma Digital Cameras
- Sigma SD10 - Note that there is no chroma subsampling in the Sigma dSLRs with the Foveon sensor. In addition, there is extremely little compression being used on this camera when compared to other dSLRs.
Nikon Digital Cameras
- Nikon D2x - Interestingly enough, it seems that the Nikon D2x and Sigma SD10 share the same quantization tables and hence compression quality.
IrfanView
- The JPEG quality range for IrfanView runs from 0 to 100.
- At quality setting 97, IrfanView uses slightly "worse" compression than the original Canon 10d digital photo.
- At quality setting 98, IrfanView uses slightly "better" compression than the original digital camera photo.
12 users online
Reader's Comments:
Please leave your comments or suggestions below!But I guess it depends on the algorithms that each program uses.
I am using ACDSee and I gathered that my Canon 400D uses a similar to 96% quality, when comparing to the output. But when I examine other files that I get, already handled, I sometimes wanted to match the same compression level to return the edited pic.
And thanks for this cool info you have here!
Regards from Portugal
Leonel
is there any known method to encode a JPG image file ("SOS" and scan data) using predefined/user given quantization tables (DQT), SOF0 parameter block and Huffman tables (DHT)?
I need this for reconstruction of EXIF thumbnail images.
Jhead -rgt does rebuild a thumbnail, but it uses different quantization tables and SOF0 parameters which are useless for my purposes.
As for changing the SOF0 parameters, you might want to see if exiftool can do this for you.
You were right when you doubted that the photo reader would use a hard-coded DQT. After I read your reply, I modified the DQT in the thumb file, which does work, rather than trying to get the thumb file, which does not display, fixed. This confirmed that the photo reader indeed uses the DQT in the file. Changing the DQT table in the working thumb file changed the appearance of the displayed thumb, but is still displayed.
I am still befuddled why one thumb file displays while the other one does not when inserted into an Image file and looked at in the photo player. Both thumb files open in all software based photo editors I tried. Both thumb files have the same set of JPG markers in the same order, and the identical EXIF entries. I could post a link for the two file for anyone to have a look at, and solve this technical puzzle.
[UPDATE 09/15/2007]: After receiving the files from Udo, I figured that the HDTV Photo Player may expect that thumbnails are encoded with 2x1 chroma subsampling. For nearly all digicams, this assumption will be correct -- although it may still fail on images from some very low-end digicams that use 2x2 subsampling.
In the samples that he provided, JPEGsnoop reported that the images that didn't work on the player had hand-embedded thumbnails with either no subsampling or 2x2 (horizontal and vertical). I recoded one of his sample thumbnails to 2x1 and after inserting this thumbnail into his file with his HDTV Converter software, he reports that it now works!
Thanks for your wonderful page on DQT. I learned more from your page than any of the others. I also appreciate the CS2 compression tip.
I prefer to look at, and share, my camera picture on a plasma HDTV using the excellent Panasonic photo reader. I have tried many photo editors; none saved images in a JPG format that they could be read by the hardware-based photo reader.
I am writing a programme that scales images from a camera or images saved with Photoshop (and other photo editors) into the HDTV aspect ratio, and more importantly, saves the image in a JPG format, which can be read by the hardware based image reader. I have accomplished that for the main image. I am stuck to get the embedded thumb preview into a format that can be read by the photo reader. Through trial and error, I have come to the conclusion that the problem is caused by the DQT table used to compress the thumb image. I suspect that the reader does not use the embedded thumb DQT, but uses the digital camera thumb image default DQT. Possibly, because the thumb conversion is hard-coded in the converter IC used in the reader.
I have been looking for some sample code (any language -- C preferred) to create JPG images using custom DQT tables, but have not found a single one. Any help would be appreciated.
So that I understand your problem better: is the photo reader able to read any thumbnails successfully? You were suggesting that the reader uses a "digital camera thumb image default DQT" -- which default DQT would this be? (default for thumbs from Panasonic digicams?) Since there is no universal default DQT for thumbnails, this doesn't seem as likely.
What brought you to the conclusion about the reader ignoring the embedded thumbnail DQT entries? Is the reader able to see any image data at all, or does it simply report an error? If the DQT table were being ignored (and a hardcoded DQT table in the hardware were used instead), then you should not get an error in the reader, but just some garbled image preview instead. If the wrong DHT tables were used, then yes, the decoder may encounter a failure.
As for encoding JPEG images with custom DQT tables, all JPEG encoders can use an arbitrary DQT table. Have a look at the IJG JPEG encoder C source code, and you'll see that you can simply substitute any quantization table you like.
Please feel free to post any more questions you have -- I'm sure that we can get your photo reader to work for you!
with regards
vinodh
I'm looking for the all types of actual used Quantization Tables for each Digital Camera's parameter settings. Could you tell me if it's possible to use any mathematical equations and the Quantization Tables above to get them all?
Best regards!
Eric
Each camera manufacturer and computer program selects their own quantization tables for each arbitrary quality setting. The only case in which you can mathematically figure out the quantization tables from the quality setting is in programs such as Irfanview and other IJG-based JPEG encoders, where the quantization table is scaled by the quality setting (according to the function shown in the comment posted on 2006-03-07).
To summarize, the Discrete Cosine Transform was chosen for JPEG images over Fourier Transforms because the DCT includes basis functions that have twice the period of the lowest-frequency Fourier function. This means that DCT will compress images with slower-changing components (such as the luminance) better than a Fourier Transform.
Then, the top-left corner of the interpolated 16x16 matrix may start as:
So, we are simply inserting an averaged value between each of the original 8x8 matrix values. As I mentioned earlier, this may not be the best way to create a 16x16 quantization matrix, but it may provide a starting point.
Of course, the best approach would be to process hundreds of photos experimenting with different tables (probably based on the interpolated 8x8 version) and then attempt to compare peoples' objective opinion of the quality of the compressed image against the file size savings. This is the process that was used to generate the original 8x8 tables that appear in the JPEG standard. Unfortunately, this is a very difficult and expensive process to use, and hence why many encoders probably rely on the JPEG standard's example tables as a starting point.
Clearly, you can create any quantization table you want, but the difficult part will be finding the optimum balance between image quality and file size reduction.
What is the logic behind the quantization table? Is it purely random or basend on some logic like HVS? What is the significance of the specific numbers. For example why should the first number be 16 and not some other no.
Kindly answer
veeraswamy
So, the human visual system dictates the ratios between values that appear in the quantization table. The absolute values (overall scale factor across the entire table) is determined by the total image compression ratio that one desires.
Many software programs will have a built-in quantization table (sometimes based on the one suggested in the JPEG Standard), one for luminance and another for chrominance. They then scale all values in this base table according to the JPEG Quality that the user chooses (e.g. 0-100). So, the absolute values in the resulting quantization table is based on the desired compression / quality tradeoff, but the original base table was based largely on characteristics of the HVS.
Furthermore, the fact that the Human Visual System is not very well-tuned to see error / loss in the color components (versus the luminance components) means that nearly all programs and digital cameras start with quantization tables that have much larger numbers in the chrominance table than the luminance table.
As for the selection of 16 versus some other number, it really is somewhat arbitrary. But an analysis of thousands of photos with different measurements of human perception have allowed optimum quantization values to be chosen that offer the best compression (largest coefficients) while still preserving the majority of the image quality of the original. These optimum tables are provided in the Annex of the JPEG Standard. Note all manufacturers or software vendors chose to go with these suggested tables -- instead, they came up with their own, probably after a considerable amount of their own analysis.
I have a question, on my Canon A540 there is a 2816x2112 and a lower 2272x1704. In order to keep file size a little lower, I have been opting for SuperFine (the highest compression) while dropping down to the lower res. Looking at your tables, though, I see that the 1704 res isn't a multiple of 16, which will give me problems with doing lossless rotation. Would you recommend going back up to the higher res and dropping down to the Fine compression? I doubt I will ever print anything larger than a 8.5 x 11, if ever that large.
So, what this means is that you certainly can still rotate your photos losslessly, but don't use Windows XP Explorer or Windows Picture and Fax Viewer! Doing so will result in image degradation. Instead, you can use IrfanView, BetterJPEG, jpegtran or a host of other applications.
In light of this, by all means shoot with the reduced resolution, but keep the compression quality high (BTW, SuperFine will be the highest compression quality, but the lowest compression amount). When it comes time to rotate the photos, use something other than Windows to rotate, or better yet, use a photo import utility to perform this for you automatically on the basis of EXIF information.
As an aside, I would never recommend dropping the compression quality over reducing the resolution. JPEG compression artifacts generally do far more damage to the appearance of your picture than simply having less resolution.
Good luck!
Could you describe more particularly process of transformation BMP in Jpeg
I found this page as I was looking for information on Canon EXIF formats. I found the information very useful. Thank you for creating it.
I have written (on my Mac) a C program to extract selected EXIF info from the images from my digital cameras so I can load them in my database. I am trying to find a way to express the "quality" of the JPEG compression, but there does not seem to be a standard way to save this in the EXIF. My Pentax returns in tag 0x9102 the number of compressed bits per pixel, but the Canon does not, although it has a quality value in word 3 of the CanonMaker tag 0x0001. Any suggestion on how I could compute an approximation of quality, say in a range 0-12 as per Photoshop, independently of what device or software created the JPEG file?
Thanks in advance. Regards.
Daniel Guerin
How are you intending on using this quality rating in your database? Are you trying to compare quality between images from different cameras? This is not really practical as cameras all use different quantization tables and it is hard to linearize the comparison between 64-entry quantization matrices.
That said, you have a couple options:
Thank you
If someone is aware of more specific reasoning for this, I would be very interested to hear it.
As for the energy distribution before and after compression, I understand that the DCT transform step itself satisfies Parseval & Plancheral's relations. The variance of a tile in the spatial domain can be represented in the DCT domain as equal to the squared average of the AC coefficients (prior to quantization).
Hope that helps, Cal.
Thank you for helping me last time.
I would like to ask you about JPEG decompression,what are the steps and what is the dequantization step?
Another quation : if you know any thing about the Speach compression , and what is ADPCM and how it is work .
thank you
how I can implement JPEG using MATLAB spacially the Quantization step
thank you
Some authors give a compression ratio (10:1, 30:1, etc) and some give quality factor (10%, 75%, etc) while talking about JPEG compression in their studies. To make a comparison, what is the relation with these terms, i.e can we say for example 30:1 compression ratio is more or less equivalent to bla bla percent quality factor JPEG compression?
Best regards
Erkan Yavuz
That being said, it is easy to determine the compression ratio of an image, as this can be done by looking at the difference in the image stream size versus the uncompressed original (resolution x 3 Bytes per pixel).
Hope that helps... As alluded to earlier, the newer JPEG2000 format actually sets a known relationship between a compression quality setting and an output size (i.e. compression ratio).
I would like to know how to compute the compression ratio using different quantization tables provided above!I would like to know how can I compute the number of bits reduced when I use a certain quantization table
Thank you inadvance.
Mona
As for translation from quality factor into the new quantization matrix, here is the algorithm used by cjpeg:
Hope that helps,
Cal.
Could you show me all the Quantization Tables of IrfanView--quality from 0 to 100.
Thank you~
Nearly all applications I have seen use quantization tables that are based on the ones defined in the standard's annnex. It would take a fair amount of investigative effort to develop a different set of tables that are better. The difference is in the scaling of the matrix coefficients on the basis of the quality factor. It looks like files from some digicams use their own optimized quantization tables.
The hard part is that the conversion between quality factor and the scaled quantization table is really application-dependent. So, trying to determine what quality factor gives certain matrix coefficients is really hard.
You can't directly specify the quantization tables in Photoshop. Other tools, such as cjpeg, do, however.
I am looking for 4x4, 16x16 and 32x32 quantization tables..Can you help me ?
Best Regards
Imran KHAN
I would start with the suggested 8x8 table and then interpolate the values to get the 16x16 and 32x32 (perhaps using bicubic interpolation or just linear). It would take some extensive experimentation to find the optimal values for these tables to work with arbitrary image data. While I haven't seen any published, I think the interpolated versions should provide a reasonable starting point.
NOTE: I am out of the country for several months (in India), so comments will be held and only posted infrequently. Thanks!