Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Jpeg.io – Convert any major image format into a highly optimized JPEG (jpeg.io)
122 points by matylla on Sept 28, 2016 | hide | past | web | favorite | 83 comments

Has anybody tried mozjpeg? https://github.com/mozilla/mozjpeg

It works much better than any of the alternatives listed here, I'm surprised noone mentioned it yet.

Here is an image compressed to the same size with

mozjpeg http://m8y.org/hn/12597098.jpeg jpeg.io http://i.pi.gy/AP8v.jpg

MozJPEG is especially impressive at reducing artifacts around text:


> If you want to run MozJPEG on your own machine, then you’ll need to use an ugly command-line program.


And I'm out.

Command-line-only apps are typical of this genre of software (pngquant, pngcrush, all the webp utilities, ffmpeg, etc.)

However, sometimes there are GUI apps which wrap the tool itself.

There has been a request pending for it on the IrfanView forums for 3 years now ;)

If you need to do one-off Mozjpeg compressions, I highly recommend imageoptim's online compressor, which you can find here:


It has sensible defaults and is super-easy to use.

Did a quick comparison test with this beautiful piece of artwork I just created.

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

jpeg.io http://i.pi.gy/AP8v.jpg (102 KB)

Photoshop 60% jpeg Export http://i.pi.gy/Wr4P.jpg (90 KB)

tinypng.com http://i.pi.gy/ndKA.png (74 KB)

Note pi.gy does not compress uploads.

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...


[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%


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.

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 :)

I am pretty sure “Kraken.io's proprietery JPEG optimization algorithms” is based on the Psychovisual Error Threeshold: http://ieeexplore.ieee.org/document/6530010/

Have a read at what Google engineer Colt McAnlis has to show about it: https://medium.com/@duhroach/reducing-jpg-file-size-e5b27df3...

I was about to share it, but FB cached something crap:


I was about to refetch it for you, but the FB debug tool throw some error.

From a technical point of view, this is a great way to collect more real-world image datasets to test and optimize their algorithms against.

Moreover, from a business point of view, this is a great way to collect pictures that are usually not published by other means (e.g. Flickr), but I don't quite see how this could be exploited without copyright infringement.

Look at the bottom, it's powered by Kraken.io. This service is just a nice acquisition channel for them while providing something useful. I like these win-win scenarios.

> just a nice acquisition channel

My point was that it is not just an acquisition channel, but also a great way to collect more sample images for their algorithms.

I totally agree. I suppose the parent comment could be referring to customer acquisition or acquiring real world sample image data.

Really nice tool, but I'm not getting the best results in terms of size optimization so far: http://i.imgur.com/2lfx3P8.png

I guess "highly optimized" is a rather ambiguous term. Maybe add a slider for quality <------> compression?

Progressive jpgs increase the size

For anyone else who also didn't know what progressive jpegs are - https://www.wired.com/2013/01/the-return-of-the-progressive-...

When I was experimenting with PS a few years ago, progressive JPEGs were always larger than baseline which is why I came to that conclusion.

This isn't however the full picture. To keep it short, baseline JPEGs are usually smaller if the file size is less than 10 KB.

Useful article about progressive JPEG sizes: http://yuiblog.com/blog/2008/12/05/imageopt-4/

Has anyone gotten it to accept a webp image as input? It threw 'Error while processing this file' for the ~10 files I attempted with. They were all created with cwebp and the photo preset.

I was, of course, quite curious if it could improve upon file size, as that was the main reason I was using webp in the first place.

Worked for me with a file from Opera Turbo. The result was about two times bigger (as expected).

To make comparisons though, you shouldn't use webp as input, use original instead.

Strange, I uploaded this PNG [1] and it came 14,917 bytes larger:

    $ ls -lhias
    -rw-r--r-- 1 root root  2845 Sep 28 07:58 colors.png
    -rw-r--r-- 1 root root 17762 Sep 28 07:59 optimized.jpg
