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

[coder]

If you can’t stand the heat…

...eat some chicken.

[ksec]

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.

Welcome the the world of Internet where the only righteous codec are those by AOM. As they are "Patent Free". And their supporter are absolutely against anything else.

[Flaburgan]

Well, all this is great, but in reality... https://caniuse.com/jpegxl
No browser is supporting it, and definitely not the "old" operating system. So it won't be used before years, and probably never.

[pkese]

I'm not saying the transcoded files won't be close. And for many, they'll likely be close enough. I just don't like seeing false claims driving a hype machine.

Which part of the word lossless don't you understand?

> ./cjxl photo1.jpg photo1.jxl -d 0.0 -e 9 --lossless_jpeg=1
> ./djxl photo1.jxl photo1b.jpg

> diff -bs photo1.jpg photo1b.jpg
Files photo1.jpg and photo1b.jpg are identical

> ls -al photo*
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:06 photo1b.jpg
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:04 photo1.jpg
-rw-rw-r-- 1 peter peter 4958842 Aug 19 15:06 photo1.jxl

[billyswong]

There is a default, and someone could reasonably expect that JPEG-XL's transcoded output should match at least one of the three IDCT algorithms in libjpeg: ISLOW, IFAST, or FLOAT.

Those are encoding algorithms. JPEG allowing 3 different algorithms in image encoding has nothing to do with image decoding. We all know there is no one true way in encoding an image into JPEG. Each encoder can encode it differently. But what concerns the JPEG-XL lossless transcoding is standardization in decoding. If only one conformant image can be decoded from each JPEG file, lossless transcoding is mathematically feasible. Variation in JPEG encoding algorithm / parameter is irrelevant details.

What's theoretically possible is theoretically interesting. However, those desiring truly lossless conversion might be interested to know the practical reality.

Again, I'm just about setting expectations, here. Let's not sell JPEG-XL as being able to losslessly re-compress legacy JPEG, if the practical reality is that you don't get the exact same output. All it takes is a slight shift in language, to "reversibly re-compress". That's it.

Since JPEG-XL is designed to have a lossless-transcoding-from-JPEG mode, any mismatch, if ever found, will be considered a bug.

Bugs in computer software is commonplace. If we hold everything by your standard, backward compatibility of any software updates / upgrades are also just "theoretically possible" and not "practical reality". While such scenario is often sadly true for Microsoft Office files, PDFs are a lot more resilient. You are giving no evidence that JPEG-XL format and the library are designed and implemented in Microsoft Office level competence, not PDF level competence. If we push the suspicion to its limit, even the reversibility is also just a theory. You could cast doubt forever until you exhaustively test all JPEG files in the world and claim JPEG-XL may not be reversible until your test completes.

Meanwhile, I choose to trust that the JPEG-XL work has been sufficiently peer-reviewed such that the reversibility has been proven mathematically. And then any bulk transcoding in datacenter will also be tested again with reversibility if the images are in important archive.

If you think JPEG-XL "don't get the exact same output", show an actual example to us then maybe some of us could file a bug report to JPEG-XL team.

[coder]

Which part of the word lossless don't you understand?

> ./cjxl photo1.jpg photo1.jxl -d 0.0 -e 9 --lossless_jpeg=1
> ./djxl photo1.jxl photo1b.jpg

> diff -bs photo1.jpg photo1b.jpg
Files photo1.jpg and photo1b.jpg are identical

> ls -al photo*
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:06 photo1b.jpg
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:04 photo1.jpg
-rw-rw-r-- 1 peter peter 4958842 Aug 19 15:06 photo1.jxl

Nah, try actually reading my posts if you're going to argue with me. You've only demonstrated reversibility.

I've been very explicit about my concern: the actual behavior most users expect, when they see word "lossless". So far, nobody has yet demonstrated this property.

[amxfonseca]

Which part of the word lossless don't you understand?

> ./cjxl photo1.jpg photo1.jxl -d 0.0 -e 9 --lossless_jpeg=1
> ./djxl photo1.jxl photo1b.jpg

> diff -bs photo1.jpg photo1b.jpg
Files photo1.jpg and photo1b.jpg are identical

> ls -al photo*
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:06 photo1b.jpg
-rw-rw-r-- 1 peter peter 6263118 Aug 19 15:04 photo1.jpg
-rw-rw-r-- 1 peter peter 4958842 Aug 19 15:06 photo1.jxl

Thank you! I was tired of reading a bunch of crap, but I was too lazy to grab a computer and install the encoder/decoder to demonstrate it.

The codec was explicitly designed to support this behavior. It does that by skipping some of the new techniques used in JPEG-XL, and by saving a legacy reconstruction bitstream on the resulting JPEG-XL file. This bitstream makes sure that the resulting JPEG image will bit exactly the same as the original JPEG image. Of course that the cost will be a bigger file with less compression ratio when compared with a JPEG-XL without the “legacy” mode.

It is important to say that not all JPEG images can be re-encoded without loss. Since JPEG compression, together with its most used file formats (Exif and JFIF) and quite complex, and not every feature can be transcoded in a lossless way. But AFAIK it supports the most common use cases.

[coder]

Those are encoding algorithms.

They select the DCT or IDCT to use, depending on whether you're encoding or decoding.

Since JPEG-XL is designed to have a lossless-transcoding-from-JPEG mode, any mismatch, if ever found, will be considered a bug.

JPEG (baseline, at least) doesn't store that. I wrote a bitstream parser for it and I'm pretty sure I'd remember if it did.

Bugs in computer software is commonplace.

I don't need a treatise on bugs in computer software. I've been in the game for a while.

I've been pretty clear about my expectation for anything declaring itself to be "lossless", and it seems like you're now just trying to talk your way around the issue.

Meanwhile, I choose to trust that the JPEG-XL work has been sufficiently peer-reviewed such that the reversibility has been proven mathematically.

Now you're trying to turn the issue into being about something I never questioned, which makes me even more suspicious.

If you think JPEG-XL "don't get the exact same output", show an actual example to us then maybe some of us could file a bug report to JPEG-XL team.

I'm sure they don't consider it a bug, because they probably mean "reversible", not "lossless". I just think people should actually say what they mean. I know, I've always been a hopeless idealist.

[coder]

Thank you! I was tired of reading a bunch of crap,

If you're too tired to read what the argument is about, then maybe you shouldn't weigh in.

but I was too lazy to grab a computer and install the encoder/decoder to demonstrate it.

This has been demonstrated before. Reversibility was never in question.

[coder]

Welcome the the world of Internet where the only righteous codec are those by AOM. As they are "Patent Free". And their supporter are absolutely against anything else.

I haven't noticed anyone pushing AOM, in this thread. That's certainly not where I'm coming from.

That's not to say this thread is free of zealotry, however.