Show HN: Jpeg.io – Convert any major image format into a highly optimized JPEG
jpeg.io
jpeg.io
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
:(
And I'm out.
However, sometimes there are GUI apps which wrap the tool itself.
https://imageoptim.com/mozjpeg
It has sensible defaults and is super-easy to use.
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.
Perhaps jpeg.io specializes in photo-realistic pictures rather than graphics and logos.
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...
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.
... 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.
jpeg is lossy, even at 100%
https://stackoverflow.com/questions/7982409/is-jpeg-lossless...
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.
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.
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...
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/
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
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.
> 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.
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 refetch it for you, but the FB debug tool throw some error.
https://gigaom.com/2014/06/30/the-dark-side-of-io-how-the-u-...
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.
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 guess "highly optimized" is a rather ambiguous term. Maybe add a slider for quality <------> compression?
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/
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.
To make comparisons though, you shouldn't use webp as input, use original instead.
$ 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...
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.
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.
JPEG will have a really hard time competing against WebP, x264 --tune stillimage, or HEVC. Nobody uses those though.
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.
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).
PNG-24 is a lossless format, and generally shouldn't be used for production sites.
(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.