Figured this is worth a note here: Squoosh is an image compression web app that allows you to dive into the advanced options provided by various image compressors.
https://github.com/GoogleChromeLabs/squoosh
Looks interesting, though on recent iOS devices, images will be in HEIF format, which is about 50% the size of JPEG at similar quality, and MozJPEG isn't compatible with it afaik.
If you're interested in compressing JPEGs without quality loss, there's a free Mac app called ImageOptim that can handle JPEG, GIF and PNG. It has Google's Guetlzi, so on some JPEG you can reach 20-40% compression without any loss of quality that I could detect (and sometimes lower levels around 10% on images that are already well compressed or smaller resolution).
It's interesting to see no iOS example code in Swift.
I know that the Swift adoption rate at Facebook is low for certain reasons, but I was hoping it would go up, or at least be of concern for open sourced projects.
As someone maintaining Obj-C libraries, I can see why. Usually the Swift examples are 90% the same thing so maintaining both is just a boilerplatey hassle. And really, I expect all competent iOS developers to be able to use an Objective-C API from Swift without even thinking about it, much less require specific examples.
With that said, I do find it useful to write unit tests in Swift, just to see that the Swift API looks as expected. So that’s one way to add examples.
Facebook has the worst image compression on any website, their photos are compressed to a point where they look horrible. Why would anyone want to use this?
I do not see what this benefits any developer over just using mozjpeg with better settings.
Do you really not see the benefit in avoiding the need to recreate a bunch of scaffolding around 3 separate image encoders, or is this just an excuse to dump on facebook?
libimage-magick should be sufficient, however I don't know how well that runs on androids and iphones.
It smells like a NIH project to me, but then again there might have been some very special requirements that facebook needed that was not already available in other libraries.
At Facebook's scale, the choice of whether to resize/crop/compress images on devices or at the backend must be a complete no-brainer. Why would you stand up additional datacenters instead of just burning a little more of your user's (your "product's"?) battery?
I like how there are 2 products called Spectrum on the front page and they are completely unrelated. Anyway, this lib looks pretty ok for it's purpose.
GAFAS tends to never do their homework before choosing a name: they know they can roll over most previous projects and just don't care about the community as long as they can't get PR from it.
