Talk:JPEG

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the JPEG article.
Please sign and date your posts using four tildes (`~~~~`). New discussion topics go at the bottom of the page; click here to start a new topic. New to Wikipedia? Welcome! Frequently asked questions. This is not a forum for general discussion about the article's subject.	Talk page guidelines Be polite Assume good faith No personal attacks Don't bite the newcomers!

[edit] Multimedia Wiki

Could some of the authors contribute to the wiki.multimedia.cx jpeg article? Dcsmith77 02:58, 21 October 2006 (UTC)

[edit] Wikipedia's JPEG Encoder

wikipedia JPEG encoder is piece of shit. Filesize is 3 times what it should be and everyone knows it. It's Wikipedia's problem.

[edit] Page Appearance

Notice how the flower graphic at the top of the page blocks some of the text? Not sure how to correct this myself, if indeed it's not just an issue with my own browser? I thought it worth mentioning just in case.

[edit] Virus Alert to add?

There was a computer virus alert earlier this year regarding the JPEG format. Evidently, there's some way to hide a virus in a jpeg file, and have the virus activate when the jpeg is loaded in a typical viewer. This would be good info to include, but I would want to research and verify the details first. Perhaps someone will beat me to it? Wesley

There is some weird virus that attaches itself to JPEG files. (Un)fortunately, JPEG files cannot be executed on any computer I know of, so the virus will never be activated. The writer might as well have written a computer virus that attaches itself to lamp shades, that would have the same effect. See [1].--branko

Unless there's a buffer overrun or similar exploit for some commonly-used JPEG decoder library... -- The Anome 09:22, 1 Sep 2004 (UTC)

iirc there was (iirc it was in a microsoft implementation) Plugwash 20:48, 2 Apr 2005 (UTC)

[edit] graphics

pl:JPEG If you would like to use some graphic for this topic.

There's an online Polish-English translator that does one sentence at a time, though results can be sketchy. (unsigned comment by Ke4roh

anything that uses the % sign when describing jpeg quality has no credibility whatsoever sorry Plugwash 20:48, 2 Apr 2005 (UTC)

[edit] external link

Are you sure the "Compress JPG and GIF images" link is appropriate for this article? The site looks quite commercial, but I didn't delete it since I didn't know if someone put it there on purpose or if was simply vandalism. TheListener

mmm link didn't work at all for me i'll try it again later. Plugwash 20:48, 2 Apr 2005 (UTC)

[edit] typo to be fixed

In the example 8 by 8 matrix to be put through the jpeg compression algorithm, there is something wrong with the entry 68 in row 6, column 6, because subtracting 128 does not give the asserted result -65 in the next displayed matrix. It is not clear which of the two matrices is wrong, except that the discrete cosine transform result matches the second matrix rather than the first. These matrices, with same inconsistency, also appear in the second edition of the Gonzalez/Woods book Digital Image Processing, second editon, page 499. Hopefully the author of this page can clear up the inconsistency. ---- 24.118.95.84 (sig added by Cburnett)

How's that now? Cburnett 03:58, Apr 19, 2005 (UTC)

Not sure. Which of the two numbers was wrong? ---- 24.118.95.84 (sig added by Cburnett)

You'll have to go into the history and check. I re-ran all the numbers and just pasted them in. Cburnett 02:11, Apr 20, 2005 (UTC)

I contacted the original author of the example to determine which of the numbers to correct. The correct fix is to 63. ---- 24.118.95.84 (sig added by Cburnett)

You're point is irrelevant as everything is based on the matrix here. Changing them requires changing of *ALL* the numbers. There are enough discrepancies in Gonzalez & Woods numbers that I didn't copy the numbers but generated them on my own.

So stop reverting as you're invalidating all the numbers. Cburnett 22:47, Apr 22, 2005 (UTC)

OK. Fine. That's what I wanted to know - that you had recalculated them all. I was in the process of writing code to do it myself, for the same reason you gave, but I am happy to have it done by you.

[edit] The matrix reformatted?

The numerical matrices are in what looks to me like a *terribly* old-fashioned font (probably through association with similar fonts I've seen in antiquated schoolbooks). They're also so wide that when viewed at 800 pixels width (which I often do when using a Favorites or History sidebar in IE6) the right hand side of some tables disappears behind the images on the right. Lee M 00:39, 3 May 2005 (UTC)

A lot of web viewers sitll use 800x600; it's about 30% of the browsing public. Time to fix it. Samboy 09:02, 3 May 2005 (UTC)

yeah its mediawiki math markup being rendered as png

maybe there is some other way to do the matrixes that will work better (is there any particular reason for them to look like maths matrixes rather than more generic grids of numbers?) Plugwash 10:14, 3 May 2005 (UTC)

As the author of the data, you're going to have to explain to me the difference between a matrix and a "grid of numbers".

Regarding the "*terribley* old-fashioned font", do you never read any math articles? Like covariance matrix or List of integrals of rational functions. It's TeX. Cburnett 14:21, May 3, 2005 (UTC)

I think we should use a different font than the one TeX uses; it doesn't look that great against the sans-serif font what we use for articles. Samboy 04:41, 16 May 2005 (UTC)

This is the incorrect place for such a discussion... Cburnett 23:11, May 22, 2005 (UTC)

Imo the issue at hand here is if its appropriate to use matrix math markup for a table of numbers that afaict has basically nothing to do with matrix algebra etc. Plugwash 12:22, 23 May 2005 (UTC)

A matrix IS a table of numbers. MATLAB stores images as matrices and there's really no difference between a 2-D array and a matrix. Simply because the subimages in question are not used as linear algebra matrices will not compel me to agree to switch to another form of representation of the same numbers. Cburnett 16:16, May 25, 2005 (UTC)

Mediawiki math markup goes to outputing as an image pretty quickly even when its feasible to represent what is desired without using an image. Just because we have a built in tool for generating ugly images doesn't mean its the best option in every case i've redone the first matrix below using wiki-table markup as an example and it looks far far nicer and is more compact (helping those with narrower screens) without changing the basic layout.


52	55	61	66	70	61	64	73
63	59	55	90	109	85	69	72
62	59	68	113	144	104	66	73
63	58	71	122	154	106	70	69
67	61	68	104	126	88	68	70
79	65	60	70	77	68	58	75
85	71	64	59	55	61	65	83
87	79	69	68	65	76	78	94

version currently in article to compare

$\begin{bmatrix} 52 & 55 & 61 & 66 & 70 & 61 & 64 & 73 \\ 63 & 59 & 55 & 90 & 109 & 85 & 69 & 72 \\ 62 & 59 & 68 & 113 & 144 & 104 & 66 & 73 \\ 63 & 58 & 71 & 122 & 154 & 106 & 70 & 69 \\ 67 & 61 & 68 & 104 & 126 & 88 & 68 & 70 \\ 79 & 65 & 60 & 70 & 77 & 68 & 58 & 75 \\ 85 & 71 & 64 & 59 & 55 & 61 & 65 & 83 \\ 87 & 79 & 69 & 68 & 65 & 76 & 78 & 94 \end{bmatrix}$

Firstly, the HTML is not narrower than the image table on my browser. Secondly, your HTML table is, no offense, an ugly hack; even if you don't reproduce the [] effect it's still hackery.

I've had this discussion many times about TeX vs. HTML and I don't really care to repeat it...again. Sufficient to say that your objection to using TeX is the generation of images. Again, I don't want to repeat the discussion, but the goal should be to get TeX output of the above to be renderable as HTML instead of removing perfectly correct math markup for those that don't desire to view TeX images. I prefer them.

The TeX output is extremely foul. First of all, never minding how good or bad the font is in isolation, it doesn't match. Basic typography rule: only change fonts for a very good reason. Second of all, it does look a bit archaic. (The badly named old "Computer Modern" perhaps? Whatever, it sucks.) Third of all, line thickness varies dramatically. The "1" and "4" are thin/light. The "3" and "9" and "6" are thick/dark. The "0" is even lopsided. Frankly it's an abomination. Adding insult to injury, the result can't be selected with a mouse and it makes the page load slower. It probably doesn't work all that well with a screen reader. AlbertCahalan 03:43, 14 April 2006 (UTC)

It's pleasing to my eyes. As for not changing fonts, presenting math formulas seems like a very good reason to me. As for screen readers, that is what the alt text of the image is for. Tnikkel 07:00, 14 April 2006 (UTC)

I prefer CMR to sans-serif fonts, although the name modern was meant by Knuth to mean the visual compatability of different fonts, not the style, which was in fact based on a 19^th Century schoolbook. (damn, nearly used the LaTeX command for superscript, oh well) In fact, I have books from the fifties at home in a font which is very similar to CMR.|333173|3|_||3 23:36, 12 November 2006 (UTC)

I have just done some reaerch (picked up the AMS authour handbook:D), and found that this might help the ppl who hate the use of Roman math in sans-serif text.

Failed to parse (unknown error\mathtt): \begin{bmatrix} \mathtt 52 & 55 & 61 & 66 & 70 & 61 & 64 & 73 \\ 63 & 59 & 55 & 90 & 109 & 85 & 69 & 72 \\ 62 & 59 & 68 & 113 & 144 & 104 & 66 & 73 \\ 63 & 58 & 71 & 122 & 154 & 106 & 70 & 69 \\ 67 & 61 & 68 & 104 & 126 & 88 & 68 & 70 \\ 79 & 65 & 60 & 70 & 77 & 68 & 58 & 75 \\ 85 & 71 & 64 & 59 & 55 & 61 & 65 & 83 \\ 87 & 79 & 69 & 68 & 65 & 76 & 78 & 94 \end{bmatrix}

Solve the problem, lazy, I managed to find this command in the first Google hit for LaTeX math font change, with a clear explanation of what it does, so next time stop whingeing and change it.23:36, 12 November 2006 (UTC)

Solve the problem — TeX rendering not in HTML — not the symptoms. Cburnett 01:29, August 11, 2005 (UTC)

Well my position is to use the tools availible to produce the best results possible and that to me means avoiding math markup whereever there is a feasible alternative. but i cba to start an edit war over this here so i'll leave that to someone else if they care, i've shown the way to make it look nice. Plugwash 21:54, 24 September 2005 (UTC)

I will try to find the TeX code and change the math font from CMR to CMS or similar, which willl change it from the good-looking but non-matching default (La)TeX font to a sans-serif font. THis will not match perfectly, and is not normal practice, but it is a small improvement. THis was part of the point of Computer Modern, the font sizes will match wheter using Roman, Sans-Serif, or Typewriter text. If you don't like the PNG graphics, there are user setting for other viewes. If you want to have a HTML output mode, there are HTML LaTeX compilers avaliable, so you could be WP:BOLD and use that. Of course, if all you want is for it to match, create a new skin using a truetype of CMR instead of the default font.

Once I find the right place to change it, it will take seconds to fix.|333173|3|_||3 22:58, 12 November 2006 (UTC)

Math rendering seems to have improved greatly from the situation when i orginally reported this (the horrible grey edges and uneven lines have been replaced by nice sharp transitions and even lines). Having said that on a normally configured windows box the text in the math pngs is still significantly larger than the main body text. Plugwash 11:20, 13 November 2006 (UTC)

[edit] Quantisation matrix

Where is that quantisation matrix from and what justification is there for calling it a common one. Plugwash 21:54, 24 September 2005 (UTC)

I originally got it from Digital Image Processing (ISBN 02091180758) and it describes it as "the JPEG baseline standard" which leads me to believe it's in the actual JPEG standard as the default quantization matrix. It's been a while since I took the class, but I recall the prof echoing that it's the common matrix.

I believe both the Q matrix and the 8x8 subimage size are the result of heuristic testing of various images and those turn out to yield the best average result.

Of course, references to it would be great. Cburnett 02:43, 7 April 2006 (UTC)

Isn't it the IJG standard matrix? 83.184.217.78 16:13, 8 May 2006 (UTC)

My thinking is that, as illustrative as the matrices may be, they take up way too much space in the article, to the point of being overly pedantic. Would it make sense to break them off into a stub? algocu 23:47, 19 September 2006 (UTC)

[edit] Progressive encoding

Could do with a mention of the progressive encoding capability. This uses multiple passes and usually involves sending low-frequency DCT components first to give an early low quality render. But you can also do funky stuff like send the colour info first or last, or send the high frequency components first. --KJBracey 17:40, 29 October 2005 (UTC)

I was looking for this topic in the article too, didn't see it. 24.23.133.238 18:29, 27 May 2006 (UTC)

[edit] Transparency

Has Jpeg got no transparency in it?? /Slarre 19:54, 26 November 2005 (UTC)

The JPEG standard doesn't define any means of including transparency, and the usual JPEG file formats (JFIF and Exif) don't allow transparency. JNG allows transparency (but nobody uses JNG). --Zundark 21:45, 26 November 2005 (UTC)

JPEG cannot easily support transparency because it is lossy and doesn't store precise color (transparency is treated as a color) values for each pixel but approximates it.

http://www.faqs.org/faqs/jpeg-faq/part1/

83.184.217.78 15:55, 8 May 2006 (UTC)

[edit] slack area

if my understanding of this is correct there is an area beyond the actual image that must be filled with something to fit the block size. I'd also imagine that what this is filled with could affect the quality of the bit that is visible. Does anyone know what strategies image processing software uses to fill this area and what affect the strategies have on image quality in that part of the image?

Yes I do :) You can do tests by opening the file with a HEX editor, searching for the dimensions, and changing them to the next multiple of 8 (i.e. 9x7 --> 16x8), or the next multiple of 16 with color subsampling. I found that "most" encoders (which I would pressume use the "official" JPEG code) just repeat the border pixels. This seems suboptimal. Example:

