JPEG XL

For reference (since it can be annoying to find specific topics in a broad AMA reddit thread), here are the three questions that were asked on JXL: https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8g0hqx/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8fp95c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8frw87/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Nope, yota-code... I contributed on this one https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8fp95c/ and, at the end, got a bad excuse too

That would be me. Unfortunately not surprised by their response but I agree that I'd be much more accepting of a more honest "nobody cares what Firefox does so why bother doing anything until Chromium forces our hand" type answer.

firefox cant directly say that since the only reason firefox has any significant market share is because it "prevents the chrome monopoly from dictating the future of the web"

(which is a lie)

when you fear your bs debunked with hard facts and numbers, retreat into silence

Sorry, maybe I should have stripped those. Though they don't seem to contain much info...

Not sure if this has been posted elsewhere: https://gregbenzphotography.com/lightroom-acr/shrink-your-raw-files-with-compressed-dng/

Is there an option for this not using Lightroom?

https://helpx.adobe.com/uk/camera-raw/digital-negative.html

DNG Converter

High-fidelity lossy "raw" is I think a great application of jxl. Good to see there's an article about it!

Never understood the idea of lossy raw. Even converting proprietary raw to lossless dng is not acceptable for me 🤷‍♂️

The fact lossless compression is not available is a problem in the interface of the converter? Or does the dng spec mandates lossy

DNG can be lossless, of course

Also with jxl

i guess it might be slower to process?

But having an intermediate option between a JPEG and a lossless raw is nice imo. For a lot of use cases, you don't really need lossless, but you do need something with more precision than JPEG can bring.

Depends on the effort used. At e1 it can be faster than lossy.

I do photos as hobby and I hate large raws and especially large tiffs after editing. So this would be awesome. So much freed space.

is e1 any good at compression though?

would it be better than JPEG-LS?

Good question. A lot better than uncompressed in any case.

what about decoding, that is also a big factor when it comes to using these kinds of codecs

Btw, does jxl act like raw in this case so you can still change white balance? I know that in jpeg it's baked in.

also remember that lots of RAW formats haven't been debayered, so it's storing a weird checkerboard greyscale file

probably depends on the specific implementation of RAW

if JPEG XL is used in lossless mode, it by definition is the same thing

no matter what options used

if you debayer a raw you increase the size by 3, that's why raw formats typically don't de-bayer.

that would make sense

but could you theoretically split the file into 4 subchannels to increase some kind of correlation like each image is 1/4 of the original size, but only contains 1 part of the bayer pattern ``` R G G B ``` becomes a channel with just `R`, 2 channels with just `G`, and a channel with just `B`

i just had the idea, there's probably a sensible reason on why that's stupid

I think they do this or something similar for lossless compression of some raw formats

I believe this is the only valid option, because compression of bayer data treated as one single image would be terrible (500% zoom)

you technically would not have to store the colors, just the grayscale data, and the actual colors could be interpreted via metadata or something similar

It is just presentation. I mean this mosaic, for compression it is like hard 1-pixel frequency noise

The same in grayscale presentation

yeah, doesn't look great for compression

And of course lossy compression of bayer data as one image would produce terrible color shifts throughout the image

It would be interesting if someone made a mosaic with a similar semi-random-seeming pattern as the cone cells in the human eye.

Blue noise pattern mosaic

would probably suck at compression, as you would then have to enode the mosaic matrix

unless it was procedually generated or previously agreed-upon

You can set lossless JXL along with distance and effort in the command line version I linked

That was actually added into the JXL spec. There's extra channels to store the extra green and then use an average of the two for a preview, since it's back to RGB then

> kCFA 5 Channel used to represent Colour Filter Array data (Bayer mosaic)

I'm trying to test this, but god Adobe are awful with this command line. The parameters are case sensitive, order dependent and seem to override each other with the only documentation being examples that don't work

On the plus side, while fighting the command line I ended up fixing my DNG files changing exposure on conversion

I have a bunch of CR2 files, could I turn them into DNG and expect a file size shrink?

Yes, but difference between old lossless dng and lossless jxl dng would be marginal in most cases according to my tests. Maybe Adobe can tweak it, but when I tested - size difference was small

Compared to my uncompressed source DNGs, JXL reaches 77% compression, and the old lossless with full compatibility is roughly 70%, or in terms of improvement 22.5 MB, 6.67 MB, 5.25 MB respectively. Final filesize is 20% smaller with JXL Unfortunately the effort setting does nothing, so I can't test effort 1 or 9

In my tests difference was much smaller, like 90 MB vs 85, old and jxl respectively

Not sure if it is caused by difference in 'bits', your is likely 10-12, and my - 16

I assume DNG uses 4 separate channels or separate codestreams to encode bayer data losslessly? I would expect effort 3 to work well on that.

For lossy the only thing that makes sense is to debayer and do the basic color balancing to make it make sense as an RGB image. But you can use as wide a gamut as you want, as much dynamic range as you want, and as much precision as you want, leaving room for all kinds of color adjustments without blowing up artifacts

```JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 672x752, (possibly) lossless, 16-bit Grayscale Color space: Grayscale, D65, Linear transfer function, rendering intent: Perceptual``` Looks like separate codestreams, and still in TIFF tiles ```[SubIFD] JXLDistance : 0 [SubIFD] JXLEffort : 7 [SubIFD] JXLDecodeSpeed : 4``` They also store the encoding parameters inside the metadata

```[SubIFD1] JXLDistance : 2 [SubIFD1] JXLEffort : 7 [SubIFD1] JXLDecodeSpeed : 4``` The JXL preview file has it too

interesting, effort 7 and decodespeed 4

672x752, ugh that's not a very optimal tile size for the default 256x256 groups...

Probably better compression can be achieved if instead of encoding it as single-channel codestreams, it would be encoded as a 4-channel codestream. Then again probably our usual RCTs don't work very well on RGBG data, since the usual RCTs are based on the assumption that grays have R=G=B, which is not the case here...

