JPEG XL

Info

rules 57
github 35276
reddit 647

JPEG XL

tools 4225
website 1655
adoption 20712
image-compression-forum 0

General chat

welcome 3810
introduce-yourself 291
color 1414
photography 3435
other-codecs 23765
on-topic 24923
off-topic 22701

Voice Channels

General 2147

Archived

bot-spam 4380

Hi. I strongly believe progressive

paperboyo
paperboyo Hi. I strongly believe progressive decoding is one of the most important, if not the most important, feature that makes JPEG XL worth considering for web delivery context (the context which may well make or brake a format nowadays…?). I have some questions about progressive, super-newbie, but haven’t found answers anywhere… 1. jxlinfo doesn’t print any information about how progressively image was encoded, is that true (tried `-v` and can’t see more verbose) (I am comparing two CDNs here, one is “more”, the other “not enough” progressive in my opinion) 2. I heard “all lossy JXLs” are somewhat progressive. What is the control over making them more or less progressive? Is there a detailed writeup somewhere? (something like the martians for JXL: https://cloudinary.com/blog/progressive_jpegs_and_green_martians#how_about_another_scan_script_) 3. Going into sci-fi, I could imagine encoder to be driven differently when it comes to “scans” for thumbnail images of which there are 50 on a page versus for hero images one per page. So: basically by resolution. But forgetting sci-fi, what would be the sensible default for **all images** when it comes to progressive encoding options for JXL (like when eg. useful MozJPEG got rid of ugly black and white scan…), that would work well in all contexts? 4. Is there a downside to filesize by making the image more progressive? Or any other downside? I am doing some baby playing. It doesn’t help the only browser that (almost) matters “forgot” to support progressive JXL 🤦‍♂️ (this is the only place I know when one could voice opinion on this: https://bugs.webkit.org/show_bug.cgi?id=272350). Sorry for the length. Any ideas super-welcome.
2024-06-25 06:52:55
2024-06-25 06:52:55
Not sure (hate Slack), but maybe thread better…?
_wb_
2024-06-25 07:52:40
Lossy jxl always has at least two passes: one with a 1:8 resolution image (enough for a blurry preview that is good enough to understand what's in the image, but bad enough to see it's not the final image), and one with the final image. The passes themselves can be ordered in other orders than top to bottom too, e.g. you can do middle-first or salient regions first, and get interesting loading behavior even with just two passes.
2024-06-25 07:55:39
More passes can be added, it should not make a big difference in filesize but it will generally come at a small cost compared to doing just the basic progressive.
2024-06-25 07:56:37
The basic progressiveness that you always get is also a good default, which is why we made it the default 🙂
2024-06-25 08:01:49
cjxl currently doesn't offer a lot of control over progressive passes, it only has a few options for non-default things to do. The main thing is to do more "AC" passes, which is similar to what you can do in progressive jpeg, and gives you intermediate steps between 1:8 and 1:1. JXL is more flexible than JPEG here though: in JPEG the quality/resolution improvement of each pass is always affecting the whole image, while in JXL you can e.g. make a pass that adds a lot of detail in, say, the faces or the text, while other regions are left blurry in that pass.
2024-06-25 08:03:06
Another thing JXL can do is "progressive DC", i.e. passes that are even lower resolution than 1:8.
2024-06-25 08:05:41
jxlinfo alas cannot give much info about progressive passes since libjxl itself does not expose much information about it, besides implicitly by generating more events during actual decoding. But jxlinfo doesn't do actual decoding, it only does the header parsing bits of the process without asking libjxl to do the actual decode.
paperboyo
2024-06-25 09:21:00
Thank you! So could maybe djxl give info about what progressive-related options were used during encoding? I guess I will have to experiment with ``` --progressive (sounds magic, is it default?) --group_order (are its --center_x&y basically the saliency demo knobs?) --progressive_ac (what’s its input? number of extra steps?) --qprogressive_ac (I really need to read some book or somepin) --progressive_dc (so 0 removes even the 1:8? 1 is default 1:8 and 2 introduces 1:4?) ``` ? Yeah, can’t read code, but maybe will find some discussion of them on github. Thanks you for pointers!
_wb_
2024-06-26 06:42:34
You cannot remove the 1:8. --progressive_dc=1 will add 1:16, 1:32 etc. Setting it to higher values than 1 is only useful for super huge images where you can do recursively progressive DC (only useful if even the 1:64 image is still a useful preview).
2024-06-26 06:43:23
Group order / center x/y is indeed like in the saliency demo
2024-06-26 06:49:30
Progressive ac and qprogressive ac are two different "scan scripts" that are available in libjxl, for the 1:4 / 1:2 passes. I don't remember exactly what the difference is, iirc one of them does more (in progressive jpeg terms) spectral selection, while the other does more successive approximation.