http://img268.imageshack.us/img268/6462/jpeg8x81ra.png (Right original; left exposed)

The JPEG encoder of Photoshop, however, does a special kind of "mirroring":

http://img98.imageshack.us/img98/1931/resultados6jm.png

(original is 4x4, expanded is 8x8 or 16x16, withouth grid it's confusing, sorry)

(top left, original without chroma subsampling) (right: expanded)

(bottom left, original with chroma subsampling) (right: expanded)

For images where only 1 pixel is left, this is the same as the "repeat" method, the other 7 pixels are just repeats. If 2 pixels are left, Photoshop (and ImageReady) "mirrors" them twice (one to 4px, the second time to 8px). If 3 pixels are left, the first is copied to the 4th, and then the usual mirror to 8. So it basically picks up the first 1, 2, or 4 available pixels and fills with a mirror of them.

I hope that made some sense.

[edit] Photo of a flower doesn't look like JPEG

Something like this? Not as good as I hoped...

The "photo of a flower compressed with successively lossier compression ratios from left to right" doesn't look right to me. It looks like the compression applied is in fact color depth reduction, as it doesn't show JPEG-like artifacting (blocking, ringing), and indeed retains high frequency/spatial resolution thorough, just loosing color accuracy.

The fact that it's displayed resized doesn't help, as downsizing it gets rid of the obvious JPEG artifacting (though the original full-size one still seems rather strange to me).

Good point, it doesn't look like JPEG to me either. Maybe we could apply the same idea to Image:Sunflowers.jpg (as suggested here) and create a new image that displays JPEG artifacts better. Tnikkel 07:43, 8 April 2006 (UTC)

I made a quick attempt at this in GIMP, by cutting the image into 16px stripes, saving at different qualities and stitching them back together. I don't like the result much, though — I think this isn't a very good test image for this purpose, being too dark and too busy. Something lighter with smooth gradients and some well-defined sharp edges would be better. —Ilmari Karonen (talk) 16:59, 22 April 2006 (UTC)

Much better!

I found a better flower photo on Commons and played with it until I got a reasonable test image. I like it, what do you folks think? —Ilmari Karonen (talk) 22:57, 30 April 2006 (UTC)

[edit] Donkey image?

I was wondering, maybe we could use the lenna image for the comparison of different compression ratios instead of the donkey as it is the de facto standard?--Frenchman113 21:10, 8 April 2006 (UTC)

I saw you used a Q100 image to show full quality jpeg, but the standard full quality image is Q95 as Q100 is a theorical maximum and should never be used but for experimental purposes. :)