They could do 4 channel, they could match group sizes, they could use lower effort instead of decode speed (Or make the effort parameter work at all)...

effort 3, default decodespeed is probably faster to decode, certainly faster to encode, and probably compresses the same

I dunno if DNG allows storing multiple channels in the same codestream or if that requires spec changes in the DNG spec

The dng spec owner never asked you, the devs, to help them design an efficient addition to the spec?

<https://helpx.adobe.com/uk/camera-raw/digital-negative.html#resources> > DNG is an extension of the TIFF 6.0 format. It's essentially just a TIFF file with extra metadata

> JPEG XL compression is allowed for N-bit integer image data, where 8 ≤ N ≤ 16, and 16-bit floating point image data. The number of images planes must be either 1 or 3. So they made it spec that JXL can only have 1 or 3 planes > JPEG XL supports two types of bitstreams: > > • A “bare” format with no metadata > • A “container” format that uses the ISO Base Media File Format box structure with optional metadata > > Both types of JPEG XL bitstreams are supported in DNG. > When using JPEG XL with multiple tiles, it is recommended to use the bare format, because each compressed tile will be slightly smaller, and per-tile metadata is not required And also went against their own advice of using bare streams in tiled mode

https://free.com.tw/imgto-xyz/

And this https://imgto.xyz supports JXL

oops

I tested it with cjxl : ```cjxl -d 0 8stycfrzk69b1.png 8stycfrzk69b1.jxl JPEG XL encoder v0.10.2 38dcd185 [AVX2] Encoding [Modular, lossless, effort: 7] Compressed to 4613.7 kB (1.645 bpp). 4144 x 5416, 2.586 MP/s [2.59, 2.59], , 1 reps, 4 threads. ```

almost twice smaller

with only default options

oxipng: ```oxipng -v C:\8stycfrzk69b1.png Processing: C:\8stycfrzk69b1.png 4144x5416 pixels, PNG format 8-bit RGB + Alpha, non-interlaced IDAT size = 8102331 bytes File size = 8103864 bytes Transformed image to 8-bit RGB, non-interlaced Trying: Entropy Found better combination: zc = 11 f = Entropy 6956385 bytes IDAT size = 6956385 bytes (1145946 bytes decrease) file size = 6956442 bytes (1147422 bytes = 14.16% decrease) 6956442 bytes (14.16% smaller): C:\8stycfrzk69b1.png ```

It's not even using oxipng smh major skill issue 🥱

https://github.com/cloudinary-community/imgto.xyz

<@171381182640947200> posted it in <#794206170445119489> first, and it just popped up in <#805722506517807104>, but should be here if anywhere https://www.youtube.com/watch?v=FlWjf8asI4Y

I do wonder if we'll end up with some new members from the video, since most of the comments seem to be about wanting JXL support (back) or finding out about progressive decoding and wanting to learn more

imo lossless reversible jpg-jxl conversions are the biggest deal. with all other formats, lossless conversions consistently result in much larger converted files and lossy in quality loss without guaranteed smaller filesize

that conversion is an almost instant process too (less than 30 milliseconds), whereas a conversion to any other format would in compareason take forever and be impossible to do on the fly or without consuming ton of energy

a weak server could complete a web service's conversion in a fraction of the time, cost and nrg. odd this isnt more known

still can't help myself when the Chromium guys claimed AVIF being faster than JPEG XL, lol in 100% of the cases, JPEG XL takes a teeny tiny fraction of time required by AVIF

this isn't true, on lots of hardware images can decode a lot faster with avif

ofc the image itself and the encode settings matter

... hardware acceleration is required for performance, where other image formats don't need?

is that really "faster"?

hardware acceleration is not required for performance. Dav1d often performs better then JXL does when the file is encoded with I what I would call "normal" encode settings. and once when you limit yourself to 1-4 threads of decoding dav1d often decodes images faster then djxl or jxl-oxide does

also, for some reason djxl doesn't get optimized very well with android's scheduler for some reason, not sure why, but when you get big little cores, I found djxl to get punished unusually hard

guess dav1d is really something then... though I'm still not using AVIF to encode stuff with the abysmal performance of libaom

To be honest, I don't think image decoding is the most significant contribution to the overall slowness of web pages.

it is if you are loading 20+ at a time, or large ones like https://dolphin-emu.org/m/user/blog/progress-report/2016-november/windwaker35xnative.jpg

Booru sites:

but decode speed is very significant for stuff like local galleries too, including comic viewers.

For local archive, I would use either lossless format or preserve the original format.

I mainly consume written/drawn media on my phone, so I keep originals on my portable hdd, and transcoded versions on my phone

hardly known but hw acceleration adds latency, thats why almost all implementations for jpg are done in software

Im not sure hardly known is the right word but I suppose

couple months ago i recall someone tested thumbnailing with multiple formats, everything but avif loaded really fast. sub 300ms each compared to 15+ seconds for avifs

shame i couldnt find the discussion again

it would depend a lot on ofc, what decoder is actually doing.

especially considering that for some reason, libgav1 is still used in cases

My GPU can barely do HEVC, only 4:2:0, and no AV1 at all, so no HW acceleration for me. Too bad format support can't be added to older GPUs, that are otherwise perfectly fine.

in theory, parts of av1 decoding can get offloaded to gpu, currently this is limited to grainsynth, though this ofc isn't asic and would increase energy consumption as gpu compute is not super cheap

For lossy, I think the decode speeds of all image formats are all more or less in the same ballpark. In encode speed there is more variation...

libjxl has great threading so on most modern devices, assuming it has unrestricted access to threads, it will usually be quite good, however since that's not always the case, avif can often out perform it, especially if you are only using 1-2 threads I found

let’s not forget, though, that especially if decoding is limited by network speed anyway, jxl’s better progressiveness likely means that you’ll get some visible content sooner nonetheless

indeed, it would be nice to have some better low thread perf tho, especially for older hardware

