Talk:JPEG

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the JPEG article.
Article policies
JPEG was a good article nominee, but did not meet the good article criteria at the time. There are suggestions below for improving the article. Once these are addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.

Reviewed version: October 28, 2007

Contents

[edit] JFIF vs. JPEG Interchange format - which one extends what?

The JPEG page states "The file format is known as 'JPEG Interchange Format', as specified in Annex B of the standard. This is often confused with the JPEG File Interchange Format (JFIF), a minimal version of the JPEG Interchange Format that was deliberately simplified so that it could be widely implemented and thus become the de-facto standard.", while the JFIF page states that JFIF is an extension of JPEG Interchange Format. So, what is it? Stolsvik (talk) 14:27, 11 January 2008 (UTC)

It's a bit of both! It's a concatenation of the JPEG Interchange Format in that it uses a subset of the elements in the JPEG standard. It's also an extension of the JPEG Interchange Format in that they created a standardized JFIF header, which was necessary so that decoders could reliably identify a file meeting the JFIF standard. That JFIF header is written in a block with an APP0 marker, which is part of the JPEG standard but whose contents are not defined in the JPEG standard (they are application specific). This formalization of the contents of the JFIF header within the previously defined APP0 block is the only 'entension'. Ian Fieggen (talk) 22:10, 11 January 2008 (UTC)

[edit] Multimedia Wiki

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

[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. Qutezuce 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 19th 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 function\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)
The current quantization matrix shown on the JPEG page is provided as an example of a luminance quantization table in Appendix K of CCITT Recommendation T.81, the latest version of which is available, free of charge, from here: http://www.itu.int/rec/T-REC-T.81-199209-I/en. I believe this document is technically equivalent to the one referenced in the external links section, it is however easier to navigate. Recommendation T.81 states, in clause 4, that it does not specify a default quantization matrix, regarding the example tables in Annex K it states: "These are based on psychovisual thresholding and are derived empirically using luminance and chrominance and 2:1 horizontal subsampling". In response to the last comment about removing the matrices, I for one found them useful and think they should stay where they are. Jon A Fox 11:04, 5 March 2007 (UTC)
Highly agree with the technical details staying. This is an encyclopedia and how JPEG actually works is definitely encyclopedic, which is why I added it. Cburnett 13:39, 5 March 2007 (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...
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. Qutezuce 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!
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)

I added a link to the Lenna article at the bottomKriegaffe 17:57, 28 May 2007 (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)

The section states a crop cannot be done from the top or left (unless it is a block boundary). Bottom and right do not have this restriction. As a JPEG can be losslessly rotated/flipped, it is possible to first flip/rotate, then crop and finally flip/rotate back. So in practice an image can be arbitary cropped? --Jontew (talk) 14:35, 30 April 2008 (UTC)

You're forgetting that lossless rotations/flips also only work on block boundaries. For example, if you take an image which is an exact number of blocks, flip it horizontally, then crop it half way through the rightmost block, you can't then flip the image back because that rightmost half-block cannot become the leftmost half-block. Well, it can, but not losslessly. —Preceding unsigned comment added by Ian Fieggen (talk • contribs) 00:33, 1 May 2008 (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)

from http://www.jpeg.org/jpeg/index.html : "the file format was created originally by Eric Hamilton, the then convenor of JPEG as part of his work at C-Cube Microsystems, and was placed by them into the public domain under the name JFIF (available here in the latest version, 1.02)"
This seems to conflict with your statement that jfif is an extention of the standard file format. Plugwash 14:43, 14 December 2006 (UTC)
Yes I have seen the http://www.jpeg.org/jpeg/index.html site - you are right that it is in conflict - I can't explain why the Joint Photographic Experts Group would have that on their website. The file format is very definitely specified in the main JPEG standard, not in JFIF - look at Annex B of http://www.w3.org/Graphics/JPEG/itu-t81.pdf, which specifies the JPEG Interchange format. The JFIF spec refers to JIF. I recently wrote a parser for JPEG data, and only discovered JFIF even existed when I was almost finished. I've made an article at JPEG File Interchange Format which explains what is specified by JFIF. --Ozhiker 15:26, 14 December 2006 (UTC)
What we really need to solve this conflict is the original versions of both the JPEG and JFIF specifications. Just because a subset of JFIF is in the standard now doesn't mean it always was. Plugwash 15:44, 14 December 2006 (UTC)
You're right. I've had a search for the history of JPEG & JFIF and not turned up much, however I did find this document from May '92 which refers to JPEG Interchange Format being in JPEG-9-R7: Working Draft for Development of JPEG CD, 14 February 1991. Which I think is before the first meeting to agree a JFIF standard -March 1, 1991. I couldn't find any of the working drafts or previous versions of either standard online. --Ozhiker 16:38, 14 December 2006 (UTC)

