JPEG XL

you can view the default being a power of two minus one as kind of a coincidence

a stop above is just twice that as it normally would be

Thanks, you are right. I'll just follow the *2 rule

Nominally, sRGB is 80 nits. But it's rare to see such dim displays nowadays. The current consensus for defining SDR max nits seems to be 203 nits. But typical SDR displays will be even brighter. We used the default 255 because at some point, we were using a linear RGB representation where the numbers went up to the intensity target (so they were basically in nits), and then converting floats to 8-bit values would be just rounding to int. We no longer do that, but the number 255 sticked.

I've always seen 300 nits as the SDR max, but that could be because I've only recently seen it in passing now that displays are brighter in general

Thanks for the explanation.

SDR max doesn't actually have a specific nit value, since it's just relative to whatever the SDR monitor outputs

most monitors are around 200-300 nits give or take

but theoretically you can have any SDR white point and any SDR black point in nits

though most software expects SDR black to be 1/1000th of the SDR white

Yes, in SDR everything is relative. In a cinema, the max value can be only 48 nits (that is what DCI-P3 uses, for example), since you're viewing in a very dark room. The sRGB reference was 80 nits but that was assuming an indoors office environment. In practice many current SDR displays (e.g. phones and laptops) are designed for more varying ambient light conditions and can often do 300 nits or even more. The 203 nits is a recent convention of where to nominally put SDR white when mixing HDR and SDR content.

PQ can't come soon enough, I don't want relative transfers any more, so much headaches

not that most HDR displays actually do a great job at tracking PQ, but that's a different story

it's not really desirable either to interpret PQ exactly. You want your display to have manually/automatically adjustable brightness. It makes sense to make it darker when used in a dark room and brighter when used outdoors.

absolute luminosity only really makes sense if the viewing conditions are also absolute

PQ was designed by Dolby with cinema theaters in mind. HLG was designed by BBC with consumer TVs in mind.

In practice, it seems like most stuff that supports PQ (like HDR TVs or Apple Macbook laptops, say) does interpret PQ in an HLG kind of way: everything is relative to SDR white, which has a brightness that depends on the display brightness setting, rather than having everything in absolute nits as it is theoretically supposed to be in PQ.

The improvement from v0.10.2 to main is huge! I'm wondering when will the next version gets release?

improvement in what?

quality and file size changes

For lossy only? Or do you mean lossless is smaller and quality for a given file size is better in lossy?

what about on displays that can display "true" black (ie. oled)?

In SDR mode they may not use true black, or they might

basically SDR is a range of 0% to 100%. the black point is 0% and the white point is 100%

if the black point is actually 0 nits that's called infinite contrast

well *technically* 0 nits is impossible due to quantum physics 🤓☝️

sure, but you asked about true black

which would be 0 nits

nits are visible light btw, so infrared radiation does not have any nit value

I haven’t tested lossless yet.

OLED can't actually achieve 0 nits since light can reflect off the screen

https://youtu.be/p6q54q2iam8 [⠀](https://cdn.discordapp.com/emojis/1059276598660059136.webp?size=48&quality=lossless&name=av1_trollhq)

But light from the screen would bounce off your face and then back to the screen !

Mask?

then you cant see

imagine just seeing flying white eyes in the dark void <:KekDog:805390049033191445>

https://tenor.com/view/laugh-black-man-dark-darkness-scary-gif-19605615

I encoded a 2096x2088 PNG to JPEG XL with effort 9 and the bottom right corner has a small 48x40 "patch" where colors are really distorted

i got this error on the cover art for femtanyl's "CHASER" which is slightly graphic, but painting out the rest of the image still produces this error after JXL encoding->decoding

So apparently it only happens >= effort 5

This issue was demonstrated with 0.10.2. This does not occur on 0.9.3

0.10.0 crashes(?!) during encode

0.10.1 as well

0.10.3, like 0.10.2, doesn't crash but has the same bug

could you open a github issue about this? The DC group size is 2048x2048 so those image dimensions would have one full group and then three very small ones, the one at the bottom right only 48x40. It could be that there's some kind of edge case bug in the encoder heuristics that makes it make bad decisions in this case.

he already did https://github.com/libjxl/libjxl/issues/3717

yeah, just saw. Looking

Can someone check if bug exists in master?

Is this a bug? I have a 14-bit grayscale PGM `src.pgm`, and I converted it to lossless JXL by using `cjxl -d 0 src.pgm target.jxl`. The problem is the brightness of these two are slightly different. By using `identify -verbose`, I get the `Channel statistics`: **src.pgm** ``` Channel statistics: Pixels: 24337152 Gray: min: 0 (0) max: 15871 (0.968748) mean: 642.471 (0.0392157) median: 229 (0.0139779) standard deviation: 1242.43 (0.0758363) kurtosis: 15.1143 skewness: 3.73396 entropy: 0.759787 ``` **target.jxl** ``` Channel statistics: Pixels: 24337152 Gray: min: 0 (0) max: 15871 (0.96875) mean: 642.457 (0.0392148) median: 228.99 (0.0139773) standard deviation: 1242.42 (0.0758362) kurtosis: 15.1143 skewness: 3.73397 entropy: 0.759787 ``` So I checked another 16bit RGB PPM. No problem at all. The `identify` result are exactly the same. Is this a code issue for Grayscale image only?

I've checked again. It seems no problem.

I did, it does 😄

thank you for testing!

isn't it weird how master builds still say 0.10.2?

indeed 😄 they could call it 0.10.3pre

lossless? if so that's a bug

can you post src.pgm?

though if I had to guess, the issue is one of 14 -> 16 bit

14-bit is 0 to 16383 and 16-bit is 0 to 65535, and 65535 is not divisible by 16383

so there may be some sort of issue with rounding

<@184373105588699137> https://discord.com/channels/794206087879852103/848189884614705192/1265271751349108796 ``` ffmpeg -i foo -c rawvideo -f framecrc - ```

alternatively `-c rawvideo -f hash -`

``` leo@gauss ~ :) $ ffmpeg -hide_banner -loglevel error -i george-smile4.jxl -c rawvideo -f hash - SHA256=c9f1c023f0310760e6bd5ecfab97464a77a4eaecb3ff9102cc55a11449b7f535 ```

right! and i'm really concerned

my first draft of the message started by saying it was a bug but ig it was lost somewhere lol

doesn't jxl support arbitrary bit depths?

internally it supports between 8 and 16 (actually up to 32) yea but the library only supports receiving or providing 8 or 16 bit buffers (or 32-bit)

hhuh

