JPEG XL

I see it as a recurring gag, a bit like gif vs gif

you know what looks coolest?

JXL

So, no images wider/taller than 65,536 pixels? That's kinda tiny!!

what about my 5 GPx images? 😦

Jpeg xl sounds like the image will be larger than regular jpeg. So I prefer JXL

I mean, when will user see next to each other jpeg xl and jpeg xs they will think xs will be smaller 😄

are my jpeg xl images being sen to google?

the comments section on Phoronix is commonly unhinged

I have never seen him reply to people pointing out his mistakes.

too much work ?

making youtube video = money reply to people pointing out mistakes = not money 😄

That typeface almost made me vomit honestly

The reliability of contents using Comic Sans-like typefaces is always questionable

"JPEG-XL" is actually searchable. Trying to search JPEG XL or JXL results in "too few symbols" error in most sites

"JPEG XL"

Does not work in some sites, sadly

https://letmegooglethat.com/?q=JPEG+XL

it's not bad for search engines, but discord's god awful search still messes it up a lot

If a search engine can manage to produce results for "hot dog" that are not all about sweating pitbulls, it should also be able to return sensible results for "jpeg xl".

You overestimate most site engines. Many don't even use Elastic(Open)Search/Lucene, just plain SQL.

every search engine should support three modes of operation, Grep, Fuzzy, and whatever discord does, I don't know why on earth people want that, but apparently some do

there was a campaign at the time for the lycos search engine (Lycos !) which put side by side Enceinte (speaker) and Enceinte (pregnant) to brag about their context aware search engine

yeah, for discord even "jpegli" is unsearchable, it will be anything that contains jpeg or something even worse

OK, some decent news! ATP read the follow-up email I sent in to them. Episode 603, 16:10 https://atp.fm

A pretty good followup, wasn't expecting effort levels to be mentioned but they seemed to like it. Might've been worth getting some more ideas here before sending the email, but still good to hear them talk about it nonetheless

So it started out VERY long and it was suggested I trim it waayyy down, which I did. I ran it by <@794205442175402004> quickly. Unfortunately they didn't read it all (not surprisingly). I knew John would be into the tech details of cjxl, so I tried to throw in as many of those as I could.

Ahh right, fair

huh, trying to generate this image on browser throws `R is undefined` error on firefox

and then on chromium it throws `Cannot read properties of undefined (reading 'byteLength')`

JPEG-XL is comparable to Iphone and MacOS

Seeing them always makes me disgusted

what about “Archlinux”?

X.264/X.265

xHTML

x.com

Even Apple is wrong by spelling USB 4

If the trend can't be stopped, we will see JPGX, jpegXL, etc.

Jpeg_Xl

JxL

J.P.E.G. extra-large

Actually to get really pedantic, the correct spelling is "JPEG XL"

That's a non-breaking space between the JPEG and the XL, not a regular space

I’d just like to interject for a moment…

(Stallman’s response to the text is almost funnier than the original https://www.gnu.org/gnu/incorrect-quotation.en.html)

JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL see how it never breaks the line at the wrong spot JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL JPEG XL

lol, a failed test for me as it cutted nonetheless between *it* and *never*

you can play around with resizing the window

I did, but the defaut rendering was funny

Having the linebreak between JPEG and XL is kind of awkward, and I suspect one of the reasons some people like to write "JPEG-XL" is that it is easier to type (or to remember how to type) a hyphen than a non-breaking-space.

Almost certainly, I wasn't even aware non-breaking spaces existed

really ? but what to you put between text and colon : or text and exclamation mark !? or text and question mark ?!

In English there is no space before exclamation/question mark, so it's not an issue. In French there is, but I expect most layout engines would be smart enough not to do the linebreak just before the punctuation, even if a regular space is being used?

Facebook’s layout engine is most definitely not smart

it even goes as far as replacing my non-breaking spaces with normal ones

I hate it

Word/Libreoffice just auto replace the space with a non breaking space while you type IIRC, I don't even know the shortcut to insert one with a fr keyboard layout 😄 (ubuntu one)

whydoweevenbothertohavespaces?

in bépo, it’s Shift+Space for a non-breaking space and Shift+Alt Gr+Space for a thin non-breaking space

bépo !

indeed

(you’re actually supposed to use the thin kind before punctuation)

japanesestyle

well, not quite “before”, but rather “inside”

which, for colons, semi-colons and exclamation and question marks, is before

reminds me of the SI units library for LaTeX, which has the amazing feature of putting the correct amount of space between the number and the unit

yes, I love that package

also the correct dash for ranges

I love typography for its infinite possible amount of pedantism 😄 (without offending anybody)

https://thejenkinscomic.wordpress.com/2024/05/02/pedants-club/

TeX is probably the only place in the whole universe that still puts more space after sentences than between words

nah, some people put two spaces after full stops

You sovnd like an ancient Greek or Roman.

😄

let's bring back roman cursive and using wax tablets for note taking

Breaking news: Apple announces the iWax!

It may look a bit old-fashioned, but it's gonna be a very hip thing to carry around. And the battery life is amazing!

warning: users may experience issues in warmer climates

or a Fortran programmer

(in fixed form, spaces are optional)

Of course it comes with a very expensive iStylus with a gold-plated tip, and an iScratcher made of precision-milled aluminum that you can use to wipe the wax to reset it to a perfectly clean state.

```fortran programbcch implicitnone externalcch reala,b,tol,cch integeribis,nmax read*,a,b,tol,nmax callbis(a,b,cch,tol,nmax,ibis) print*,a,b,cch(a),cch(b),ibis endprogrambcch ```

well, almost, you do need the initial 6 spaces so that the code starts on the 7th column

o.o

I like how it causes Discord’s syntax highlighting to only recognise “print”

JPEG&nbsp;XL

just shorten it, JPG-XL <:megapog:816773962884972565>

is this for one of those languages that puts question marks around the whole sentence?

planned obsolescence: you can only use it so much before you reach a metal block in the middle that could have easily not existed

x-post from AV1 for Dummies https://www.macitynet.it/jpeg-xl-jxl/

It's actually a pretty comprehensive explanation, I'm impressed

apparently fab wrote it

i would read it but firefox's internal translator sucks

In early days there's no space in article titles on Wikipedia

Such as WhatsTheRelationshipBetweenWikipediaAndNupedia

ListofListsofLists

imagine this article https://en.wikipedia.org/wiki/Cneoridium_dumosum_(Nuttall)_Hooker_F._Collected_March_26,_1960,_at_an_Elevation_of_about_1450_Meters_on_Cerro_Quemaz%C3%B3n,_15_Miles_South_of_Bah%C3%ADa_de_Los_Angeles,_Baja_California,_M%C3%A9xico,_Apparently_for_a_Southeastward_Range_Extension_of_Some_140_Miles

The old wiki software is the easiest to add JXL support however

MediaWiki JXL?

No, UseModWiki

Just add jxl in one line and it's done

Is it basically just registering it as an image format?

As there's zero process on handling images like most of other softwares

So it’s literally as simple as adding a new MIME type to EngineX?

$ImageExtensions = "(gif|jpg|png|bmp|jpeg)";

Also for MediaWiki https://phabricator.wikimedia.org/T270855

JPEG-XL JPEGｰXL JPEG—XL JPEG⸺XL JPEG⸻XL All one symbol dashes <:YEP:808828808127971399> 3rd one actually looks good

I wasn't aware of the existence of a non-breaking space

until now

Wonder if the next codec will be called JPEG XXL

and then JPEG XXXL

sony and philips may hear about JPEG-XL and make their own slightly different format called JPEG+XL

JPEG Super Extra Extremely Bigger Edition

maybe JPEG 1 should be the one named JPEG XL

and the format this server is focused on should be JPEG XS and what is currently JPEG XS , im not sure what we could call that, as it's not really a distribution format

Often used in wikipedia

em dash?

i dunno, I like JPEG extremely-long XL

longest is "three em dash" yeah <https://en.wikipedia.org/wiki/Dash#Unicode>

and then the FSF will create JPEG/XL

a JPEG system with XL kernel

Apple's gonna call it "JPEG ProXL" or something stupid

on the Google Pixel 9 it will be called it "Ultra XL" and on the Samsung Galaxy S25 it will be "Super XL"

Nintendo will probably write XL in such tiny font that it looks like a slight revision over the original JPEG

My phone already has `JPG-L` for a jpeg at the actual sensor resolution, I was very dissapointed when I tried it after a firmware update and imagined an X in there too :P

an article in German. Mentions XnConvert and IrfanView https://www.chip.de/news/Das-Ende-von-JPG-Wer-den-Bilder-Koenig-vom-Thron-stossen-koennte_185424775.html

iJPEG XL

IrfanView plugin is buggy and limited, unfortunately

Reminded me the chaos between DVD-R/RW and DVD+R/RW

(that was indeed the joke)

The fourth result of "jpeg xl" on DuckDuckGo is JPEG XL, the New Image Format Nobody Wanted or Needed

For me it’s entry 9

> nobody needed or wanted Meta, Intel, Apple, Shopify, The Guardian, Cloudinary, 3/4 of Google

it’s not even among the first ~70 results for me

What region are you set to?

I've disabled the region option

I turned mine on and it’s now 16th

Safe search disabled too

Never use it personally

Switzerland, French language

Wow that reaches top 3 when safe search is set to moderate

I’m curious as to what result was downgraded due to safe search

caniuse

Ah yes, CanIUse, the most objectionable site ever

Sometimes results may be slightly different after refreshing

The following post https://x.com/stalman/status/1832957792187261415

Hmm... The "Signature Dish" comparison between JPEG and JXL, when you select "compare size" and it's normalized to SSIMU2=50, low quality... the JXL version is clearly visually inferior to the JPEG in terms of visual acuity and retention of details, despite the matching SSIMU2 score.

Someone ought to look into that as that's an obvious fault with ssimu2. Maybe a better comparison image can be chosen too, in order to better illustrate the strengths of the libjxl encoder for particular types of images.

The press website for jxl/libjxl should be as positive as possible and easy for journalists to understand the benefits even when the journalists lack the training and discipline to understand the complicated nuances of lossy codec comparison

This is probably another instance where JPEG XL is overblurring high-distance images

It's more of an issue with ssimu2 failing to recognize that the JXL image is extremely blurred and nowhere close to matching the same level of detail and fidelity as the JPEG.

This is tricky for algorithms to recognize because it's hard for a computer to distinguish between distortion that interferes with human perception and changes the nature of the image, and uncorrelated high-frequency noise that's easy for a human brain to filter out and see through.

The JPEG probably contains more absolute, objective "noise" or "distortion" compared to the original, than the JXL version does... The difference is that in the JPEG the noise is almost invisible to human eyes and brain because it's mostly-uncorrelated HF noise, whereas the JXL blurs and pixellates the image which is extremely noticeable to the human brain and changes the image in a fundamental way.

This, in my opinion, is the most painful Achilles of libjxl and ssimu2 right now

agreed

Scrolling down further, to the AVIF comparison, the same failure can be observed, where the AVIF image consistently has sharper defined features and more texture compared to the JXL counterpart at the same SSIMU2 score.

if this is about https://jpegxl.info, we should probably talk about this in <#1256302117379903498>

I realize this might not be the most well received comment, in a server about JXL, but I am only bringing it up because I'm also a fan of JXL and I hope it succeeds and becomes the new universal image interchange.

Yeah, we talked about it before there that anything above e4 blurs it to oblivion

Yeah, <#1256302117379903498> could be better. But it's mostly a problem with the ssimu2 scoring software, actually.

4152

Since the image comparisons are normalized with it, and it consistently fails in most of these comparisons to give a reasonable estimate of what is considered "equal quality"

Maybe it would be better to hand-select some images where the difference and the advantages of libjxl would be most obvious at a glance to a layman or member of the press.

I don't want to get too off topic here so that's all that I'll say in this channel. I hope my feedback manages to be constructive.

On the topic of <#822105409312653333> though, I will say this: I think more frequent releases, with more emphasis in the release notes on quality improvements, with before-and-after comparisons, would do wonders for positive press coverage and awareness of libjxl, since news outlets often report on whatever interesting-looking highlights they see in the release notes.

It's like the classic case where applying a small amount of uniform noise throughout an image is considered by the algorithm to be worse than changing a photo of a dog into a photo of a cat... In audio codecs there is a well established theory and practice of psychoacoustic "masking" and the same theory also works with images as well... but I don't think it's really applied and exploited to the same extent as it is in audio. Visual metrics don't seem to be capable of recognizing when uncorrelated noise is masked by the original input signal and thereby rendered imperceptible.

I agree, the 38 kb JPEG does preserve more detail than the 22 kb JXL. Then again it also has pretty noticeable ringing artifacts around most edges, and some obvious blockiness. I personally prefer the JPEG over the JXL (it preserves more information), but I also think it's true that if you don't have access to the original image and just see an image on a website, the JXL looks blurry but has no _obvious_ compression artifacts, while the blockiness and ringing of the JPEG makes it obviously compressed too much. Just to say: I'm not sure if this is an obvious fault with ssimu2. The JPEG and JXL are very different at ssimu2=50. I'm not sure if it's true that the JXL is clearly visually inferior. To me it is, but not by a huge margin — I dislike the loss of detail of the jxl (and I would never use distance=6.4 on my own images), but I also dislike the mosquitoes around the edges in the jpeg, and the blocking. Different people have different tastes when it comes to artifacts: some people don't seem to mind smoothing/blur much but they hate ringing, while other people like ringing ("looks sharper") and hate blur.

I agree with you, Jon, when you said in the past that fidelity to the original, and preservation of information, should be the priority, not things like appeal or smoothing that would fundamentally alter the nature of the original image.

I would prefer artifacts that are easier for the human visual system to "see through" or "cancel out" to get a better idea of what was underneath the artifacts.

The same issue can be consistently observed in the AVIF comparison images too. SSIMU2 consistently gives equal scores to images that preserve a lot less information and that look "obviously worse" to my own eyes.

I long for a day where modern psychovisual models are as good as modern psychoacoustic models, and images with obvious compression artifacts are as rare as audio with obvious compression artifacts.

At lower scores, ssimu2 is more about appeal than about fidelity. It was tuned with cid22, tid13 and kadid10k. Cid22 is mostly about higher qualities and fidelity, the two others are mostly about low quality and appeal. So the end result is a bit of a mix of those two things...

I think ssimu2 < 60 should just be avoided in most use cases.

Nothing wrong with appeal, in my book, as long as it doesn't come at the expense of preferring a completely different image to a slightly-noisy image, otherwise we're back at the embarrassing cat vs dog situation again

It looks more like a failure to take into account the effects of noise masking to lessen the impact of certain types of distortion

You're not gonna get cat vs dog with ssimu2, but yes, it will prefer blur over less appealing artifacts. In particular it really dislikes banding and blocking.

Like for example, if someone uses a filter to remove the film grain from an image, and then they add the film grain back by using synthetic film grain, that would probably get a huge score penalty from algorithms like this, even though a human wouldn't really notice or care.

yes, synthetic noise is something all classical metrics have a really hard time with

Banding and blocking are really bad and it's good that ssimu2 punishes them severely. But blurring is basically just as bad, to most people's eyes I would think, especially since it also has potential to alter the image insidiously. If blurring was punished just as harshly as the others, and decorrelated and masked noise was punished less, that would be perfect.

Well, maybe not just as harshly... But at least half as harshly.

I hope with AIC-3 we'll at some point get more good subjective data to tune metrics, so I can make a ssimu2.2 or ssimu3 that does a better job. For now, I mostly had to use old datasets like tid13 where blur is not punished very harshly due to the testing methodology they used — side by side comparisons, as opposed to the in-place ones we're using in AIC-3. When doing in-place comparisons, blur is way more visible/problematic than when doing side-by-side comparisons.

It's very crucial to the future of image compression that the noise problem is addressed some day... In the audio world at least, it seems to be a long-solved problem...

The livestream where the iPhone 16 will be announced: https://www.youtube.com/watch?v=uarNiSl_uh4 (10am PT / 7pm CEST, in about 4h20m)

Could always have an optional "metric mode" that loves blurring and a "psycho mode" that completely throws metric scores out of the window and does worse than JPEG according to metrics but uses uses a lot of noise masking techniques to retain the most texture and fidelity better than anything else out there.

today was september 8th though

i think this is a great idea

like further psycovisual tuning but at the detriment of the objective metrics?

sounds like svt-av1-psy

all for the idea

Honestly I think tuning for metrics is a wasted effort in the first place unless you're optimizing for manipulating the press and manipulating the results of (common but lazy) automated evaluation.

objective measurements will never be as good at saying what looks better than your eyes

(unless you're me)

Maybe you could call the one optimized for humans "psycho mode" and the one optimized for computers "sicko mode" :)

This again returns me to the question about what is changing on e4 -> e5, because all that blurring starts on e5, and with e4 jxl image looks much more like jpeg 🤷‍♂️

Humans are too different 😦 Jon says he does not like ringing and blockines on par with blur (if I get him correct), but for me blurring out details is much worse than ringing

Most humans are accustomed to ringing artifacts without even realizing they are there, because ringing is common in a lot of digital cameras. In the built in digital filters that you can't even disable. In a lot of image resizing and sharpening filters. Most humans can't even notice excessive amounts of ringing until you point it out to them several times.

Blockiness is very bad but not as bad as banding, and arguably equally bad as blurring. Both blockiness and blurring can usually be eliminated by resizing the image. Blockiness usually retains information better than blurring though.

They're grown on low quality jpeg 🙂 Especially older people who saw dial-up internet and floppies

When viewed in 1:1 scale, blockiness is harder to notice than blurring.

I don't think it's as complicated as it sounds to optimize for human perception, as long as you stay focused on the task of optimizing for detail retention and fidelity as the ultimate goal.

Instead of appeal.

If you ignore what looks best to your eyes and your own subjective sense of appeal, and only ask yourself, which one contains more information about the original image and less deceit, then it's a much, much simpler task to optimize for human perception.

What’s ringing again?

Halo-like waves around sharp edges

DCT rings?

Yes, or think about an exaggerated edge-sharpening filter.

https://en.wikipedia.org/wiki/Ringing_artifacts

Yeah, ringing is kinda a general thing for any form of signal processing not even just digital, where as banding and blocking is really digital looking

Anyways, as long as you're NOT aiming to please everyone's visual preferences or sensibilities, and only aiming for "maximum preservation - minimum deceit," judging which version of an image is "better" becomes incredibly straightforward and obvious. Like Jon has said in the past, the purpose of a codec is preservation of the original signal, not an instagram filter.

But then what counts as “more information”?

Also HEIC and AVIF be the skin smoothing filter

More information = The human is able to know more about how the original signal looked.

This is why you compare with multiple metrics like butteraugli and dssim, these metrics punish blurring more heavily

Less information = The human can't perceive as much of the original image. Or worse, misled about what the original image looked like.

Oh, dssim is by the pngquant guy. Cool!

Yeah, Kornel has made some cool stuff!

indeed. I hope he plays around with jxl coding :)