[edit] SVG

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

Maybe, but its not really supported on the web at all (flash is better supported but has issues of its own ;) )and anyway monitors are raster devices so a hand optimised bitmap is generally the best choice for getting good display on them. Plugwash 14:41, 14 December 2006 (UTC)

[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)
I'm not positive but i belive the quality number controls the agressiveness of the quantisation tables and in some programs thresholds in it are also selected to change between the three subsampling ammounts. Plugwash 15:39, 13 December 2006 (UTC)
According to http://www.ams.org/featurecolumn/archive/image-compression.html , the quality setting (aka q) applies a scale factor to the quantization matrix. FivePointPalmExplodingHeart (talk) 07:31, 26 April 2008 (UTC)

[edit] does a JPEG

have to use the same quantization table for all blocks? —The preceding unsigned comment was added by Plugwash (talk • contribs) 14:32, 14 December 2006 (UTC).

[edit]  ???

Why are the example images not in a gallery??? It looks messy. I liked a the donkeys better. 216.37.139.6 22:36, 25 December 2006 (UTC)

[edit] For Evaluation: Graphic illustrating the relationship between MGT and DCTs

I have uploaded an image for evaluation for use on the JPEG article. Not sure if it will be useful. Clearly, it will need to be broken up into smaller images. Please let me know if anybody wants to work this into the article. Thanks. * Image:Mcu_dct_evaluation.gif

Please leave comments in this section. TCMike 04:11, 6 January 2007 (UTC)

Broken link to the image. Rain 01:17, 9 February 2007 (UTC)

[edit] Encoded size in the example

Thanks for the informative article. It is a clear explanation and a good level of detail for a lay reader like myself. Could I request that in the detailed example where we take one block through all the steps of encoding, someone knowledgeable add one more detail? After the example is all the way through the process to the Huffman-encoded bit stream, I think it would be cool to say something like "Under standard encoding the data can now be stored in x bits, compared to the y bits required to store the original data." 132.170.162.196 23:46, 19 May 2007 (UTC)

[edit] A discussion of JPEG's limitations?

I would like to see a discussion of JPEG's limitations (on text, on line drawings, on sharp edges) in this article. Is that appropriate? It seems that a lot of people use JPEGs for text and come to regret it, and it would be nice to be able to explain why in a useful fashion. Any takers? jhawkinson 21:45, 23 June 2007 (UTC)

I highly suspect that JPEG could be more attuned to text if the quantization matrix were reworked for text. Text has a lot of high frequencies and the general quantization matricies used don't have retaining high frequencies in mind. Cburnett 13:12, 11 July 2007 (UTC)

[edit] DCT maths

Recently, a lot of DCT maths and working was added. I don't think that most of this is necessary, as the general form of the DCT-II can be found at the DCT article, and the worked example for the DC coefficient breaks the flow unnecessarily, without really adding anything. Therefore, I've taken the liberty of removing the majority of this. Oli Filth 08:18, 11 July 2007 (UTC)