there's no way to request 14-bit packed pixel data from the library, you have to request 16-bit data

so in theory if you have a 14-bit buffer you can provide it to the library as a 16-bit buffer, and there's a flag to tell it which bits are significant

theoretically the library could be expanded to perform this however? not that anyone might implement it...

well you can provide 14-bit data with the top two bits all zeroes and tell the library it's 14-bit data

and likewise you can request the data back, with the same flag

and it'll be between 0 and 16383, but in a 16-bit container

if that makes sense

hmmm i get it

however, in the src.pgm and target.jxl, it says "max: 15871" which leads me to believe that imagemagick is scaling the 14-bit data to 16-bit data for the src.pgm, but it's letting libjxl do the scaling for the target.jxl, and the two libraries don't scale it in exactly the same way b/c of rounding

mmm conflicting codec handling

i have noticed there's some images in which webp beats jxl in lossless compression, maybe i'll make an issue

tho the savings are not huuge or anything, and cwebp's highest compression setting is really slow (e11 worthy)

are you passing `-mt` to cwebp? if not you should since it can speed things up even if cwebp can only use a max of like 2 or 3 threads

i haven't really noticed a difference with `-z#` (lossless), but sure i'll try again

there should be a noticeable difference at `-z 9` since the highest level enables the "lossless cruncher" which can be multithreaded with `-mt`

interesting, i didn't know

I’ve double checked it. No problem now. It was my mistake.

huh

https://github.com/libjxl/libjxl/pull/3563 About this PR, if I only compress image once with high quality settings, should I turn on the Gaborish manually?

I have used hash before, I just pipe to b3sum since it's marginally faster in my scripts and I have it memorized now (shaves maybe 1/8th of a second, but that matters a lot when validating 60k image sets)

that said if your'e going to hash the output you're relying on ffmpeg's specific ppm encoder

may be better to just use -f rawvideo

I never really considered that ffmpeg's ppm encoder could cause issues 0.0

well it's more that you're relying specifically on its semantics

if it's changed, the hashes will change

I prefer `-f rawvideo` as only time you'll get identical hashes is if the bytes are identical but the shape is different (or there's a collision by accident, but lol)

also why b3sum? is it faster tham md5sum?

what about xxhash?

xxh64sum sounds faster

since you don't need cryptographic hashing

much faster then md5sum by default at least these are the commands as is, iirc b3sum just has way better threading ```ps ➜ Pictures hyperfine --runs 10 'md5sum windwaker-no-fast-1.jxl' 'b3sum windwaker-no-fast-1.jxl' 'xxh32sum windwaker-no-fast-1.jxl' 'xxh64sum windwaker-no-fast-1.jxl' Benchmark 1: md5sum windwaker-no-fast-1.jxl Time (mean ± σ): 796.7 ms ± 9.5 ms [User: 722.9 ms, System: 67.0 ms] Range (min … max): 785.3 ms … 817.8 ms 10 runs Benchmark 2: b3sum windwaker-no-fast-1.jxl Time (mean ± σ): 72.6 ms ± 1.0 ms [User: 464.9 ms, System: 79.2 ms] Range (min … max): 71.2 ms … 74.9 ms 10 runs Benchmark 3: xxh32sum windwaker-no-fast-1.jxl Time (mean ± σ): 147.8 ms ± 6.6 ms [User: 85.9 ms, System: 61.1 ms] Range (min … max): 141.8 ms … 163.1 ms 10 runs Benchmark 4: xxh64sum windwaker-no-fast-1.jxl Time (mean ± σ): 102.2 ms ± 3.5 ms [User: 42.1 ms, System: 58.2 ms] Range (min … max): 96.4 ms … 107.0 ms 10 runs Summary b3sum windwaker-no-fast-1.jxl ran 1.41 ± 0.05 times faster than xxh64sum windwaker-no-fast-1.jxl 2.04 ± 0.10 times faster than xxh32sum windwaker-no-fast-1.jxl 10.98 ± 0.20 times faster than md5sum windwaker-no-fast-1.jxl ```

im sure that there can be hashers that are faster then b3sum, but b3sum is something I have on all of my systems by default so it's safe to just default to it then go hunting and find a new hashing tool

xxh64sum may be worth it

considering that it's like, 42.1ms vs 464.9 ms

it's certainly faster for sure. I had never really tested it before

it's designed to be an extremely fast in-memory non-crypographic hash

it's used by lots of databases for hashbuckets and the like

er, hashtables

developed by the Lz4 guy, uh what's his name

uh Yan collet or something

i see, I can for sure start including that when I do stuff for sure. b3sum's speed mostly comes from the absurd level of optimization the devs did, which iirc includes an absurd amount of hand written ASM

also iirc it looks like it's parallelizing better

compare the real time of the b3sum to the user time, the user time counts all threads

arch ships this by default https://github.com/BLAKE3-team/BLAKE3 which is what I use,

oh yeah, it hits a lot harder on resources ```ps ➜ Pictures time xxh64sum windwaker-no-fast-1.jxl 74127cc7e3d61d2d windwaker-no-fast-1.jxl xxh64sum windwaker-no-fast-1.jxl 0.03s user 0.09s system 98% cpu 0.118 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 4 MB ➜ Pictures time b3sum windwaker-no-fast-1.jxl 49e5cfa296f70fd0f29a0b7041f4bacd0f40371746d67e74851a88808d12678c windwaker-no-fast-1.jxl b3sum windwaker-no-fast-1.jxl 0.52s user 0.06s system 673% cpu 0.085 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 510 MB ```

510 MB oof

yeah disabling mmaping helps a lot in resource usage, but *really* kills the perf since it kills threading too ```ps ➜ Pictures time b3sum --no-mmap windwaker-no-fast-1.jxl 49e5cfa296f70fd0f29a0b7041f4bacd0f40371746d67e74851a88808d12678c windwaker-no-fast-1.jxl b3sum --no-mmap windwaker-no-fast-1.jxl 0.27s user 0.07s system 99% cpu 0.335 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 4 MB ```

oh I see it mmaps the input file

so what happens if you stream it? ie `cat windwaker-no-fast-1.jxl | b3sum -`

cause that's what matters for your use case rn