There's a lot of room for improvement still with threading

Lots of wasted cpu time compared to single thread

If you have a lot of files to convert, it's much less CPU time and thus much less real time if you utilize only 1 thread per image and convert multiple images in parallel

I know I'm late to reply to this but I just wanna point out that the timing he presents in the video of between when the AVIF team tests came out and when JXL support was removed from Chrome is wrong/off. JXL was announced as getting removed from Chrome and then a month or two later the AVIF team tests came into existence.

Is he well known? Why the hell is he doing a video wearing Spiderman tights?

This was the most disturbing part, given the camera angle

Kinda, his main channel has a little over 1 million subscribers

Mostly known for CSGO videos on his main channel, but does more technical exploration and tests on his second channel such as video and image codecs Tends to get a few hundred thousand views per video, with that one hitting 220K in 1 day

https://issues.chromium.org/issues/40168998 the "reconsider jxl in chrome" issue is very active lately. Last blow : libjxl decoding is not energy efficient enough, that's why 🤦‍♂️

not wrong, you see, adding JXL would cause developers to merge some patches, and that expends developer energy, not very efficient

[av1_galaxy_brain](https://cdn.discordapp.com/emojis/657649371038482482.webp?size=48&quality=lossless&name=av1_galaxy_brain)

half of jxl is jxl modular

and jxl modular is the slowest image format ever

so they were never wrong

> I follow their Github releases and test new versions when available, although recently there have been breaking changes and some missing artefacts in some of the archives they put out, which is to be expected with pre-release versions. 🙄

The lack of understanding is negatively correlated with the mouth opening

they're joking, right? dav1d not in consideration, AV1 is by far the worst performer not sure what libvips is using for AV1 decoding, but when libvips decodes way faster than davif (libaom), it's still behind libjxl

as I said before, is that really "energy efficient" if you need hardware-accelerated decoding, when the alternative (that being JXL) doesn't even need that?

« mieux vaut se taire et passer pour un con… »

And if I read this well https://www.reddit.com/r/AV1/comments/jz6hkh/can_av1_hardware_decoding_be_used_for_avif/ hw acceleration for avif is not desirable nor feasible

HW decoders are not very reliable either.

yea, spinning up a hardware decoder for a single frame is usually not worth it compared to decoding in software this is why chrome doesn't do it even if a hardware av1 decoder is available, and just uses dav1d for avif. it makes sense to do it the way they do it

So, for real, how do they (the chromium team) claim jxl decoding is slow compared to avif? What is the catch?

they catch is that avifs decode faster the lower quality they are (unlike jxl, which has relatively constant decode speed regardless of vardct quality), and they ran their tests on ultra-low-quality AVIFs (unsuably low, like probably libjpeg-turbo q=35 equivalent), and then used that flawed methodology to claim that avif was a faster image format than jpeg xl

Thanks for the explanation

> All current computer GPUs and most mobile ones support AV1 hardware decoding That isn't utilized 😭 lmao

And current doesn't mean fully adopted

also something else to point out is not all AVIF files are even hardware decodable in the first place. want a 12-bit image? no hardware decode, want to use a chomra sub-sampling value of 4:2:2? no hardware decode.

about claims jxl is slow in the chromium issue, I wonder if the (likely flawed) method used even works - in a different discord, a hater thought he was diligently testing new libjxl releases while his machine was actually endlessly compressing using 0.7.0 (some issue with paths or linkage, supposedly obtaining libjxl through scoop or similar doesnt update ). bro saw the light as soon as he checked 0.10 for real. odd this happened to even someone as experienced. maybe theres flawed or outdated documentation floating around?

about issue; the nrg consumption of jpg->jxl conversions is extremely small (less than 30ms for anything below 20megapixels, tested on a weak ryzen 2600 - so low a cdn can generate and cache new jxls on the fly without raising their compute costs) , and avif is only capable of lossless conversion at the cost of massive nrg use and bloated increased filesize whereas jxl guarantees a consistent 20% lower filesize

I think the russians would have something to say about that

Or even the extremely common case of 4:4:4

Also there IS a rust port of the decoder... Thanks tirr

it's not a port, it is it's own from scratch implementation

Idk who this mo...@gmail.com is or why people even need to respond to him. He is throwing out a red herring by mentioning hardware decoding that AVIF doesn't even benefit from. It's just ragebait

Calling people conspiracy theorists etc

Yes, I suppose calling it a port could be misinterpreted.

I didn't mean to imply that it's based off libjxl

...yeah, he seems to be just some random guy. With a random gmail. Just throwing his irrelevant opinion out there for people to rage over red herrings... instead of crucial points like how Google's own AVIF test they published and their own graphs show JXL destroying AVIF

it's just a random gmail account, pretty much anyone can comment on the issue tracker

also btw the issue tracker censors full emails hence why there are 3 dots after "mo"

The study the avif team performed and used as justification, shows jxl eating avif for lunch. Their own graphs on their own page...

I can't believe no one talks about this more because wb is STILL waiting for the avif team to respond to his email!

He was the first person to point out that their own comparison shows jxl winning and they still haven't responded to that or explained why their own graphs show that

How can they use it to justify it when it shows the opposite of what they say and their own graphs prove themselves wrong?

imo case studies should show how massive the savings would be going with jxl, especially after datacenter compute costs rose significantly. jpg->jxl is almost instant, an image host like photobucket and flickr could losslessly convert everything they have in 2 weeks

its information scattered over the web and much of it is locked behind discord that cant even be read without creating an account

some centralization would help supporters produce relevant information whenever they need it whatever the use cases

https://storage.googleapis.com/avif-comparison/Kodak.html

Their own comparison contradicts them... and there's still articles online saying "avif team posted a comparison showing avif is better" but that's not even what it shows... it's outrageous

If you just follow a link or two on their main page to see the detailed results it's utterly laughable how they could look at these results and say avif won

https://storage.googleapis.com/avif-comparison/images/Kodak/rateplots/Kodak_avif-jxl_t-1_avif-s3_jxl-s9_ssimulacra2__bpp-0.1-3.0.png

This is their own graph. Avif only wins at ssimu2 less than 60

But they call this an avif overall victory because they average qualities all the way down to 0 and less for avif even though no one would ever use that image

I kid you not, this specific graph, they say avif is winning by 7.32% because of how they averaged in the useless-quality images

jxl displays images while avif hasnt even finished downloading half

that alone could be huge with browsers and proxies if they had some 'dont load images completely' bandwidth saving optimization

It's consistent across all of their graphs. ssimu2 quality 60 and below is where avif overtakes jxl. None of their graphs show avif winning if your target quality is higher than 60

Progressive rendering and legacy transition of old JPEGs are the two biggest impact, non negotiable features. Plus I have a feeling that jxl has more room for improvement than avif

discarding a lot of detail so your algos dont malfunction is hardly a win. libjxl preserving more detail for all filesize target levels is a win for imaging

different codecs or builds can focus on discarding more detail or other optimizations

but thats not a limitation of jxl the format itself, just how its implemented in upstream's libjxl

There are more tools for a future lossy encoder to take advantage of. A lot of untapped potential. Noise detection. Image decomposition. Hybrid wavelet/dct/spline layers with noise generation

something I noitced about the AVIF team tests is that they define 4:2:0 chroma for all the AVIFs and pass in `--progressive` into libjxl for all the JXLs, which uh seems very unfair

anytime caught, do the usual: dont respond, pretend to have heard nothing or close the discussion

they actively don't care about progressive decoding yet pass into libjxl the option that makes images even more progressive at the expense of file size

in the test? are you sure?

https://storage.googleapis.com/avif-comparison/verification-process.html#JPEG-XL-Running

ohh apparently they just did what I described only for the decode speed tests? https://storage.googleapis.com/avif-comparison/decode-timing.html

bruuuuuhhhhh these people

oh wait they have different test runs done both with and without the progressive libjxl option, guess I miss saw the page when I looked at it yesterday

I thought they *only* did it with the libjxl `--progressive` option. apologies

I like how they didnt specify threads in the jxl decode,

oh wait, those are encode threads [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

does anyone have a function "decode benchmark" page? could be neat to point users to

ah yes i found out about this format thanks to him lol

what are the requirements for that test? might just build one out of `derpi-image-corpus`

currently only have a quality to time spent decoding curve in mind

for a decode benchmark quality probably doesn't really matter, the issue is managing to keep the encode things somewhat in comparison to eachother, for instance libaom vs svtav1, svtav1 has a fast decode which can help a lot cjxl has faster_decoding which can also help, vardct vs modular, threads, etc

quality might be a factor in AVIF's case though: https://discord.com/channels/794206087879852103/822105409312653333/1272963187591090317

that's true to an extent, but the encoding bits and bobs that are use is a more important factor, it just so happens that high quality encodes use more bits and bobs, but those can actually be turned off, which is what svt's fast decode does

also libvips decodes AVIF images quite fast compared to davif

yeah, in general avif is actually really fast to decode because dav1d, the underlying library, has a LOT of optimizations for most platforms

davif has been dead for like, 2 years now iirc

to benchmark avif you can use `avifdec --jobs 1 --info FILE-Here >> /dev/null` I don't know why they use -i but it is what it is `-i,--info : Decode all frames and display all image information instead of saving to disk`

BD rates are computed only for the range covered by both codecs, so not only do they overrepresent the uselessly low qualities, also the high qualities are just not included at all because they use yuv420 for avif, so avif saturates at something like ssimu2=84 which means that for the BD rate computation, performance at qualities higher than that just doesn't matter. This is one of the major perversions of comparing codecs using Bjøntegaard Delta rates: encoders that just cannot produce high quality at all are not punished in any way for that, they just get compared only in the range they can produce.

If we would make a version of cjxl that just doesn't produce any output for d>4, it would suddenly magically perform much better than the normal cjxl, at least when compared according to the methodology used by the avif team (BD rates).

To call that graph a "7.32% victory for avif" when the graph clearly shows that AVIF only wins literally right at the point after which the quality line falls off a cliff and right into the unuseable range, is the most preposterous part of them using this comparison to justify their decision. They still haven't responded to your feedback about this, pretending as if they haven't heard a thing so it gets memory-holed

maybe not a bad idea... <:KekDog:805390049033191445>

But another funny thing about their comparison is they are only using metric graphs instead of side by side comparisons. They only show side by side comparisons for a few images.

which is important for getting rid of utter nonsense and insanity when doing comparisons like this

https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png-s-6_0.93bpp.avif

https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png

https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png-s-7_0.93bpp.jxl.png

From their subset1 comparison page...

Both avif and jxl have severe color distortion but I think avif is significantly worse here... (sorry edit)

Again, this is the avif team's comparison. They think this shows avif is winning.

This is what they used to justify removing jxl

it's so absurd that I can't believe it's real

lol, discord doesn't even generate thumbnails for avif images...

At some relatively low quality point, around d3.5, the lower end of what can be called "web quality" and the point that some bandwidth-focused webperf folks would recommend to use to "optimize" a website, AVIF and JXL are roughly equivalent. So if you only care about that quality point, there is an argument to be made to say we don't need JXL if we already have AVIF. You could also make the argument the other way around (we don't need AVIF if we already have JXL), but AVIF was first — I don't really get how that aspect of timing matters much in the long term though, since the difference in timing is not large (it's not like AVIF is so well-established already that you would break the web if you stop supporting it). My main frustration is that the range of qualities relevant for the web is broader than just this specific low quality point, and also includes higher qualities like d2.5, d2, d1.5 and even d1. For some use cases even lossless is useful on the web (and not just for nonphoto images where lossless is just smaller than lossy). To me it feels very paternalistic and arrogant for browser devs to dictate (even if just implicitly, through the assumptions they make when assessing which codecs to support) what qualities are relevant for the web.

