libspng VS libjpeg-turbo

It also works well on high-res, high-quality images with lots of single-color background and/or smooth gradients. But give it grainy, noisy, smaller-format images and it completely breaks down. We ended up sticking with PNG, which btw. Has fast open source implementations too [1][2]. [1] https://libspng.org/. - Source: Hacker News / over 1 year ago

That's why it's healthy to have competitors written in C. Like the library libspng, which has a simpler API than libpng. Or like samurai, a C reimplementation of the ninja build tool written in C++, or crun, a C implementation of a container launcher in contrast to the original written in Go. Source: over 1 year ago

It makes sense to treat it as an error but the ISO standard is too vague on this and the libpng developers never "fixed" this[1], it issues a warning but otherwise just masks off the high bits. Firefox has a workaround[2][3], Chrome doesn't. FWIW I do the same in my library[4], handling it as an error is problematic because it would mean the chunk gets discarded and then you can't even retrieve the values. [1]... - Source: Hacker News / over 2 years ago

This is interesting from the standpoint of how new JVM features can be used to improve performance (what I presume the article's main purpose to have been), but the image processing improvement itself isn't head-turning. Also, we've found that libjpeg-turbo (https://libjpeg-turbo.org/) is ~5x (IIRC, can re-run my JMH benchmark if anyone wants me to) as fast for decoding JPEGs as ImageIO, so we wouldn't even... Source: about 1 year ago

For all but the simplest formats (basically BMP), the difficulty of implementing encoding/decoding from scratch is significant - well beyond a beginner's ability, and challenging/time-consuming even for senior developers. So, libraries are used in practice - e.g. Libpng and libjpeg-turbo. Source: over 2 years ago