http://www.faqs.org/faqs/jpeg-faq/

83.184.217.78 15:48, 8 May 2006 (UTC)

[edit] History?

When and where and why and by whom and for what application was JPEG developed? We need to mention this. ProhibitOnions 13:40, 28 April 2006 (UTC)

[edit] Patent claims

Now that the patent has been invalidated, does that mean JPEG is public domain? Copysan 20:35, 26 May 2006 (UTC)

It has NOT been invalidated (yet). BsL 03:32, 31 May 2006 (UTC)

The "Potential patent issues" section doesn't agree with it's references (hooray!):

Text from the article:

The USPTO also found that Forgent knew about the prior art, and did not tell the Patent Office, making any appeal to reinstate the patent highly unlikely to succeed.

Text from http://www.groklaw.net/article.php?story=20060526105754880 (ref 4):

Forgent can respond, but it seems they'll have some explaining to do, because PubPat's Executive Director, Dan Ravicher, says that the submitters knew about the prior art but failed to tell the USPTO about it.

Also, comments attached to [4] indicate that the patent is NOT invalidated, only that some parts of it are. Note that [4] doesn't say anywhere that the patent has been overturned, although it is a little ambiguous.

-- Eu neke 00:58, 3 November 2006 (UTC)

[edit] See also: GDI vulnerability

