'''Introductory note by [uniquename] 2014may21:''' I have moved the following discussion from my 'Category = Personal' page to this separate page because it has become way too long for that already-long personal page. This discussion was started by the comment from [PYK] below --- in particular the statement "the images you've been adding ... look fuzzy on my screen". The discusion rapidly devolved into a discussion of JPEG versus PNG --- and then relative sizes of files. Unfortunately, PYK did not point out which images and what part of those images he is talking about. So I have to bow out of this 'discussion'. Here is the start of the 'thread': ------ [PYK] 2014-03-02: Hi Blaise, I think the images you've been adding are nice improvements to the Wiki. They look fuzzy on my screen though because they are in the jpeg format. PNG is a great format for screenshots because it preserves the crispness of lines. I've had good results in making .png files of screenshots even smaller than typical .jpg files by decreasing the color depth, and wanted to suggest the low-color-depth .png files would look even better on wiki pages. --- [uniquename] 2014mar09 : Hi PYK. If you are referring to pictures like the plot image just above, it is blurry because it is a reduction of the full-size image. Click on the 'number-link' just below that image to see the full-size image. I think you will see it is much clearer. Apparently digital camera manufacturers do not share your preference for PNG over JPEG. All those manufacturers capture photos in JPEG format not PNG. One place you see PNG a lot is on Wikipedia --- in cases where they have provided several different sized images of SVG (scalable vector graphics) files. Since those kinds of images (SVG) generally have a relatively small color palette --- perhaps larger than 256 colors but much smaller than 16 million --- there is a case were PNG is probably at least as good as JPEG. But for photos, which can literally have over a million shades of different colors, professional photographers (and digital camera manufacturers) have chosen to stay with the JPEG format. Check out the screen captures (in JPEG) format on the [tkGetComics - to get 'old' comics from comic archive web-sites] page that I added recently. If those images look blurry to you, there is something wrong with your computer or your eyes. The 3 JPEG screenshots there look quite clear to me, using my computer and LCD monitor. If you are using an LCD monitor, there may be some settings that you need to fine-tune. On my Ubuntu 9.10 system (using the Gnome 2.28 desktop environment), there is a utility available via 'System > Preferences > Appearance > Fonts' that allows you to fine-tune various LCD monitor parameters. --- [RLE] (2014-03-14): In general [PYK] is correct in his statements regarding utilizing PNG for screenshots. JPEG is optimized for continuous tone images (i.e., real world photographs) which is why digital cameras output JPEG images. But for screen captures, which are not continuous tone images, the sharp contrast changes between the differently colored lines/elements in the image cause the JPEG compression algorithm to produce some output noise in the resulting compressed image. It exhibits typically as a ringing or halo around sharp line edges. This noise is a direct result of how the JPEG compression removes high frequency image components in order to compress the image. PNG's compress the input image data using a lossless compression system, so there is no compression noise introduced into a PNG. This is what makes PNG the better choice for screen shots. The decompressed image is identical to the input image. --- [uniquename] 2014mar16 RLE, That may be your experience with your process, but that is not what I am '''seeing''' with mine. I do my screen captures of the GUI windows with 'gnome-screenshot', which by default makes PNG files. I usually crop the capture and sometimes do some other processing (like blurring out a name in an entry field) with the 'mtpaint' image editor. Then I use the ImageMagick 'convert' command to make a JPEG from the PNG file --- at high-quality (near lossless) by using the '-quality 100' parameter with the 'convert' command. I use a script that makes the JPEG file in the same directory with the PNG file, with the same filename except for the suffix '.jpg' instead of '.png'. Then the script shows the '.jpg' with the 'eog' (Eye of Gnome) image viewer. '''That image viewer allows me to quickly switch back and forth between the '.jpg' file and the '.png' file. They always look identical to me''' --- while the '.jpg' is typically one-third to one-sixth the size of the '.png' (or smaller). I put the '.jpg' on the wiki since it is much smaller. Note that if what you say is (always) true (even when using 'convert' with '-quality 100'), then I should be seeing a definite difference between the '.jpg' file and the '.png' file. I have to wonder if the fuzziness that PYK is talking about is mainly in the fonts (the text) --- and not in 'photo' images put on a Tk canvas. Some people do not like the way some systems do anti-aliasing of fonts. They prefer their fonts without anti-aliasing. I have used the LCD monitor fine-tuning that I mentioned above to make the anti-aliased fonts on my system look quite acceptable to me. (Also I am probably not as sensitive to some fuzziness in fonts as some people are.) PYK should take a look at my page [tkPlayMediaFilesInPlaylist - a front-end for multiple media-players] where I have posted 3 screenshots of the GUI, with 3 different fonts --- 'Comic Sans', 'Times New Roman', and 'Zachary'. I suspect that PYK would say he prefers the 'Times New Roman' --- because it looks 'crisper'. The 'hinting' or 'anti-aliasing' of the other two fonts may be making them look a little fuzzy --- as generated by a Linux version of the 'wish' interpreter, using the underlying anti-aliasing system. By the way, as I mentioned above, Wikipedia uses PNG to render multiple sizes of SVG files --- BUT I do not see Wikipedia converting their many thousands of JPEG files to PNG files. When digital camera manufacturers and professional photographers and Wikipedia switch from JPEG to PNG, then it becomes convincing that PNG is the way to go. Note that professional photographers convert their RAW format to JPEG, not PNG. They must find, like I do, that when 'near-lossless' compression is done, the results are more than satisfactory. --- [RLE] (2013-03-17): Just because you can't visually discern the loss, does not mean it has not happened. It just means that it is not visually perceptible. Which is why JPEG works so well on continuous tone photographs. For those inputs, the loss is usually not visually perceptible to most viewers. The reason you are not seeing much loss is that you are using -quality 100. That setting is the closest you can choose for "lossless jpeg" with JPEG. (Note the quote from the '''man cjpeg''' page below. There is still some small loss even with -quality 100.) Have you ever tried converting any of your screenshots into 256 color PNG's. Gnome-screenshot is likely outputting 32-bit (or maybe 24-bit) PNG's. I've often found that color quantizing a screen shot down to 256 colors produces a significantly smaller PNG output file than trying to apply high quality JPEG compression to a 24bit (or 32bit) JPEG file. Professional photographers keep their RAW snaps archived for a reason. There is no loss. They produce JPEG for distribution for two reasons: 1. most users have no ability to view RAW images (every camera maker has a different RAW format); 2. RAW images are much too large for general use/viewing. But professional photographers are also taking continuous tone photographs. Exactly the type of source image that JPEG was specifically designed and optimized to compress. JPEG compression/images are a tool. A tool optimized for best performance with photographs. PNG compression/images are also a tool. A tool that is optimized for computer bitmaps with high contrast edges (well, not really why it was designed, it is optimized for lossless image compression). The tools serve complementary, but different segments and purposes. Just as you can, but generally should not, use a hammer to drive in a screw, you should also use the right image compression tool for the job. For computer screen shots (that don't include real world photographs in the shots) JPEG is not the correct tool. It will work, and most of the time it will be more than acceptable. But that does not change the fact that it is still not the correct tool for that job. Since you are using gnome-screenshot, that implies you are using Linux. Here is a test you can do for yourself. For whatever distribution you are using, do this: 1. Install the GIMP (http://www.gimp.org/). 2. Take a gnome-screenshot of a GUI window. 3. Convert the output into a JPEG using your script. 4. Start the GIMP. 5. Open both the original screen shot and your JPEG converted file (this will produce two GIMP image windows), 6. In one of the GIMP image windows pick the Edit->Copy command from the menu. 7. In the other GIMP image window, pick the Edit->Paste As->New Layer command from the menu. 8. Now close the other image window (where you did the Copy). 9. Now, find the "layers pallete" there should be an entry labeled "Mode: ..." with a dropdown to select several options, pick the "difference" option. 1. The view of your image should now change to view where you see the differences between the two images. Anything that is not black is a change between the PNG original and the JPEG result. Note: support from additional sources for my facts below: http://en.wikipedia.org/wiki/Jpeg#Typical_usage: "The JPEG compression algorithm is at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. ... On the other hand, JPEG may not be as well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images may be better saved in a lossless graphics format such as TIFF, GIF, PNG, or a raw image format. The JPEG standard actually includes a lossless coding mode, but that mode is not supported in most products." man cjpeg: "The -quality switch lets you trade off compressed file size against quality of the reconstructed image: the higher the quality setting, the larger the JPEG file, and the closer the output image will be to the original input. Normally you want to use the lowest quality setting (smallest file) that decompresses into something visually indistinguishable from the original image. : -quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are not recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. Some examples of JPEG compression artifacts: http://en.wikipedia.org/wiki/Jpeg#Compression_ratio_and_artifacts http://www.faqs.org/faqs/jpeg-faq/part1/: [[Note, much of the JPEG FAQ was written before PNG, when GIF was what PNG is today, that is the reason the quotes below all refer to GIF]]: JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with. (There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.) JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans. If you plan to machine-analyze your images, the small errors introduced by JPEG may be a problem for you, even if they are invisible to the eye. : JPEG has a hard time with very sharp edges: a row of pure-black pixels adjacent to a row of pure-white pixels, for example. Sharp edges tend to come out blurred unless you use a very high quality setting. Edges this sharp are rare in scanned photographs, but are fairly common in GIF files: consider borders, overlaid text, etc. The blurriness is particularly objectionable with text that's only a few pixels high. If you have a GIF with a lot of small-size overlaid text, don't JPEG it. A brief technical overview of JPEG can be found in section [[75]] of the comp.compression FAQ located here http://www.faqs.org/faqs/compression-faq/part2/ This page has a javascript applet where you can use a slider to select different quantization parameters and immediately see the results: http://www.visengi.com/products/jpeg_hardware_encoder Note that the image is a photograph, so the quality slider has to be dropped quite a lot before noticeable artifacts start to become visible. --- [uniquename] 2014mar21 RLE, '''your very first sentence above claims I am saying something that I definitely did not say''': "Just because you can't visually discern the loss, does not mean it has not happened." '''I did NOT say that it was lossless. In fact, I said it was "near lossless"''' (under the right conditions) --- in multiple places. '''Please do not keep ascribing to me things that I did not say.''' In any case, you just made my point for me --- "can't visually discern the loss". Let us not forget what kicked off this 'discussion' --- PYK's comment "They look fuzzy on my screen". If PYK (or you) can pick out several images that I have captured and point out '''specific places''' on those images where you think the image is 'too fuzzy', then maybe we can get someplace, instead of piling words upon words. I have suggested images on two pages already: [tkGetComics - to get 'old' comics from comic archive web-sites] and [tkPlayMediaFilesInPlaylist - a front-end for multiple media-players] If PYK (or you) have issue with screen captures that I did of windows I made from other people's Tk scripts, how about looking at [The Classic 15 Puzzle] and [Morley's Miracle] Tell me a '''specific''' area on the images that is 'grating on your sensibilities'. (This discussion should be moved to another page --- or deleted. This is junking up a page that is categorized as a 'Person' page --- not a 'JPEG' page.) (By the way, where is a list of wiki 'Categories'? --- so that 'contributors' can know the categories that they should --- and should not --- be using. The [wikignomes] page encourages using categories, but how are we supposed to know what are valid categories? Any word we want to use? Is 'Pussy Riot' OK? ------ '''INSERT by''' [EMJ] 2014-03-21: Click on "Category Person" at the bottom of this page, then click on "Category Category" on the bottom of that page, then click on the page title (but also read it to see how they work). You could create a category if you wanted, I wouldn't create "Pussy Riot" if I were you, one gnome or another would probably remove it anyway!) --- [uniquename] 2014may21: I just recently saw your 'insert', EMJ. I have been avoiding this discussion for a couple of months while I try to get some scripts (like [wheeeMorph - to morph 2 images - GIF/PNG/JPEG/other - using a barymetric technique on triangles]) done. It is a waste of my time to respond to RLE, who is continuing to ascribe statements and beliefs to me that I have not made and do not hold. I fully expected a 'wikignome' to remove the 'P. Riot' reference. For those who do not know, that is the name of a Russian girl band that was in the news in early 2014 after being imprisoned for a while by Putin's government. It has been surprising to me that the various news outlets (CNN etc.) have not been bleeping their name --- nor was it bleeped as they were introduced on various interview shows such as the Colbert Report and others. If anyone is offended, they are welcome to remove it --- or replace it with 'crap', which seems to be quite acceptable on the 'Everyone Loves Raymond' show. ------ (Continued) (Another 'by the way': What does 'RLE' stand for? The [RLE] page does not say. I know who 'major' contributors like [KPV] and [RS] and [MBS] and [GS] and [DKF] and [DPE] and [BHE] and [AMG] and [AM] and [KBK] and [JH] and [BBW] and [JO] are --- by their deeds and by their first and last names. But who is this RLE? And who is 'Poor Yorick' [PYK]? Trolls or Wikignomes --- that is the question.) [RLE] (2014-03-21) You are welcome to move this discussion to a new page (or wrap it in a <> tag pair). So, lets review how this discussion began: [PYK]: ... They look fuzzy on my screen though because they are in the jpeg format. PNG is a great format for screenshots because it preserves the crispness of lines. ... The first half of sentence #1 is subjective. To [PYK] they must look fuzzy, or else he would not have said anything. The second half of the statement is 100% factual. [JPEG] does not preserve, with 100% fidelity, straight edge lines. The third sentence is also 100% factual, PNG preserves the exact image, because it uses loss-less compression. So, your response: : ... Apparently digital camera manufacturers do not share your preference for PNG over JPEG. All those manufacturers capture photos in JPEG format not PNG. ... #1 - an irrelevant aside. Camera's are not capturing computer screen shots, so what format camera makers utilize is not relevant to the capturing of computer screen shots. : ... But for photos, which can literally have over a million shades of different colors, professional photographers (and digital camera manufacturers) have chosen to stay with the JPEG format. ... #2 - the same irrelevant aside. You are not posting photographs. You are posting screen shots. The proper tool optimized for a photograph is not always the proper tool for a screen shot. : ... Check out the screen captures (in JPEG) format on the tkGetComics - to get 'old' comics from comic archive web-sites page that I added recently. If those images look blurry to you, there is something wrong with your computer or your eyes. ... #3 - a thinly veiled attack on PYK, stating that there "IS" something wrong with his monitor or eyes when you are uploading images compressed with an algorithm known to create fuzziness for screen capture format images. Two completely wrong statements, and a thin attack. You don't exactly have the high-road here yourself. As to your size arguments, I just performed a quick test. I pulled off the image you uploaded to the wiki here: http://wiki.tcl.tk/_/image?N=38347. It is the help screen for the Morley's Miracle code example. I first converted the jpg downloaded from the wiki to a png, then optimized the png with [optipng]. Additionally, I loaded the png that resulted from [JPEG] conversion into [GIMP], converted it to 256 colors with an optimal pallette, and saved it from [GIMP] and ran that save through [optipng]. Below are the results: 188 -rw-r--r-- 1 rellis 192386 Mar 21 07:54 image.01.jpg 64 -rw-r--r-- 1 rellis 64444 Mar 21 07:55 image.02.png 64 -rw-r--r-- 1 rellis 64360 Mar 21 07:55 image.03.opt.png 24 -rw-r--r-- 1 rellis 23277 Mar 21 07:57 image.04.256color.png 24 -rw-r--r-- 1 rellis 23253 Mar 21 07:57 image.05.256color.opt.png The number mapping is: 01 - jpeg downloaded from wiki 02 - jpeg to png conversion (jpegtopnm image.01.jpg | pnmtopng -compress 9 > image.02.png) 03 - result after applying [optipng] (cp image.02.png image.03.opt.png ; optipng -o9 image.03.opt.png) 04 - result after loading into GIMP, converting to 256 colors, and saving from GIMP 05 - result after applying [optipng] to [GIMP] output (cp image.04.256color.png image.05.256color.opt.png ; optipng -o9 image.05.256color.opt.png) Now, I don't have access to your original [PNG] from gnome-screenshot, so all I can do is present the values above based upon downloading one of your [JPEG] files. But for this one example, the [PNG] 33% of the jpg (02 vs 01) or 12% of the jpg (04 vs 01). So at least for this one example image, it would appear that not only would [PNG] have preserved exactly the pixels present on your screen, but it would have been 1/3th to 1/8th of the size of the [JPEG]. As per your loss-less argument, lets review: : ... That image viewer allows me to quickly switch back and forth between the '.jpg' file and the '.png' file. They always look identical to me ... Note that if what you say is (always) true (even when using 'convert' with '-quality 100'), then I should be seeing a definite difference between the '.jpg' file and the '.png' file. Yes, you didn't say they were "loss-less". Any more than I said you said they were loss-less. You said (summarizing) "I can't see any difference". To which my response of "Just because you can't visually discern the loss, does not mean it has not happened." is a properly valid response. I.e., yes, you can't see the loss, but mabye PYK's setup is such that he can, indeed, visually perceive the loss. If you want a couple examples, the lettering in the Doonesbury comic on your comics downloader page looks slightly fuzzy to me. (The lettering in the comic, not your surrounding GUI). That, however, is likely a representation of the quality of the original comic image itself rather than your screen shot of the comic. The fonts in this image also look slightly fuzzy: http://wiki.tcl.tk/_/image?N=39477 And the font in the title bar on the help window for Morley's Miracle (the image I used in my size tests above) looks ever so slightly fuzzy. Are any of them blurry/bad to the point of being unusable or 'grating on my sensibilities' from my viewpoint, no. They all look reasonably acceptable to me on my monitor, even though I can perceive a bit of fuzziness. At the same time, neither of us are looking at [PYK]'s monitor, so neither of us know what is appearing for [PYK]. Maybe he has a setup with a very large format monitor such that the images end up magnified when displayed on his screen. Magnifying [JPEG] compressed images will also magnify the inherent fuzziness that the [JPEG] algorithm creates when asked to compress screen shots. That would make any JPEG compression artifacts much more noticeable to him than to either of us. Which would allow [PYK] to argue that maybe the fuzziness he perceives is the result of the [JPEG] compression. Using [PNG], properly compressed (see example above) would mean that if [PYK] continues to see blurriness that it is clearly something at his end, and not the result of applying the wrong image compression algorithm. Additionally, assuming my example above with image.01.jpg holds for your other screen shots, you could save an additional 2/3 or 7/8 worth of space by uploading properly compressed [PNG] images. So if space is your concern, [PNG] would appear based upon the test above to be the clear winner. You can get a list of wiki categories by searching for "category category" in the text search box, then clicking the title link to pull up the page of "what links here". Does it really matter who [RLE] is? If you must know, RLE are the initials of Rich Ellis. --- Some more JPEG vs. PNG image size comparisons for you: The key below is the same as above: 01 - jpeg downloaded from wiki 02 - jpeg to png conversion (jpegtopnm image.01.jpg | pnmtopng -compress 9 > image.02.png) 03 - result after applying [optipng] (cp image.02.png image.03.opt.png ; optipng -o9 image.03.opt.png) 04 - result after loading into GIMP, converting to 256 colors, and saving from GIMP (generate optimal pallete, no color dither, PNG compression 9 during save) 05 - result after applying [optipng] to [GIMP] output (cp image.04.png image.05.png ; optipng -o9 image.05.png) 1) The image here: http://wiki.tcl.tk/_/image?N=39488 (comics) 332 -rw-r--r-- 1 rellis 336425 Mar 21 10:50 image.01.jpg 196 -rw-r--r-- 1 rellis 198399 Mar 21 10:53 image.02.png 196 -rw-r--r-- 1 rellis 198111 Mar 21 10:53 image.03.png 72 -rw-r--r-- 1 rellis 72251 Mar 21 10:55 image.04.png 72 -rw-r--r-- 1 rellis 72155 Mar 21 10:55 image.05.png 2) The image here: http://wiki.tcl.tk/_/image?N=39490 (comics) 400 -rw-r--r-- 1 rellis 408785 Mar 21 10:59 image.01.jpg 252 -rw-r--r-- 1 rellis 255419 Mar 21 11:00 image.02.png 252 -rw-r--r-- 1 rellis 255047 Mar 21 11:00 image.03.png 92 -rw-r--r-- 1 rellis 91044 Mar 21 11:01 image.04.png 92 -rw-r--r-- 1 rellis 90924 Mar 21 11:01 image.05.png 3) The image here: http://wiki.tcl.tk/_/image?N=39478 (your media GUI) 148 -rw-r--r-- 1 rellis 149783 Mar 21 11:03 image.01.jpg 60 -rw-r--r-- 1 rellis 57490 Mar 21 11:03 image.02.png 60 -rw-r--r-- 1 rellis 57394 Mar 21 11:03 image.03.png 20 -rw-r--r-- 1 rellis 17914 Mar 21 11:04 image.04.png 20 -rw-r--r-- 1 rellis 17890 Mar 21 11:04 image.05.png 4) The image here: http://wiki.tcl.tk/_/image?N=38363 (15 puzzle) 48 -rw-r--r-- 1 rellis 48711 Mar 21 11:05 image.01.jpg 16 -rw-r--r-- 1 rellis 15764 Mar 21 11:05 image.02.png 16 -rw-r--r-- 1 rellis 15751 Mar 21 11:05 image.03.png 8 -rw-r--r-- 1 rellis 6567 Mar 21 11:06 image.04.png 8 -rw-r--r-- 1 rellis 6567 Mar 21 11:06 image.05.png That is five out of five where all of the PNG's that I've created from your JPEG's have been smaller than your JPEG's. <>Enter Category Here