I wholly disagree.
1) Showing the general form here avoids having to jump to another article.
2) The general form here does not match that used on Discrete cosine transform because it doesn't address normalization in the transform (only mentioned in the inverse discussion). Again, avoid having to jump to another article insufficiently written for the context of the JPEG encoder discussion.
3) The generalized form & normalization applies directly to the example I added here many moons ago. Having to both digest another form the DCT and apply that as used here is unnecessarily diverting the reader's attention from understanding the JPEG codec.
4) Explaining how to use the DCT equation to determine the DC coefficient is simple, direct, and very telling to someone not familiar with DCT or how to use it. Hardly "unnecessarily" in my book.
5) If the example for the DC coefficient breaks the flow then it can be fixed without simply removing it.
6) Simply saying that the DC coefficient is -415 doesn't tell you anything about how to use the DCT or how the DCT works. Just like how saying "you DCT shifted subimages, quantize, RLE, then Huffman" doesn't tell anyone how JPEG encoding works. An example illustrates how it is done. Same thing with the details about using the DCT.
I have no problems with reworking and rewriting my work. That's not my complaint. My complaint is that deleting is generally a cop-out to doing work. Remember, this article is not supposed to be written for just people like you and me who know DSP. Cburnett 13:09, 11 July 2007 (UTC)
Hi. Here are my thoughts (matching your numbering above):
  1. Wikilinks are the whole point of a web-pased encyclopedia. If the user is reading about X, and wants to know more about Y, they can safely drill down by clicking on the link to the article about Y, so that details of Y aren't "inflicted" on other, more casual, readers. In this context, the mathematical details of the DCT are not essential for the flow of the article, and don't (in my opinion) provide any further insight into how JPEG works.
  2. Normalisation is discussed in the DCT-II section; although admittedly, its not as clear as it could be. Anyway, in my edit, I left the specific form in.
  3. I sort of agree. That's why I've left the specific form in.
  4. I don't believe it's necessary to demonstrate how to use an equation. Also, demonstrating with the DC coefficient is a bad choice, because all the cos terms evaluate to 1 and disappear, which doesn't give a good impression of what's going on.
  5. Possibly true.
  6. I think the example as it stood was more than adequate as an illustration of the DCT in action.
In some senses, yes, deleting is a cop-out; I generally only do that when I see incorrect stuff. In this case, the stuff wasn't incorrect, I guess I was just being lazy!
However, I believe that because "this article is not supposed to be written for just people like you and me who know DSP" is precisely why we shouldn't fill it with lines and lines of equations. Oli Filth 20:16, 11 July 2007 (UTC)

I wholly agree with Oli that the DCT details shouldn't be on the JPEG page, and I applaud him for removing them. What's needed in that section is an explanation of what the transform is actually doing to the data and why the transformed data is far more compressible than the input matrix of pixels. This subject is big enough that it deserves a separate Wikipedia page about image compaction, imho. In any case the new stuff added by Cburnett is totally worthless as an explanation of JPEG and moreover it just duplicates what's in the DCT article. Cburnett claims to know what he's talking about. (More exactly he claims to "know about DSP", which is not at all the same subject as JPEG.) It's my view that the formulas he stuck are not understandable by an ordinary programmer who wants to undersand how JPEG succeeds, and it's my suspiction that Cburnett doesn't understand it decently himself either. User: sean Sean111111 20:40, 11 July 2007 (UTC)

So you're claiming that JPEG encoding is...not DSP? And you claim I don't know what I'm talking about? Re: "totally worthless": meta:don't be a dick. Cburnett 00:51, 12 July 2007 (UTC)

[edit] downsampling

The wikipedia article mentions downsampling of the chroma channels as second step of the jpeg encoding process. I've been trying to find the description of this in the jpeg specification (http://www.w3.org/Graphics/JPEG/itu-t81.pdf), but I can't find it, it seems as if the specification is missing an exact specification about this. The JFIF spec also doesn't mention it.

Where in the spec can I find which bytes exactly of the JPEG file mention exactly what type of subsampling of the chroma channels is used? What does the subsampling do if the number of pixels in a certain dimension is uneven? What kind of filters are used?

193.74.100.50 07:32, 25 July 2007 (UTC)

[edit] Example is so cool

The way the work out the compression algorithm by hand in this article is so cool. 134.79.236.179 22:27, 2 August 2007 (UTC)

[edit] "Color space transformation": Probable mixup of YCbCr and YUV

Hi, the article states in the Color space transformation section that "[YCbCr] is the same as the color space used by PAL [...]". This contradicts the YUV article, which says that PAL uses YUV, not YCbCr. The YCbCr article says that YCbCr and YUV are often mixed up, this seems to be one instance of the problem. --Stachelfisch 22:44, 5 October 2007 (UTC)

[edit] CMYK jpg