yup, it hurts. still better then md5 though by a good amount, looses to xxhash a lot ```ps ➜ Pictures time cat windwaker-no-fast-1.jxl | b3sum - 49e5cfa296f70fd0f29a0b7041f4bacd0f40371746d67e74851a88808d12678c - cat windwaker-no-fast-1.jxl 0.00s user 0.25s system 69% cpu 0.364 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 4 MB b3sum - 0.22s user 0.13s system 95% cpu 0.364 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 4 MB ``````ps ➜ Pictures hyperfine --runs 10 'md5sum windwaker-no-fast-1.jxl' 'cat windwaker-no-fast-1.jxl | b3sum' 'xxh32sum windwaker-no-fast-1.jxl' 'xxh64sum windwaker-no-fast-1.jxl' Benchmark 1: md5sum windwaker-no-fast-1.jxl Time (mean ± σ): 814.3 ms ± 11.7 ms [User: 724.3 ms, System: 84.7 ms] Range (min … max): 795.4 ms … 835.9 ms 10 runs Benchmark 2: cat windwaker-no-fast-1.jxl | b3sum Time (mean ± σ): 381.3 ms ± 6.4 ms [User: 262.6 ms, System: 358.2 ms] Range (min … max): 373.3 ms … 395.3 ms 10 runs Benchmark 3: xxh32sum windwaker-no-fast-1.jxl Time (mean ± σ): 164.2 ms ± 4.2 ms [User: 92.2 ms, System: 70.9 ms] Range (min … max): 157.9 ms … 172.6 ms 10 runs Benchmark 4: xxh64sum windwaker-no-fast-1.jxl Time (mean ± σ): 119.8 ms ± 3.4 ms [User: 37.5 ms, System: 80.6 ms] Range (min … max): 116.0 ms … 126.6 ms 10 runs Summary xxh64sum windwaker-no-fast-1.jxl ran 1.37 ± 0.05 times faster than xxh32sum windwaker-no-fast-1.jxl 3.18 ± 0.10 times faster than cat windwaker-no-fast-1.jxl | b3sum 6.80 ± 0.21 times faster than md5sum windwaker-no-fast-1.jxl ```

i managed to make b3sum faster

`alias b3sum="xxh64sum"`

:^)

Division by zero contrast 😂

it's called "infinite contrast ratio"

I didn't invent the term

Public cause that happens when you’re dealing with learning point numbers

Floating point numbers

lim x -> 0+ 1/x contrast

YOO I GOT MY OLD ACCOUNT BACK

why is xxh32sum like 3x slower than xxh64sum

that doesn't make sense?

I've been out of the loop for a while, so I have a couple questions about splines: where are they at with implementation and will they close the gap between JXL and AVIF for simple shaded anime-style images? I was surprised and a little disappointed to see that AVIF did much better with the line art edges than JXL at the same quality setting (eg 80) and confirmed it myself using XL Converter.

Currently there's no spline encoding in libjxl due to how complex it would be to find good placement of them. Decoding is fully supported, and there are example files or tool to make a file using splines, but they need to be added by hand until more time can be spent developing an efficient method to encode them

it's been multiple years

It's joever

older and less optimized maybe? just guessing

Same quality setting does not mean same quality. The avifenc scale is very different from the cjxl scale.

I think the biggest quality/bitrate breakthroughs in the future will be from hybrid images that use splines or wavelets to encode an extremely smooth and simplified "edge/shape detection" color image, and DCT to encode "texture" only since that's the 1 thing DCT is always really good at. Of course, hybrid images will take at least twice as long to decode, but it's the price you pay for really good lossy bitrate/quality improvements.

I'm not a power user, so that's the only "objective" metric I can give to show similar usage. But, yeah. It's annoying how different codecs use different scales behind the scenes, or even user-facing, since it kind of defeats the point in having something for regular people.

I guess the main thing I noticed was it prpduced a smaller file in Avif for simple shaded anime images than JXL using either VarDCT or Modular settings and with no artifacts (though, Modular was a clear winner compared to VarDCT).

Encoders are generally not consistent enough to be able to have quality settings that would be consistent across codecs. Just keep in mind that these setting scales are completely arbitrary. It is very easy to make an encoder that just produces worse quality for the same q setting and it will look like it compresses very well 🙂

In fact, I think that's a 'trick' that both lossy webp and avifenc are applying, since they both have a scale that is producing worse quality for the same q parameter than typical jpeg encoders (libjpeg-turbo or mozjpeg) would produce for that setting.

I don't really like that kind of trick aimed at deceiving naive users. It basically causes people to accidentally select a quality that's worse than what they were doing before, giving them the impression that they're saving many bytes but it comes with a drop in image fidelity (moreover, a drop that's not so easy to notice since both webp and avif are good at preserving appeal even when fidelity is low).

