Talk:JPEG

Multimedia Wiki

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

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.

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.

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)

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)

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)

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.

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.

${\begin{bmatrix}{\mathtt {5}}2&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)

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)

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)

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)

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.

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)

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)

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)

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)

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)

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)