PDF files seem to often have embedded image streams in "DCTDecode" format, which is their term for jpg. The streams can be extracted by hand to a file, and become complete working jpg files. This seems to work fine if they are "DeviceRGB" 3-byte-per-pixel streams. But "DeviceCMYK" 4-byte-per-pixel streams also seem common. These seem to be very hard to view/generate directly. What exactly is a CMYK jpg? -69.87.200.6 23:43, 19 October 2007 (UTC)

The JPEG FAQ says, in the answer to question 16:
“ Adobe Photoshop and some other prepress-oriented applications will produce four-channel CMYK JPEG files when asked to save a JPEG from CMYK image mode. Hardly anything that's not prepress-savvy will cope with CMYK JPEGs (or any other CMYK format for that matter). When making JPEGs for Web use, be sure to save from RGB or grayscale mode. ”
Of course, if you're looking for technical details, that's not very helpful. I'm sure they're out there somewhere, but my very quick Googling didn't turn up anything more detailed. —Ilmari Karonen (talk) 14:21, 21 October 2007 (UTC)
When Photoshop saves an RGB image as a "JPEG File", it actually creates a JFIF file, which is a standardised subset of the JPEG file format. One of the assumptions of this simplified format is that the image data uses the YCbCr color space. When most people talk of a "JPEG File", they're actually talking about a "JFIF File".
When Photoshop saves a CMYK image as a "JPEG File", it actually saves it in a JPEG format with an EXIF header. This allows it to maintain the original CMYK color space. It's not possible to create a JFIF file with CMYK color space because the color data will be interpreted incorrectly by any program that assumes it to be YCbCr data.
JPEG files in CMYK format are used mainly in the publishing industry. Not many other programs handle them correctly, as the decoding can be much more complex because they are not in the simpler JFIF format. Programs that can only handle JFIF formatted files should check for a JFIF header and abort if it isn't present. Most browsers abort when presented with CMYK formatted JPEGs, often displaying a "broken image" icon.
In terms of viewing / editing programs, I've used CMYK format JPEGs successfully in Photoshop, ThumbsPlus, IrfanView, ACDSee and JPGExtra, to name but a few. Be prepared for some odd results though, particularly with the way some programs convert the CMYK colors for display on RGB screens, sometimes producing dark results and sometimes lurid. Ian Fieggen 05:32, 23 October 2007 (UTC)

i find that there are some JPEG files with an EXIF header are RGB file... —Preceding unsigned comment added by 121.33.199.173 (talk) 06:47, 15 April 2008 (UTC)

[edit] Variable-quality jpeg images

What are the best tools for generating variable-quality jpeg images? In particular, it would be desirable to be able to specify a low quality for the general background, and a higher quality for a small portion of the image of particular importance. This would allow further reducing image storage sizes. It can be done tediously by hand with IrfanView, to demonstrate the theoretical feasibility. Are there any tools that make this easy? -69.87.200.6 23:49, 19 October 2007 (UTC)