Interesting. I didn't realize it went back even to WebP. Though, I do notice the "blurring" or "smearing" that the VPX codecs apply, which is why I'd pick Jpeg (who's artifacts I was more okay with) over WebP when re-encoding images to save space.

Regarding Avif + aminu pics, it produced an image that looked fine upon broad and fine tuned inspection, with no artifacts and was also a bit smaller than its Modular JXL version (which did have some noticeable, but minor, artifacting around the edges). So, I was wondering "what would be needed to close that gap between the formats in this area?" I have a lot of images in that style, but I'd like to use JXL as exclusively as I reasonably can, partly out of loyalty and partly out of convenience of not having to juggle multiple formats.

So, splines were what came to mind, since the issue mainly appear around clean edges and I remembered discussion a while back about how that might address that aspect. I'm still really impressed with what JXL is becoming and all the improvements being made already.

While on the topic of `quality`… In JXL, is its relationship to `distance`… fixed? Static? (I’m looking for a correct word…) If I’m using the exact same `quality` is it like I would be using exactly same `distance` and nothing changes this relationship (eg. `effort`)?

I can't find the graph, but quality is mapped to distance on a fixed curve

I read and enjoyed your article about appeal vs fidelity. I also think it's possible to target both at the same time... Compression artifacts don't have to look deceitful, nor distracting and irritating. If compression artifacts resemble natural-looking noise patterns, then it won't look irritating and distracting nor deceitful, compared to typical smearing, or macroblocking, or blurring caused by image compression. High frequency noise patterns also help to convey a sense of "bad transmission quality" as opposed to deceptively changing the contents of the image.

Imagine a JXL image getting progressively fuzzier and noisier as the bitrate drops and the distance setting increases, instead of blurry smears and smudges.

They're functionally the same but the noise helps hide some of the ugliness of the lost information, without hiding the fact that information is missing.

Film photos is the best example of this, I believe

Kinda sounds like analog interference

Yes, exactly. That would be more honest AND better looking at the same time, compared to typical digital lossy compression artifacts.

It reminded me of the way AI art starts from noise, then refines into an image over time. The less refinement, or data, the more noisy the image is. Unfortunately it's a lot harder to do that in a way that looks good at all levels

Smears and blurs and smudges does a worse job, both at avoiding deception, and avoiding looking looking awful and weird.

I don't think anyone is currently working on an encoder that does spline detection. Another option to improve anime compression is to implement something similar to avif's palette blocks (using modular patches). There are a few tricks that could be tried to improve jxl encoding on anime-style images, but for now this hasn't really been a priority — it's a relatively specific use case, and I think we prefer to first focus on the more general things (like getting libjxl v1.0 done). AVIF works well on anime-style images because it has directional prediction with many angles, which is good for saving bits when encoding clean hard edges. On photos it tends to cause smearing / smoothing artifacts, but on anime-style images the artifacts tend to be OK. Closing the gap between JXL and AVIF on lossy anime-style images will require coming up with nontrivial encoder improvements in libjxl. Don't hold your breath. If you want to use JXL for these images, for now I would recommend using lossless.

Reminds me of what Opus does, it fills some parts with artificial noise which is actually mostly not unpleasant

I wonder how exactly one would make such an image codec, where it has a "noise floor" you can reach by missing data

it's also worth noting that it's not like avif does better for all "anime style" images. more detailed images will usually start shifting heavily towards JXL anyways

Yes, it's mostly when the image is "clean and simple" that lossy avif will work well on it. But those are also images where lossless jxl will work well, in some cases even producing smaller images than high-quality lossy. Images that involve more detail / texture / more realistic drawing styles, will be better for lossy jxl than for lossy avif.

The worst thing an encoder can do, is to completely change what you're looking at and create something completely different that didn't exist in the original. Like for example, completely change the color of an image, or completely erase certain details or textures from an image. Or create new signals that didn't exist in the original, like moire patterns or banding patterns or macroblock patterns. It's especially bad if it's worse than simply resizing the image to a smaller canvas, or if the artifacts are visible after resizing.

Yay HEIC and JBIG2

what's heic do?

heic (hevc) can artifact with fake data

jbig2 is funny

I would say JBIG2 is good only for storing coloring pages.

The pain of the recent Reddit post > (input image was originally .jpg, converted using imagemagick at the end of 2023) And now they're wondering why the image is so large when they try to re-compress it with cjxl, I really hope they still have that jpeg to transcode it properly

big love to the dev who fixed the modular/lossless bug i filed

lossless is now a little less lossy than before :))

That was a rather nasty one, I am happy it got caught before the 1.0 release

no idea how it managed to slip past for so long... how sure are you it also repros on 0.8.2?

https://github.com/libjxl/libjxl/issues/3717#issuecomment-2247106108

User-reported

I did ☝️ I tested with the "static" releases provided on the github. I may have made a mistake but I hope not... Please check again if you can. Should a `--check` flag be added? To be used on lossless mode to add a pixel level check of decoded compressed image?

Does libpng do a pixel check?

I guess not... It would sounds like the library is not very mature 😄 but jxl is both a bit less mature and a bit more complex

I think we should maybe do a large scale test, running it on some big random corpus with various effort settings and number of threads etc, just to check everything roundtrips.

(also with asan/msan/tsan builds)

Sounds good. I'd only argue against it being a "relatively specific use case" in the sense that an increasing contingent of the images on the internet are of this style. But, I understand the logic behind prioritizing the overall parts of libjxl and the fact it'd take some actual work to close that gap. The whole reason I asked about this was so I could have an idea of what would be needed to make that improvement and to have a realistic expectation about what would be required to make that happen. All of that was nicely answered in your reply here. So, thank you and good luck. I'll continue doing what I can to help further along the adoption of the format.

Yeah. That's why I specified "simple shaded anime images." I'm currently sorting images downloaded from Pixiv and such into two folders ("Convert to JXL" and "Convert to Avif") based on that criteria, which is of course subjectively eyeballed and guesstimated.

Lossless JXL can sometimes make smaller files than high quality lossy Avif? I'll have to do some testing on that, then. Maybe someone will come up with a machine learning tool that will scan images and figure out which conversion formats/settings would work best. Just automate everything. Lol

in basically any format that natively supports both lossy and lossless, you'll usually find cases where lossless will be smaller than high quality lossy

it's very content dependent though...

Just compress to both avif and jxll (l - lossless), and compare sizes. But I'd stick to jxll anyway, storage is quite cheap these days. And I hate avif, it is the reason too

🥲

Hope you have backups

Sure, another hdd with the copy lays in the bookcase

also hope it’s organised and not just a pile of random files in no structure

Sure 🙂 Photos\year\year-month-day <name>\ <files>

I think we're gonna be saying that for quite a bit after that scare 😅

Speaking of 1.0, is there any estimate for it? This year, next year?

I think it is likely to happen in 2024.

awesome

maybe we can finally shut up the Mozilla devs claiming JXL isn't stable <:KekDog:805390049033191445>

jxl (the specification and bitstream) is stable since 2022 and conformance is tracked. discussions tend to confusingly mix between jxl and libjxl, capabilities of the format itself and the reference library (its current state generally)

Admittedly, the conformance tests haven't caught two cases of lossless not being lossless, one needing the spec to be changed so they stayed compatible and the other thankfully being due to rare combinations of arguments (Chunked multithreaded lossless encoding above e4) With some bolstered tests before releases, and maybe using the other JXL decoders for sanity checks, it should be in a very stable state already

Like with png sometimes being smaller than jpeg.

>muh storage is cheap cope No. Lol

I think a more accurate statement would be, "storage is getting cheaper"

I said about myself and my choice. For me any my needs - it is

I'm just sad all my HDDs died, running on a single non-redundant SSD now

I know. It's a meme to reply with "storage is cheap" to any data size related problems online, especially chan-style message boards. So, I try to shut it down when I see it, because it's an attitude of "don't solve the core problem, just let it get worse and adapt by spending money."

"Data hoarding is one hell of a drug. I myself just got into rehab and I deleted a ton of stuff off of my hard drive. Now I wake up everyday with optimism as I look at all the free storage space I have! This has not only improved the performance of my computer, this affects me to the very core of my life. My ex-wife is now talking to me and I might even see my kids again!"

I am big optimization (in better meaning) fan, so I understand you clearly. So let me rephrase my statement - storage is cheaper for me than the quality. But if anything helps me to save storage without losing quality - I'll be the first to use it 🙂

No, I understand. I was only attacking the meme. I figured you were in favor of optimization, since you're here in this channel. 😉

And Call of Duty needs to stop putting out 300GB "games."