I think libaom has had some very significant tuning very recently, and looks a lot better today than it did back then. it compares much more favorably now today...

It is to be expected that encoders will still improve over time, especially for codecs that are widely supported.

But of course it's shocking that the avif team would promote their own format by abusing their influence over the chromium project and unilaterally sabotaging software support while gaslighting everyone and saying "the community has spoken"

"This is not the avif you're looking for. Move along."

the AVIF team when they see the JPEG XL encoder also making improvements

I think JXL has a lot more untapped potential than avif does...

yeah, only thing is actually tapping ito that potential will take some ingenuity and dev time

(and possibly sacrifices to encoding speed, although that chould be mitigated with autodetection of whether certain features will be helpful for certain images)

Yep and it might make encoding/decoding slower depending on what techniques are used

Anything that involves image decomposition will probably have a big effect on performance.

maybe make new effort settings? (`-e 42069` for ultra-omega-tiny encoding but don't expect the encode to finish in your lifetime or any of your children's lifetime)

avif does have a lot of untapped potential though

Even JPEG still has untapped potential.

WebP, J2K, JPEG XR, they all have a lot of untapped potential too. The main thing is that nobody is going to spend a lot of time on tweaking encoders for formats that are not very ubiquitously supported.

So to some extent, there is an element to self-fulfilling prophecy. If major platforms don't support a codec, then it becomes less likely that good encoders for that codec will be developed.

