• WSpfurrie

    WSpfurrie

    @wspfurrie

    Viewing 2 replies - 1 through 2 (of 2 total)
    Author
    Replies
    • in reply to: Putting Registry-/system-cleanup apps to the test #1306241

      Some people are saying that previous articles which claim that “registry cleaners aren’t necessary” got me thinking: Does this article necessarily bust that claim, or is more testing required before we could reasonably reach that conclusion?

      The programs being used are doing two things, not one: removing old or unneeded files, and removing old settings from the registry. Perhaps only one of them is really causing the observed effect (file removal), which would then leave the “registry cleaners aren’t necessary” unchallenged. As the article’s testing methodology doesn’t get that granular, we can’t make the distinction based on this test. All we can say with some certainty is that, after having done both file removal and registry cleaning, the system-in-question is faster.

      I’m not suggesting that reg cleaners don’t help — just pointing out that the test which was related in this article isn’t sufficient to prove it either way.

    • in reply to: Putting Registry-/system-cleanup apps to the test #1306118

      I would have been interested in see how CCleaner would have done regarding file removal if additional file options had been chosen (over-and-above the defaults, as mentioned in the article). Otherwise, the results are interesting and informative.

      A side note:
      While reading the article, I was noticing the included graphics. After all, that’s where the interesting compare-the-results meat was presented. But I was surprised… at how bad they look.

      JPEG? Everywhere? It is understandable why you would use JPEG on a photo, or on a screen-grab which has complex gradients in it. Those kind of images either look ok with JPEG, or are reasonably less byte-heavy than other formats. But many of the graphics in the article were not photos, and have no gradients at all (let along “complex” ones). They were simple, illustrative charts, with solid colors and text. There isn’t anything wrong with that from a stylistic perspective, but when using JPEG as the format-of-choice, the hard-edged text becomes muddled with JPEG compression artifacts. Besides the annoyance of my eye being drawn to that on each image, there are a couple of practical matters:
      1) The JPEG artifacts make the text less sharp. If you want people to read the text, why make it harder than it has to be?
      2) It actually makes the file size larger, in many cases (and almost certainly in these cases), when compared to a PNG graphic.

      If the author were a novice, I’d chalk it up to that. But he isn’t, so I’m left wondering: What am I missing here? What trick about JPEG vs PNG does he know?

      A quick Google of “JPEG vs PNG” yields this entertaining page on the subject.

      Ok, PNG is good for quality, but what about the file size question? If I take a photographic image and save it as both a JPEG and a PNG, I can easily adjust it so there is no visible difference, but the JPEG file will be a much smaller file. But in this case, we aren’t talking about photos, but talking about charts, graphs, line art, and other things which often don’t have gradients.

      But given that Fred’s article was all about side-by-side comparisons, perhaps I should endeavor to do the same. Here’s my procedure:

      I’ve taken a screen capture of a blank Microsoft Excel 2010 page using the freeware (non-commercial) version of PicPick. This opens the PicPick editing window. From here, I’m going to select four different regions of the captured image, each with a different mix of attributes, and save each of them twice: once as PNG and the as JPEG. Then I will compare the images for quality and byte-size.

      After creating the initial files, the quality between the PNG and JPEG were the same. Going into the options for PicPick, I found the JPEG compression control. The default in PicPick is for JPEGs files with a “100” quality setting. This would make the best-looking JPEGs but would also make them the largest size. I dialed this back to 50, in order to obtain a representative example of the visible artifacts in the images, as well as bring the file size in line with what one might expect from the graphics in this article. As a result, each comparison is as follows:

      Figure A: PNG
      Figure B: JPG as maximum quality/minimum compression/largest size
      Figure C: JPG at medium quality/smaller file size

      First, a portion of the screen with no gradients, just solid colors, lines, and text:
      29391-Figure-1

      Second, a larger portion of the screen, including some simple gradient in the tool ribbon background:
      29392-Figure-2

      Third, a larger portion including complex gradients in the “File” tab background color and the blurred Windows desktop graphic as seen through the Excel title bar (thanks to the Aero UI effect) [note: the portion of the screen originally grabbed and saved was larger than included here, but I cropped them somewhat so as to keep this composite graphic to a reasonable physical size]:
      29393-Figure-3

      Lastly, a smaller section, showing complex gradients in the background fill of the “File” tab, and the Aero-UI blurring of the Windows desktop image through the Excel title bar:
      29394-Figure-4

      In the first set of images, the file size for PNG1 is significantly smaller than both version of JPG. This is expected — this image is all solid colors and text. While JPG1x is much smaller than JPG1, it is still nearly twice the byte-size of PNG1, but has substantial artifacting around the text.

      As we move from figures 2 through 4, the scales tip the other direction. The obvious difference is the inclusion of more and more gradients in the image. JPEG handles these better from a compression point-of-view.

      So, what is the take-away? That for many graphs and screen-grabs, PNG is better quality-wise than JPEG (but never worse than JPEG), and PNG can often be comparable in file size (sometimes much better).

    Viewing 2 replies - 1 through 2 (of 2 total)