I don't have a wife or kids, but I did this a few weeks ago on 250 GB of random videos I had taken over the years

Does looking at all that free storage space fill you with joy? 😊

It means I don't have to constantly worry about running out anymore, was at 40 GB left at one point with the swapfile using up another 20 GB during a game

I had similar issues with my laptop. I had 20 GB left with a 12 GB swap file. So I got rid of 80 GB worth of junk.

whenever i have free space it fills me with the urge to start `yt-dlp`ing random crap that i'll never need ever again

Hello. When I convert animated .jxl to .apng using `djxl` I always get gigantic images. When for example a program or a webiste doesn't support .jxl and I convert it to .apng I still can't upload it because of the size. I wanted to convert my GIFs to JXL but then if I ever need to go back to another format I will get a gigantic file and lose quality when trying to make it smalller. A 5,3 MiB GIF converted to APNG using ffmpeg is 7 MiB. Looks identical to original. When I convert original GIF or ffmpeg's APNG to JXL using -d 0 I get 6,3 and 6,2 MiB JXL files. When I convert those JXL's to APNG I get 32,9 and 32,6 MiB files. Does anyone knows why is this happening? Is there any way to get .apng from .jxl with similar size to the original? Happens with `djxl` on latest commit I compiled (v0.10.2 f7f20ce0), v0.10.3 4a3b22d from GitHub releases and v0.8.3 from Fedora repos.

I assume `djxl` isn't using that that much compression effort when creating APNG files leading to the large sizes, you might need to put the APNGs produced by `djxl` through another program such as [APNG Optimizer](https://sourceforge.net/projects/apng/files/APNG_Optimizer/1.4/) to get the file size down back to normal

The main issue is probably that djxl returns full frames

Thank you! apngopt 1.4 from Debian repos reduced the image size to 5,7 MiB

That's smaller than the jxl size you reported

These image optimization tools could be ported to jxl in the future hopefully

Interframe video compression with patches?

These animation optimizers usually encode differences between old and new pixels, leaving rest of the frame transparent.

Yesterday, I was not trying to create the smallest JXL. The original GIF is 5,3 MiB cjxl (v0.10.2 f7f20ce0) `-d 0` creates 6,2 MiB JXL `-d 0 -e 9` 5,7 MiB `-d 0 -e 9 -P 0` 4,4 MiB `-d 0 -e 9 -P 0 -g 0` 4,3 MiB djxl + apngopt (defaults, 7ZIP with 15 iterations) creates 5,7 MiB APNG

Both of those are options. The APNG way is both encoding differences by using transparency to previous frames, but also using frames only as large as they need to be (A 32x64 area out of a 512x512 animation, for example). That can only be done for the entire frame though, JXL could likely use adaptable patch sizes along with referencing outside concurrent frames as you said

theoretically jpeg xl could also do funky things with layer mixing modes to add kind-of interframe prediction

https://youtu.be/FlWjf8asI4Y

Just learned I can use JPEG XL in Obsidian using the community extension "Image Magician" and adding `jxl` to the supported files list

Hello! Nice to meet you all

woah great!

Pedantic. 2 keywords are too general right now. Just remove https://github.com/topics/lossy-compression and https://github.com/topics/lossless-compression-algorithm from https://github.com/libjxl/libjxl. The repository has 2 -image-compression keywords and even image-compression. JPEG XL can't compress arbitrary binary files easily...

Which advanced parameters outside of distance/quality and effort are most commonly used/most useful for encoding?

the `-I` is often usefull for non photographic images (lossless)

Well it depends. What content are you encoding, lossy or lossless? Do you care about progressive decoding?

Well, I mean which options should be in UI, and which ones are too useless/technical.

https://github.com/JacobDev1/xl-converter

This program provides a good starting point

My only nitpick would be to replace quality with distance

what does the "Intelligent" checkbox next to effort mean/do? does it like change/scale the effort value based on resolution of the input file or something?

idk, I've been meaning to look into it ¯\\_(ツ)\_/¯

I wouldn't be surprised if the author of this was here, in this discord

It seems like the only advanced option is lossy modular mode

Here's Krita's JPEG XL save dialog. I dunno if it's overboard, or only essentials.

it seems overwhelming !

Just quality and maybe encode effort should be enough to expose, imo. Most of the encode options are more useful for experimentation and maybe some specific use cases, but for general use, even exposing just quality, with some reasonable default for effort (say, e3 for lossless, e6 for lossy), should be ok.

wow, it exposes literally every single option

cool

I think it's fine since it's under the advanced tab

The most advanced useful option I see there is lossy alpha. For everything else you can let the encoder decide automatically.

Krita's documentation actually has descriptions and explanations for things not listed in the help of cjxl or the github, since they read the code and implimented it themselves ~~Unlike Adobe~~

Why does Krita not offer the use of distance. 😔 Like it only took me a minute to learn how to use it and I've never gone back

Such an underrated feature.

krita still not having associated alpha support T.T

I'd love for that to be an optionally automatic feature, like letting the app figure out if modular or VarDCT should be used based on a loose scan of the image contents. Like, "lots of detail" vs "smooth colors with sharp edges/lines."

Since we're talking about apps, would someone be interested in looking into this issue: https://github.com/T8RIN/ImageToolbox/issues/1202 There's some rendering oddities in the middle, but the main bit is at the beginning and the last few posts.

FYI: latest 4K monitors@1000 Hz are crazily bottlenecked by common broadband speeds in 2024. 1/1000 second at 100 mbps = 100000 bits = 12.5 kB 1/1000 second at 1000 mbps = 1000000 bits = 125 kB

This means that progressive should be enabled pretty early for these in online/streaming over broadband scenarios...

New fab is here 🫤

I’m not sure using a 1000Hz monitor implies that you necessarily expect 1000fps decoding for still images

1000 Hz refresh rate, that seems overkill. That's an order of magnitude faster than the temporal resolution of human vision. Maybe it's useful to reduce ghosting etc to have such a high refresh rate, but it seems useless to have the actual content signal at that speed. Just like a display resolution much denser than retina resolution is not really useful for human viewers.

the temporal resolution of human vision is a bit of a tricky question: https://www.100fps.com/how_many_frames_can_humans_see.htm

for what it’s worth, on my 2019 X1 Carbon (4K model), I could detect the PWM flickering with my naked eyes (in some situations) even though it was measured by notebookcheck at 200 Hz

I think my main criterion would be “a GPU that supports some form of adaptive sync with this monitor”

I agree, 1000 hz could also mean that the vsync is inexpensive for the gpu