There are tools that allow this, such as the regional compression feature of JPEG Wizard. However, it's always struck me that these features are rather ridiculous. The whole point of the JPEG compression algorithm is that low-detail areas such as sky and other flat backgrounds are compressed much more than areas with higher detail. The idea of taking this further by manually outlining low detail and high detail areas for higher or lower compression is merely exaggerating the existing compression algorithm. One could presumably achieve the same effect with no manual intervention by changing the DCT or quantization matrices.
Of course, one can use regional compression to manually apply higher compression to selected higher detail regions, but this will be at the expense of introducing more noticeable artifacts. Ian Fieggen 22:16, 20 October 2007 (UTC)
You're under the assumption that the image is fairly uniform and low-frequency based. Cburnett 01:34, 21 October 2007 (UTC)
The purpose of lossy compression is to favour information that is relavent to the viewer over that which is not, getting the detail right in say a face is far more important than getting it right in a leaf litter background. Plugwash 14:50, 23 October 2007 (UTC)
Absolutely incorrect.
The purpose of lossy compression is to reduce the overall size by the loss of information. One common way this can be done is selectively discarding data. The standard Q matrix weighs heavily on the low-frequency corner of the DCT coefficients. If you take a picture of Plaid (pattern) (assume the pattern is of very high frequency in both directions) and use the standard Q matrix then not only will you get a high error rate but you will not achieve good compression compared to a matrix that favors the high frequencies. So using a different Q matrix for your picture will net better compression and less error.
Now, if you take a picture of a plaid t-shirt on a solid white background then if you use aforementioned Q matrix for plaid then you get good compression on the shirt, but you've masked out the entire DC coefficient because this plaid shirt is only high frequencies. If you use another Q matrix that is only the DC value then you will get good compression on the background with little to no error.
The standard-ish Q matrix is trial-and-error matrix that works good "in general". Cburnett 16:01, 23 October 2007 (UTC)
Something like a plaid pattern has high and low frequencies; leaving out the low frequencies will produce bad artifacts for any image that is not a construed case of sine-like oscillations that have a half-integer number of periods within each 8x8 square of the DCT. The best approach would be to use the same quantization for all components, but that would anyway hardly give a space saving compared to using a bit less quantization for the low-freq. components since there simply are many more HF than LF components (i.e., a factor 4 if you place the cutoff halfway). But re the original question, I think there can only be one Q-matrix for the whole image, so for selective compression you would need to filter out HF components or pre-quantize them with a higher factor in uninteresting areas before starting the final compression. Is that what irfanview and jpg wizard do? Han-Kwang (t) 16:39, 23 October 2007 (UTC)
I said "assume the pattern is of very high frequency in both directions". If it's @ 45 degrees then you have no DC and no low frequencies horizontally nor vertically for sufficiently high frequency. I explicitly said it was all high frequency to demonstrate my point. Cburnett 19:09, 23 October 2007 (UTC)

(unindent) Try doing a DCT on data that looks like f(x) = 1+cos(pi*x*7.5/8). [changed 7 into 7.5 @ 24 Oct] For starters, you always have a DC component since image data is not negative. And because the period of the high frequency part does not match the size of the 8-pixel DCT blocks, this supposedly high frequency component will generate a DC contribution (and plenty of other lower frequencies) in the DCT. Han-Kwang (t) 21:52, 23 October 2007 (UTC)

You missed this step in JPEG codec:
To center around zero it is necessary to subtract by half the number of possible values, or 128.
So an image does not have negative but JPEG forces it so that the issue you just raised is moot. Cburnett 16:31, 27 October 2007 (UTC)
So what? If the average of an 8x8 block is 234, then after substraction of 128 you still have a DC component of 234-128=106 to deal with in the DCT. That's why there is a DCT basis function G_00. Han-Kwang (t) 17:41, 27 October 2007 (UTC)
And if I have a 2x2 block of one diagonal of white (255) and the off-diagonal is black (0) then the average is 127.5, or 128. Subtract 128 and you have zero. Zero DC and maximum frequency in both directions. No offense, but I'm done being your teacher on this. Cburnett 00:36, 29 October 2007 (UTC)

Plugwash's analogy of a face against a leaf litter background is one of very few examples where regional compression could see significant benefit. Most examples that I've seen involve things such as a face against the sky, which already compresses very well and benefits little from being compressed further using lower quality.

Let's use an example image of a face against sky, where the face occupies 50% of the image and sky occupies the remaining 50%. That sky would already compress well, and may only occupy 20% of the file data. Compressing this with a substantially higher compression may save 50% of that storage, which is only 10% of the whole file, hardly worth going to that much manual effort. The only way to achieve more savings is to go for a greater differential in quality between "face" and "sky" regions.

If the background occupied a more substantial percentage, say 75%, the savings are greater. However, because that same higher percentage of the image is now at a visibly lower quality, the overall perception is of a lower quality image. In other words, with more backround at low quality, and less face at high quality, the image looks worse overall.

To gain any worthwhile benefit, there needs to be a substantial difference in the quality setting for a substantial portion of the picture, which is always noticeable. I've experimented by saving an image with regional compression, then saving the same image with uniform compression at a lower quality setting to achieve a similar filesize. The latter required much less manual intervention, yet produced images with similar perceived overall quality. Ian Fieggen 00:24, 24 October 2007 (UTC)