For jxl we currently still have only one encoder, really. We are basically where jpeg was before libjpeg-turbo, when there was only really the IJG libjpeg. Time will tell if we will at some point also get a libjxl-turbo, mozjxl and jxlli 🙂

Recently google was pronounced illegal monopoly in US court... And tbh, being able to single handedly decide about adoption of format on the entire internet seems something only monopoly could do

I've mentioned this before, but since they've been designated a Gatekeeper in the EU, might be possible to force them to support it, since they're causing harm by forcing us to deliver more bits than necessary. Not only that, penalizing sites that don't use webp in SEO… https://ec.europa.eu/commission/presscorner/detail/en/ip_23_4328

I love how the us government declared them a monopoly as if they weren't the ones who made it so by giving them tons of government contracts...

"And now that you're a monopoly, exactly as we intended, we're going to use that as an excuse to control and threaten you even more rather than actually take away your (our) power."

what are you talking about?

If the government didn't want google to become a monopoly they wouldn't have given them tons of money and contracts.

It's just a funny and hypocritical behavior pattern

they really couldn't and didn't. My sister is on IOS and actually has saved some JXL images.

I'm pretty sure certain parts of the government wanted them to become a monopoly in the first place. Like the intelligence agencies.

Until Apple decides maintaining webkit is too much work and switches to chromium...

they would probably just support the jxl patchset

what money and contracts specifically?

apple will never do this

Can't be bothered to look it up right now when it's been so long ago since I just stopped caring about things outside of my control.

But like every other giant successful multinational conglomerate, the line between Google and the government is pretty blurry

The reason why government exists in the first place is to make it simpler to consolidate everything

When I searched for "early sources of Google funding" this is one of the first things I get on ddg: https://qz.com/1145669/googles-true-origin-partly-lies-in-cia-and-nsa-research-grants-for-mass-surveillance

Seems like a pretty detailed article if you're... truly curious. I kinda doubt your sincerity though.

I hope you're right but I'm not an optimist when it comes to big tech

<:JXL:805850130203934781> mentioned: https://youtu.be/RFWJM8JMXBs?t=1075

I still didn't deliver VMX vectorized version for PPC32

ANS explained. It seems to make Jarek happy. I'm happy too.

I think not -- I believe it needs a new entropy coder to perform properly in high quality

I watched first half of this video and it is well made, worth watching if one has interest in compression -- it is more textbooky than incorporating all modern 'ahas' of compression, but still ok

yeah, it's a good description of how it works, but it has a click-baity title and barely scratches the surface of the patent issues plaguing modern compression formats

though I suppose one could apply the latter criticism to many textbooks as well

but in medium-high to low fidelity, there's room to grow. JXL (imo) has the edge in high fidelity forever

Another overview of <:JXL:805850130203934781> in Russian https://habr.com/ru/companies/ruvds/articles/835150/

A bit strange statement about decoding speed where jxl is behind avif, but in general - nice article

AVIF decodes faster the lower the quality. In JXL the decode speed of VarDCT mode is more constant regardless of quality. Also they have somewhat different parallelization behavior. So for speed measurements it depends a lot on what exactly you're comparing.

