Results 1 to 6 of 6

Thread: Why does progressive helps compression so much in jpg's

  1. #1
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    885
    Thanks
    52
    Thanked 107 Times in 85 Posts

    Why does progressive helps compression so much in jpg's

    I've tried looking for a answers on this on the net so finally im asking th experts here.

    In basic term why does progressive encoding of jpgs seems to always offer better compression. both in greyscales as in Truecolor images.

  2. #2
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 62 Times in 33 Posts
    There are several reasons, sometimes sequential JPEGs hold more data since MCUs have to be padded with empty matrices but most of the savings probably come from better entropy coding since each progressive pass has its own Variable Length Encoding Tables and probably holds more similar data (Cb and Cr are necessarily handled separately) and if I'm not wrong there's also a trick to prematurely end a progressive scan when there's actually nothing else than zeros to send.
    Some tools like mozjpeg or jpegrescan trials many (dozens) different progressive configurations, on the sequential side most of the time only the fully interleaved scan with a single entropy table for both Cb and Cr is used whereas some more creative options could produce slightly smaller files, but this may cross the border between "baseline" and "extended sequential" JPEG and lead to some compatibility problems.
    If you are familiar with jpegtran I could try to find some odd configurations I used once to create different sequential JPEGs.

    For French speaking audience a put a video on YouTube to demonstrate why image dimensions in pixels slightly affects compression efficiency:
    http://www.youtube.com/watch?v=pSp_MnXBOPg

    A previous one has more background information RGB->YCbCr, chroma subsampling (unfortunately this one is too fast paced even native French speakers are not always able to cope with it):
    http://www.youtube.com/watch?v=V7LvgXqsh60
    Last edited by caveman; 6th May 2014 at 07:05.

  3. #3
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    Because the low and high frequency coefficients have different distributions. Progressive mode uses separate Huffman codes for them.

  4. #4
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by caveman View Post
    There are several reasons, sometimes sequential JPEGs hold more data since MCUs have to be padded with empty matrices
    That only happens at the edges and is a dimishing factor for large images.
    Quote Originally Posted by caveman View Post
    but most of the savings probably come from better entropy coding since each progressive pass has its own Variable Length Encoding Tables and probably holds more similar data
    Actually, itis entirely a choice of the encoder whether it uses separate tables or not. Of couse progressive provides the *option* to use separate tables, but it is strictly speaking not necessary.
    Quote Originally Posted by caveman View Post
    (Cb and Cr are necessarily handled separately)
    Well, AC components have to be coded separately for each component, thus again there is the option to given them separate Huffman tables. But the difference between Cb and Cr is usually not huge, and you can already use separate tables for sequential. Luminance/chrominance makes a difference, but that's as said not unique to progressive.
    Quote Originally Posted by caveman View Post
    and if I'm not wrong there's also a trick to prematurely end a progressive scan when there's actually nothing else than zeros to send.
    That's the block skip mode, additional symbols progressive allows, and yes, that's the one that provides the coding gain over sequential, especially for the first successive approximation passes. Again, it's a matter of how the scan pattern looks like, but typically, yes.
    Quote Originally Posted by caveman View Post
    Some tools like mozjpeg or jpegrescan trials many (dozens) different progressive configurations, on the sequential side most of the time only the fully interleaved scan with a single entropy table for both Cb and Cr is used whereas some more creative options could produce slightly smaller files, but this may cross the border between "baseline" and "extended sequential" JPEG and lead to some compatibility problems.
    No. Not at all. Baseline JPEG is Huffman sequential only. Thus, with progressive, you're already leaving baseline (that said, it's not a problem to do so, just saying...). The difference between baseline and extended Huffman is just the choice of the quantizers and, IIRC, some constraints on the Huffman codes. Thus, it's pretty harmless stuff. Progressive adds a lot, thought that's not baseline at all. Also, subsampling is (astonishlingly) not a matter of baseline or extended, and JPEG offers *insane* subsampling configurations (something like 5/3 or 7/13 subsampling factors are possible, though I have yet to see a single code that supports this insanity).

  5. #5
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 62 Times in 33 Posts
    Quote Originally Posted by thorfdbg View Post
    The difference between baseline and extended Huffman is just the choice of the quantizers and, IIRC, some constraints on the Huffman codes. Thus, it's pretty harmless stuff. Progressive adds a lot, thought that's not baseline at all. Also, subsampling is (astonishlingly) not a matter of baseline or extended, and JPEG offers *insane* subsampling configurations (something like 5/3 or 7/13 subsampling factors are possible, though I have yet to see a single code that supports this insanity).
    When you write about constraints on the Huffman codes do you point to the limit of 4 simultaneous Huffman tables?

    I did not try yet but could it be possible to use subsampling on all components (even Luma) to store a roughly zoomed in image (x2) using only one quarter of the original data?
    To be clear this sample has been upscaled from 128x128 to 256x256 pixels each 2 by 2 square has exactly the same color, could it be possible to apply 2x2 (4:2:0) subsampling to all components (would result in 3 internal 128x128 frames).
    I ask this because I heard some complains about HiDPI or so called Retina display that blur low res images when they upscale the image using interpolation, having a zoomed image that would not weight more could sometimes be a cheap solution for this problem.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	mushroomlamp256.jpg 
Views:	128 
Size:	42.3 KB 
ID:	2919  
    Last edited by caveman; 16th May 2014 at 01:28.

  6. #6
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by caveman View Post
    When you write about constraints on the Huffman codes do you point to the limit of 4 simultaneous Huffman tables?
    It's actually four tables *per scan*, not for tables in total. Each scan may come with its own table.
    Quote Originally Posted by caveman View Post
    I did not try yet but could it be possible to use subsampling on all components (even Luma) to store a roughly zoomed in image (x2) using only one quarter of the original data?
    That's unfortunately not possible, due to the way how JPEG signals the subsampling factors. Instead of just plainly including the subsampling factors as clear code, it signals the size of the MCUs (minimum coding units) per channel. If all channels have the same MCU size, subsampling factors are all one. The best you could do is to include a fourth dummy channel with no data, but then most decoders would try to reconstruct this as CMYK, so that's not a good alternative either. What happens if you include in addition an Adobe RGB/YCbCr marker, a JFIF marker or a color space as ICC profile is unclear. At least I would not expect consistent results amongst implementations. Specs might be clear on this, but implementations not always follow specs... Similar problem with JPEG 2000: Yes, subsampling factors are signalled in plain in the codestream, but the effective image size is given by the pixel dimensions divided by the gcd of all subsampling factors. But then again, JPEG 2000 has better means to drop high frequencies - just drop the the high passes. Thus, if you want to do this, you can, but in a different way than one might guess: Signal one additional wavelet resolution level, but do not include it. You even get bi-linear interpolation for free from the wavelet. JPEG XR only has hardcoded subsampling cases possible, and plain upsampling of all components is none of them.

Similar Threads

  1. Replies: 9
    Last Post: 12th June 2015, 00:28
  2. AMD helps WinZip optimize file compression
    By Sportman in forum Data Compression
    Replies: 5
    Last Post: 16th December 2013, 23:26
  3. UTF-8 transformation to 7 bits format, helps compression
    By caveman in forum Data Compression
    Replies: 3
    Last Post: 14th January 2013, 14:04
  4. New guy look for helps on naive questions
    By yacc in forum Data Compression
    Replies: 4
    Last Post: 1st January 2010, 18:39

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •