Krita 5.1 Released With JPEG-XL Support, XSIMD For Better Paint Performance

[phoronix]

Phoronix: Krita 5.1 Released With JPEG-XL Support, XSIMD For Better Paint Performance

Krita 5.1 is out today as the newest evolutionary update to this leading open-source, cross-platform digital painting program...

https://www.phoronix.com/news/Krita-5.1-Released

[pkese]

Jpeg-XL is such a great tech:
- re-compressing existing Jpeg archives with zero quality degradation (bit perfect reproduction relative to original jpeg)
- very efficient lossless encoding (some 40% smaller files than PNG, 20% smaller files than lossless AVIF or WEBP)
- responsive web sites with single image for all resolutions
- change brightness, contrast, etc., without re-encoding pixel data
- small and lightweight enough to be used in embedded applications (other candidate image codecs bring in the bloat of a full video codec)
- less CPU intensive than video-based image codecs

Problem is that browser vendors are ignoring Jpeg-XL and rather pushing image encoders based on video codecs (e.g. AVIF), because they are integrating video codecs (AV1) anyway.

[esbeeb]

That improved painting performance might actually matter on a Raspberry Pi 4, where the paint strokes appearing can currently lag behind where you drag the mouse, if you swipe a little too fast...

[amxfonseca]

Jpeg-XL is such a great tech

After reading more about the format lately, I tend to agree. It’s a great next generation image format. With a awesome migration path for current JPEG encoded images. It’s rare to be able to move between two lossy formats without quality losses. Let alone the fact that you algo get better compression ratios with the change.

Unfortunately I am afraid that it arrived too late. Apple pushed HEIC a few years ago, and to be honest, it was one of the best formats at that moment for the job.

But a ince the compression gains that JPEG-XL provides are not that great when comparing with HEIC and AVIF. So I am afraid that most companies will skip the JPEG-XL, since it’s not worth the trouble. Especially when hardware HEVC decoders are present on almost every modern device.

Hope I am wrong!

[skeevy420]

Problem is that browser vendors are ignoring Jpeg-XL and rather pushing image encoders based on video codecs (e.g. AVIF), because they are integrating video codecs (AV1) anyway.

Which is such an ignorant reason. Just gonna pull some formats here...Could you imagine not moving on to MP3 because we use AC3 in DVDs?

[rabcor]

Jpeg-XL is such a great tech:
- re-compressing existing Jpeg archives with zero quality degradation (bit perfect reproduction relative to original jpeg)
- very efficient lossless encoding (some 40% smaller files than PNG, 20% smaller files than lossless AVIF or WEBP)
- responsive web sites with single image for all resolutions
- change brightness, contrast, etc., without re-encoding pixel data
- small and lightweight enough to be used in embedded applications (other candidate image codecs bring in the bloat of a full video codec)
- less CPU intensive than video-based image codecs

Problem is that browser vendors are ignoring Jpeg-XL and rather pushing image encoders based on video codecs (e.g. AVIF), because they are integrating video codecs (AV1) anyway.

Can it make 40% smaller true lossless files (not transcribed from an existing already lossy jpeg file) than PNG? If it's a new and better lossless format I am all for it. Looks like it has alpha channel support too, so transparency!

I hate lossy image compression, jpeg artifacts can ruin ap erfectly good picture with relative ease, but if we can have lossless jpegs with 40% smaller files than equivalent PNGs I'm actually intrigued.

Which is such an ignorant reason. Just gonna pull some formats here...Could you imagine not moving on to MP3 because we use AC3 in DVDs?

MP3 is a shitty garbage format, and I regret it's existence, AC3 would be quite a lot better but there are other options now.

[pkese]

Can it make 40% smaller true lossless files (not transcribed from an existing already lossy jpeg file) than PNG? If it's a new and better lossless format I am all for it. Looks like it has alpha channel support too, so transparency!

I hate lossy image compression, jpeg artifacts can ruin ap erfectly good picture with relative ease, but if we can have lossless jpegs with 40% smaller files than equivalent PNGs I'm actually intrigued.

This is what they claim themselves:

• Lossy: about 60% smaller than JPEG for same visual quality
• Lossless JPEG transcoding: about 20% smaller (when you compress existing JPEGs without any loss)
• Lossless: about 35% smaller than PNG (50% smaller for HDR)

I took the estimates from https://github.com/openclimatefix/Sa...ent-1023458031

[pkese]

But a ince the compression gains that JPEG-XL provides are not that great when comparing with HEIC and AVIF. So I am afraid that most companies will skip the JPEG-XL, since it’s not worth the trouble. Especially when hardware HEVC decoders are present on almost every modern device.

HEIC and AVIF are of similar quality or slightly better at images with lossy low bit-rate compression.

JPEG-XL is in the ballpark of these with lossy images, but much better with lossless images as well as more flexible in other areas.

[coder]

- re-compressing existing Jpeg archives with zero quality degradation (bit perfect reproduction relative to original jpeg)

IIRC, nobody has ever confirmed this. It's a mistake to assume that reversible = lossless.

Anyone depending on transcoding being lossless should actually try it. Take the decoded images (from the original + transcoded to JPEG-XL) and subtract them with a bias of 128. Then, look at the differences with you eyes and look at a histogram of them (preferably log scale). This is the only way you can know if it's truly lossless, or how significant the errors are, if it's not.

If it's not lossless (as I suspect), then try it for different image content at different scales, because a 20 MPix image that's a little blurry at 1:1 scale is going to behave differently than typical images you see on web pages (i.e. where there's much more high-frequency content).

[RedEyed]

That improved painting performance might actually matter on a Raspberry Pi 4, where the paint strokes appearing can currently lag behind where you drag the mouse, if you swipe a little too fast...

Raspberry PI doesn't have simd, unfortunately.