he makes amazing tools

I use pngquant & dssim a lot <:Stonks:806137886726553651>

^ <@826537092669767691>

Time for the real coverage in about 2.5 hours later

fyi, the event seems to be in HDR again like the last one probably just works™ on apple's site on apple devices, but it also works on windows on the apple tv app (no account required)

Tim Apple comes

Who the hell is Steve Jobs?

The hell knows

No mention of JPEG XL for Apple Watch

not entirely unsurprising

Also the noise-cancelling earbuds do not support JXL, disappointing...

So cringe how they use "Apple Intelligence" instead of AI

even before they introduced that term, they never used the terms "AI" or "artificial intelligence", I think. Only "machine learning".

Hm, the segment on the camera is done, no mention of jxl yet?

maybe they think image formats are too boring and it'll just silently be available when the phone launches

If they just tack it on a whiteboard at the end again....

that would not be surprising tbh

quick someone pre-order an iphone the millisecond the store comes back

Clearly new pastel colors for the phone case are more exciting than new image formats.

https://tenor.com/bw15F.gif

Oh, they have a separate thing about the iPhone 16 Pro? Ugh why am I watching this hype nonsense

inb4 jxl is iphone pro exclusive

Always like that

heef

global shutter? neat

Also nothing on jxl in the Pro segment, it seems.