"see GDI vulnerability section of GDI article" in see also, this page doesnt contain any info like that.--152.78.71.52 19:49, 11 June 2006 (UTC)

[edit] Lossless operations

Certain operations on JPEG images can be performed without having to re-compress them. Rotation, flip, crop, partial modification (say, text insertion), color correction. Can we add a section about this? --AlexMld 13:41, 12 October 2006 (UTC)

It's already there, though not necessarily in the right place, under "Usage". How can color correction be done without recompressing? Just curious. Notinasnaid 13:56, 12 October 2006 (UTC)

Yes, I just noticed it is there, but it is not very correct:

"can be performed losslessly as long as the image size is a multiple of eight pixels in both directions." Should say "to rotate 90 clockwise image height should be multiple of the MCU height, to rotate counterclockwise, it's width should be multiple of the MCU width". MCU width and height are not always 8 pixels, any of them can be 16px as well.

We can also add information about lossless crop (which I think is a part of IJG library now) and other lossless operations.

As for the lossless color correction, I think it is done by manipulating DC values or/and quantation tables. I have seen this kind of operation in JPEG Wizard --AlexMld 17:07, 12 October 2006 (UTC)

[edit] Dots per inch (DPI)

No mention is made in this article about JPEG and dots per inch (DPI) -- i.e., most JPEG images are 72 dpi, and if small, are often unsuitable for print work. Shouldn't a note about JPEG and DPI be added? - Mecandes 18:29, 22 November 2006 (UTC)

That really isn't a characteristic of JPEG. Any given image can be any resolution. JPEG images may be a problem for print work if the resolution is too low (like any image format), or if the compression artefacts are too great (a specific JPEG issue). Notinasnaid 18:33, 22 November 2006 (UTC)

While JPEG has a specified DPI in the file format its pretty meaningless, what really matters with any image is the DPI at the desired output size. Images intended for the web will indeed be too low for most proffesional print work but thats hardly a jpeg issue. Plugwash 18:57, 22 November 2006 (UTC)

[edit] What about CMYK JPGs?

When this page details the whole process of color space trasformation from RGB to YCbCr, how does this explain CMYK JPGs? Sure, it should be just as easy to convert CMYK to YCbCr as it is to convert RGB to YCbCr, albeit with a different set of calculations. The result of either will be a file encoded with YCbCr values. How then does the resulting JPG file know that it should be decoded to a CMYK image and not an RGB image?

From what I understood, it is only JFIF files that imply YCbCr color space, and that CMYK JPGs do not undergo the same color space transformation. This would therefore require a different method of encoding and decoding for CMYK JPGs, or in fact anything other than RGB or YCbCr color space. Can anyone shed any further light on this? Ian Fieggen 23:57, 25 November 2006 (UTC)

Note that RGB-->YCrCb is reversable (other than rounding errors) but CMYK to YCrCb isn't, dunno what CMYK jpeg does though. Plugwash 00:21, 26 November 2006 (UTC)

