JPEG XL

is that just the transcript?

wait, is JPEG XL already been shipped to the new phones?

so i can go to the store and buy a phone with JXL and it's not a leak

🎉 🎉 🎉

do we know what codec they're using?

probably just libjxl?

I hate these 'online' converters. Only console apps is fine

more hyphens :/

fair

this seems like a good first step for mass adoption, it's already making waves in the raw format scene, time will tell if/how this propagates to the processed delivery format scene

hope they eventually discard HEIC for JXL

maybe they're just waiting for more installed base

maybe iOS 19?

only thing is, I could imagine people being like "oh my goodne ss another damn image format, i was finally getting used to heic"

JXL compression inside DNG is a subtle beginning in contrast to HEIC

maybe JXL-in-HEIF? although that sounds like a terrible idea

Well, it is terrible idea, but probably someone will write jxl-from-heic lossless extractor

JXLIF?

That just sounds like FLIF

JXL in TIFF? or is that just called DNG

libjxl is the only finished encoder, and hardware implementation is still at least a year away unless Apple randomly decided to make Silicon on an accelerated schedule and then not mention anything about it...

DNG is just TIFF with extra steps

I used an AI upscaler, I should now have a JPEG-XXL

Well JPEG XS exists, and JPEG L could mean JPEG LS (lossless)

Also JPEG M could be M-JPEG (motion jpeg)

So technically not wrong

JPEG-LL and JPEG-LS are very common spellings

if it's lossless jpeg 1 i call it L-JPEG to distinguish it from JPEG-LS which is more akin to JPEG 2000, argh too many codecs

although now I don't really use any of those because I can just use JPEG XL

JPEG -2000

JPEG d/dx sin(x)

Asked some contacts to see if they could get the hyphens removed. Hyphens aside, it's definitely great coverage.

Ugh. The response from PetaPixel

this server gonna wage the war against the hyphens

this is actually a fairly solid move for apple, since they can push jxl into assured usage, without screwing over their customers sharing photos. ofc this falls apart when you realize HEIC literally has less support then JXL does, ~~but we can ignore that for apple's sake~~

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

```To Tim@Apple.com Please remove the hyphen from your upcoming iPhone 16. I understand it's not been announced yet but this has been a big issue with our representation.```

Inb4 somebody suggests the cursed idea of pushing DNG for the Web.

https://caniuse.com/?search=dng

https://tenor.com/view/no-shit-sherlock-genius-sherlock-holmes-big-brain-gif-21242595

tcook@apple.com

Looks like PetaPixel is going to update the article. 👍

Looks like they did

https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-the-iphone-16-and-what-it-means-for-your-photos/

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

Is the hyphen really a big deal?

At this point is more like a meme

It’s a text version of GIF vs GIF

honestly I don't mind the hyphen/dash. and also it's not anything new as people did the same thing back in the day with JPEG 2000 and JPEG XR

no-it's-not-a-big-deal

it's-more-funny-how-often-people-mention-it-here

`JpegXl` is how it is in my source code •_°

imma start saying jPEG-xl from now on

jpEg_xl

JPEGxl

I just hope this doesn't make jxl seem like project with crazy fans that flip out just because someone writes hyphen.

The AVIF team seem like a group of people that flip out whenever anyone suggests a different format so yeah

Maybe devs, but in AV1 discord server image channel it's more jxl than avif which is funny

Yeah I meant the devs

It’s funny seeing the av1 server suggest jpeg xl

Yeah

do you have the link of the av1 discord ? When I search these terms on google, I get links about how well discord supports AV1

not sure if i am allowed to advertise it but it's on the r/av1 subreddit

both AV1 for dummies and the main AV1 server

it's just a matter of being sane, people joined the AV1 communities because they want good compression with reasonable restrictions and performance

Av1 is a sane codec for video and long animations, and JXL is a sane codec stills and short animations

camelCase

seems interop is attracting negativity early. wouldnt be too hard asessing who blocks or shuns. those in favour can lift all doubt by just publicly demonstrate theyre aware of proposal, read/understood it well, researched and asked for details if any they needed to *properly evaluate it* - easily done on twitter or privately

on an aside, i wonder if ladybird doesnt already qualify as a strong independant browser deserving of a seat there. maybe next year

there's literally no point to put something into interop that only one browser has

if firefox gets jxl next year. there'd be a much better case for getting jxl into interop

chromium and firefox do too. the code might have been deleted or limited to specific release channels but the implementations do exist. those browsers have lots of 'inert' code implementations locked behind build parameters or flags but theyre still considered done

either way, without a way to confirm that proposals are seriously considered or even read (ie a simple 'has viewed this page'), i doubt this time will be any more transparent. insiders will backdeal while the webdev community theyre supposed to be interoping in service of will be locked away from even disambuiguing anything needing clarifications or extra info about

Interop is basically browsers announcing that they all agreed to implement a feature. As long as Chrome does not plan to implement it, proposing it for Interop is kinda useless.

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

Did I say anything wrong? https://www.reddit.com/r/jpegxl/s/HXmpQK2RXO

How the f shall we handle that OP's mother's 105 "gb" pictures if we don't know anything else?

People are foolishly too generous in this subreddit

Judging by the lack of a response, It seems like his question was already answered.

In my opinion, the jxl subreddit is not a good place for questions, most people give bad/confusing responses. If you want good answers just join the discord.

It’s also just a nice community if you’re interested in compression

I suppose

If the person is serious about the question, providing conditions like operating systems, desired compression rate of JXL should be necessary

And why a mom would ask her children converting such huge amounts of pictures into JXL

> In lossy mode I think there is no difference between AVIF, HEIC or JXL. AVIF is even a little bit ahead. :|

(from that Hacker News thread)

> If people are going to take credit for crunching something down from 10 MB to 8 MB, I wish they'd also take the blame for massively bloating something into a modern monstrosity out of sheer laziness or betting that profit margins will be higher if they waste user time, storage, and cpu for the sake of releasing the project faster.

https://tenor.com/view/confused-nick-young-what-question-marks-idk-gif-14135308

> crunching something down from 10 MB to 8 MB > waste user storage

the less you know, the more you speak about ! old internet rule

https://github.com/web-platform-tests/interop/issues/700#issuecomment-2362136562 > Basically, if Chrome opposes JPEG XL then it won't be approved, period. Ohh, so its basically UN Security Council 😄

The Interop team then needs a "veto override" mechanism as well, lol.

the thing about WPT interop is it's just for making sure that web features that all browsers have all work properly between said browsers. last year a large amount if not most of the top submissions where rejected because they wheren't supported by all browsers

the entire web as a platform is a giant mess that will never gear down. constant creation and adding of new features while not even bothering to add or finish older officially standardized ones

I'm pretty sure there are still quite a few web standards/features from 10 or so years ago that are **still** not fully supported by some or all browsers

That's what I said to someone asking about storing IR, R, G channels with a ROI mask. The reddit has some fans but most of them have no idea what they're talking about

but, contrary to this discord, reddit posts appears in google searches... perhaps it would be better to ensure that good answers are given too...

I wish I had the energy and will to use reddit again. Reddit showing up in search results *is* a big deal.

I distanced myself from reddit once they jacked up the prices for their API, killing off all third-party apps.

same

https://www.youtube.com/watch?v=QqTSnI0bfFk&t=673s

Oh god, my phone's HDR is horrible. I'm not sure I've actually seen a person on it before, only test videos

The beach is just pure white and he looks like a cherry tomato xD

what phone?

Huawei Mate 10 Pro

Saying "JPEG to JXL" we can assume they mean transcoding, OS is generally Windows 9/10 times, especially on legacy devices

Discord is a black box that's not indexed, not archived, not public and could disappear overnight. It's for chatting, that's it.

And yet it has replaced forums in 80% of cases

Sad reality

it also replaced IRC

which in 99% of cases is also not indexed

I've even seen some projects lock off downloads to Discord

> not archived Looks at my 54 gb discord download folder

Also I think a conversation based system like discord is better for getting advice

As you can have real time conversations

Instead of waiting hours for a reply

Maybe someone should make a read only mirror of the discord?

So it can be indexed

Split into file

I could probably set it up, just don’t have the money to host it

Not true. IRC web-archives were pretty mainstream.

Like an interactive chat bot that hooks into the server?

More just using that discord scraper tool which outputs static HTML

Then hosting that on a webserver and occasionally updating it

That could work but having an open system for people to post sounds like a recipe for spam

I see

In a perfect world public discord servers would be search indexed so we wouldn't have to resort to such measures.

*some* irc channels had logging. But it was extremely common to forbid logging. If you published logs you'd be banned from the channel. It's a pretty common opinion among IRC enjoyers, that they don't want what they write to be saved.

I miss the IRC matrix bridge, not that matrix is any good, but it was nice for actually not dropping a conversation

- ask for help in morning - wait all day with irc channel open - turn of PC for the night - someone replies - wake up in the morning and ask for help again

many such cases

I've already had to reply and correct half a dozen answers like that, all getting upvoted because no one actually knows what they're talking about 😔

Argh, don’t use image magic it doesn’t support lossless transcode 😦

I tried https://www.reddit.com/r/photography/comments/1f48b2g/comment/lo1qkzd/

10/10 embed Discord

Just logged into reddit after 3 months just to upvote it

Mom is gone

Oh it is now mentioned below

https://www.journaldugeek.com/2024/09/20/quest-ce-que-le-jpeg-xl-lance-par-apple-sur-liphone-16/

huh, I didn't realize you can say "Qu'est ce que le JPEG XL", I always say "qu'est ce que **c'est**"

(in any case it is funny how many words French uses for "what is .,..")

So JPEG XL is a masculine term

nighty-eight years ago -> il y a quatre-vingt-dix-huit ans

unless you’re Swiss or Belgian, then it’s « il y a nonante-huit ans »

Something my Duolingo would never teach

“too easy” — Duolingo, probably

Septante and nonante are very convenient

Unfortunately we don't have octante

Still the 4x20 thing

some Swiss cantons have huitante

This seems the most logical way to do it

Just need to replace vingt with dante

https://www.macrumors.com/how-to/iphone-16-pro-choose-jpeg-xl-proraw-formats/

What's the -d for "perceptively lossless"?

cjxl defaults at d1, which is perceptually lossless at 100% zoom. Adobe uses 0.2 for their DNGs for editing

That size resembles 0.5 for me

Generally I consider 0.3 a good number. Adobe's setting sometimes results in larger than lossless files, but we'll hopefully be able to figre out what Apple are using

I use 0.8 for standard images just for a bit of headroom

Here is a DNG with lossy JXL

I also have one with lossless but it’s too big for Discord

well, the idea is it's lossless at 1000 pixel viewing distance in particular lighting conditions, but this is less true today than in the past. you have to decrease the distance for such claims today.

By iPhone 16 Pro?

Yes

I went to the Apple Store

Have you recorded the file size of the lossless one?

Lossless

Lossy

The difference is quite larger for this

The image itself is basically blank

So lossy can do a good job

https://www.reddit.com/r/jpegxl/s/s0PLWewyLH

> Personally, I prefer AVIF. Its lossless. And it works better in lower quality images, older cameras for instance with 24mp sensors .

Does that mean converting old JPEG pictures into lossless AVIF?

What the hell

There is a format designed specifically for converting JPEGs into losslessly

That would probably be a better choice

> JPXL That’s new

https://forums.macrumors.com/threads/jpegxl-and-less-file-size-dont-support-older-models.2436976/

b and B are different for file sizes

mb is milli-bits

8 billion mb is one MB

Lol, millibits is a funny unit. We should express jxl art sizes in millibits per kilopixel

Is a unit smaller than bit possible?

Well you can have fractional bits (Shannon’s) when talking about information theory

Like if you have a weighted coin that has less than 1 bit

1 millibit per kilopixel is 1 bit per megapixe, since JXL art is 1024x1024 (1.05 MPx) it could actually work

100 byte JXL art is around 780 mb/kPx

> ProRAW images on 16 Pro are only about 20 mb when JPEG XL lossy is used, with losless option they are bigger... Who could've predicted that

well i guess sometimes lossless is bigger, although this situation it's kinda silly

like a png of a flat shaded logo is usually smaller than a jpeg

Can someone run `exiftool -a -u -s -G1 IMG_0051.dng` on it and dump the output in a code block here. I'm stuck on my phone

Could split into 9 MB parts with 7zip

sorry about wrong order

``` [SubIFD] TileWidth : 2016 [SubIFD] TileLength : 2016 ```

that's way better than whatever adobe was doing

Could you on the lossless too?

What do you mean?

Thanks. Strange that it has half as much

i think it's because <@1102876331986927627> used different exiftool settings

I just copypasted your command line

oh i just used `exiftool`

That one

?

Just pointing to the command

now they're the same size

or did i do the wrong file

lmao

wait what

hang on

So that's an 8-bit JPEG preview and then 10-bit lossless jxl?

Only 10-bit?

But then there's also this: [SubIFD] ProfileGainTableMap : (Binary data 3158080 bytes, use -b option to extract)

3 MB of gain map data? Can you extract that and see how it is encoded?

apple proraw does some weird stuff to images i think

there is a lot of proprietary apple coding stuff apparently

i think it's probably f32be data

ikr

There's also [SubIFD] LinearizationTable : (Binary data 5284 bytes, use -b option to extract) so maybe they're encoding it as a 10-bit image with some transfer function to bring it to 16-bit linear, and then on top of that some gain map?

i found this video that might explain things

https://developer.apple.com/videos/play/wwdc2021/10160/

it explains what most of the tags do

Apple goes to great effort tuning the quality of our images. ProRAW images have a default look that is consistent with the look of our HEICs and JPEGs. This is achieved by embedding special tags in the DNG file. These tags are documented in the DNG spec and provide the recipe for how to render the default look of each image. The first tag applied is the LinearizationTable which decompands the 12-bit stored data to linear scene values. We use the BaselineExposure tag because ProRAW images adapt to the dynamic range of the scene. The BaselineSharpness tag allows us to specify how much edge sharpening to apply by default. The ProfileGainTableMap tag -- which is new in the DNG 1.6 spec -- allows us to describe how the adjust the bright and shadow regions. Lastly, is the ProfileToneCurve that specifies the output global tone curve. All of these tags are unique to each image.

this is the data from an 48mpx shot from iphone 14 pro max

```[SubIFD] SubfileType : Full-resolution image [SubIFD] ImageWidth : 8064 [SubIFD] ImageHeight : 6048 [SubIFD] BitsPerSample : 10 10 10 [SubIFD] Compression : JPEG [SubIFD] PhotometricInterpretation : Linear Raw [SubIFD] SamplesPerPixel : 3 [SubIFD] PlanarConfiguration : Chunky [SubIFD] TileWidth : 1008 [SubIFD] TileLength : 1008 [SubIFD] TileOffsets : (Binary data 431 bytes, use -b option to extract) [SubIFD] TileByteCounts : (Binary data 382 bytes, use -b option to extract) [SubIFD] LinearizationTable : (Binary data 5438 bytes, use -b option to extract) [SubIFD] BlackLevel : 0 0 0 [SubIFD] WhiteLevel : 65535 65535 65535 [SubIFD] NoiseProfile : 3e-05 3e-08 [SubIFD] DefaultBlackRender : None [SubIFD] ProfileGainTableMap : (Binary data 3158080 bytes, use -b option to extract) ```

Okay, so they did adjust some values for JXL at least, although no higher bit depth

they probably wanted more compression, not higher quality

not sure why they never mentioned this in the event even once

at least now we know where that rumour came from

it was about ProRAW

Could be because it's only on the Pro and they didn't want backlash, could be a late addition, could be they don't think saving storage is worth announcing compared to the other features

<@386612331288723469> I'm guessing you didn't take a normal DNG at the same time? Could've roughly compared compression then (even if it is mostly white)

sadly no

took a photo of a white wall

52.1 MiB

So 40% smaller, very, very roughly. Lines up with expectations of around 45

Such an inconspicuous image holding so much information

took it while going to see a movie with a friend is JXL or friends more important

ahh whatever, took photos with my friends in JXL

the jxl payloads inside look like this: ``` 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: 2660374, contents size: 2660366 JPEG XL image, 2016x2016, (possibly) lossless, 16-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 2016x2016 Orientation: 1 (Normal) Color space: RGB, D65, Rec.2100 primaries, Linear transfer function, rendering intent: Perceptual ```

wonder why they used the container

what level does the `jxll` signify?

is that lossy or lossless?

strange that it's 16 bit RGB

maybe to store out-of-gamut?

jxll is just to signal that it's conforming to level 10, which is needed if you want to do 16-bit

that makes sense

is the `BitsPerSample : 10 10 10` just wrong then?

so looks like it stores 16-bit linear RGB with rec2020 primaries (or rec2100, that's the same thing)

ugh

``` Image statistics: Overall: min: 339 (0.00517281) max: 885 (0.0135042) mean: 784.204 (0.0119662) ```

that looks like the actual data is 10-bit

Likely just calling a 16 bit encode in the API instead of using the exact bitdepth of the camera, happens a lot

but they're encoding it as if it is 16-bit, just using only the bottom 1/64th of the range

I'm guessing palette doesn't help much?

doesn't make that much of a difference if they're doing the padding in the msb

but just silly that they're pretending it is 16-bit if it's not. The e1 encoder should be a little faster for 10-bit than for 16-bit

(and also you can stay within level 5 so no need for the container)

is there any signalling to be able to tell which effort they're using?

like what coding tools they're using?

Could we test how much of a difference it makes using one of the extracted tiles?

Could just run cjxl on the tile at every level and see what matches or is close

looks like it's doing e3, doesn't quite match exactly though so maybe some custom options or maybe an older version of libjxl

oh wait, if I encode with cjxl with 10-bit ppm as input, I can get an exact match at e3

Which JXL version are you using ?

0.11

though 0.10 would be identical I think

Is there a list of what commits were made in between🚗

Whoops no car

I don't think for lossless e3 anything has changed since 0.10

Yeah, I don't think much was done to lossless apart from some palette tweaks

anyway, so it's pretty much OK what they're doing, lossless e3 makes sense for photographic images

telling libjxl it is 16-bit instead of 10-bit is a bit silly because it makes it add the container and the level box, which isn't really needed

Only e3 and d0 with no other parameters? Means they didn't use faster decoding like Adobe too

It’s 49 bytes though so not the end of the world

Less than 1 kB total for the whole image

I guess their CPUs are fast enough to handle them

Would be interesting to see what lossy settings they chose

It doesn't make much difference but bloats lossless files, so I'm glad

What does faster decoding disable?

Deep MA trees?

They already save more than that by using 2016 tiles instead of 764 or whatever like Adobe

lol fair

I always heard that ProRaw is 12 bit, but I looked into it now. Apparently Apple used to say 12 bit, on older iPhones, but now they say 10 bit. I wonder if it was always 10 bit, and they were lying before, or if they actually reduced it.

maybe it's 10bit + gain map info?

or maybe it's 10 bit with dithering?

Actually, what format is the gain map in?

"16 bit RAW*" *JXL files are 16 bit, data contained may be lower

haven't been able to decode it yet

Huh, it's the same size for both lossy and lossless...

Half of the lossy and 20% of the lossless are just embedded preview and gain map images

isn't there also a semantic map somewhere in there?

is that also JXLified or is that still JPEG

actually the images i sent probably don't have a semantic map

Something not- or very slightly compressed, however I can't guess exact format

It looked like big endian float32s to me

Haven’t tried actually visualising it though

so wait to get things straight are the ProRAW JXL files 16-bit JXLs that are given 10-bit data and then brought up to 16-bit with a external gainmap?

I guess it could have been worse..

They’re 10 bit images with padding to 16 bit

Not sure about gainmap

Haven’t looked into it further

https://youtu.be/WMRzK-yCbr8?si=28Qw9jaJSBBXdGd3

@ 9:10 People need to understand that “Google” didn’t remove JXL support, the “Chrome Codec Team” specifically did

I don't see anything wrong with blaming Google as long as the guy works under Google and Google doesn't make a statement disavowing his actions

The question is who at Google should do it? His manager?

Everyone stays in their lane probably. He acts like he has almost no oversight as lead of the Chrome Codec Team, a proven expert in the field no one else is around to challenge his ridiculous conclusion

Especially when he explains it away using weasel words such as "we" and "I had a discussion with... partners, trust me bro"

Like someone trying to avoid taking responsibility for his own decisions.

Weaseling out of accountability, as they say

He's just doing the will of the "wider community" you see. He speaks for the "wider community" and they have spoken and said there's not enough interest!

i had a discussion with me, myself and I

There just isn't enough interest, trust me bro, I spoke with the "wider community" and this is what "we all" want.

He literally speaks like that and I’m surprised more people didn't respond or even ridicule him personally for such vague weaselly language

> "not enough interest" apple, intel, meta, shopify, the guardian: 🤷‍♂️

Especially since this is coming from the webp/avif guy and we know how much enthusiasm there was for those formats when they were added to Chrome

The complete shameless hypocrisy is staggering.

webp and avif did not have anywhere near same level of ecosystem interest as jxl

And I guess that bothers him

I guess he took that personally

WebP interest: argh a new image format that nothing supports AVIF interest: new format, slightly better compression, nice i guess i don't care though JPEG XL interest: This is the best thing since sliced bread

Chrome codec team: 🧂

Pardon me. When he added them to Chrome...

Since as head of the Chrome codec team he's directly responsible for not only overseeing the development of avif/webp but also fast tracking them into Chrome

integrating the support isnt the win they might think. sites are still free to use any formats they want - even with all the forcing, nobody uploads webp or avif, theyre literal 'final delivery' formats only cdns serve as reduced quality substitutes for large jpgs and pngs, and those would gladly switch to jxl the month chromium decodes it out of the box

so it's just "how long can we keep up this charade of jxl not having ecosystem interest"

and for what? these are all FOSS

Correct me if I’m wrong but there is no financial gain for Google for pushing AVIF?

Or are they just playing favourites for the sake of it?

imo its just they continued believing video-based codecs make sense and now theyre too deep to course correct

And they just don’t want to say “sorry we were wrong”

they knew avif had no chance at adoption if the competition wasnt kneecapped in some way. its not good even at converting gifs (jxl is better in lossy and lossless converting existing gifs), you have to go back to the original video to make an av1 video stream to smuggle into an avif extension

av1 is good, avif being short/small av1 videos makes sense, almost nothing else does. storage is cheap - keep your original jpgs, wether youre a user or web service

Basically AVIF is a good replacement for GIF

only if regenerated from an original video, but then even ancient divx wouldve been adequate

Sadly not

https://caniuse.com/?search=divx

It just seems like this guy Jim for whatever reason has something personal against what he perceives as a competitor to his life's work.

Can’t they just be friends

It never even occurred to me that jxl and avif are competitors until after he made his absurd announcement

I always assumed they would be used together for different purposes

Same

I use AVIF for thumbnails all the time

Ego issues.

Why so angry? Firefox is going to support JPEG XL at some point, one of the most popular FOSS gallery apps on android now support JPEG XL, some amount of Android support is being considered, rumors of Windows support, good news all around

Don’t forget Apple charging in head first

> one of the most popular FOSS gallery apps on android now support JPEG XL Which one? Currently using Aves Libre which doesn't want to add support until Android has native support for JPEG XL

Oh this one I guess? https://discord.com/channels/794206087879852103/803574970180829194/1287159313697341525

Simple Gallery is popular, and Fossify Gallery is it's successor

I'm so stealing this : P

https://www.threads.net/@stalman/post/DAOv7JVSZx6/?xmt=AQGzIhpZk6GzFwdmdSn8Pnyq-VvCQo2hFxPsm9QejSBDYA

https://www.youtube.com/watch?v=SzsM4HMKmEI

"Jpeg XL create a sandwich of superiority" ! amazing

As I'm watching the video, I wonder what settings the photoshop(?) export actually uses... And if the 0.8 release could've given sharper images due to the regression since

ISO noise could've helped too, but that's only in Krita or cjxl if I recall

Who's this

Just one image and one person's opinion, but the comparison methodology is OK.

there was maybe a bit of a gap in between “medium” and “high” quality

the sandwich of superiority was a nice analogy

Sad he didn't compare lossless. I think jxl as replacement of png is also important

yes, it compresses so much better/faster

It is quite telling that Adobe didn't even bother to have lossless avif as an option.

In terms of interop, it's hard to beat PNG — but then again the same is true for JPEG

I wonder what effort photoshop uses. Would be shame to say jxl is bad if low effort is used even thou higher could be used with small difference in encode time

And yes, that "sandwich of superiority" was a funny way of putting it, but I do think it's quite correct to think of it that way. Basically the cases where 1) the network is fast enough not to have to worry about progressive rendering, and 2) the network is slow enough to make low quality images an acceptable trade-off (to the point where you're in the low-quality region where avif is usually better than jxl) — the range where both are true at the same time seem quite narrow, if not empty...

1) users 2) companies , they believe

lossless recompression of jpg is worth its own video

normally any recompression from jpg either results in a massively bigger lossless file (in avif, webp or even jxl), or degraded quality without even a guarantee of lower filesize (unless you lower quality level even more until you hit that final filesize)

no loss AND guaranteed lower filesize AND in less than 50 milliseconds per file of common resolution (20megapixel-ish) at default effort? thats massive for galleries and image hosts and near-realtime

afaik jpg->jxl transcoding also turns what were non-progressive jpgs progressive

No idea of the effort or the actual quality because of the Photoshop UI, or what libjxl version since like I said before, 0.8 was much sharper and photon noise could've made low efforts easily beat AVIF

I would want a "more grain less blobby mess" mode in cjxl 😄

Libjxl 0.8 ftw <:Stonks:806137886726553651>

It looks like jxl has been getting progressively smoother over the years. ¯\_(ツ)_/¯

Not all hope is lost though, https://discord.com/channels/794206087879852103/1278292301038227489 A corpus of images is being made to re-tune jxl to be sharp again <:Hypers:808826266060193874> <:pancakexl:1283670260209156128>

`--photon_noise_iso=2000000`

that's above the maximum 😛

Not on my cjxl

The max is `--photon_noise_iso 445536` for me

Oh, weird. The limit goes up to around 2 million when the input is a jpeg with `-j 0 -d 1`

And the weird chromatic abberation still happens in lossless

And yet a different output with transcode enabled... Very odd

Original, Transcode, Lossless, Lossy `--photon_noise_iso=2000000` (Beautiful artwork I know)

For a .jpg input, the max photon noise is 2202244, for a png input it's 445536

wait a minute

does the max noise vary per image?

In the video he shows exporting from photoshop as a JPEG XL. It doesn't show as a supported export format in Adobe's documentation. Does photoshop support it as an export format now?

Could've been exporting from lightroom, all I know is that it's Adobe because of the arbitrary quality settings

I'm quite surprised AVIF retained this much detail without even using noise synthesis at such a low file size. I was under the impression that the reason AVIF looked better at lower bitrates was specifically because it chose to smooth out detail instead of trying to retain it

If anyone has Lightroom(?) installed, maybe you could check the "open source licenses" to see which encoder and which version they used?

;_; This video is painful to watch. JXL really struggles perceptually against AVIF and his criticism is exactly what I've been worried about... About how AVIF surprisingly preserves the grain better than JXL, and how the grain helps preserve more of the original details...

Forget a mode, this should be the default... "blobby mess" mode should be either nuked from orbit or turned into a "--tune=objective" mode for tricking naive objective metrics

Preferably nuked from orbit though, metrics be completely damned

On one hand I am glad this video is bringing attention to this problem so it has a better chance of getting improved or even fixed... but on the other hand embarrassing videos of poor performance makes it harder to promote adoption :(

I still feel like this may be because of poorly chosen encoder settings or a poor encoder in general if Adobe rolled their own instead of using libjxl. I'm going to try to reproduce this with the reference encoders when I get home

If AVIF is indeed much better, it's still possible that this is more of an encoder thing than an image format thing. We're not comparing the best theoretical JPEG XL to the best theoretical AVIF. We're just working with what we've currently got

He also makes the observation that grain "is more pleasing to look at" and "helps preserve the extra detail and patterns" compared to "blurry messes" which I've been saying for a long time.

Yes, it's a matter of tuning the encoder. there is a lot of quality left on the JXL table waiting to be unlocked

And really old versions of the encoder had better lossy performance too from what I've consistently seen

Wasn't AVIF the one that had been criticised more for being blurrier?

In the past, yes, when AVIF was blurrier and JXL was sharper.

Since then aom has gotten sharper and libjxl has gotten blurrier.

it's weird but they somehow traded places

Some people took the blurrier details on AVIF as an advantage however

in the past I asked why is AVIF sharper in small images https://discord.com/channels/794206087879852103/794206170445119489/1100446546123825192

I can't find anything about jxl

people don't like the smoothing, actually, from a pure appeal standpoint, because they know how the world looks like, and unnatural smoothing stands out, especially if it happens inconsistently across the image

aom devs put a lot of work into allintra mode few years back, since then it performs quite well even with default settings

Does Camera Raw have .jxl lossless as an export option? Affinity Photo 2 does not, but it does have lossless for WebP

And now I've named Affinity, does anyone know what version of libjxl they use? They don't have libjxl mentioned at all in their third-party licenses

Yes it does.

I doubt they rolled their own encoder. The excessive blurring is a well known problem with libjxl.

Yeah, Apple has lossless JXL-DNG capture as well as lossy.

Since which version did libjxl start blurring more than it should? Maybe we should tweak it a bit...

really? check Licenses.rtf

I've already done. There are license notices for other libraries like WebP's, LibTiff, LIBPng, JXRlib and more. None for JPEG XL

Libjxl 0.9 onwards started blurring a lot. I made a couple github issues [here](https://github.com/libjxl/libjxl/issues/3754) and [here](https://github.com/libjxl/libjxl/issues/3530)

Jyrki mentioned that the blurring degradations are likely due to the filtering strength, which is now butteraugli tuned instead of tuning by the human eye. He also said that fixing this issue will be easier if he receives more material to test with. So I opened a thread here for anybody to upload their own images. https://discord.com/channels/794206087879852103/1278292301038227489

Timecode 22:45, Episode 606: https://atp.fm

https://chatgpt.com/share/66f3a0a1-9a10-8009-b59e-77357f7aefa1

ChatGPT prefers AVIF over JPEG XL, QOI and WebP

<:KekDog:884736660376535040>

did you search "jpeg xl" or "libjxl"

LLM are just hallucinations machines

industrialised Dunning-Kruger

using metrics to tune the encoder will inevitably lead to embarrassingly bad blurring. Metrics harshly punish what looks great to the human eye and reward what looks awful.

including butteraugli and ssimu2

It's worrying that at a crucial time of jxl adoption, avif encoders are producing better-looking output while the libjxl encoder is getting progressively uglier over time.

At least libjxl is improving in other ways.

I really wish he used the CLI encoder and tried out the intensity target in order to bias <:JXL:805850130203934781>'s encoding to the darker areas

because that's what I'm always doing for lossy JXL <:YEP:808828808127971399>

well, especially for low quality more sharpness looks better than less

You shouldn't have to use additional settings and explicitly TELL the encoder not to blur and destroy details and texture in shaded regions. Detailed shadows is what make images pop and have depth

A perceptual codec with "perceptually uniform quantization" should realize that small differences in light intensity make a bigger difference in dark regions because our eyes adjust and use a different scale in the darkness.

Whenever there are many adjacent dark pixels that aren't next to really bright pixels

Unless there's something really bright in the same region preventing the eye from adjusting

With bright and dark overlapping each other.

If it's a continuous, shaded region then humans are going to notice if they suddenly can't see anything in the shadows anymore after encoding to jxl

We need to stop tuning for just metrics

<@532010383041363969> what *was* the reason for changing from manually adjusted to butteraugli based filtering? To handle a more diverse image set?

There is no mention of anything relating to any reasonable way you'd spell JPEG XL or libjxl

interesting, cause I don't have the program and can only google it but someone on the internet (I know, I know) said they found it

`Filename.jpegxl`

Moral of the story is metrics are completely useless nonsense and none of the metrics have any clue what "perceptually uniform" is, nor even tell the difference between uncorrelated noise that is easy to "see through" to the original signal underneath, and distortion that completely hides and destroys the original signal. All of the metrics seem to prefer distortion that hides and destroys the original signal

I still think it's important to come up with better metrics though. Metrics and codecs need to be tuned by human perception. Tuning a codec with metrics is like circular logic

It's like trying to tune two guitars that need tuning by listening to each other

This is from version 2.5.5 of Affinity Photo

I'll remove the file again if it isn't allowed to be distributed

I dug around inside the app, and it's not in the Frameworks: `liblibacs.dylib liblibaffinity.dylib liblibbmp.dylib liblibbook.dylib liblibcfitsio.dylib liblibcommands.dylib liblibcurl.dylib liblibde265.dylib liblibdwgimport.dylib liblibeps.dylib liblibepub.dylib liblibexpat.dylib liblibfonttools.dylib liblibgeometry.dylib liblibgif.dylib liblibgl.dylib liblibhdphoto.dylib liblibheif.dylib liblibhunspell.dylib liblibicu.dylib liblibidmlimport.dylib liblibipc.dylib liblibjbig2dec.dylib liblibjpeg.dylib liblibjpeg2k.dylib liblibjsoncpp.dylib liblibkernel.dylib libliblf.dylib libliblittlecms.dylib liblibmetadata.dylib liblibnetwork.dylib liblibocio.dylib liblibopenexr.dylib liblibp2p.dylib liblibpersona.dylib liblibpk.dylib liblibplugins.dylib liblibpng.dylib liblibpsd.dylib liblibraster.dylib liblibrastertools.dylib liblibraw.dylib liblibregex.dylib liblibrenderer.dylib liblibscripting.dylib liblibsnowplow.dylib liblibstacktrace.dylib liblibstemmer.dylib liblibstory.dylib liblibtga.dylib liblibtiff.dylib liblibwebp.dylib liblibxml.dylib liblibzlib.dylib liblibzstd.dylib libpdfimport.dylib libpdflib.dylib libxmp.dylib`

That's interesting, did they link statically to it or something?

`find *.dylib -type f -print0 | parallel -0 'if strings "{}" | grep -qi "jxl\|jpeg xl"; then echo "{}"; fi'` produced: `liblibplugins.dylib liblibraw.dylib liblibpersona.dylib`

ProRAW-only?

This moment really makes me regret not continuing my project for detecting object code reuse

`find *.dylib -type f -print0 | parallel -0 'if strings "{}" | grep -qi "libjxl"; then echo "{}"; fi'` produced `liblibplugins.dylib`

And the size of that?

11.2 MB

they list the adobe DNG sdk so they may be doing it through that?

protip: `grep -al 'libjxl' *.dylib`

`grep -a` is `--binary=files=text` which tells it to grep files detected as binary anyway

and `grep -l` is `-l, --files-with-matches print only names of FILEs with selected lines`

allows you to do tricks like this

``` $ grep -al 'eXIf' /usr/lib/*.so /usr/lib/libexiv2.so /usr/lib/libMagickCore-7.Q16HDRI.so /usr/lib/libopencv_imgcodecs.so /usr/lib/libOpenImageIO.so /usr/lib/libpng16.so /usr/lib/libpng.so /usr/lib/libspng.so ```

Would the Adobe DNG SDK allow them to export and import .jxl files? AP2 doesn't support DNG 1.7 with JPEG XL compression

For RAW photos they use libraw

https://community.adobe.com/t5/lightroom-classic-discussions/certain-raw-files-export-unusually-large-with-jpeg-xl/m-p/14881167

looks like lightroom implementation isnt much good

it produces a jxl with alpha?

``` Alpha: min: 64069 (0.97763) max: 65535 (1) mean: 65535 (1) median: 65535 (1) standard deviation: 3.74241 (5.71055e-05) kurtosis: 91367.7 skewness: -293.478 entropy: 5.80654e-05 ```

why?

my first guess would be a merged HDR stack

the images don’t align perfectly and so there’s a small border

it's just a few pixels that are not fully opaque, and even those are over 97% opaque

when exporting to avif or jpeg, it just drops that alpha channel, but when exporting to jxl it keeps it

it doesn't make a big difference for compression but it is quite bad for decode speed to add unnecessary alpha channels to big images

oh wait

looks like they do some non-standard setting of faster_decoding

which does something messed up when there's alpha, it seems

``` bash-3.2$ cjxl skyline_cemetery_20240628_0J7A5396-HDR-2.jxl -d 1 skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.jxl -e 6 JPEG XL encoder v0.11.0 0.11.0 [NEON] Encoding [VarDCT, d1.000, effort: 6] Compressed to 5548.6 kB including container (1.377 bpp). 6954 x 4636, 10.394 MP/s [10.39, 10.39], , 1 reps, 12 threads. bash-3.2$ cjxl skyline_cemetery_20240628_0J7A5396-HDR-2.jxl -d 1 skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.jxl -e 6 --faster_decoding=3 JPEG XL encoder v0.11.0 0.11.0 [NEON] Encoding [VarDCT, d1.000, effort: 6] Compressed to 62014.7 kB including container (15.389 bpp). 6954 x 4636, 16.259 MP/s [16.26, 16.26], , 1 reps, 12 threads. ```

<@179701849576833024> could you take a look? seems like faster_decoding is causing some really bad choices for alpha

It doesn't happen on images without alpha, just when there's an alpha channel: ``` bash-3.2$ cjxl skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.ppm -d 1 skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.ppm.jxl -e 6 -x color_space=Rec2100PQ JPEG XL encoder v0.11.0 0.11.0 [NEON] Encoding [VarDCT, d1.000, effort: 6] Compressed to 5537.4 kB (1.374 bpp). 6954 x 4636, 11.637 MP/s [11.64, 11.64], , 1 reps, 12 threads. bash-3.2$ cjxl skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.ppm -d 1 skyline_cemetery_20240628_0J7A5396-HDR-2.jxl.ppm.jxl -e 6 -x color_space=Rec2100PQ --faster_decoding=3 JPEG XL encoder v0.11.0 0.11.0 [NEON] Encoding [VarDCT, d1.000, effort: 6] Compressed to 5592.8 kB (1.388 bpp). 6954 x 4636, 17.512 MP/s [17.51, 17.51], , 1 reps, 12 threads. ```

Alpha defaults to lossless currently even with a lossy quality set, right? So it's just the usual bloat from faster decoding of lossless files

Try adding `-a 1` too

Yeah but the gap between default and faster decoding should not be that big, that's ridiculous

It's storing alpha almost uncompressed, looking at that bpp difference. Something must be very wrong.

https://github.com/libjxl/libjxl/issues/3532

Seems like 3 and 4 are affected now too