Could just be me, but they've certainly done a good job hiding any hint of what format the photos were taken in... Then again Apple have always hidden the camera format settings

i like how the livestream video compression makes the high quality video footage look terrible

>meters i thought this was america

well nothing at all about jxl

Nope

Yeah, a lot of changes to the camera though

maybe the DNGs will contain JXL

So that's false rumour

Who would've guessed every news outlet reporting on a single rumor wouldn't end well

where's that info?

https://www.apple.com/iphone-16-pro/specs/

ty

Now I am curious where the rumors came from

could be a case of old info getting mixed up with new then spread around?

Created the largest hype ever of JXL server

I could easily see it being someone in the chain of the rumour misunderstanding a move to the newer DNG spec

or maybe someone just made it up

Well if they are using jxl payloads in DNG, I guess the rumor is still kind of true.

it is, or they would have spelt it “metre”

How can we find out what kind of DNG the new iPhone is producing?

i guess we have to wait until someone gets a hold of one and tries it

if i know someone who gets one of the new iphones ill ask them to try it

https://support.apple.com/en-us/119916 about ProRAW

Assuming they are, I'm mostly curious if they're just using the Adobe SDK or if they made their own, actually logical, implementation

iOS 18, iPadOS 18, macOS Sequoia and watchOS 11 will be available on Sep 16

I have the beta installed already

unfortunately ipad air apparently doesn't allow raw capture