I don't know for sure, but couldn't they just encode each of the four channels? You could do the same with RGB, without the YCrCb transformation. The reason RGB is transformed to YCrCb is so that the luminance (Y) channel can be encoded with higher quality than the chrominance channels, since we humans see changes is brightness much more than changes in colour. Thus you can compress the image more using YCrCb. With CMYK you'd probably just leave them in the CMYK colour space and compress all four channels equally, or perhaps compress black a little more. Like I said, I don't know for sure. Just some ideas. --Imroy 10:12, 26 November 2006 (UTC)

[edit] Apparent Confusion in article

There seems to be confusion within this article over what this article is about, also the redirects to this article don't all make sense. Here's how I see it:

JPEG - An article about ISO/IEC IS 10918-1 | ITU-T Recommendation T.81
This should include both the JPEG codec and the JPEG Interchange Format (which is NOT JFIF), since both are specified in the ISO document. (the JPEG Interchange Format is specified in annex B)

JFIF - This should be separate article about the JPEG File Interchange Format (JFIF) application segment zero extensions. Which are mostly no longer relavent or useful.

Joint Photographic Experts Group - Should be a separate article about the body that developed ISO 10918-1 as well as JPEG2000, JBIG....

--Ozhiker 13:52, 28 November 2006 (UTC)

Also, JFIF is listed in the article as being from the 'Independent JPEG Group'. This is incorrect as far as I can tell - it was developed by Eric Hamilton of C-Cube Microsystems. - see this.

JFIF has apparently been supersceded by the SPIFF extensions to the JPEG standard. SPIFF is defined in Annex F of ITU-T Recommendation T.84 | ISO/IEC IS 10918-3. It appears however that it is not in widespread use. Neither of these standards are of any relevance now, with the near universal acceptance of EXIF.

If there are no objections, I'll make changes to reflect the above, and also add some history of the JPEG standard ( this will help with the history) --Ozhiker 01:10, 30 November 2006 (UTC)

Just how much is there to jfif thats not part of other jpeg file formats? if its only a small ammount then it probablly doesn't deserve a seperate article. Agree on splitting off the Experts group but what we could really do with is info on exactly WHAT parts jpeg defines and what the various file format authors had to add to it. Plugwash 02:46, 30 November 2006 (UTC)

The JFIF standard contributed the following things:

A standard colour space (which as far as I understand is universally ignored, as sRGB is used instead)
A standard sub-sampling method for chromiance information (centered) ( I am not sure what is used currently by most software)
An application segment extension to JPEG. It uses Application Segment #0, with a segment header of 'JFIF\x00' and defines the horizontal and vertical pixel density, and may provide a thumbnail.

All of these things have been replaced and extended in EXIF (and other metadata standards).

I think that most people often mistake JPEG Interchange Format and JPEG File Interchange Format. JIF is defined in the JPEG standard, and lacks only pixel aspect ratio, component sample registration, and colour space designation to make it a universal format.

--Ozhiker 10:21, 30 November 2006 (UTC)

I agree that a separate JFIF article would be desirable. I also agree that JFIF wasn't the creation of Independent JPEG Group. I have an old copy of the Image Alchemy documentation that says that JFIF was agreed upon on 1 March 1991 at C-Cube by representatives of C-Cube, Radius, NeXT, Storm Tech., the PD JPEG group, Sun, Handmade Software, and maybe others. --Zundark 13:20, 30 November 2006 (UTC)

how about mentioning SVG in the first para, for vector/line/text graphics, rather than gif/png?

[edit] quality parameter

How does the quality parameter influence the JPEG compression? That is: at what point in the algorithm does it make a difference whether I chose a quality of 10 instead of 90? --Abdull 19:47, 11 December 2006 (UTC)

My experience of examining compressed files suggests the following. The JPEG compression settings don't have a place to plug a number. Rather, the quality is affected by a bunch of settings including the quantitisation table, and whether downsampling is done. JPEG encoders often offer quality settings. Sometimes, they might have "low, medium, high". Some might have 10 to 90. Some might have 0 to 12. It's arbitrary. Anyway, what I suspect happens is that the programmer has a range of compression paramers (quantitisation tables and subsampling), which the quality settings deliver. Some programmers might use a lookup table; some might derive settings algorithmically from a quality "number". Notinasnaid 20:23, 11 December 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../j/p/e/Talk%7EJPEG_801a.html"