21–30 of 138 posts
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…
Apple is gonna do what apple wants.
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…
Apple is gonna do what apple wants.
JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.
I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.
[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
Earlier quoted context omitted.
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibili…
avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size…
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
What am I misunderstanding here?
Earlier quoted context omitted.
I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibili…
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…
jxl-rs started to outperform the C++ library 2 months ago.
Chrome appears to be doing the same: https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDoj...
This is awesome! All it took was a Rust implementation I guess?
And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
Earlier quoted context omitted.
Apple is gonna do what apple wants.
What a funny tangent to go off on. JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices. I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking. [1] Worth noting…
Earlier quoted context omitted.
avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size…
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
Earlier quoted context omitted.
avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size…
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?