Timing-wise, I was surprised by those rumors about jxl in iPhone 16. To me it made more sense to do it next year, when likely there will be a hardware encoder available and when at least within the Apple ecosystem jxl decode support will be universal (currently it isn't quite yet, not everyone has upgraded already). But within DNG it would make sense, like Samsung did... Curious if they're doing that, or just the old DNG.

Should we expect the hardware encoder to be competitive with hardware encoded HEIC? Since it's likely to only use a subset of simpler to implement parts of the spec.

It will be similar to libjxl-tiny

At camera quality it shouldn't be much worse than libjxl e4 or so

(software encoding mostly makes a big difference at web quality and lower)

I wonder how HW encoders for JXL will do all the math. Going full fp32 would probably either be too expensive (if fully pipelined) or too slow (if just a couple of fp32 units are used in a loop for everything)

They do it in fixedpoint arithmetic

Probably 18 bit or so

Maybe number of bits will be different in different parts of the pipeline

Also the big DCT transforms are just not implemented, probably only 8x8, 16x8, 8x16, 16x16 or so. That also helps to keep the math easier in fixedpoint.

for fancy 14-bit camera sensors, I hope (i don't actually know) that 4 bits of headroom is enough to have very little in the way of rounding errors

Well the hw encoder would be for lossy in XYB, not for storing Bayer data

But yeah, 13-14 bit XYB is plenty even for wide gamut HDR, and then a few bits extra for the DCT, basically.

Anyway, whatever Apple is gonna do right now, is gonna be in software. Unless they secretly designed their own hw jxl encoder (I doubt it).

I guess it will be either jxl-in-DNG, or no jxl at all for now. Or maybe jxl after all, as an option they for some reason don't want to brag about.

would be weird to not have it in the spec sheet even if they didn't care to advertize it

Although if it were to be lossless, it would use the fast lossless currently used in cjxl e1, so up to 16 bit ints if I recall

Hm, but pretty much everything that stores Bayer data these days is some form of lossy designed for photos (DCT, wavelets, etc)

So if you want to do hardware accelerated encoding for, say, JXL-DNG, you'd want to do VarDCT, not Modular

Yeah, basically something like d0.5 to replace camera-quality jpeg and d0.1 to do "lossy raw". For lossless raw you can probably do libjxl e1 in software on a phone and it is fast enough.

Would it be best to convert R, B, and average G to XYB, and then G-diff as a modular extra channel, or to store RGGB as four separate grayscale VarDCT frames?

For "lossy raw" you just store a debayered image.

storing lossy bayer data is very common AFAIK

Storing a debayered image is what Apple's ProRAW has been doing for a while if I understand correctly. Don't bother with storing actual raw RGGB, just store a debayered image with enough precision. People care about having dynamic range available, being able to adjust color without getting hit by blown up compression artifacts.

I know that some high end film cameras store lossy jpeg2000, 4 grayscale frames per actual frame

yeah I think it makes sense. A few of photographers have told me that they want to have control over the debayering process so they don't want such "raws"

But personally I prefer to not have to think about Bayer stuff, so high precision debayered data sounds good to me

debayered DNG has occasionally been called “Linear DNG”

if you’ve ever come across that term, that’s what it refers to

I wonder to what extent it really makes sense to do custom debayering as a photographer, as opposed to leaving it to the camera to do it in a good way — and allowing camera vendors to innovate in how exactly they do things, since 2x2 Bayer patterns is certainly not the only way to do it.

I think some vendor camera software implements the exact algorithms actually used on board the camera

And I *believe* that some raw files from some cameras can't be handled by open source tooling due to having weird bayer stuff that hasn't been implemented in those open source tools yet, so I think there's some innovation (maybe)

I'm still very annoyed Adobe didn't use the CFA channel type to store JXL DNGs, or tile size properly...

It kind of makes sense from the DNG spec point of view to use jxl as just a 'dumb' payload encoding so they can treat it symmetrically with the already existing encodings...

I wish we could move to just using JXL files instead of DNG though, with just a box for whatever proprietary camera maker stuff they want to add but a main image that is just a standard, interoperable image.

As far as I can tell, there's not really any reason we couldn't. It's just image data, either RGB Linear or a greyscale bayer, then a lot of metadata. The real hurdle would be getting the RAW editing software to read the JXL files properly with the presence of the metadata or the CFA channel

I tested LOTS of images. I picked the ones that performed the best on paper, since it was just too time consuming to do full a/b comparisons for every set.

We can always tweak it further. Probably we are currently going a bit too low quality, and doing the comparisons at d1-3 instead of up to d6, with 2x zoom, would be a better way to show the difference between jxl and jpeg/avif.

Anyway, I have to admit I am a bit disappointed that the rumors about jxl in iPhone 16 turned out to be either false or only about DNG. It's not going to give the visibility to jxl I was hoping for. Then again even the rumors did help to spark some interest, and maybe it will still help to get Apple to add it later, in an iOS update or in the iPhone 17...

Now the speculation can start about where these rumors came from: was it just baseless speculation, was it something they were actually planning to do but couldn't finish in time, was it cancelled last minute for some political reasons, ... ? I guess we'll never know the full story.

Not sure why so many were citing it as a confirmed thing either...

Software rumors have often been off by a year in the past too <:AngryCry:805396146322145301>

Ah well, at least now we have time to get the website looking it's best

and to get Firefox and Chrome to catch up 🙂

If someone could get the 2-3x zoom back into the comparison tools, that would be awesome. We pulled them cause they were causing havoc on the mobile sizes. We also wanted to implement a "compare to original" we never got around to

Maybe we could reuse this three-way comparison interface from the webp folks: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2024_09_04/visualizer.html?bimg=..%2Fclic_validation_2021_2022_2024%2Fimages%2Fcasey-fyfe-999.png&btxt=original&rimg=encoded%2Fcasey-fyfe-999.444e8q034.jxl.png&rtxt=JPEG+XL+4%3A4%3A4+effort+8&limg=encoded%2Fcasey-fyfe-999.444e6q033.avif&ltxt=AVIF+4%3A4%3A4+speed+6

Yes, that's what I'd hoped for for the full page comparison tool

If you don’t show the CFA layer or the green extra channel does it still look normal after colour correction?

Who knows, maybe iOS 18.1

I’m installing it on my iP14pm

Does Exiftool tell you what format it’s using?

I don't know but you could upload the DNG here or elsewhere and we'll try to check?

That was in response to the image comparisons on the new website, but if I recall yes, RAW JXLs would display using RGB bayer offset to align, with the extra G stored in a CFA extra channel only used when decoding as RAW data. Been a long time since this was mentioned though, so I could be wrong

Yeah, it also says the encode parameters with Adobe's implementation

I’ll Exiftool a RAW image

It’s odd that every other format has a badge but not JXL

Wake up <@794205442175402004> ! https://www.macrumors.com/2024/09/09/iphone-16-pro-supports-jpeg-xl-format/

nice

"according to code found in" presumably hints at someone stumbling on something in publically released materials, rather than a leak, which means that there should be a source they should be able to link to. But "journalists", for some reason, seem allergic to this practice.

oh! I notice that they linked to the new website, nice :)

<:Thonk:805904896879493180> https://news.ycombinator.com/item?id=41484914

Of course. I just hope I can be useful or constructive by my examining and giving feedback. :)

I noticed even one of the comments here on ycombinator is expressing confusion over how the JXL images look noticeably worse in the comparisons.

if it mentions the pro iphones specifically, couldnt it be about proraw (proraw max in particular)

I promise it wasn't me :)

proraw was dng 1.6 earlier, perhaps they upgraded to 1.7 and also added jxl as a codec for dng 1.7 (under high efficiency mode?)

if anyone knows a reviewer with a device they can talk about, might be worth asking about and get sample files from

iPhone 13 Pro Max after today's iOS 18 update:

> Bits Per Sample : 12 12 12 > Compression : JPEG

someone pointed me to the OS package for iOS 18 for iPhone 16 Pro and a decryption tool, wish me luck

with any luck I'll be able to grep the binaries for relevant strings

Were you using libjpeg-turbo for jpeg?

actually, I think I'm missing some tooling to run this stuff. If anyone is on mac and has Xcode installed, please download this: <https://updates.cdn-apple.com/2024FallFCS/mobileassets/032-87820/49E96347-486E-47BD-858A-202BD5A90E0B/com_apple_MobileAsset_SoftwareUpdate/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aea> and then decrypt it with this tool: <https://github.com/dhinakg/aeota>

nevermind this other tool worked <https://github.com/blacktop/ipsw>

My testing gives bit depth of 10 instead of 12

Weird

oh, double nevermind, the dylib cache can only be extracted if you're on macos...

Working on it!

Why are media people obsessed with that hyphen?

When asking my friend about the site they used `jpxl`

Not true. > HEIC is a lossy format, and while it retains better quality than JPG images, pros will likely prefer JPEG-XL for zero image degradation.

Similar to AVIF, HEIC can be lossless too

Yeah, I think so but I'll have to go through my notes. I originally compressed them back in May, so getting foggy. I only used mozjpeg for testing the progressive decoding I think.

Did a bit search and it's been like that for years

.jpgxl

So we went from rumors to an announcement that doesn't mention jxl and now back to rumors? I feel like I am getting trolled 🙂

An announcement about news of a rumour, in an announcement that didn't have the rumour, which now has a rumour about news of JXL being in the 16 Pro exclusively

Istg if they release it and it’s iPhone 16 only

https://x.com/jyzg/status/1833223807416381624

Most people would not care, I will 🤷‍♂️ Also software algorithms are improving with time, camera firwmare are not. And do not forget file size difference

Rephrase your question, please

You know how there is 2 greens per each red and blue, right? If the green pixel is stored in an extra channel, but is not rendered, does the image look fine with only the R,B and one of the Gs?

It is used for demosaic, without it you would have square without one quarter of information. It is first point, and second - idk the reason, but manufacturers some time have *different* green channel specs. I.e. slightly different dye, for example

so you can't render the R,G,B data before demosaicing?

No, of course. Demosaic is the process of 'guessing' 2 channels for each camera pixel, to create RGB value. One pixel in camera has only one 'channel'. And in the simplest approach demosaic is performed by squares of R, G, G, B (or any other bayer layout variant)

can't you just desample the image 2x each way and use the R,B and one of the Gs?

You will get 1/4 of possible resolution. I.e. for 24 mp sensor you would have 6 mp rgb image. It is possible, but noone would be happy with it

Also it leads to some very special artifacts in rgb image

weird colour aliasing?

Yes

Left - normal demosaic, downsize by 50%, right - demosaic by joining rggb squares to one pixel. Zoom to 200% to see difference

image isn't loading, what format is it?

Lossless jxl 🤷‍♂️

oh yeah, those colour artifacting

Joining RGGB into one pixel is effectively doing nearest-neighbor subsampling (mostly for R and B) with a wrong offset of half a pixel. It's ok-ish for a rough preview but not really great. I think for lossless raw, you just need to store the bayer data as it is (as 4 separate channels, maybe with avgG and deltaG to decorrelate those two), that's the only effective way to do it if you insist on mathematically lossless and keeping the sensor data exactly as it is. We _could_ represent it as RGB + deltaG so it's viewable at half resolution and with some artifacts on naive decoders (assuming the channels can be rescaled appropriately via some ICC profile), but I think it makes more sense to do it as lossy preview + four CFA channels. For 'lossy raw', I think it makes the most sense to properly demosaic and white balance first to create a normal RGB image (at full resolution) and then use high-precision lossy compression. It's not going to be as good as real lossless raw, but it can be way better than doing some additional processing and producing an 8-bit JPEG. I'd assume that for 98% of the use cases where people now use raw, 'lossy raw' would be good enough. And I think that with jxl, we could basically do 'lossy raw' in about the same file sizes as camera jpegs, but with enough precision to preserve the dynamic range and keep it editable.

Lossy preview in the preview frame?

So “lossy raw” is effectively ProRes and Log colour space?

nah just use the main color channels for the lossy preview (a regular vardct image, e.g. at half resolution and d2 or something) and put the RGGB in four extra channels.

I think ProRAW is more or less like that

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

yeah, it's just lossless JPEG

yeah, four extra channels of that type, with a channel name that follows some naming convention so applications know what kind of subpixel it is

would it make sense to apply some kind of RCT to them to decorrelate?

anyway, that's what _could_ be done, for now the only thing that exists in practice is DNG which just uses jxl as a grayscale code

yes, RCTs could be used to do things like converting G1 G2 to avgG deltaG

at this point, this format can do so much, can JXL help me pay my taxes or look for a career?

you wouldn't even need to use channel names

you can use the `cfa_channel` entry from Table D.8

ah right, that would be enough to identify which subpixel it is. Just need to store some other stuff somewhere, like what the Bayer layout is, what the scale is for each subpixel, etc

maybe a `dbyr` Debayer info box?

probably there is metadata from DNG that can just be reused and put in some box

the reason why i was thinking of the main channels is so that vardct could be used, as as far as I am aware you can't use VarDCT for extra channels, is that correct?

correct, extra channels are modular-only

is there specific reason?

vardct is kind of deeply hardcoded for dealing with 3 channels

if you really wanted to use it for extra channels, could you do some weird RCT permutation?

like have 3 empty Modular extra channels and RCT swap them with the VarDCT channels?

RCT only applies to the modular-encoded channels

oh ok

It is: CFA Pattern : [Red,Green][Green,Blue]

wouldn't it be funny if this "code found in iOS 18" is just the same code that was in iOS 17 to support JXL in Safari and other apps?