To be fair, even average gaming mouse have 1000 Hz polling rate

My friend might've made the solution to that https://youtu.be/VvFyOFacljg

The performance of opening JXL hasn't been improved in macOS Sequoia public beta

Can you check to see if it fixes this? https://discord.com/channels/794206087879852103/804324493420920833/1272600654287994992

Never saw that issue with my 10500 * 10500 pixel images on both Sonoma and Sequoia

Above 8-bit?

Oh I didn't have such image

Just in case someone needs large 16-bit jxls. Color space is in the name, size is ~18800x9000

Btw, can anybody tell me why cjxl tells me *libpng warning: iCCP: known incorrect sRGB profile* or *libpng warning: iCCP: profile 'ProPhoto RGB': 0h: PCS illuminant is not D50* on every png file from photoshop?

Photoshop embeds an ICC profile in sRGB pngs but it embeds and incorrect sRGB profile

and libpng devs are aware about it and warns you about it

apparently this bug has been fixed if you update

hi, newbie here i have 1500+ images that all somehow add up to 9GB how would i go about converting these all as a batch

oh ifranview support?

Assuming some are jpegs, I'd suggest using cjxl instead of any other tools

um wait huh

im not seeing that in the git

https://www.mankier.com/1/cjxl

this?

Yeah, here's the file in the github <https://github.com/libjxl/libjxl/blob/main/tools/cjxl_main.cc> and the latest release where you can download it directly https://github.com/libjxl/libjxl/releases/tag/v0.10.3

hold on, i figured out how ifran does it

i'll check this other one later

I'm fairly sure cjxl is the only way to use jpeg transcoding currently, so do test the results before deleting all the originals

use XL Converter, preserve metadata instead of wipe, make sure automatic JPEG recompression is *enabled* (lossless conversion from jpg to jxl) and stick to effort 7 - higher efforts arent worth the slowdown for a few less kilobytes when youre already guaranteed 20% smaller filesize anyway

e7 will have the lossless conversion almost instant. 1500 images should be a few minute's job.

*Assuming they're all jpegs I'd guess there's a lot of PNGs in there too, so they'll be a fair bit slower but still relatively quick

But it also warns about AdobeRGB and both ProPhoto profiles

different warning message

is there no "jpeg transcode" support in the public libjxl api?

I probably would not recommend doing large batch conversions yet, until the lossless encoder gets a "verify" mode

Just to make sure nothing goes wrong without you noticing, like a rare corner case or bug with a particular image input

Currently I don't think there would be any way for you to tell if one of the images became corrupted during conversion. There's no test to make sure the decoded sample/coeff values match the original.

Oops I already transcoded over 15000 images :/

noted

might as well compress it in a 7z

you can manually compare the encoded image to the original (which is what I do)

I'm paranoid about this sort of thing, but it's easy to script it in

it's pretty fatiguing to manually compare thousands of images though... for lossless compression, it would be a good idea to verify first before deleting the original file, to ensure the original data can be recovered.

maybe us as a community should start encoding images in lossless and comparing them in mass to try to find any kind of issues

well by "manual" I mean you aren't doing it within cjxl; I still script it in so it happens automatically when encoding to <:JXL:805850130203934781>

it's kind of a long script but here's the relevant part: ```sh if [ "$(djxl "$sf" - --output_format ppm --quiet | diff -q "$uc" -)" ]; then de fi ```

for jpeg, you could try decoding back to jpeg and checking with diff before deleting the original. and for lossless pixel data like png, you could use a tool to check if the sample values are identical, like vips_equal

Then you can delete the original files with confidence. And it can be done in a scripted, automated way.

yeah, for jpeg it should be even easier

What’s de?

Translate to German?

no, just a simple function that prints an error and dies: ```sh de() { rm "$uc" echo "Recompressed $sx file not the same as the original for file: $se" exit 1 }```

How is uc generated?

well in this script it was with dwebp (as the source images were all lossless WebPs), but it could just as easily be done with imagemagick

I would 100% recommend bulk converting images into jxl format to save space, as long as you are 100% confident in the verification process. If you need help creating a script for converting and verifying, I can help and I'm sure others would be willing to help too.

as long as it's not MS batch, powershell, or python I'm willing to help <:CatSmile:805382488293244929>

Perl?

yeah lol powershell is just needlessly different from literally everything else

😍 I love perl

perl rocks

I’ve been meaning to learn

it's just bash on steroids

Powershell is “we wanted to make Bash but we want to be Microsoft”

and bash is just ksh but slower and with 100% more "i'd like to interject"

IMO fish = oh my zsh - POSIX

powershell uses way too much powershell specific jargon that is completely unique to powershell and not used anywhere else... it feels like I have to learn to speak klingon to use powershell

I'm sure powershell is great but I just don't have the patience when it just looks like it's trying to be different just for the sake of being different

We’re happy over in UNIX land and Windows is like “me have confusing bash knockoff mixed with CMD? “

and instead of typing pwd they would prefer to Spell-It-Out with Weird-Capitalization Like-This

So cool!

feels so modern!

suprised they didn't call it `Microsoft-Power-Shell`

It seems the latest public beta of Sequoia (24A5320a) has fixed it

No glitch in contrast to macOS 14.6.1

TIL. thanks :D

SPEAKING OFF, continuing in <#806898911091753051>

Powershell has many of their Unix/Linux equivalents aliased. Just type alias in powershell lmao

Don't you mean List-Aliases or something like that

No, simply 'alias' will work as well

"alias" is likely aliased to "List-Aliases" lol

guys i back did i miss anything important

not really, just everyone pooping on powershell

Is there any way to indicate the Modular data is using yuv420p/444p? Like an ICC profile? I’m trying to store video frames losslessly

