Results 1 to 10 of 10

Thread: JSK -JPEG Scan Killer- progressive JPEG explained in slowmo

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Member caveman's Avatar
    Join Date
    Jul 2009
    Strasbourg, France
    Thanked 64 Times in 33 Posts

    JSK -JPEG Scan Killer- progressive JPEG explained in slowmo

    Colt McAnlis recently wrote "Image Compression for Web Developers", the article was rather good but I've found that the part concerning progressive images lacked details and was somewhat misleading.
    Explaining progressive JPEG is far from being easy since two mechanisms are involved: "spectral selection" and "successive approximation", thus I thought that it would be cool and enlightening to actually see what happens in the different scans (refinement passes).
    I quickly hacked together JSK -JPEG Scan Killer- as the name suggests it takes an existing (progressive or sequential) JPEG and progressively removes all the scans excepted the first one. This is done crudely by inserting an End Of Image marker and cutting the rest of the file, therefore the files produced by JSK are truncated JPEGs that do not comply with the specs but most decoders will do their best to display them, this means they will often blur the image as if it was still in-flight.
    Jpegtran can be used to turn them into standard JPEGs (will no longer be blurred when displayed) and PNGOUT does not complain when encoding them as PNGs (it has some flaws though). Such a series of PNGs can be turned in an animated PNG -APNG- with tools like apngasm or closely inspected at will.

    command line usage:
    jsk file.jpg
    will create files named scan-xxx.jpg

    Linux, Mac OS X binaries and C source in tarballs below.
    Windows binary in zip archive below.

    Now to clarify some points for those not familiar with JPEG inner workings, contrary to PNG with its Adam7 interlaced mode, there are tens of thousands different ways to produce progressive JPEGs, "progressive" is definitely not restricted to a single predefined way. For instance JPEGrescan conducts trials with different progressive configurations to reduce the file size, yes progressive JPEGs are often smaller than sequential ones. Even what is often called "baseline JPEG" ("sequential" is more appropriate) could be recorded in 13 different ways. 99.99% of sequential JPEGs use the single scan with 3 interleaved components scheme therefore JSK will only output a single scan_001.jpg file when it encounters one of these numerous sequential JPEG (it's not a bug, it's a sequential JPEG).
    JSK produces between 1 and 3 scan images when the input file was a sequential JPEG, 4 scan images and more mean the input file was a progressive JPEG.
    On this sample (click to enlarge) the images on the left represent one of the shortest progressive sequence and those on the right one of the longest sequential sequence.
    Click image for larger version. 

Name:	smiles.jpg 
Views:	1126 
Size:	118.3 KB 
ID:	2500
    A sequential JPEG can be turned into a progressive one losslessly (and the other way around) using jpegtran. Most of the progressive sequences shown here have been crafted for educational purpose, you'll find "custom_something_scans" text files in each archive these were used to produce the specific sequence the sample illustrates, feel free to reuse them (-scans option in cjpeg/jpegtran, syntax of scan files is explained in the wizard.txt file).

    Commented JSKs output
    The arrays representing JPEG "data units" on the right were hand added, they reflect the various DC/AC coefficients available so far for each YCbCr component. Only 5 data units per component are fully displayed, a 272 by 176 pixel image is actually made of 34 x 22 = 748 data units per component (when chroma sub-sampling kicks in this figure is usually halved or quartered for Cb and Cr components). If you are not familiar with YCbCr components and chroma sub-sampling I've started to write a .pdf document (yet another work in progress) called "JPEG for the horseshoe crabs" meant to expose JPEGs inner workings, read it first and get back.

    - "spectral selection" is represented by filled cells (Y: light gray, Cb: yellow-green, Cr: violet) along the zigzag path.

    - "successive approximation" is represented by partially filled cells (starting at sample 3).

    1) Fish sample
    - The initial scan is very common, it's an interleaved scan holding the DC coefficient of the 3 components.
    This results in the typical mosaic image made of 8 by 8 pixel squares.

    - The second scan holds the 9 first (in the zigzag order) AC coefficients of the Y component.
    The dorsal and caudal fins take form and the eye is now round. The red colored blocks are clearly twice as big as the initial 8 by 8 mosaic this reveals that 4:2:0 (2x2) chroma sub-sampling has been applied.

    - The third scan holds the 9 first (in the zigzag order) AC coefficients of the Cb component.
    Some temporary green and purple spots appear this is due to the unbalanced quantity of information now available in the Cb and Cr components.

    - The forth scan holds the 9 first (in the zigzag order) AC coefficients of the Cr component.
    Chroma is now well balanced, a lot of jaggies remain especially near the fish/background border.

    - The fifth scan holds 18 AC coefficients of the Y component.
    The overall image quality jumps suddenly, this illustrates the importance of the luma signal compared to chroma and also shows that the first half of the AC coefficients is usually more important than the later ones.

    - The last scans will only slightly improve the image quality, some JPEG compression artifacts remain even after the last scan this is due to the lossy aspect of JPEG compression.

    2) Snap sample
    - The initial scan only holds the DC coefficient of the Y component.
    Since there's no chroma signal the mosaic is in grayscale.

    - The second scan holds the 9 first (in the zigzag order) AC coefficients of the Y component.
    Still no chroma, the overall shape of the windows appears but texts look totally weird.

    - The third scan is an interleaved scan holding the DC coefficient of the Cb and Cr components.
    This brings some color.

    - The forth scan holds 18 AC coefficients of the Y component.
    Texts are now readable but there's a lot of image noise around them. Horizontal window edges are plagued by ringing artifacts (lighter ghost lines).

    - The fifth and sixth scans hold 9 AC coefficients of the Cb and Cr component respectively.
    This improves color accuracy and reduces smearing around color spots.
    The same DC/AC coefficients are now available for this image as on the fifth scan of the fish image (at this point the fish looked rather good) the artificial nature of the snap image makes it harder to compress, JPEG has been tuned (quantization tables, zigzag order) for continuous tone images which makes the sharp edges in this image harder to compress whithout artifacts (that's why some images -say cartoon like- should definitely be saved as PNGs and never as JPEGs).

    The and archives hold the original JPEG image, a custom scan file (-scans option in cjpeg/jpegtran), the 8 or 9 scans as raw JSK outputs and as PNG files and finally an animated PNG (use Firefox or Opera to watch it).
    The animations are also available independently, click on the thumbnails below to watch them (a new scan is displayed every 1.5 or 1.8 seconds, be patient).
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	fish_scan.jpg 
Views:	958 
Size:	774.3 KB 
ID:	2475   Click image for larger version. 

Name:	anim_fish.png 
Views:	596 
Size:	279.4 KB 
ID:	2476   Click image for larger version. 

Name:	snap_scan.jpg 
Views:	734 
Size:	781.7 KB 
ID:	2478   Click image for larger version. 

Name:	anim_snap.png 
Views:	506 
Size:	122.6 KB 
ID:	2479  
    Attached Files Attached Files
    Last edited by caveman; 11th June 2014 at 02:15. Reason: Added some JPEG background informations

  2. Thanks (4):

    Biozynotiker (6th October 2013),Jaff (8th October 2013),lorents17 (28th December 2013),Mangix (30th September 2013)

Similar Threads

  1. JPEG Huffman Coding
    By lorents17 in forum Data Compression
    Replies: 26
    Last Post: 16th December 2013, 00:51
  2. Unoptimizing? a JPEG file
    By Mangix in forum Data Compression
    Replies: 7
    Last Post: 7th September 2013, 12:55
  3. jpeg to zpaq lossy compression
    By toi007 in forum Data Compression
    Replies: 11
    Last Post: 24th January 2013, 04:20
  4. Test JPEG Standards Online
    By thorfdbg in forum Data Compression
    Replies: 0
    Last Post: 27th November 2012, 22:14
  5. Detector for ex-JPEG images
    By Alexander Rhatushnyak in forum Data Compression
    Replies: 22
    Last Post: 13th September 2012, 04:18

Posting Permissions

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