Since he doesn't summarize the test above, let me. The jpeg.io result is bigger than the other two and noticeably worse quality. The problems were with the sharp lines.

Perhaps jpeg.io specializes in photo-realistic pictures rather than graphics and logos.

Photoshop is smart enough to disable chroma subsampling[1] if it will screw up the image, it looks like jpeg.io doesn't do that.

One of the worst case scenarios for chroma subsampling is alternating black and red lines. Some monitors/TVs do 4:2:0 by default. It can cause problems...

https://plus.google.com/photos/photo/100697962438000631056/5...

[1] https://en.wikipedia.org/wiki/Chroma_subsampling

Hi, co-founder of jpeg.io and kraken.io here. Thanks for this, we're still in "kinda beta" right now and will have a fix in production shortly. In summary, that's not supposed to happen at all and there are highly likely some other nasties which we will be ironing out over the next hours.

for being "kinda beta" you have quite the claims up on your website

Thats kind of what the format is for.

jpeg.io may have lost on sharp lines, but it had WAY fewer artifacts than either of the other exports, and the blue was closer to the original compared to the Photoshop export. In my opinion, it's a better quality image.

Honest question: if I can't see the artifacts without zooming in, is there any reason why I should care? Of all the conversion results offered, the Photoshop export actually looks the best to my eyes, so I'm genuinely trying to understand why the jpeg.io result would be considered better quality in this particular case.

I don't need to zoom in or even look that hard to see the artifacts. Maybe that's me, or maybe that's the retina display on my MacBook, but that's why jpeg.io looks the best for me. If you can't see the artifacts though, I would say jpeg.io loses out.

For me, it looks like a different image. As in, I would never have expected that the differences to the original weren't a (bad) choice by the "designer" making the image. That seems risky, and in many use cases a worse kind of artifact.

Would it be worthwhile to compress the edges separately? I.e., use edge-detection + dilation + quantize + mask to get the edges, then compress that less aggressively, and overlay over the aggressively-compressed image?

That was your take away from the comparison? Wow ... I fail to see how the jpeg.io is worse than the other two examples.

Look closely around the red and yellow rectangles and just about and edge meeting the blue and you will see. Open all 3 and tab one to the next and you will notice the big difference.

upon first glance it looks like the lines are blurry in the jpeg.io one compared to the original and other two.

If you zoom in a bit that may still be the case, but it looks like the overall image quality is much better.

The photoshop export has significant artifacts visible, while the jpeg.io compressed image has far fewer visible artifacts. The tinypng version isn't jpeg compressed but shows dithering as you would expect from a GIF file.

I've cropped a section of your comparisons and made one extra one of my own which is using imageoptimise (190KB as was lossless compression) on the original image and scaled that section to 1024px on the long edge, saved them as a lossless tiff and uploaded back to pi.gy which as you said does not compress uploads.

... then I realised that pi.gy must not work properly with tiff's as although it appears to upload them fine, it doesn't give you any links to view the images hahahaha, so I re-exported them as jpeg 100% (i.e. no compression and no loss).

Doing this you can clearly see the differences between the different formats.

- original: http://i.pi.gy/DP55.jpg

- photoshop 60%: http://i.pi.gy/LGmK.jpg

- jpeg.io: http://i.pi.gy/qA3a.jpg

- imageoptimise: http://i.pi.gy/4KOa.jpg