I think, this was discussed somewhere. If I remember correctly, modular cannot be told to proceed explicitly in 420 but will encode the planes losslessly as if they where 444 (with a repeated color in the missing spot? Don't remember, the answer should be added to the FAQ)

various codecs uses different subsampling methods iirc, so it would not be lossless if you keep samples in video frame as is

https://discord.com/channels/794206087879852103/794206170445119489/1261606346092969985

i was planning to upscale the u and v channels to convert it from yuv420p to yuv444p

In non-XYB images, there is a frame header field to denote that the YCbCr transform is used (with 444,422,440, or 420 subsampling). This is used when recompressing JPEGs but can also be used in Modular mode to do lossless yuv. Only limitation is that the ycbcr matrix, range and subsampling siting is fixed (it is the way JPEG does it), so you can't e.g. do tv-range yuv with the chroma siting of h264.

can I store the pixel data as YUV in modular channels and then apply an ICC profile to convert back to RGB? Now that I think about it, i don't need full lossless, can i just use vardct xyz at like d0.3?

If you need a different yuv matrix than the jpeg one, you have to store it as "RGB" with an ICC profile. If it's the jpeg yuv matrix, the libjxl decoder will do the inverse transform...

im probably just going to decode to RGB, is 12 bit precision good enough to be lossless?

is the RGB data stored in JPEG XL gamma encoded? or is it linear?

When using lossless, it is whatever you want it to be.

so whatever the input is?

when you use lossless jxl it disables those transforms

it uses the input space and tags it

I only just looked again, but for some reason I'm missing the newer Lossless Alpha and CICP options. On 5.2.3 and they were added months ago so not sure where they went

Same in the Advanced Export too

it was merged for 5.3, currently available only on nightly builds

Ahh, thanks

Is there no way to use anything other than XYB (or YCbCr) for VarDCT?

You can in principle do VarDCT on RGB. So using a suitable ICC profile, you can use any color space. Also note that XYB is configurable: currently libjxl always uses the default XYB but all the parameters of the transform can also be signaled.

just wondering, has this been submitted to upstream yet?

no, it's kinda hacky, I mean it does work and all. but it may have some unintended side effects

that and mailing lists are a hassle, no chance I would remeber to respond to correspondence lol

it's unlikely to be merged

you'd need to have your own quantization matrices to get any performance out of that -- finding good quantization matrices is time consuming as everything needs to be in a balance, but in a balance that puts weight on the worst case behaviour

so basically it's a bad idea?

it just needs some work -- of course utility of the outcome is a bit unsure, too

i guess this is the benefit of having an extremely expressive bitstream

what is `-e 11`?

Slow

and did literally nothing compared to `-e10` for me

Only -e 10 and -e 11 or did you have other parameters too?

`-d 0 -e 11 -I 100 -g 3 -E 4`

but im not running it again just to test

it took 25 minutes on my M3 Max with a 1024 x 1024 image

-e11 saves some bytes from time to time over -e10, but time required for image larger than few KB makes it an instument of curiosity

Is it basically my idea of “try every possible valid bitstream”?

I'm also not sure if using `-I 100 -g 3 -E 4` might disable some of it's searches

I generally stick to 128x128 or less when trying it

Isn’t that what you’re meant to add for better compression?

Normally yeah, but when it's trying to test everything, forcing it into specifics means it might not try the 'correct' combo

I've had cases where `-g 2` was best, or `-I 74` in one instance

hello 👋

I'm trying to create my own android app (using java) and I want it to be able to read and display images stored on my phone I tried to use this java implementation of jpgxl here https://www.reddit.com/r/jpegxl/comments/zb1hvn/standalone_jpeg_xl_decoder_written_in_pure_java/ but something about the jar file causes the the build process to fail even though it works fine in an eclipse project in windows. Is here anyone who knows how to integrate libxl in a java android studio project or how to resolve my jxlatte.jar - gradle build issue?

I would probably make a ticket on the git repo for that myself, but seeing as you are here, <@853026420792360980> is the dev for it, and would be the person to ask

<#1042307875898408960> may have some info too

Got another round of simple color testing https://saklistudio.com/miniblog/modern-image-format-linear-color-analysis/ (along with some comparisons)

There are libraries that exist for that if you want, such as https://github.com/awxkee/jxl-coder or https://github.com/oupson/jxlviewer

thank you I'll take a look at them.

"Causes the build process to fail" what do you mean?

gradle is crashing with some internal exceptions when i add the jar. but i just tested it with a fesh empty project and there it doesn't crash. so it seems like whatever is happening was caused by something i did I'm now trying to figure out why this is happening

i should have tested it with an empty project before asking here. sorry about that

<@853026420792360980> after updating some plugins, invalidating the cache, multiple restart of adroid studio and removing/adding it is now suddenly working 🎉 but now I'm not sure how to get the image information out of the JXLImage object because java.awt that contains the BufferedImage class is not available on android so i can not use asBufferedImage() is there another way?

It tries 432 setting combinations: ```-d 0 -e 10 -P !,0 -E 4 -I 100 -g !,0,3 --modular_palette_colors !,0,70000 -X !,0 -Y !,0 --patches !,0 --wp_tree_mode !,2 -d 0 -e 10 -P !,0 -E 4 -I 0 -g !,0,3 --modular_palette_colors !,0,70000 -X !,0 -Y !,0 --patches !,0``` Read `-g !,0,3` as trying each of `-g -1`, `-g 0`, and `-g 3`. Notice tree mode is not actually exposed to the CLI, so it is possible e11 achieves something otherwise inaccessible. e10E4g3I100 is very effective in general, and e11 will often pick this combination or equivalent, in which case nothing is gained. In e11E4g3I100, those specific settings are overwritten when traversing all combinations above.

If java.awt isn't present at all, then you can't. I didn't realize some java dustributions were missing that core package, so ill need to do some refactoring

I use java.awt.Dimension in a few places too so those classes will fail to load

My work schedule dies down a bit after this week so I'm going to start a few major codebase refactorings based on performance soon

Unexpected. JXL increased the filesize of some jpegs

how were they encoded? just with `cjxl in.jpg out.jxl`?

Only java.awt.font is present in Android, as I can see. Have never used it though

This should basically never happen with lossless jpeg transcoding

use the jpg->jxl reversible transcode. all full conversions to ANY format normally results in either huge lossless output or a worse image that does not even guarantee lower filesize unless you sacrifice even more quality

xl converter added lossless transcode for jxl when jpgs are source but its disabled by default for no reason. with it enabled, conversions are hyper quick

note that if you used ffmpeg or imsgemagick something similar, you wouldn't be doing a lossless transcose

it would be decoding to pixels and encoding those pixels

which isn't what you want

`magick`. Is it wrong?

imagemagick won't do that

use cjxl

imagemagick is doing a decode to pixels and then encoding that pixel buffer

you can check with magick compare that the images are different

i find it incredible that jpgXL is able to losslessly recompress jpg images and make them 20% smaller

that alone make it quite usefull for backups

Alright there. Much better

Every file shrunk in size

Now to wait for browsers to support it

> 2 years ago > jpegxl is only compiled in on nightly. the pref has no effect on beta or release. Why firefox?

maybe google put pressure on them

I doubt it

mozilla's releases of firefox are the issue. some rebuilds and derivatives like floorp and waterfox support jxl out of the box and even better than firefox nightly using patches that were handed out to mozilla for free

I've never even considered using alternate builds of firefox 🤔

are there other good reasons to try them out?

specific optimisations or different defaults, extra patches. its not forks or derivatives by any definition, what we once called 3rd party builds or unofficial compiles

openmandriva's firefox supports jxl, fedora has a copr that swaps regular ff with the jxl enabled build

waterfox seems a bit faster then firefox does on my systems

threadripper would be quite nice right now 🙃

what parameters and source format are you using?

all jpg images to jxl with lossless recompression

odd my gettho ryzen crushes conversions. are you using effort 6-7? in regard to jpg->jxl conversions you already significantly lower filesize and a few less kilobytes might not be worth the trouble of drastically longer jobs with higher values than 6

I'm only using 3 cores for the conversion and it doesn't really matter how long it takes

just to make sure, its reconstructible? lossless jxl smaller than the source jpg

it should be 🤷‍♂️ when I'm done converting to jxl I'll reconstruct them all and compare the file size to my original

afaik its not possible if a full decode+conversion was done. better check the images that already completed

well i set it to lossless recompression so i should be able to restore the original files

what effort? anything higher than 7 multiplies the total duration for really negligible gain. asking since its a huge conversion

9 but what does effort even do?

uses more tools and more exhaustive checks to get more compression at the expense of encoding time

try harder to shrink filesize or hit the target filesize. with lossless files get even smaller, with lossy images look better for any determined filesize OR files are larger for the same quality

with lossless recon even effort3 should be smaller than jpg yet like 50x quicker than e9

well my main goal is to make it as small as possible for long term backups

For the lossless mode of jxl, the higher the effort the more time the encoder spends trying to losslessly optimize the image to take up less file space. In my experience, jpeg transcoding higher than effort 7 (the default) is kind of a waste of time. You only see files shrink by about 0.5-1% more and it takes 10-20 times as long to compress

If you're happy with waiting a literal week to get 1% more compression I won't stop you

I've thrown jpg files at paq8 compression programms for far smaller gains just to see what the limit is

<:kekw:808717074305122316>

my CPU consumes in idle 30w but if i limit it to 3.3GHz it also just consumes 30w up to about 30% utilization so from that point of view i have a certain amount calculation power that doesn't cost extra and is just wasted if not used and there are certain situations where you just have a certain amount of space available and just can't go above it for example you can't upgrade your internal phone storage and even if your phone has a microsd slot 2TB will always be the hard limit of what you can add because the SDXC standard that current phones support (well if they have an sdcard slot at all)

out of curiosity, what kind of images are you converting? photographs, colored/greyscale comics?

<:ReeCat:806087208678588437>

sometimes av1 preset 0 with crf 63 seems insufficient

is there any way to get the image comparison slider that works with jxl that runs offline?

like squoosh?

but the experience with paq8px shows that time also matters. and decoding time... and the decoding time of 32k x 32k jpeg xl does not suit me.

<:JXL:805850130203934781>

shouldn't it tiled decode?

it's still infinitely long and rip ram

many anime/manga style images all colored but also every images that i have ever taken with my phones or that i have send/recieved on whatapp, scanned documents. everything i can find

is jxl much better at compressing certain types of images?

we talking about lossless?

all i do is lossless recompression so far but I'm also curious about the others

in terms of percentage the best improvement I've seen is a 100% white image that went from 4864 bytes to 484 bytes

this is lossless JPEG recompression?

yes

1 color images are not that relevant but still interesting to see

🤔 not really sure then, I haven't done enough of that, but the gains result from better entropy encoding

I imagine low BPP benefits more from that (in terms of % saved), but like I said, I haven't tested it

BPP stands for?

bits per pixel

Compressed metadata also helps

is lossless recompressing also preserving all image metadata too?

it should

xl converter defaults to wiping metadata unless you choose to preserve it iinm

wait, it does?

metadata 'encoder - wipe'

found it

oh, XL converter is a front end; I was thinking about cjxl 😅

well not a bad thing for me I've never needed any of this

how do you plan to consume the jxls afterwards? wondering what viewers or server software people use

mmh if i use them for anything other than backups it will probably be 100% personal use where i have 100% control over the software

it wouldn't make sense to share an image with others when they probably can't use it without converting it back

reconstructible jpg->jxl seems can be decoded as either format almost instantly

anything under 12megapixels blitzes here at like 40 milliseconds, almost realtime

if i want to view the jxl files on my PC right now i havbe to open them in gimp mspaint or my image viewer don't know what to do with the files

we really need viewers that do this kind of decoding, would help adoption big time

This kind of decoding?

xnviewmp handles jxl fine. some comic viewers as long as the right dll is added

mmh this progressive decoding feature of jxl means that you can already display a burry version even if the file is not 100% loaded correct?

for reconstructible jpgs, i was under the impression the goal was not only for it to cover conversions with permanent storage of the output, but realtime conversions by web services, cdns and image viewers so any browser or gallery app that lacks jxl still decodes the jpg-encoded jxls just fine

more so downloaded rather then loaded as in cases of local viewing it's probably better to just load the whole image rather then load in steps

jxl is always progressive. you can make it *extra* progressive. however some software may not load images progressively

well lossy and jpg transcodes are but not lossless images

so it probably doesn't make sense to do the progressive loading on an android app that reads from an sdcard. i wonder how the code for that would even look like. for fully loaded images i call whatever function decodes the image and just use the return value to make a bitmap out of it. how would a partial loading work?

I mean if the data/storage access is slow and you are able to work with partial data as it's streamed in from said slow storage then progressive decoding would probably make sense

as for how to do that on android, uh I don't have the required know how for that

i think whats slowing image loading down most is that i have to do individual file access and not the actual reading process if I'm right about that then packing like 20 images together in a zip file and just keep that in memory would probably boot performance much more than any partial loading

progressive load makes even more sense on slow media but i think the long accepted norm is to have images completely decode or serve their integrated thumbnail before decoding the next image

it's weird how cjxl does significantly better than cwebp on some pixel art images, and way, way worse on others

like on windows with color management, projects have stuck with old default choices and not revisited em post-jxl (assuming devs even are aware of whats possible now)

I'm annoyed that that i need to convert images to .ico if i want to use them as windows folder icons

there is no other use case for these ico files that i know of

iirc they are also used for website favicons

one think that i personally don't like about webp and jxl is that there are so many types of internal encodings combined under one name

if i see a .jpg file o know it's lossy compressen and when i see a .png file i know it's lossless

and .gif is always animated. but with jxl webp and other container formats i have no idea what I'm dealing with