EDIT: Disregard, it's because of the addition of the white pixels.

[1] https://gist.github.com/anonymous/de2f5f8e6ecb5881e1357ebaf4...

Cool. When would you want to use JPEG over PNG though? I don't know much about these things (just using PNG/SVG everywhere).

My rule of thumb: If the image has few colours, PNG is typically better as you can retain maximum quality with little degradation compared to JPG (e.g. a logo, an illustration). If the image is complex with a lot of colours/shades (e.g. a photograph, an illustration with dozens of colours), JPEG is typically better.

Any time it's a photographic image (rather than a drawing, diagram or rasterised vector image).

This. Here's a quick guide:

JPG - Use for photographic images only.

GIF/PNG-8 - Use for line-art, logos, etc.

PNG-24 - This is a a lossless format/TIFF replacement and generally shouldn't be used for production sites.

> PNG-24 - ... generally shouldn't be used for production sites.

But it is sometimes of course, particularly when the designer does not want the PNG restricted to 256 colors. For example, suppose that your logo is a single lowercase letter with an overlaid multicolor gradient rainbow, the banding in the transitions becomes super pronounced in PNG-8.

Beyond that, SVG can replace a lot of what PNG has been used for on the web for the past couple decades.

Some images get better compression with JPEG than PNG - photographs in particular.

Pretty much everywhere where you're not forced to use PNG. JPEG is significantly smaller and on most devices faster to decode.

It totally depends on the situation, JPEG isn't always smaller, and it's lossy unlike PNG. Flat colour images like logos will be smaller as PNG, and look better too. PNGs also support transparency.

Yes, this is kinda what I mean with "where you're not forced to use PNG". If you need transparency or you have tiny flat colored icons, PNG is better. For any kind of complex images JPEG tends to be even 10x or so smaller.

How do jpeg.io's proprietery JPEG optimization algorithms perform compared to JPEG2000, webp or re-jpeg ?

Probably well against JPEG2000, which isn't actually that good. Wavelets look bad when compressed because they blur so much.

JPEG will have a really hard time competing against WebP, x264 --tune stillimage, or HEVC. Nobody uses those though.

Great question. To the top!

No privacy policy on the main or "About" page.

If you upload an image, who knows what the site operator will do with it? Without any kind of limit spelled out, we must assume the worst.

OP, unless the main goal of this site is to harvest images from oblivious people, please add a privacy notice.

So do these do anything different than making image magick available in the browser?

PDF support would be nice.

What about openjpeg.org?

The amount of people in this thread who don't understand what is JPEG and PNG for is staggering!

no pdf?

In what scenario would that be useful? I'm just curious.

Probably when you accidentally scanned a document to PDF. Or when you received a document in PDF from some nasty man.

Cool. But I prefer tinyjpg or tinypng


Forgive me, but why on earth would I want to use JPG in the age of PNG?

Are you serious? A digital photo translated to PNG is going to be quite large. PNG has it's place, for sure, but it doesn't compress photographs like JPEG does. PNG is great for line art, solid color vector that has been rasterized, etc. JPG is great for photos.

>Are you serious?

Perfectly. I'm not very familiar with image compression and JPEG conjures up images of pixellated atrocities.

It seems like either progress has been made in this domain or most JPEG encoders on the internet are poorly configured (in which case the present webapp makes sense).

I think it's more likely that a pixelated jpg is a result of the creator using the wrong format (ie, using jpg where gif/png-8 would have been more appropriate) or over-compressing the image.

PNG-24 is a lossless format, and generally shouldn't be used for production sites.

Perhaps if you were, I don't know, the biggest photography site on the internet:


(Or one of the others: https://500px.com/photo/20852455/-by-maxim-gurtovoy https://1x.com/)

JPEG is used for any type of complex image as PNG compression can't compare.

File size is probably the biggest reason.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact