From Wikipedia, the free encyclopedia
Jump to: navigation, search
Former good article nominee JPEG was a good articles nominee, but did not meet the good article criteria at the time. There are suggestions below for improving the article. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.
October 28, 2007 Good article nominee Not listed
WikiProject Computing / Software (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as High-importance).


Billa charles — Preceding unsigned comment added by Billa Charles (talkcontribs) 03:20, 22 March 2014 (UTC)

Need a better Video to show the continuosly varying JPEG compression[edit]

A better video could be utilized to showcase the compression scale from Q=100 to Q=1. Below are few reasons for my point: 1. The video is black and white i.e. grey scale. JPEG's strength lies in capturing and rendering the colors of natural images, photos. — Preceding unsigned comment added by (talk) 08:36, 6 July 2014 (UTC)


Should this vulnerability be added to this article? As with many compressible file formats, the relatively small size of some JPEG files can hide the requirements to view or process some JPEG files. For example, the webpage has a link to a 618KB JPG file of a 10,000 x 10,000 pixel 24-bit image, which if a program converted to an uncompressed format would require at least 300MB of memory or file storage. • SbmeirowTalk • 08:08, 22 November 2014 (UTC)

If this topic isn't added to this article, should we create an article similar in concept to Zip bomb, E-mail bomb, Billion laughs articles. Possibly name the article "JPEG bomb"? • SbmeirowTalk • 08:16, 22 November 2014 (UTC)

Has anyone come across an article/blog on the internet that describes this vulnerability? • SbmeirowTalk • 08:19, 22 November 2014 (UTC)

It's probably not DCT, it's flood fill ![edit]

You make a balanced flood fill over the source image that aborts when the average of all covered pixels differs with the current pixel by more than a tolerance limit. The covered area is then filled with the average value of all of it's pixels. When you compress the result with RLE or ZIP, you'll see that a lot of redundancy can be won without completely ruining the image. When the resulting image doesn't look that good or photorealistic, you can still interpolate the areas with sinus or cosinus formed shades and it will get a bit better.