FR: configurable compression levels

[IngmarStein]

Hi and thanks for the great project! I‘m thinking about using it in https://github.com/tronbyt/pixlet (and transitively in https://github.com/tronbyt/server). It‘s a system that produces still images and animations for LED matrix displays in lossless WebP format. Pixlet has two modes of operation: an offline rendering which produces previews for an app browser (this can take long but should produce images as small as possible) and a just-in-time rendering for display on a device (this should be fast, but not make images too large for devices with little memory). With go-libwebp, we chose the highest compression level for previews and something in the middle for just-in-time.

nativewebp currently is not configurable in that aspect, so I assume it’s similar to a low-to-medium level in libwebp, right? Do you happen to have made a comparison with libwebp already (if not, we‘re happy to create one, if you think that could be useful)? Do you plan on offering different compression levels?

[HugoSmits86]

Hi, thanks a lot for the kind words and for the detailed context; Pixlet sounds like a very cool use case 🙂

You’re correct that nativewebp isn’t configurable yet.

The project originally started with a very narrow goal: being able to produce a valid WebP file purely in Go. This came from situations (for myself and others) where WebP was required as an interchange format, but libwebp or CGO wasn’t an option because the encoder was just a small piece in a larger pipeline.

Since then, compression has been improved incrementally, but it’s still not on par with libwebp.

I do plan to improve compression quality further, and my intention is to add configurable compression / quality levels once the encoder itself is in a better place. I’m hoping to spend some time on this over the Christmas break.

I haven’t done a systematic, side-by-side comparison with libwebp yet. Since nativewebp is currently the only fully native option, it initially made more sense to compare it against PNG, which was the main alternative when staying native. Once the encoder is closer to libwebp in terms of compression quality, it will make more sense to include a direct comparison with libwebp as well. If you’re interested in creating one for your use case, I’d definitely find that useful.

Thanks again for taking a look at nativewebp, and feel free to share any findings if you end up experimenting with comparisons, happy to discuss or iterate on that.

[the-hotmann]

I would also love to see an option for "quality" or "compression" just like in other libraries, but I understand things take time.

When I currently convert the JPGs (which are already optimized) from my camers, this library is creating bigger webp files, that the JPG it was before.

If you are interested in the pictures just tell me and I will share them :)

[IngmarStein]

@the-hotmann this library currently only implements lossless compression, so it's expected to create image files larger than lossy JPEGs. This FR is about different compression profiles for the lossless encoder because different applications may want to make different trade-offs between file size and CPU time.