(assuming you're measuring it correctly, some people measure djxl speed by timing the whole thing including encoding an output PNG...)

AVIF has issues with smoothing -- it oversmooths very easily -- it's smoothing is not modulated by the respective quantization level, so it can smooth details that were actually sent in the stream -- the control stream for modulating smoothing has 64x64 resolution, so it cannot control even through a side channel This plus weaknesses in entropy coding larger numbers (as all numbers are in high quality) make sure -- in my opinion -- that no substantial encoding advances are possible

In JPEG XL format the biggest mistake that I made -- I think -- is that the dct decomposition is shared for X, Y and B If I could decide that again, I'd have separate integral transform decomposition for them -- it is very difficult to decide the right sizes when it affects all three channels and I need to opt for smaller sizes than otherwise would be possible

Substantial encoding advances over what current flagship implementation?

over current practice -- which I believe is more or less the same since five years (I might have lost touch as I didn't follow it during the last 2 years)

Oh okay gotcha. Reigning champion is aomenc 4:4:4 deltaq mode 3 tune ssim

Although that will likely change in the coming weeks

AVIF does benefit from doing more exhaustive search for directional prediction modes — which is costly and explains the substantial gap in compression performance between the slowest settings and the faster settings.

In libjxl we don't really have any super slow very exhaustive encoders for VarDCT mode, most things are basically single-shot heuristics, except for the butteraugli iterations done at e8+ to decide the adaptive quantization weights.

aomenc is also just a really painfully slow implementation

(reversed JXL's effort numbers to make it consistent with the rest of the graph here)

also this is real time, not usr time

if I turn on/off directional prediction, I don't see much change in behaviour -- I consider the AVIF's improvement with graphics may be more caused by: 1. palette transform that allows 8 colors to be used in a pixelized local transform (it starts breaking up weirdly if a gradient is part of the block, but is nice for compressing certain features at low quality -- at high quality we usually need more than 8 colors for a block) 2. wedge codebook for compound wedge prediction (also great at lower quality, when you can only spend a few bits per block) 3. and to a lesser degree, stronger smoothing (which comes with a downside of oversmoothing)

tune ssim? tune butteraugli is no longer available or is it just worse nowadays?

Worse nowadays, esp ever since SSIMU2 became ubiquitous

https://www.chip.de/news/Veraltete-Technik-Sterben-die-klassischen-JPG-Dateien-bald-aus_185424775.html

That's a PNG...

"Apple will introduce a new image format called "JPEG-XL," sitting alongside HEIF, JPEG, HEIF Max, ProRaw, and ProRAW Max": https://appleinsider.com/articles/24/08/22/exclusive-every-iphone-16-iphone-16-pro-camera-spec-capture-button-detail-revealed

yup i found out about jxl because of this video

I am looking forward how will it compare to HEIF

Big if true

Interesting...

will jpeg xl camera also come to older iPhones?

Knowing Apple, probably not. It's always an incentive to upgrade and consoom

me when cjxl 🤷‍♂️

It seems silly it wouldn't but it's definitely not in the iOS 18 beta (that I can find)

praying this is true, holy shit

praying that it won't be an iPhone 16 exclusive feature

"our new A18 or whatever chips have a new block in the Media Engine for handling JPEG XL images. Without this hardware block, JPEG XL encoding is not feasible"

I mean that'd be pretty sweet, but I'm just hoping it's not a jpeg transcode

given they're currently using HEIC, they probably wouldn't go back a step (to baseline JPEG) to adopt JPEG XL

Anyone running 18.1 that can check? My phone is too old (13 Pro Max)

this article suggests that it's only for iPhone 16 <https://www.idownloadblog.com/2024/08/22/iphone-16-jpeg-xl-rumor/>

im probably not going to be affected either way, as i shoot in ProRAW and the transcode to JXL manually, but if Apple does add native JXL capture that would help with adoption

especially because it's not a patent-riddled mess of a format (ahem HEIC)

hopefully they don't make any silly choices or mistakes such as encoding in 8bpc or something

ahem Adobe

Would be great if ProRAW DNGs support JXL encoding though…

there's a chance they also add that

it would be in theme

true

https://x.com/stalman/status/1826831590405931212

this feels so wrong lmao

DNG supremacy

I love the term raw because it means nothing [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

ProRAW is just linearised DNG with apple stuff

Also Vencord?

I think apple think raw just means “uncompressed with better dynamic range storage”

it's also pre-processed by a couple steps

yup

exactly, raw doesn't mean anything, and I hate that manufacturers use it

True RAW means just DMA from camera sensor to SSD right

true raw just means "untouched" "RAW" doesn't actually mean anything, one sec I have a quote from troy sobotka somewhere

``` Seriously, “RAW”, “Raw”, “raw”, “r@W” isn’t a thing. LOL The whole “put mosaicked imagery onto disk” is a patent minefield, which is why it’s tricky for any company to negotiate. It would seem the “BlackMagic Raw” is a demosaicked camera native RGB. ... The issue is that sensors aren’t like USB peripherals with drivers. That means you have engineering to massage the values, a crapload of register tweaks, and then PCB chips / software to further massage the crap out of those values. By the time you are at “Yo dudes this is Really Awesome WTF format!” it is as close to raw data as “meat” is to a McDonalds Sausage Patty. TL;DR define “raw” before throwing it around. (I’d take a ProRes LogC Arri Wide Gamut in a heartbeat over some “raws”.) ... Because raw isn’t a thing. So it’s fair to call it raw. Unmassaged RGB primaries are most certainly “raw” LOl Hence Yet Another Meaningless Garbage term. ```

So ProRAW is RAW by the current market definition of RAW but it’s not *really* raw

yeah

market definition being whatever it wants to be

terrible term, only marginally better then HDR

Still think ProRAW looks better with detail and dynamic range (especially at 48MPx)

Me when 400 nit LCD “HDR”

to be fair, a PQ monitor that can reliably dump 400 nits still looks better then sRGB in many cases

With the information required to postprocess it AND described. I have a camera where only manufacturer knows how to do one part of linearizing, and despite this information is written in every raw - none of 3d party raw converters know how to use it. So in order to use these raws I have to convert them to dng (without demosaic), thanks god manufacturer decided to bake in this linearization into dng data.

Although now we’re talking about WCG which is usually lumped into HDR

I feel like there should be a distinction between HDR and WCG HDR = larger range in luminance WCG = larger range in chrominance

larger gamut support is nice too indeed, I think even cheapo HDR monitors can somewhat reliably dump larger then sRGB gamut

accuracy aside

Does DNG require all the demosaic / processing info to be baked in?

Yeah, they’ll look decent, colour accuracy be dammed

No, but in this case manufacturer decided to bake in that damn linearization step, and it is lifesaver for me

As in they linearise before writing the file? And the file is linearised?

It is term ambiguation. It is not that linearization that Adobe calls 'linearization'. I mean this dng is still bayer, but non-linear sensor response is corrected

Other manufacturer used the same sensors did this step before writing file in the camera, and honestly I prefer this approach

Linear like this definition?

Exactly

So basically at this point quite a lot of RAW images are just equivalent to an uncompressed EXR?

in the sensor’s native colour space

No, but for old (especially) sensors lot of work had to be done to get usable image. Some manufacturers did it before writing files, some wrote data as is, writing linearization table to the metadata. But these tables are not described, and noone but manufacturer knows how to use it.

So it’s more like “here’s the linearization table but in a weird proprietary formats and don’t ask us how to use it”

Right

Apple ProRAW may as well be an EXR though

It seems like linearization and debyering happens before saving

And it’s just a tiled JPEG-LS image

In LOG or something? Idk

I'm just hoping if they also add JXL DNG support, they don't do whatever Adobe did with splitting tiles between groups

What tile size were they using again?

672x752 https://discord.com/channels/794206087879852103/822105409312653333/1253000937669132410

🤮

why not just 512x512

They also have the container enabled, when in their own DNG spec sheet they say to use raw codestreams

Why would you need the container ever for each individual tile?

What do they store in there?

I'll *try* to make a JXL DNG and get the verbose jxlinfo output

Emphasis: try to Adobe DNG converter is a joke sometimes

Spot the difference

Well I am pretty much blind but one took way longer

Why are the options a mix between camelCase snake_case and PascalCase?

Ask Adobe

iDontKnow if_i ReallyWantTo

```box: type: "JXL " size: 12, contents size: 4 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20, contents size: 12 box: type: "jxll" size: 9, contents size: 1 box: type: "jxlc" size: 288930, contents size: 288922 JPEG XL image, 672x752, (possibly) lossless, 16-bit Grayscale num_color_channels: 1 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 672x752 Orientation: 1 (Normal) Color space: Grayscale, D65, Linear transfer function, rendering intent: Perceptual```

So nothing, literally just a bare bitstream in the container cause why not

What is hill again?

jxll*

Now I don't have to brave the DNG converter next time

I believe because jxl encoder is more clever in choosing 'tile' size than just such hard defined tiles, also maybe jxl can do it's job better when 'seeing' the whole image, rather than small part of it?

So basically forget about tiling, the entire image should just be 1 JXL code stream?

JXL can tile itself just fine

I believe yes

Also just wondering are the tile sizes of JXL predefined in the header or can it be adaptive? EG if the image mainly uses 1024x1024 can one tile be split to 4 512x512?

If I recall it's defined in the header

Only VarDCT has variable block sizes

It would be cool though

Although I guess for modular a smaller tile would never really be helpful as the MA tree can basically do that for you

Apple could use an "innovate" method to acquire smaller file sizes with better compatibility

by making a new format?

Take a photograph -> Process to JPEG -> Convert to JXL (lossless) This would achieve smaller sizes and still could convert back to JPEG, with the exact same quality

that wouldn't have as good a quality as actual JXL encoding though

This is to make sure no loss when converting back to JPEG

itd have the same issue of jpg taking a lot of storage - gainmaps taking little more doesnt make such a messy approach viable since uploads and shares will have to be recompressed

they already use JEIC, they wouldn't care about lossless JPEG reconstruction

I've tested some and the resulted JXLs converted from JPEG could be just slightly larger than genuine JXLs

Apple could brand it as ProConvert

that's because JPEG converted JXLs can only use 8x8 DCT where as true native JXLs can take full advantage of VarDCT

or ProJPEG

they dont need reconstructibility, with os updtes going as far as they do they can go full jxl with true hdr

definitely, remember, they did this with HEIC, they can easily do it again

now ball's in photo sites' court- smugmug was an early support (owns flickr now, and no word from photobucket

browsers really skewed public perception about image formats - even if a browser cant view something natively, offer to have the file **downloadable** - simplest adoption possible

https://x.com/jyzg/status/1763141558042243470 Would using Jpegli make a difference?

jpegli+xyb would force the hand of the ecosystem into supporting+enabling by default iccv4 and make higher quality jpg sources to work with

firefox is the highest profile app that fails decoding xyb jpeglis, barring mobile apps with their own internal logic

I want a CICP for xyb but I don't think that really actually makes sense since I think that only actually exists for yuv

how many devices support XYB jpegs?

probably anything with the proper level of icc support

ProXL

we should go apply for a job at Apple

specifically their marketing team

about iccv4 in particular, reportedly anything based on webkit, blink, chromium. most mobile gallery apps (samsung's is preinstalled and has a billion installs). on windows it varies, viewers need color management enabled first. windows store's Photos

showerthought: there should really be packs of sample images, this 'generate your own' situation causes issues since not that many are even familiar with the formats' specifics

maybe some kind of JXL art website where people can share JXL art?

like the <#824000991891554375> channel on this Discord but a website

or do you mean more like images that most people would use (photographic? )

something more organized and far better accessible. discord cant even be browsed without an account and images' tokens expire

website would be fine as long as files are also *downloadable* (ie under the jxl, theres a 'dont see this image? download it' message)

Squoosh app is a good way for people to experiment with compression

squoosh runs a super outdated jxl and showcases little of value imo

There should probably also be a way for it to convert the image to PNG just for the browser to show it correctly

I still think the largest chance for JXL adoption is if Apple goes all in

for jpegli, diverse visual examples comparing jpg encoders and how certain kinds of artefacts are improved

tables with numbers are a good start but the numbers should correspond to something people can visually appreciate

since jpegli can target a specific filesize, it could more accurately regenerate new jpgs of the same filesize using png originals if those are available

Does Jpegli help with candying and such?

candying ?

Banding

And blocking artefacts

What is this glove doing

Phone

does reportedly, or at least is affected less visibly thanks to working in higher precision in encode and decode

Sometimes the comments baffle me, definately no hardware acceleration and what does 'Native Encoding' even mean?

firefox works with xyb jpegs

https://www.cultofmac.com/news/jpeg-xl-iphone-new-photo-format-explained?utm_content=cmp-true

only somewhat related to the article, I hate article titles "what is y and why x should care" has to be the most annoying thing to come from the internet lol

now to the article itself, didn't really do a great job selling it

https://x.com/stalman/status/1826849907778748771

they're good when that's literally what you're after

kinda preachy when you're not

> It can handle images up to 1 terapixel Maybe my math skills are on pre-school level, but for me it seems to be ~10^18, i.e. exapixel. Or I'm wrong?

they probably got that info from wikipedia

I missed it was crossposted to Threads. Bit of a flame ware breaking out there: https://www.threads.net/@stalman/post/C_AAEQgsyYw?xmt=AQGzpwiI5bGAOdynFO5WNKQN8M2GU6Ut464rXrW0w3LgIg

Here the title would be similar to "Look! The new iPhone will add this feature" in Chinese

Much misinformation from the comments below

And which website did he mention?

instant regret looking at the comments

Yeah, it's pretty painful.

Nope. That's me! I asked him if he'd help us get the word out before the Apple event. He usually gets invited to them.

I don’t use X. What do the comments say

About what I expected

https://news.ycombinator.com/item?id=41334964

https://x.com/nightshademagia/status/1827071348738285892

Such as this

pretty much

I find comments less bad than months ago. People start to understand what it means to be able to convert all existing jpegs or having a free lossless codec which doesn't suxks. There is still some simpletons though

"BUT WEBP IS THE BEST FORMAT EVER"

And "BuT JpEg XL iS nOt fReee"

when they say that do they mean the spec is not open?

They mean The spec is paywalled

is the format "free" because after paying for the spec you can implement it however you want?

Thus JpEg iS nOt fReee eITHer

integrating libjxl is totally unrestricted and requires agreeing to nothing. libjxl is also not jpegxl, only the reference library made as a working implementation - youre free to create or use any other library

Unfortunately time is not free either as ISO 8601 is paywalled

Reimplementing is also free... ISO take a fee for the administrative process of making the document

i recall almost everyone who could need iso access already has it paid by their workplace or education

as in if I want to write my own version of the spec im completely allowed to?

what about hobbyists who just like reading specs

As jon said. Av1, owned by corporations could be seen as less free... At least, less independent

They can comme here

and get the copy of the draft spec from https://discord.com/channels/794206087879852103/1021189485960114198 ?

theres also some wip version of the spec somewhere iinm but integrating is the smarter approach

there's https://discord.com/channels/794206087879852103/1254012901816274956 but last PR was a month ago so not sure if it's continuing

Absolutely. You are even encouraged to 😁

ffmpeg supports countless formats and nobody ever needed memberships anywhere despite it covering patented formats with actually restricted access

and i won't get in trouble as long as I am not just copying the ISO spec word for word?

Yep, ISO have an authorship right on the spec they provide. If you want to re write it (and make it clearer or cleaner) please do.... However, the ISO version will forever remain the reference

https://en.wikipedia.org/wiki/ISO_8601#Adoption_as_national_standards Example

You can adopt it and write your own

it's OK, many things have historically had multiple conflicting specifications, just look at sRGB [av1_omegalul](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&quality=lossless&name=av1_omegalul)

so the ISO is the reference spec like how cjxl is the reference encoder, but anyone is allowed to write their own version of the spec, even if it's to handle the same format?

like how `jxl-oxide` is for the same JXL files as `djxl`

yeah, anyone can write anything they want so long as they don't step on the wrong toes. in the case of JXL it should be fair game

even if the spec I write is the same functionally, as long as it's isn't just copypaste?

is the copyright on the bitstream format or the words in the spec?

As long as it is not plagiarism

sorry i don't want to be sued

You can describe the format again in your own words as much as you want. The original text is only copyrighted : no word for word translation or copy paste...

that makes sense

> You can describe the format again in your own words yeah, that clears it up for me

thanks

The format is free, its original description is copyrighted and available with a fee

yeah, the format is basically as free as it feasibly can, the reference implementation is FOSS, anyone can write their own encoder or decoder, you can rewrite the spec, it's just the original spec that costs a one-time administration fee

Yep, ISO is a big beast which need to be fed

not everyone can be an Xiph.org or an AOM

devs need to be paid

isnt xiph practically dead these days?

The ISO fee don't pay devs, only the organization of meetings, deadlines and other administrative tasks

but that's also important

not sure, i personally thought they were part of AOM

given they helped make a lot of open media codecs (Opus, FLAC, Ogg, Theora, etc)

Copyright is on words, not on ideas. So you can make a functionally equivalent spec and make it publicly available, just have to avoid copying phrases of text. Tables and code are OK to copy, just not the prose in between.

As far as I understand, most of the xiph folks used to work for Mozilla, until the whole Mozilla codec team was cut in the big layoffs of August 2020.

They were talking about this website: https://discord.com/channels/794206087879852103/1256302117379903498/1256305400102391898

Why do some media use "JPEG-XL" instead? Is that a legit name?

The "official" name is JPEG XL, with a space.

The comments saying jxl is nonfree are just nonsensical. It's like saying jpeg isn't free.

the only part that isn't "free" is the official spec, and that's just talking about money

Some people also saw an article about Microsoft supposedly patenting rANS or something, which isn't even what happened, and has nothing to do with jxl

but that spread misinformation that the format is supposedly patented by microsoft

is rANS even used in JXL?

haven't looked into JXL entropy coding

Even though microsoft was granted a patent on something else entirely, that has nothing to do with jxl.

it feels like there's a lot of anti-jpegxl propaganda

maybe google is doing some anti-jpegxl campaigning

otherwise why are there so many people who don't just not care about it, but actively dislike/despise it

doubtful. It's normal for people to be misinformed and bad at playing telephone.

and i guess people don't want a repeat of WebP

Everyone hates new formats being introduced without good reason too. Plus recent versions of libaom have made some strides, and preserve details and colors much better than recent versions of libjxl in my experience, so that doesn't help things.

there's a crowd of anti-JXL people who are like "You won't take away my PNGs and JPEGs!", do they realize that if it's not JXL then it's going to be something worse like WebP or AVIF?