Future support for Lepton?

From what I can tell, Lepton is a server-level technology, not an actual file-format that can be served to visitors like WebP.
It doesn’t save anything bandwidth for the end-user, because the results have to be decoded back to JPG before viewing is possible. It is highly likely that the decoded results would be larger than something encoded with mozjpeg, like what we do in lossless mode for our API users. It would be closer to the size of the stock jpegtran that the free version of EWWW includes.

So, with all that in mind, while it would save you (potentially) 22% on storage space, it would be a larger file, and load slower than just serving a regular JPG file compressed by our API. That kind of defeats the purpose of optimizing your JPGs in the first place… It would also be very CPU intensive because every single JPG would have to be uncompressed on-the-fly as your visitors load the page.

Sorry to rain on your parade, it has some really cool potential if you’re cramped for space on your server (or you can save petabytes of data on the scale of Dropbox), but I think it’s a loss overall for serving images on the web. I’d also be curious to see what the tradeoff is in power consumption vs. storage cost. For a storage company, it would especially make sense because you assume folks aren’t going to be decoding images all the time. For the most part, they upload stuff, and then it sits there dormant, unless they share them with someone. Even then, it won’t have near the activity of images on a live website.

The lossy JPG compression costs me a lot of money, so it will always require use of the paid API. That said, there is a 200-image refund policy, so you can try it out on a few images, and if you aren’t happy, you get your money back.

• This reply was modified 9 years, 6 months ago by nosilver4u.

Right, but it would cost you more to run it on your own server, unless you’re doing more than a million images per month 🙂
And the lossy compression works on JPG and PNG both (using TinyJPG/PNG).

EDIT: I was originally planning to make EWWW IO able to interface to whatever lossy compression you wanted just like you described. JPEGmini and TinyPNG were really the only high-quality tools out there back then. When I started checking them out I quickly realized I could save people money and time (and boost future development of EWWW IO) by adding those into the API. TinyJPG was released early last year, so I added that into the API as well, for even better compression (best quality:compression ratio on the market currently).

• This reply was modified 9 years, 6 months ago by nosilver4u.

It’s not very CPU intensive to use TinyJPG on a VPS, since the image compression is handled “off-site”, same as the EWWW I.O. API.
The cloud service uses JPEGmini for regular lossy compression, and uses TinyJPG for the “maximum lossy compression” setting.

Theoretically you could hack it to do so (not without mucking up the code significantly), but list price is about $200/month for jpegmini. You can set it up on AWS for about half that, or cheaper yet if you destroy the instance right after you are done. But even then it is $39/month minimum charge.