From this, I woud say that while photoshop at 60% (which is very low quality produces a noticeable amount of jpeg compression artifact, it retains image structure and colour depth /significantly/ better than jpeg.io even at such a low quality setting, if you wanted to clean up one an image later, cleaning up the freckled Photoshoppe 60% image would be a lot easier than the very damaged jpeg.io image.

*Edit: Spelling, formatting.

> I re-exported them as jpeg 100% (i.e. no compression and no loss)

jpeg is lossy, even at 100%

https://stackoverflow.com/questions/7982409/is-jpeg-lossless...

I think you mixed up the cropped images. In the original post the one with visible artifacts (dots) is the Photoshop version, not jpeg.io.

I really wish people would stop using chroma sub-sampling in lieu of compression. It barely made sense when transmitting analog signals, and it definitely doesn't make sense now.

The artifacts along red/blue edges in JPEG can easily be fixed without giving up chroma subsampling. Everyone recovers subsampling with linear or nearest neighbor upscaling because it's "fast".

If you take one of these subsampled images and use a proper upscaling filter, or better yet, use the Y plane for edge hinting, it'll look great.

JPEG's really not good enough for efficient 4:4:4 but I do think a newer format could handle it.

Can you elaborate on your comment? I'm genuinely curious. :)

When people were devising ways to transmit television signals they had only limited available bandwidth, and since everything was analog compression wasn't feasible. So they did everything they could to minimize the information that needed to be transmitted.

They interlaced the signal, so every frame only had half as much pixels. They also split the signal in chroma and luma (basically colour and brightness, respectively) and then lowered the resolution of the chroma with the justification that the human eye is far more sensitive to differences in brightness than differences in colour. This 'subsampled' chroma should then be interpolated at the receiving end (something which many video players don't do or do badly).

Now at the time this made sense, since it was really the best they could do with no sophisticated ways of compressing images. However as this image demonstrates the human eye can definitely notice differences in colour in some cases. And with digital compression it's no longer true that 4x fewer pixels also means 4x fewer data, so while the decision to compress chroma more heavily might make sense, doing this by artificially lowering the resolution does not.

However for some reason chroma subsampling is still used everywhere; it's one of the many leftovers from the days that video signals were completely analog and only displayed on CRTs.

> They also split the signal in chroma and luma (basically colour and brightness, respectively) and then lowered the resolution of the chroma with the justification that the human eye is far more sensitive to differences in brightness than differences in colour.

It's worth mentioning that the split between chroma and luma wasn't for "compression" but so color signals were backwards compatible with black and white televisions. It's also why we use 29.97 fps instead of 30.[0]

[0]: http://glydeck.blogspot.com/2011/07/why-do-we-have-2997-fram...

Maybe it's just my computer, but I'm getting very different file sizes (using Firefox's view image info).

original - 200.69 KB (205,510 bytes)

jpeg.io - 163.29 KB (167,212 bytes)

Photoshop - 206.41 KB (211,361 bytes)

tinyping - 190.59 KB (195,160 bytes)

EDIT: pi.gy mentions the following in its FAQ [1]:

Q: Does this service compress images?

A: No, but JPEG's might lose about 0.5% of the quality thanks to CloudFlare. Other than that your image stays just like you uploaded it. But we do strip the comments and GPS details for security & privacy reasons.

[1]: http://pi.gy/

Confirmed that the file sizes you list are also what's shown in Safari dev tools.

For fun, I took your original PNG from http://i.pi.gy/0K7d.png (205.5KB), converted it to maximum-quality JPEG (with Preview in OSX), then compressed it with JPEG Mini, resulting in a 122.6KB file.

ImageOptim was able to shave off an extra 10KB with no visible loss.

The resulting image at 112.2KB: https://i.imgur.com/kzZzfIi.jpg

You just "pied pipered" it :)

I would also note that the Photoshop export has very visible artifacting, and the tinypng compression killed the gradient. For the minimal size trade-off, the jpeg.io compression takes the W.

The jpeg.io version is a different image, though - it's got what look like drop shadows.

That's https://en.wikipedia.org/wiki/Chroma_subsampling

I would note that tinypng is not converting it into a JPG, so that's not really a valid comparison - the result is quantized and dithered PNG (256 colours) and not a JPG.

Also did a comparison:

Photoshop high quality progressive scan 3 pass https://supermathworld.com/static/img/350.jpg JPEG.IO https://supermathworld.com/static/img/342.jpg

I see no difference.. a neat idea, but it doesn't seem to have value for me.

> original http://i.pi.gy/0K7d.png (2.1 MB)

> Note pi.gy does not compress uploads.

This original image shows as 201 KB for me in Safari dev tools.

I was hoping to run your source through ImageOptim and examine its output.

i just want to mention that i really like you artwork

Use webp :)