"The purpose of lossy compression is to reduce the overall size by the loss of information.". If that were the case we would just downsample our images until they reached the size we wanted. The point of lossy compression is *selective* loss of information getting rid of information that is less important (or possiblly even invisible) to the viewer while keeping the most important bits. Plugwash 01:06, 24 October 2007 (UTC)
I think we've exchanged our viewpoints by now. Per WP:FORUM, we should aim to use the talk page to work on articles. Can somebody who has software with selective jpeg compression mention how this is implemented in the article? I would implement it by pre-quantizing areas with a different Q' matrix before the final quantization with matrix Q, e.g. with Q'=2Q such that the final quantization won't give an additional quality loss. But I don't know what programs such as jpeg wizard and irfanview actually do. Han-Kwang (t) 15:41, 27 October 2007 (UTC)


Plugwash, you're tearing my argument apart...because you're on the offensive. I *never* described how you determine which information to lose. Take a step back. Lossless compression requires no loss of information, ergo it can only remove redundant information. This REQUIRES lossy compression to lose information, which is all I stated. Favoring information "that is relavent to the viewer" is one way to lose information, not THE way as you stated. Cburnett 16:31, 27 October 2007 (UTC)

[edit] Failed Good Article nomination

GA review – see WP:WIAGA for criteria

  1. Is it reasonably well written?
    A. Prose quality:
    B. MoS compliance:
  2. Is it factually accurate and verifiable?
    A. References to sources:
    B. Citation of reliable sources where necessary:
    C. No original research:
  3. Is it broad in its coverage?
    A. Major aspects:
    B. Focused:
  4. Is it neutral?
    Fair representation without bias:
  5. Is it stable?
    No edit wars, etc:
  6. Does it contain images to illustrate the topic?
    A. Images are copyright tagged, and non-free images have fair use rationales:
    B. Images are provided where possible and appropriate, with suitable captions:
  7. Overall:
    Pass or Fail:

My main concern is the distinct lack of sources. Having no sources makes it hard to tell whether there is any original research involved. There was also a few recent incidents of vandalism which may have tarnished the quality of the article. I would recommend going through the article, make sure everything is up to date, cite a few sources (1 per paragraph is fine), and then re-nominate it. NF24(radio me!Editor review) 23:14, 28 October 2007 (UTC)

[edit] JFIF and JFIF

The article has a section "JPEG Interchange Format file format" with comments that it has some problems that are addressed by various improved formats including "'JPEG File Interchange Format' (JFIF)". Huh? I am aware that I don't understand this, but this wording is not helping me. Is there another way to word this, to help me (and others) who come here to learn? Was this a typo, or are these two separate things? Are there two different formats with the same name, that we can somehow separate? Further reading tells me that they are different, but it's not clear how, or how to tell them apart. -SandyJax 16:56, 31 October 2007 (UTC)

Okay, I've fixed this by combining the two separate sections, one near the top of the article and another that was near the bottom, each with overlapping information about the differences between the "JPEG Interchange File Format" and the "JPEG File Interchange Format". Hopefully this clears up the confusion. Ian Fieggen 00:58, 1 November 2007 (UTC)
Well, I'm still confused, but I'm not going to blame you. That part, at least, is much clearer. Thank you! -SandyJax 17:05, 5 November 2007 (UTC)

[edit] 'Histogram equalized' image is not histogram equalized.

One image in the article has a caption which reads, "The 8×8 sub-image shown after having its histogram equalized (i.e., 154 becomes white, 55 becomes black). Note that this is done just for visual purposes and no such equalization is done in the example data."

The process of making 154 white and 55 black is not histogram equalization.

There is really no reason to actually histogram equalize the image, and I don't believe there is any reason to include the image at all, as it doesn't show any additional detail in the image.

Butlertd (talk) 19:00, 3 January 2008 (UTC)

