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 2014mar16RLE, 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:
- most users have no ability to view RAW images (every camera maker has a different RAW format);
- RAW images are much too large for general use/viewing.
- Install the GIMP (http://www.gimp.org/
). - Take a gnome-screenshot of a GUI window.
- Convert the output into a JPEG using your script.
- Start the GIMP.
- Open both the original screen shot and your JPEG converted file (this will produce two GIMP image windows),
- In one of the GIMP image windows pick the Edit->Copy command from the menu.
- In the other GIMP image window, pick the Edit->Paste As->New Layer command from the menu.
- Now close the other image window (where you did the Copy).
- Now, find the "layers pallete" there should be an entry labeled "Mode: ..." with a dropdown to select several options, pick the "difference" option.
- 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.
- 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.
- 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.
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_encoderNote 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-sitesandtkPlayMediaFilesInPlaylist - a front-end for multiple media-playersIf PYK (or you) have issue with screen captures that I did of windows I made from other people's Tk scripts, how about looking atThe Classic 15 PuzzleandMorley's MiracleTell 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.EJM, thanks for the reference to the Category Category page. I actually got to it via your EMJ page. The reference at the bottom of the 'Category Category' page --- How do Wiki Categories work --- gives a nice categories list, in one place. I can see at least 10 categories that I will probably use in the future.
(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 <<discussion>> 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. ...
- ... Apparently digital camera manufacturers do not share your preference for PNG over JPEG. All those manufacturers capture photos in JPEG format not PNG. ...
- ... 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. ...
. 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.pngThe 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.
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.png2) 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.png3) 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.png4) 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.pngThat 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.
PYK 2014-05-21: Oops , I missed this entire conversation until just now . All Blaise's uploaded images render a bit fuzzy in my browser (Firefox) , and I assumed it was because they were jpeg images . tkGetComics - to get 'old' comics from comic archive web-sites indeed looks fuzzy in my browser , and turns out that the browser is resizing them all a little bit . I'm guessing it has something to do with the CSS for the site , but I haven't nailed it down yet . Even if the rendering had not produced any blur , I would have made the same suggestion because PNG is a better format for this type of image job . Even the images containing cartoon scans worked out well in PNG . I converted one of your images to 256-color PNG using xnview
, and uploaded it for comparison . In spite of paying less attention than RLE to the conversion process , I somehow got an even better size reduction (58KB) . Apart from the background gradient , where there is more banding in the PNG version , quality is similar , but the PNG version is 6 times smaller :uniquename 2014jul01PYK, I was wondering why you were seeing fuzzy images. Within a week after you reported that to me, I got on my wife's computer (different monitor, different graphics card, different graphics driver, different operating system) and I looked at the images that I put on this wiki. They looked just as clear as on my computer's monitor. So I was puzzled about what is going on at your computer.Is your Firefox browser 'tunneling' through some Google server, and is Google reducing web pages and surrounding the pages with tons of ads???Anyway, I am here to report good news. I have done some experimenting with that comic image above --- creating GIF's, JPEG's, and PNG's. I have to go on vacation now so I will report back here with some size results and good techniques for getting small image sizes in all 3 of these formats.Briefly, I have found that I can read the 328KB '.jpg' image above and create PNG files around the size you got with 'xnview' (and as good as RLE got) --- about 60KB to 90KB.I am using ImageMagick 'convert' with '-colors 256' (and 128, and 64 and 32 and 16 and 8) to make the PNG and GIF files. I find it crucial to use the '+dither' command BEFORE the '-color' parameter, to turn off dithering. (I hate those speckles. Dithering is a hold-over from more than 15 years ago, when we were dealing with 2 and 8 and 16 color monitors.) Pretty amazingly, I can get nice dither-free results at the 16 and 8 color level (but somewhat less colorful than the original). More later.PYK 2014-07-03: Great! I've played around with +dither and various color depths as well. Results, of course, depend heavily on the characteristics of the original image. One of my unfinished projects is a scripted interface to Image Magick. I intend to eventually discover and post here the explanation for fuzzy rendering in my Firefox browser, but other higher priorities are occupying me for now.
