On: Corrected "real world analysis of Google’s webp versus jpg"

[jmillikin]

(edit: these settings are not optimal. See followup post)

I don't know what magical encoder the author is using, but I was easily able reproduce the original post's results (for JPEG, I didn't try WebP). Steps:

1. Download the original image from < http://fc07.deviantart.net/fs21/f/2007/275/f/4/f4e91d2565442... >

2. Open in your favorite image editor.

3. Save it with whatever optimization settings you want, until it gets down to the goal size (in this case, 44.5KiB).

4. Compare to the original.

For example, I used GIMP, with these settings < http://imgur.com/SIasU.png > , which produced this result < http://imgur.com/8Sclu.jpg >. Although the author is using a different encoder, I doubt it's this much better than GIMP's. (edit: with better settings, GIMP's result is < http://imgur.com/8aEPJ.jpg >).

[Terretta → jmillikin]

It could be that the original author, and your replication of his results, is not illustrating a JPEG compression issue, but an issue using GIMP's JPEG compression to compress a 1920x1200 image into a 45KB JPEG. This is certainly an "edge case" compression test.

The author updated comments on reddit saying he hadn't been clear, but he was talking about full 1920x1200 in the 45KB file. That's a different story, so I repeated my tests at full resolution.

Using Photoshop's "Save for Web and Devices" option, Photoshop JPEG compression (at "quality zero") introduces a moire pattern, but still does not generate the extreme banding issue shown on the blog, and replicated in your results.

Here is what Photoshop generates in 44,962 bytes, at 1920x1200 resolution:

http://michael.terretta.com/update-corrected-real-world-anal...

I apologize, I'm not familiar with GIMP or why its results might show such dramatic banding.

[jmillikin → Terretta]

After further testing, it appears that the "Save EXIF data" and "Save XMP data" options are very expensive at these resolutions/file sizes. Disabling them nets a few dozen KiB. Additionally, setting "Smoothing" to full makes the image smaller at the expense of blurriness.

Updated version: < http://imgur.com/8aEPJ.jpg >

"Save for web" is probably a shortcut to remove those extra data. I wonder if Photoshop is also adding additional smoothing, beyond GIMP's maximum? That would explain why the PS image's background is smoother, but the inner details (like specular highlights) are not as distinct.

[jjcm → jmillikin]

The EXIF/XMP data is highly insightful, I didn't even think about how much space those would take up. I updated the original blog post with the information you provided here, and cited you for it. Hope you don't mind.

[Terretta → jjcm]

I mentioned in comments on your original article: I wasn't able to appreciably beat the BMW or portrait images.

Metadata would help explain this, since as a percentage of file size, it'd be a lot more detrimental on the first image at 45K than the BMW at 575K.

But sure seems there's something else going on with the first image's circular gradient; PS seems to be dithering its blocks in a moire pattern while GIMP is showing strong banding even on files w/o metadata.

[oozcitak → Terretta]

Metadata is most certainly the case here. The breakdown of metadata for the original image (http://fc07.deviantart.net/fs21/f/2007/275/f/4/f4e91d2565442...):

  EXIF (APP1) -> 5328 bytes
  Photoshop IRB (APP13) -> 5896 bytes
  Adobe XMP (APP1) -> 26284 bytes
  Adobe (APP14) -> 12 bytes 
  Total -> 37520 bytes (36.6 kB)

That's 36 kB of metadata, leaving only 8 kB for compressed image data. This explains the banding seen in the English Hard post. The BMW image on the other hand (http://fc01.deviantart.net/fs51/f/2009/313/1/c/Jesus_Mobile_...):

  Photoshop Ducky (APP12) -> 15 bytes 
  Adobe (APP14) -> 12 bytes
  Total -> 27 bytes

The existence of the "Ducky" section means that the image was "saved for web" in Photoshop.

EDIT: Added numbers for the BMW image.

[Terretta → oozcitak]

I got GIMP, and used the "Save as JPEG" output to see if it's including metadata.

According to jhead[1], GIMP is not including metadata in the saved JPEG.

At quality "13", the file was 46302 bytes. Using the "purejpg" option on jhead, it dropped to 45592, or -710 bytes.

This 45592 bytes is exactly, to the byte, what the original article found.

[1] http://www.sentex.net/~mwandel/jhead/usage.html

[jjcm → Terretta]

Thanks Terretta, I updated the blog post with your version of the jpg as well as some of the insights you had. I have photoshop here in a vm, so I'm going to go ahead and reconvert all of them from there.

[mikeryan → jmillikin]

So I did the same test - Quality of 0 in PS got me down only to 59,475 Bytes. http://public.adifferentengine.com/files/lossy.ps.jpg

Convert with image magick got me only down to 72,634 bytes http://public.adifferentengine.com/files/lossy.magick.jpg

So yeah the encoder does matter and Photoshop's is that much better than GIMPs.

[acqq → mikeryan]

I can't repeat your results with 16bpp ImageMagick, with -quality 0 I get from 468K then 267K. How have you got 72K?

[mikeryan → acqq]

beats me ;-) Sorry I did 1% with ImageMagick

convert testImage.jpg -quality 1% lossy.magick.jpg