As far as I can tell, imageoptim eats this project's lunch. The examples given on optimage's own benchmark page show imageoptim clocking in at around half the total filesize of optimage for the entire benchmark.
Even in the specific examples that are supposed to count against imageoptim -- the destructive chroma sampling, the 'broken gradient' (I can't see it), the orange sneakers (imageoptim's looks better and not overblown colors), or the rotated beach scene -- imageoptim is dramatically smaller on all of them. It puts up a 76k file vs 141k, a 5k vs 14k, a 72k vs 177k, and a 750k vs 1340k.
Halving the filesize for such small differences is exactly what I want in an optimizer.
My biggest complaint with imageoptim is that it's primarily a mac tool, with only a secondary online interface for the windows/linux crowd. But then this project has exactly the same flaw, so there's no gain there either.
> imageoptim clocking in at around half the total filesize of optimage
Only that ImageOptim ruined most of JPEG images while PNG images are ~7.5% bigger.
> imageoptim is dramatically smaller on all of them
There are myriad ways to make them much smaller at the cost of visual quality: blurring, posterization, rescaling, etc. The question is where to stop. With visually lossless, you can apply these techniques in advance and have predictable results. For example, Optimage does choose chroma sampling when it is not destructive to original.
> the 'broken gradient' (I can't see it)
It can be seen on a calibrated display, sorry.
> the orange sneakers (imageoptim's looks better and not overblown colors)
Which is probably what about 99% of all internet users are sitting in front of, right?
This is just a misleading, weird attempt at marketing for a tool I expect to not generate any meaningful sales. To claim that ImageOptim ruins "most JPEGs" is just irresponsible and annoyingly false.
Given the differences in quality vs. compression, ImageOptim and the other free tools actually appear to define far more realistic results for real world use apart from pleasing owners of $3000+ hardware-calibrated soft-proofing displays.
> First tool for automatic image compression that just works
If you search "image compression tool" on Google you'll have millions of hits of products that do the exact same thing. You even list a bunch of competitors on your website. What makes this the first?
Why? There's an extensive benchmark [1], also seen on the homepage, that proves it is the first tool that does not break images like other state-of-the-art tools, i.e. fits the submitted tagline.
On a side note, HN voting system is horribly broken. I submitted the link in the morning and when I hit the bed it somehow got attention.
Pedantic quibble: shrinking is optimizing for size. I deal with a lot of shitty images and size is the last thing I care about. I'm sure it does a great job at making things smaller but that's not the only kind of optimization there is.
There are 40,000 coal lumps of 25 grams per tonne of coal.
That would put moving-information-across-the-net energy consumption at 3 billion tonnes (3.4 billion short tons) of coal in 2008. That's about 44% of world coal production in 2008.
If it took 1 lump of coal per MB in 2016, that would be about 29 billion tonnes of coal (32 billion short tons), or about 360% of world coal production in 2013 (latest date available).
I plan to release a cross-platform CLI tool first. The core tool already works under *nix. But there's still a good portion of business logic in the app.
The work on a cross-platform GUI is happening too, but it is way slower than I anticipated. It's going to be native or nothing. I don't consider Electron or QT as an option.
For me, squashing images is most useful when creating thumbnails. This makes pages load much faster due to the smaller file size. In this sense, optimage would be more useful if it could also intelligently crop the image down to a square.
Photoshop is used less and less by designers, with tools like Sketch and Figma taking over. Also, usually the developers would prefer to handle compression.
I agree. Unless the asset compression is actually part of the application then this does not belong on the devs' plate. There are plenty of other things to focus on.
Even in the specific examples that are supposed to count against imageoptim -- the destructive chroma sampling, the 'broken gradient' (I can't see it), the orange sneakers (imageoptim's looks better and not overblown colors), or the rotated beach scene -- imageoptim is dramatically smaller on all of them. It puts up a 76k file vs 141k, a 5k vs 14k, a 72k vs 177k, and a 750k vs 1340k.
Halving the filesize for such small differences is exactly what I want in an optimizer.
My biggest complaint with imageoptim is that it's primarily a mac tool, with only a secondary online interface for the windows/linux crowd. But then this project has exactly the same flaw, so there's no gain there either.