i tried searching on apple's developer site for any new API stuff related to jxl or dng, but didn't find anything (jxl isn't mentioned anywhere in the docs, as far as i can tell)

https://developer.apple.com/documentation/avfoundation/avvideocodectype/4354004-jpegxl

what

regular jpeg is also a video codec, apparently

AVVideoCodecType A set of constants that describe the codecs the system supports for video capture.

like, it's closer to video than audio

so this does seem to indicate support for capturing video (photo?) in jpeg xl, at least on the api level

anyone familiar with these APsI know what this constant being present actually means? can you actually use it for something?

Maybe they want to make Motion JXL?

for photo capture it seems like you'd pass it to this function: <https://developer.apple.com/documentation/avfoundation/avcapturephotosettings/1648673-init> anyone happen to have an ios device with ios 18 + a development environment? should be straightforward enough to take some camera capture sample code and just put jpeg xl in there, probably?

idk, just looks like they don't distinguish between video and photo capture formats in these APIs.. wonder what happens if you tell it that you e.g. want to record a jpeg video though, presumably it would return an error?

ProRes as a photo format?

Could work…

Could be Motion JPEG

It’s not listed in https://developer.apple.com/documentation/coremedia/cmvideocodectype

that's CoreMedia rather than AVFoundations though

<https://developer.apple.com/documentation/avfoundation/avcapturephotooutput/2991116-availablephotopixelformattypes> this should tell you whether the OS supports jpeg xl for photo capture

We need someone to run this function on iOS 18 https://developer.apple.com/documentation/avfoundation/avcapturephotooutput/1648654-availablephotocodectypes

I think that’s for raw data not for compressed codecs

oh yeah, i don't think the function i linked is the right thing

ugh, apparently these doc pages are dynamically loaded with JS, so older versions don't show up properly in the Wayback Machine

That original AVVideoCodecType is what’s returned, but that probably also be for decoding

Although it was added in 18.0 instead of 17.0 so it’s new

It’s probably what that news article meant when they said they “found JPEG XL in the code of iOS 18”

Can't some journalist just ask someone at Apple to confirm or deny that there will be jxl capture support? I know Apple tends to be secretive but I would imagine that _after_ the launch they should be able to answer such a question...

tcook@apple.com

I can say some people who write some pretty well known photography software on iOS had not heard anything about JXL support.

I was sent this: ```bash % plutil -p System/Library/PreferenceBundles/CameraSettings.bundle/CameraSettings-JpegXL.loctable { [snip] "en" => { "CAM_PRO_RAW_ENCODING_FOOTER" => "JPEG-XL offers improved compression over JPEG, resulting in smaller file sizes. JPEG-XL support is available on iOS 17 and later, and macOS 14 and later." "CAM_PRO_RAW_ENCODING_JPEG_LOSSLESS" => "JPEG Lossless (Most Compatible)" "CAM_PRO_RAW_ENCODING_JPEG_XL_LOSSLESS" => "JPEG-XL Lossless" "CAM_PRO_RAW_ENCODING_JPEG_XL_LOSSY" => "JPEG-XL Lossy" "CAM_PRO_RAW_ENCODING_TITLE" => "ProRAW Format" "CAM_SECONDARY_PHOTO_FORMAT_FOOTER_RAW12_JPEG_XL_LOSSLESS" => "• 18 MB for ProRAW at 12 MP" "CAM_SECONDARY_PHOTO_FORMAT_FOOTER_RAW12_JPEG_XL_LOSSY" => "• 11 MB for ProRAW at 12 MP" "CAM_SECONDARY_PHOTO_FORMAT_FOOTER_RAW48_JPEG_XL_LOSSLESS" => "• 46 MB for ProRAW at 48 MP" "CAM_SECONDARY_PHOTO_FORMAT_FOOTER_RAW48_JPEG_XL_LOSSY" => "• 20 MB for ProRAW at 48 MP" } } ```

<@794205442175402004> JXL-in-ProRaw confirmed (seemingly)

> "JPEG Lossless (Most Compatible)" is this option just to encode to JPEG then transcode to JXL?

RAW compressed by JXL? sounds like a dream

so similar to what DNG does, but different?

I would assume that that just refers to standard oldschool Lossless JPEG as supported by DNG for a long time.

Those are just some strings, but they look quite promising: if they are offering both lossy and lossless settings, and the lossy setting is at a high bpp like that, I think both settings will be quite nice!

ProRaw is just DNG with a few extras, so probably it's exactly the same as what DNG does

ah I see

then it makes sense

I'm going to bet that the lossless mode is e1

but I guess we will find out 😛

I assume that's for images, or is that for video too? if so the CPU they have is quite impressive xD

ProRAW is for still images

yeah makes sense

it seems to be basically a subflavor of DNG 1.6+, looking at https://www.loc.gov/preservation/digital/formats/fdd/fdd000594.shtml

At e1 they should be able to do 48 MP easily — remember that's grayscale only, or rather, four channels of 12 MP each.

Does anyone know precisely which method of compression ProRaw uses? If the table of options above lists all possibilities, it seems that they are only using Lossless JPEG right now, so I presume JXL will be a pretty decent improvement?

so probably less than 100ms or so

from the LoC article: > On iPhone 14 Pro, Apple ProRAW images can be captured at two resolutions: 12 megapixels (approximately 25MB in size) or 48 megapixels (approximately 75MB).

if it matches some data I saw in the past... yup, pretty substantial improvement

1.5x to 2x or 3x depending on resolution I guess

not bad at all

If they want to do their fancy processing with JXL, I assume they're still going to store debayered data

it will be interesting to see some samples of this

In my old testing, Abode's implementation was 20% smaller than lossless jpeg, but they also had strange tile sizes and were using effort 7 with decode speed 4. This morning I was telling Jyrki about it on twitter, 672 x 752 tiles https://discord.com/channels/794206087879852103/805176455658733570/1259094540082741338

So it really comes down to if they're using a custom implementation or are just reusing the Adobe SDK with additions

That also doesn't seem right, unless they're being stored uncompressed by default. My phone also takes 12 megapixel RAWs but they're 24 MB uncompressed DNGs

seems to match the image whose metadata was posted eariler

They must have a *lot* of extra data, because 18 MB at 12 megapixels is almost 3x larger than the JXL compressed DNGs I get from those 12 megapixel files from my phone Or thinking about it, a much lower effort maybe with the decode speed filesize bloat

does anyone have typical compression ratio figures for JPEG-LL?

Might be vaguely useful

12 megapixels is 24 megabytes uncompressed if you assume the data is 16-bit bayer data; if it's 12 megapixels of debayered RGB pixels in 16-bit then it would be 72 MB uncompressed

Riight, forgot they use Linear

which kind of lossless JPEG is DNG even using? There's the lossless mode from the original 1992 jpeg spec (which is basically just like a DC-only jpeg with some slightly better prediction, iirc), but there's also JPEG LS from 1999, and in particular JPEG LS part 2 from 2003.

I would assume/hope they're using JPEG LS part 2, which is actually pretty decent as far as lossless compression goes. IIRC it is also used in DICOM.

as in: about as good as lossless JPEG 2000

I think it's the original 1992 one but I'm far from sure

(for photographic images — none of these are any good at nonphoto)

guess I'll have to read a bit of https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_1_0.pdf

looks like you're right. So in that case there should be a pretty nice improvement when moving from lossless JPEG to lossless JXL

25 MB to 18 MB according to Apple's own numbers. 28% reduction. Or 75 to 46 for 48 MP, 39%.

Not bad for on-device gains. I suppose you could later do a re-encode at higher effort for archiving.

Not sure if already said but I use Apple ProRAW and this is what I found

It’s a DNG with extra metadata

It’s been debayered

It uses 10 / 12 (not sure) big Lossless JPEG (1992)

File sizes: 12 MPx: 20-35 MB 48 MPx: 70-130 MB

Also “JPEG-XL”

I also hope you can recompress older images, I have almost 600 TB of DNG images that could benefit from being JXL-ified

Also I don’t mean using Adobe’s tools. They suck

Part of me wonders if extracting, merging, encoding with cjxl and then implanting the new single tile would work at all

you would also have to fix the offsets

600 TB? O_o

GB*

Oops

Wish I have 600 TB

but not 600 TB of DNGs <:KekDog:805390049033191445>

that would be a fucking pain to deal with it

lol

> AVIF for the foreseeable future better for animated images and etc making it more likely not replaced by JPEG-XL for such use cases. Is that true? https://forums.macrumors.com/threads/iphone-16-pro-supports-jpeg-xl-format.2435587/page-4?post=33381563#post-33381563

animated AVIF is AV1 video, so yeah, obviously it works better if you want video since JXL doesn't do video

'animated' avif is just av1 video and still has the same limits and inadequacies for lossless animations. avif in such context seems to *require* any form of hardware acceleration (at the cost of unavoidable latency if hw versions of codecs used), whereas animated jxl decodes fine and fast in software

AVIF has the advantage of an existing encoder in FFmpeg for animations, as well as the dedicated avifenc encoder that better handles animations compared to cjxl. cjxl still requires an intermediate APNG at this time

Also, in my limited testing, AVIF uses less CPU than JXL

`cjxl` supports GIF and APNG input

whether that’s intermediate depends on the source

I’d say those two cover quite a bit of ground already

True, but I'd argue that for most cases GIF as intermediate Format is not really useful due to its limitations. And APNG has no support for the YUV colourspace, so colours may differ depending on the input

Just a single datapoint, but compare the following files and their CPU usage while playing