However, equalization yields an image such that the maximum value becomes white and the minimum value becomes black. In this case: 154 becomes white and 55 becomes black.
That said: no reason?!? You do know what the point of histogram equalization is, right? The point of this example is to understand the JPEG codec. The dynamic range in the sample subimage is less than half of that of that possible. Equalization takes full use of the 8-bit range to allow the reader to better see the differences in the subimage. I am happy, though, that you have superb eye sight and equalization is purely a waste for you. Cburnett (talk) 00:01, 4 January 2008 (UTC)
However, it's true that it unnecessarily complicates the article to the lay reader. As it's nothing to do with the codec, why not just use the equalised image as the example, and do away with the unequalised version entirely? Oli Filth(talk) 00:46, 4 January 2008 (UTC)
The equalized image is strictly for better visualization of the subimage and to exacerbate the differences caused by quantizing for the simple reason that we have a harder time seeing minor luminosity changes.
If you want to completely change the entire page to reflect your new example then...I guess I can't stop you. Keep in mind that you'll have to recalculate everything and all the data has been on this page for a while and has been fairly stable. Reworking the example will inevitably introduce errors and the cycle will have to repeat. All because you want to cater to the lower denominator.
However, I think it will backfire. If you use a higher dynamic range image then your quantization will still be fairly small and with a higher dynamic range I really, really doubt you're going to see the pixel value changes — mostly because you can't do a histogram equalization to exacerbate the changes. If you can easily tell the difference of 3-5 shades of gray then good for you. But, since you're catering to the lower denominator you've just made it harder for people with not-so-awesome sight as you. Personally, I find it easier to change my understanding of a topic than to improve my eye sight.
I also think you're blowing this issue out of proportion. Do you have any kind of evidence to support your position that mentioning histogram equalizing loses people? I don't see it as "obvious" as you do, I guess. Visually comparing the images I imagine that most people would see the lighter shade of gray is now gleaming white and the darker shade of gray is a deep black, and from that they'll "get" histogram equalization without having to know or care about what a histogram, cdf, or normalization is: it makes the dark darker and the light lighter. Cburnett (talk) 03:14, 4 January 2008 (UTC)

On a tanget: I uploaded an SVG of the original image and of the equalized image (after calculating the equalization by hand). I also put them in histogram equalization as a more thorough example since it's quite light on such details. Cburnett (talk) 01:01, 4 January 2008 (UTC)

[edit] Required precision

As far as I can tell (by doing a quick search on IEEEXplore), there is no such standard as IEEE 1880-1990. Unless I'm doing something extremely silly in my search...

Also:

""" On the contrary, the JPEG standard (as well as the derived MPEG standards) have very strict precision requirements for the decoding, including all parts of the decoding process (variable length decoding, inverse DCT, dequantization, renormalization of outputs); the output from the reference algorithm must not exceed:

   * a maximum 1 bit of difference for each pixel component
   * low mean square error over each 8×8-pixel block
   * very low mean error over each 8×8-pixel block
   * very low mean square error over the whole image
   * extremely low mean error over the whole image

"""

Wow that's a long sentence. The descriptions of the required error margins are pretty meaningless and all look very similar to me. I would have said something like "there are specified error tolerances for each pixel, block, and for the whole image" or something. Just an idea.

FivePointPalmExplodingHeart (talk) 07:37, 26 April 2008 (UTC)

"1880-1990" is probably a typo referring to "1180-1190". Rcooley (talk) 13:50, 26 April 2008 (UTC)

[edit] Are there different versions or some compatibility gaps in JPEG format?

I have apparent incompatibility problem with certain .jpg files created on XP computer, that renders wrong (or causes wrong format error on attempt to open it after a download) in every Linux and Win 98SE viewer application I tried, including Internet Explorer. I would assign it to a bug in specific installation but it is consistent and repeatable. Furthermore, it goes both ways: a (Word 97 compatible) .doc text document authored on OO.org 2.4 with embedded JPEG pictures created in Dadaware Embelish freeware (OK, I AM cheap, ... but standards are standards!) on Win 98 SE is rendered wrong in MS Word on an XP. It makes me wonder if there was some "upgrade" or "enhancement" or "deprecation" of old JPEG format in recent years that causes this apparent incompatibility? —Preceding unsigned comment added by 147.91.1.41 (talk) 08:53, 6 May 2008 (UTC)

If you're able to upload an example of one of these JPEG files somewhere, I can download the file, inspect it on a byte level, and figure out what's strange about it. Ian Fieggen (talk) 04:14, 7 May 2008 (UTC)
Follow-up: The files were CMYK JPEGs, which normally will not display in browsers and certain viewers not versed in CMYK format. Ian Fieggen (talk) 00:31, 8 May 2008 (UTC)