JPEG XL

will look at the issue probably next week

T.T

I'll probably bisect this if I get the chance since I have a hard req on faster decoding rn

Can someone comment on this? https://en.m.wikipedia.org/w/index.php?title=JPEG_XL&diff=prev&oldid=1247674602

why were the apps removed, otherwise it looks fine and the "unbiased and neutral" reasoning is solid for removing comparison

the [sic] in the john quote seems a bit weird... I would have used italic only (and I can't even see the grammatical error here :D)

Can’t edit cause am international on VPN

why "Rivals" disapeared ? and AVIF **is** AV1 in HEIF...

<:Thonk:805904896879493180> ```I am mathematician and had tested the equations and read man pages of implementation.```

It sounds both pompous and stupid

looks like he couldnt be bothered to edit the actual AVIF page to support his claim that its not HEIF container 😄 https://en.wikipedia.org/wiki/AVIF

and as a purely mathematical comparison, av1/avif is enormously behind in precision and format capabilities for images but, as for stating that something is better or worse, yeah, it just creates unnecessary heated discussions

<https://aomediacodec.github.io/av1-avif/>

ok, this is funny he has problem with calling HEIF format, according to him is not format but container

not that its important, i would just call it container format 😄

typical wikipedia moment

we are lucky here, JPEG XL is both format, container and codec 😄

We kept things as simple as we could. Codestream has everything you need to show the image, and it's in 18181-1. File format is a simple container with minimal overhead that just contains a codestream plus optional stuff like Exif/XMP and jpeg bitstream reconstruction data, and it's in 18181-2.

Compared to AVIF, which is based on MIAF (23000-22), which itself is a subset of HEIF (23008-12), which itself is based on ISOBMFF (14496-12), and to show an image you don't just have to implement the payload codec AV1 but also all of that container-level stuff because critical things like alpha, orientation, or the color space signaling are not things AV1 supports at the codestream level, so they're implemented at the level of one of these containers.

https://www.amazon.com/Give-Gift-Frustration-Practical-Christmas/dp/B0779KYSLQ

^ perfect Christmas gift for the designers of the AVIF container format

(I guess you could put a smudgy picture in the inner box)

AVIF the ironic Matroshka

matroska based container for images when <:PepeHands:808829977608323112>

Should someone revert?

Don’t wanna edit war though

no, maybe one could add the deleted apps back, but it would be better to leave out the rivals bit and whatnot

Not sure why the deleted apps were removed

Umm actually 🤓 👆 the codec is libjxl

> read man pages of implementation Is his source “cjxl -v -v -h”?

doubt it, probably other docs. anyway, that wiki change was good overall, the removed section was not really encyclopedic

Wasted

https://youtu.be/_ACCK0AUQ8Q?t=613 jpeg xl mentioned (timestamped)

suddenly Mozillas insistance on Rust based decoder seems very reasonable 😄

Great review from Tyler. First section its all about JPEG XL. https://youtu.be/be0ijSY7Kg0?si=kfmQ21DOmoiaPNz3

its always been reasonable, Decoders are a humongous Attack Vector. This has been extremely well known for a very long time.

Everybody forgets imagetragic, but it was really bad for a reason.

I consider it very reasonable myself 😉

ok I admit, I totally missed local attitude towards that 😄

very interesting theory 😄

1:50 for the timestamp

A slight graphics error labelling the JPEG Lossless sizes as Lossy JXL, and I kinda doubt the Adobe DNGs would be anywhere near the same size with their strange tiling, but a very good review, even mentioning Chrome lagging behind

https://www.pcworld.com/article/2466439/this-is-why-jpg-is-dying-and-these-are-its-successors.html

A bit strange they gave it the tagline "The Logical Sucessor" and then didn't mention JPEG transcoding

coverage or implementation, jxl always suffers from people's lack of familiarity with what it brings. some concepts like lossless transcoding with guaranteed lower filesize werent even thought of, nevermind considered possible

same as for when av1 is touted as a successor to gif. no, its a 'substitute' for gif and only as long as the original video/animation can have an avif generated from (lossy avif from gif is always worse and filesize reduction is never guaranteed), otherwise jxls *losslessly* generated *from gifs* are far better

Wait, since when did JXL have lossless gif reconstruction ?

He means regular lossless, without bit-exact reconstruction

It's a nice article

https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format#JPEG_compression_formats_in_HEIF_files > Both AVIF and HEIC are currently being considered as possible replacements for the universal JPEG format because, among other technical contributions, both can reduce file size by about 50% while maintaining equivalent quality.[dubious – discuss]

claim without source --> delete

just recorded something for the PetaPixel podcast 🙂

In animated JXL? 🧐

JXL inside ProRAW is a great debut

modern compression can make a lot of inhouse or proprietary formats in imaging either obsolete or so much more efficient

ooh, looking forward to watching that 😁

https://www.free-codecs.com/guides/iphone-16-s-jpeg-xl.htm

> Meanwhile, JPEG XL shines in lossless compression, which is why Apple opted for it in their iPhone 16’s ProRAW mode .

Does the DNG standard ever include AVIF?

It doesn't currently, and I doubt it will. AVIF has little to bring for lossless and for very high-fidelity lossy.

Then JPEG XL is the only choice that Apple can opt for

Well they _could_ offer an option to encode images as AVIF instead of HEIC, but probably it's not worth it (requires too much compute and the result will not be better at that quality point). What would make the most sense to me would be an option to encode images as d0.5 JPEG XL files, without the DNG wrapper so it's more interoperable (e.g. can be viewed directly in Safari), while still being high enough quality to do adjustments afterwards.

That "JPEG XL Lossy" option for ProRAW seems to be close to -d 0.5 but I haven't seen any review trying to verify

Current HEIC produced by iPhone looks worse than -d 1

Judging by the file sizes it is probably more like d0.2 or so

What about the cfa mosaic encoding?

Doesn't the DNG wrapper have the CFA pattern information?

Is the jxl portion just a greyscale raw sensor image?

in ProRAW, the image is already debayered so it's just an RGB image. DNG also has the option to store CFA data but ProRAW doesn't use that.

Oh, wow. So what is the value or function of the tiff container?

Is there a good open source tool to extract the jxl stream?

The one example I saw from an iPhone uses DNG tiles where the jxl payloads are 2016x2016, and also has a bunch of metadata that you need to properly interpret the image data. There's also a 2 MB preview image that's just a JPEG.

it also includes this: ``` Profile Gain Table Map : (Binary data 3158080 bytes, use -b option to extract) ```

hmm, it sounds strange calling debayered image raw

https://x.com/thiojoe/status/1841268514406928891

I predict that if Microsoft Edge (Chromium version) gets JXL support that it won't have progressive decoding support

I predict it will be the first implementation that actually supports JXL properly with progressive loading and animations and everything

one thing i'm curious about, but don't know enough about windows internals: since it has these registry entries and dll reference for the actual decoder now, does it query the microsoft store when you try to open the file? or will that need another windows update for users to actually get a prompt to install the codec

Jpeg-XL <:PepeHands:808829977608323112>

Zoltan and I wrote this originally for WebP, then we used it in the Brotli, the bug was introduced when later Brotli speed optimizations were copied back to WebP with faulty assumptions about tree completeness, and we used the Brotli code for JPEG XL -- https://github.com/google/brotli/blob/350100a5bb9d9671aca85213b2ec7a70a361b0cd/c/dec/huffman.c#L241 Brotli and JPEG XL ensure tree completeness (idea from Robert Obryk) -- so there it is impossible to break In WebP lossless I had used a simpler (deflate like) way to describe trees and that was too flexible for these optimizations

https://petapixel.com/2024/10/02/jpeg-xl-what-it-is-and-why-you-should-care/

Here is the podcast segment about jxl: https://youtu.be/ch-8xa8pT5M?t=1568&si=18qe8fCSjX3T5AJu

I hope I didn't mess that up. It was a single-take recording, and I didn't know in advance what questions they were going to ask so my answers were just what I could immediately come up with on the spot. And also I had (and still have) a cold, which didn't help.

Huh, I didn't know jpeg can actually do lossless

libjpeg-turbo can encode lossless JPEG, if you want to give it a try

Since version 3.1, it can. Kind of crazy that it took that long for a mainstream jpeg implementation to implement lossless mode 🙂

(then again lossless jpeg is not particularly useful, it's worse than PNG)

~~Just encode jpeg as the source directly then any jpeg you do would be lossless~~

Btw, this is also the first time I heard people are working on hardware jpegxl encoder

I thought this work will start after 1.0 because of risk of incompatible changes.

But I think the interview was nice.

It's not libjxl that defines the JPEG XL format, it's the standard that does (ISO/IEC 18181). The standard has been finalized.

modulo spec bugs

Sure

But presumably hardware encoders won't be doing anything crazy

Basically they will do something similar to libjxl-tiny (https://github.com/libjxl/libjxl-tiny)

Oh understood.

There is some confusion about the libjxl version being 0.x presumably meaning the format can still change, but that's not the case. The bitstream format has been frozen since December 2020 already (modulo bugs). The libjxl versioning is all about the library API, not about the jxl format itself.

Anyway, I hope we will soon have a libjxl 1.0 so the confusion won't matter anymore 🙂

I just finished watching the segment, I thought you did great. I enjoyed watching it

Sadly there are many programs that basically never update their image libraries. So any bugs in decoder or encoder are there forever (unable to open correct images or creating broken images).

I want a gpu encoder for jxl ngl

like, vk or something

e10 at e1 speeds when 🤔

xd

more like e1 at e10 speeds xD

You mean software GPU encoder like nvJPEG? Or hardware one like NVENC?

more inline of nvjpeg I guess

not asic

So unique that it even deserves its own article on Wikipedia https://en.wikipedia.org/wiki/Lossless_JPEG

Someone could try lossless AVIF as well

||jpeg tried and true and working very well. trying to reinvent the wheel. will not take up any new format. jpeg works. dont care about storage issues, storage is cheap. I have my own cloud server. and dont care to support apple proprietary stuff. nope. >And Why You Should Care I dont and wont||

Not many people knowing Roman numerals

I mean It wasn't that obvious they were referring to Roman numerals.

JPEG 2000 more like JPEG MM

So, regarding this video: https://www.youtube.com/watch?v=SzsM4HMKmEI I did the test myself. Took a high resolution raw, developed and exported it with Darktable to a 1080p image as AVIF, JPEG and JPEG XL (and JXL lossless as a ground truth). At ~200 kB, JXL and AVIF are pretty much equal in how appealing they look to me. AVIF doesn't blow JPEG XL out of the water like it does in the video

So that Adobe software they used almost certainly used a very subpar or poorly configured JPEG XL encoder

Afaik, they *are* using libjxl. I think it's possible that they used a lower effort for jpeg xl

Or just cranked the speed on the avif really low

Jpeg xl and avif should be close in quality when normalized for speed.

(For photography)

This was certainly not even normalized for speed. Hang on, let me time how long it takes both encoders to create the about-equal-quality, about-equal-size images

Yeah one of the main benefits of jpeg xl is that it's pretty fast all things considered

Okay I forgot which quality setting I used for the JPEG XL and I don't want to binary search to get it to 200 kB again, but AVIF took like... 7 times longer? JPEG XL finished in a couple of seconds

So... are we gonna tell philip or... xD

I don't have a google account, I can't comment on the video

He is here in this server 😎

Oh!

don't know how he feels about being pinged, though maybe that's just my anxiety speaking

What's their username? I'll ping them

just 3kliksphilip

Ah, I must've misspelled it before

<@162416815530704896> Heya, I think the software you used in this video might be using a bad or misconfigured JPEG XL encoder. The results I got when doing this test with similar conditions, except using Darktable to export the images, resulted in JPEG XL looking significantly better. About equal to AVIF for a 200 kB 1080p image

I remember they asked in here what the best JXL viewer on Windows is but idk if they saw the responses I and others left https://discord.com/channels/794206087879852103/822105409312653333/1278369864620445809

This is always the problem with videos compared to written articles. Showing methodology is kinda expected for written technical media, but viewers of videos often don't want to be "bored with details" so to say

You've brought this up a lot, there **is no** other JPEG XL encoder, unless you count Hydrium which is a highly experimental low memory one not actually in use

Here's some samples from a 200 kB image in different formats (the tab with the "lossless" file is there for ground truth). Be sure to "view in browser" for these images or you won't see the uncompressed version

I was a bit confused about this since libjxl wasn't in the open source licenses declaration and someone also tried to find it in the object code without any results, so from that it seemed plausible they rolled their own. I'll edit my message though (I think I wanted to write "or poorly configured" like I did in a later message, but messed that up)

wasn’t there something about Adobe producing jxls typical of --faster_decoding or something along those lines?

Looks like they're using effort 3, probably for both lossy and lossless, because the block sizes are fixed in areas where you can see them

Not just typical of, DNGConverter puts the encoding parameters into the metadata, so we could see them using -d 0.2 -e 7 --faster_encoding=4 or something similar

But I doubt it's the same in CameraRAW, or whatever Philip was using

Probably related https://www.reddit.com/r/jpegxl/comments/15z6ydp/jxl_export_from_camera_raw/

If I'm right about that, then the video is practically a comparison of jpegli vs AVIF instead

How can you see the blocks?

Is he the guy with the spiderman tights and the low camera angle centered on his spread wide-open thighs?

Or is that someone else?

By spending far too long looking at compression artifacts :P If you look closely you can see a fixed grid pattern

Yeah

I like his "sandwich of superiority" explanation 😂

Maybe you could try arguing this point with all the people insisting that AVIF is faster because all hardware is designed with AV1 in mind

Every time I see someone make that argument online, I clarify that no one uses AV1 hardware for AVIF, and that many AVIF images can't be handled by hardware anyway, but it doesn't seem to have made much of a dent in the common perception.

also WebP was designed with hardware in mind but to this day nothing does hardware WebP encoding or decoding

and yeah certain configurations of AVIF/AV1 are not even able to be handled by hardware, It's probably the reason why some places list AVIF as only going up to 10-bit despite the fact they can be 12-bit

Maybe all hardware was designed with AV1 in mind, but JPEG XL was designed with all hardware in mind

I don't know how accurate this is, but it seems plausible and sounds nice, and that's all that matters in online arguments <:Stonks:806137886726553651>

Either way, camera raw has the effort set so low it's just a glorified jpeg with some blurring... Which makes it kinda impressive it still traded blows with AVIF

good format with good defaults tainted by large company forcing mediocre or bad settings

Time stamp 54 mins in they do about 15 mins on JPEG XL: https://daringfireball.net/thetalkshow/2024/10/07/ep-411

Use jxlatte see VarDCT blocks: https://discord.com/channels/794206087879852103/794206087879852107/1242396329406238780

that works only if we have the jxl file

oh well yeah, you just have to get used to the "look" of low vs. high effort jpeg xl lol

we can't do magic

someone should make `-e 0` which just stores the image data verbatim

like ZIP Store

The most advanced image format, being used as a glorified bmp... 😭

putting the XL in jpeg thats for sure

those 75 mb extra large jpegs

although I honestly think that `-e 1 --faster_decoding=4` can replace bmp in most cases. The overhead is minimal and there is much storage to be gained.

For very high throughput situations of course

I'm sure you can implement BMP with jxl

There's only 10 methods and the compression method flag is 4 bytes

They should update bmp

I think the point is for backward compatibility

I have a blog post scheduled explaining Modular mode in some detail, no idea when it will go live (might take a while, but it's written)

hooray

we can help proof read it if you want

Nah, you'll have to wait 😛

PetaPixel comments section

They're telling me it will go live tomorrow, so tomorrow evening for me I guess...

https://cloudinary.com/blog/jpeg-xls-modular-mode-explained

Delta Palette my beloved

This is gonna be a good read

the checkmarks in the table have very low contrast

I cant even see them on my laptop

Unicode issue I'd guess

I never saw them other than as green checkmarks, I wonder why they would get rendered as gray ones

seems like most fonts have it as a solid color with no background

Fair enough to do that, but then why use a low contrast color?

because its name is `:white_check_mark:`?

✔ (heavy check mark) might work better in more fonts?

for now I'll just uninstall Blobmoji and see if whatever other emoji font I have installed will do better

make them x and o

more confusing :p

or o and blank for actual

check mark isn't that global

just me spending too much time on JP websites

Just a good ol `x`?

Followed your suggestion, better now?

yeah, very easy to read now.

I did get rid of Blobmoji and replaced with Twemoji, which looked good, but since QuackDoc couldn't see them at all, perhaps that emoji isn't very safe to use on the web?

Better for sure, not super great but legible. I have a strong green light red color deficiency though

I think this is just my panel being bad tho

oh wait scratch that, I restarted browser, and it actually loaded

how does it look for you now?

I tried to be relatively complete and "from scratch" in my description, I even went as far as trying to explain entropy coding using the example of Morse code.

It doesn't go into the _full_ details, but I think it goes pretty deep

I would say it probably goes deep enough that any somewhat knowledgeable tech enthusiast would probably get a good idea at least

Well besides the spec itself, I think it's probably the most detailed description of modular mode available now 🙂

Compared to the spec not the most complete, but certainly more detailed in my opinion compared to raw equations and code examples. Now I actually know what Squeeze and Palette do past "They turn into 2 channels"

Probably one of the most professional JXL coverages ever

This is a really cool article! I bet the author could write a really good image codec...

maybe they should go to a jpeg meeting and talk to them

JPEG? You mean "Working Group 1 of SubCommittee 29 of the Joint Technical Committee 1 of the International Organization for Standardization and the International Electrotechnical Commission?"

I never realized how much the JPEG committee name sounds like it could be part of the bureaucratic arm of the USSR

Salute you all JPEG comrades

<:WhiteFoxSalute:689481667412623385>

You should see them write Liaison letters to other subcommittees. Very efficient communication, only a 6 month roundtrip time.

https://www.trustedreviews.com/versus/jpeg-vs-jpeg-xl-whats-the-difference-4563702

JPEG XL - JPEG = XL, easy one <:KekDog:805390049033191445>

It's Extra large and bigger = better

Extra Large codebase

this cyan-on-grey doesn’t look like the best possible contrast

the “XL” is barely legible

if I didn't know it was there, I wouldnt be able to see it at all

Yeah, just unlucky placement with the color of the clouds I think

Teal JPEG vs Gray JPEG, place your bets now!

"It's green because it's not color managed"

an outline would help (it’s my go-to trick when I have text to place on a busy background that would otherwise make it hard to read)

I gave it a background

Ah yes, may favourite image format JPEG ███████

CIA's JPEG version revealed? <:Poggers:805392625934663710>

CIA needs more JPEG Trust

Pitch JPEG-XL research to these people https://en.wikipedia.org/wiki/In-Q-Tel

Extra Larger, More Smarter.

Extra C++ spaghetti

JPEG XL ... JPEG the fortieth

JPEG BAR (Xtra Large) <:kekw:808717074305122316>

https://developer.android.com/media/platform/hdr-image-format

Can't see anything about JXL in there

Is that related to Jpegli?

no, that's Android's JPEG+gainmap thing

Probably meant for <#805176455658733570> or <#803950138795622455>

Indeed, it should have been posted elsewhere... My bad. The only link with jpeg xl is the realization that some parts of google continues to push hard to avoid using jpeg xl 😥

the ultimate joke would be if only the gainmap were JXL based

nah the gain map is just another jpeg

yes, but i would not be surprised if it were the case xd

in the example I saw, they use a 4x downsampled grayscale gain map

so it doesn't seem really meant for high-fidelity HDR, but rather to spice up SDR images a bit with some roughly signaled extra brightness

here's an example:

this is the gain map at the end of that file:

you get pretty ugly color fringing at those edges in the gain map, but I guess Android folks don't care much about image fidelity, probably they assume you're going to view the image on a phone anyway, or something

Not the first time that Google have made questionable decisions regarding Android and certainly not the last time, sadly

Meanwhile Apple just uses JXL

it's particularly sad that they're forcing Android phones to use this stuff: https://www.androidauthority.com/android-15-performance-class-ultra-hdr-3480620/

JPEG over JPEG is very innovative

Making some questionable inferior HDR image format is one thing, but using a monopoly position to force it down everyone's throat is another.

Worse than HEIF

this is googles way of migrating to HDR first experience. A15/A16 is pushing hard to being an HDR primary experience

What are these A15 and A16?

android 15 android 16

I suspect by Android 17 we will see that SDR will be the second class citizen

I was thinking of Apple's SoCs

I like the idea of HDR becoming the primary focus, but not with a half-baked idea like this

Google will literally do anything except implementing JXL support smh

Trying the best to boycott JXL

yeah that was my mistake

jxl is not an option for android

like, in general, even if they added it to android 15, it still wouldnt be an option

Meanwhile on Reddit > So I'm in a middle of full fledge war with my ipad rn as obviously apple devices can't have normal file Explorer and my iPad decided to not prompt iTunes or Apple devices on my main pc (Explorer is triggered but iTunes isn't seeing any device, my laptop is seeing the device just fine) and in a middle of it as I already had to delete synchronized files as I connected ipad to my laptop (stupidest decision ever that I can't synchronize MY device to 2 different computers...) So I figured OK I will start fresh, I will reexport couple thousands of my photos as a jpegxl (I'm a photographer and ipad is my on hand digital portfolio) yet turns out jpegxl is not recognized as photo file so, I CAN send a single file via icloud download it and add to photos but I CAN'T SYNCHRONIZE ALL JPEGXL AS A NATIVE IMAGE FILE VIA ITUNES OR APPLE DEVICES.... God damn it that fcn company should burn to the ground... EDIT : it's also not recognized as image file when I plug SD card in to my iPad... Only png and jpeg

Well, at least they have on-device support I guess

I am guessing that this person is on windows, where iTunes is basically abandoned IIRC. On Mac Apple Photos have taken over the role of photo sync I believe

I haven't tried syncing JXL files with Photos

the reason that android is pushing ultraHDR so hard is because I can send the image to just about anyone and it will still work, I can't send avif or jxl images and get the same result. Android put's a LOT of emphasis on backwards compatibility, not even 3/4ths of devices are even running android 12 let alone 13 or 14, (data generated from statcounter which monitors a wackload of websites, so these does not include a lot of bespoke systems which can reliably be ignored.)

and this is *just* android, they also have to care about things like windows support

basically they have the feasible options of using png, jpeg, or webp as a format. so them choosing jpeg is really a no brainer for them

Does Windows have support for UltraHDR JPEGs?

they don't need to, that's the point

you don't *need* to support ultraHDR jpegs at all, you just need to not break with the extra data bundled after it

That's just JPEG over JPEG

This is the kind of fragmentation people like to hold against FOSS smh

I mean, whats their alternative?

Creating an HDR consortium and working on solutions together I guess

that's not a real solution

The alternative is everyone doing their own thing, no?

sure, but what android is doing is an open spec that really isn't that hard for consumption applications to implement, and it's not going to break on legacy systems

in the end, android actually cares about backwards compatibility, so whatever they do, needs to "just work" on old devices too

basically, I guess the best way to put it is, "it's the format we need and not the format we want"

I at least hope that at some time in the future they work on a "proper" format/standard

I mean we have formats and standards, none of them are backwards compatible though.

*JPEG XT walks through the door*

maybe the tail data should just have been a jxl encoding the HDR image directly, instead of a gain map

that's also going to be the main frustration with ultraHDR: applications don't _need_ to support it so most won't, and people will be confused that their nice HDR images suddenly become SDR whenever they share them

Their push for gain mapped JPEGs is unfortunate, but I am happy to see an emphasis on HDR in general

HDR on Android currently feels a bit janky and app support is pretty poor

a side effect is basically requiring oem's camera stack to capture the hdr data itself. from there it should be possible for camera apps to store it as a combined jxl with real hdr

I really hope JPEG XL isn't going to join IPv6 in the "[worse, older technology] works well enough, we don't need [newer, better technology]" club

yesterday I experimented with hdr and found the process of authoring an ultrahdr is much more intuitive

android google photos supports ultrahdr but doesnt support hdr avif

android chrome supports both but the avif is more janky

there's no "hdr data" since everything is tonemapping

raw photos are still just numbers so it ends up how bright it looks/colors/etc being up to the artist just like in sdr

chromium on windows does, idk about any other software

so it ended up being make a good looking sdr image, or making an hdr image that looks the same when tone mapped in sdr and some more contrast on hdr

and i'm not buying it

but the effect of ultrahdr was just that when it loaded in, it changed the contrast

normal hdr behaved the same so I figure a not busted image in ultrahdr when there's no hdr is better

Or JPEG is really too good from the beginning

and its potential was beyond expectations

i mean, we could always make jxl work like Apple did with HEIF store the image files in JXL, then convert transparently whenever needed (social media apps, etc.) it's actually kind of annoying to get the original HEIF files out of iPhones onto Android/Windows PCs

like other google shinies of current year, uhdr is not viable even midterm. nothing but camera apps generate that, and any creator working from his own sources has no reason to generate final versions of his images that have hdr (either native or using a gainmap)

lightroom generates ultrahdr

jpeg revisions past 6.2/6b were already considered problematic compatibility-wise. if everyone needs a newer decoder, itd make more sense defaulting to the newer revisions first since theyre at least standardized

I do think that sucks, but when the choices are "why does this image look a little worse on my PC for almost everyone" and "why is this image totally broken on my PC for the large majority", IMO the former is the lesser evil

I think this would probably be a decent approach, you do loose some audience but the HDR itself would be far better, I do think this would probably be the way to go in a clean environment for sure

not really feasible unless you have a really locked down ecosystem like apple does

the issue is not generating the images, it's distributing them, I know of folk that only do SDR images because distributing both HDR and SDR images is just not a thing

like wise, a lot of old camera apps would save both SDR and HDR renditions of images, but no longer do so, because it never worked out

unmodified files transfer just fine, many apps and web services tamper with those however (ie recompressing, stripping metadata, sending a modified copy instead of the original)

Im not sure what point you were trying to make, at least any that is relevant to what I said, can you re-phrase?

Sure, but there is a risk that this approach ends up making it harder to get traction for actual HDR support in applications. People won't even know they're missing out on something. Nothing will break, you just gracefully and unknowingly get a degraded experience, which is both a feature and a bug of this approach, in my view.

that just makes people disable the feature

just like iphone heic

normal people dont want to think about it

on the contrary, I believe this is a critical step for HDR. The primary issue with HDR adoption right now is that we don't have anyone really pushing for an HDR primary experience besides kinda osx, and even then it's rather janky. this is android's step forward in having an HDR primary experience. Applications made with the platform APIs and what not should "just work", android is creating a real path forwards to a seemless upgrade experience, unlike what we have had before which was an "just barely usable for some things" experience. We have already learned that we can't just ignore legacy users. there are in android alone, just about half of the users have support for A13, this means half of all android users (who use the device to browse a webpage according to statistica) are sub A12, and around, what is that, 13% are stuck on A11? Almost no one is going to swap to an HDR primary experience when it means that images they share aren't going to work on friends and families devices. Phone manufacturers have proved this through raw trial and error. UltraHDR means android can solve both problems, They are generating "HDR content" that looks great, but not phenomenal on HDR primary devices, but the images also look not only decent, but good and proper on SDR devices. No matter what, android absolutely has to do legacy SDR compatibility.

Android is one of the largest platforms, they can literally just brute force HDR support into everything because they control the API's and specifications for them, which I absolutely believe they will do, and have hinted towards doing so in the latest update

Android could also just start supporting actual HDR avif/jxl/whatever

Android is already forcing "performance class" hardware to support HDR displays with 1000 nit peak

Android now supports HDR AVIF since A12 optionally and A13 mandatorilly, but that would only work for devices still being supported, and they should support it, I'm not sure why they don't but granted, I havent seen any PRs at all on the gerrit what so ever so It may just be an under the radar thing, but it still doesn't solve backwards compatibility

as for JXL, I still have yet to so much as see a PR for it, so there is a chance just no one has worked on it

i'm not familiar with android internal stuff, would it be feasible to add jpeg xl decode support to existing devices (without an os update)? similar to how they recently swapped out their av1 decoder for dav1d on all (?) android 12+ devices

kinda

android has a... weird situation regarding image formats,

image decoding on android is actually typically handled by either the platform they use to make the image or NDK's imagedecoder api

since A11

if one wanted to add android support into aosp so apps using that would work, you would update skia's jxl: it is using commit #a205468bc5d3a353fb15dae2398a101dff52f2d3 : https://github.com/libjxl/libjxl/commit/a205468bc5d3a353fb15dae2398a101dff52f2d3 add jxl support to aosp's skia glue: https://android.googlesource.com/platform/external/skia/+/refs/heads/main/include/codec/ then I think you could add it here: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/graphics/java/android/graphics/ImageDecoder.java I have neither a build server, nor hands that are good for programming any more

^^^ so this is more or less what you are looking at, then applications may need to be recompiled, I dunno, I can't remeber, prolly not since it's java

interesting, thanks

NDK might just be a matter of adding it here https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/include/android/imagedecoder.h

same

from what i can remember isn't HEIF just 8bit + gainmap as well?

That's what Apple does afaiu, yes

at least it's not using 1992 compression algorithms

Not sure if HEIC is actually any better than JPEG for camera-quality images

apple says ~40% smaller

For low bit rates, sure HEIC like any video codec will beat the hell out of JPEG

maybe they just lowered the quality a bit

Well yeah they make the files that much smaller

But I think the quality is also lower

I think they aligned based on PSNR

can you send me a lossless photographic image?

There are some here: https://imagecompression.info/test_images/

what is currently the best visual metric?

Apple's default compression levels, tested using "bridge.ppm" JPEG: 3.8 MB butteraugli: 1.6288132668, 3-norm: 0.699067 ssimulacra2: 83.39591579 psnr: 34.3021 HEIC: 2.4 MB butteraugli: 3.7166814804, 3-norm: 0.948504 ssimulacra2: 73.95665903 psnr: 33.0922

so yeah, getting the smaller size is called "just lower the quality"

JPEG's quality: 94

Generally, ssimulacra2. But it's good to test both ssimulacra2 & butteraugli (i like pnorm 5 best)

Interesting thread if anyone wants to jump in: https://www.threads.net/@ericcirone/post/DBgsdwiO95H?xmt=AQGzl2i2G_bZLu1oCu5X0SrzMPiXcJ1X29DDiL2hVbV3tQ

I guess it's hard to know what Apple is actually doing. I'm not shooting anything that big.

Probably they are doing something not very optimized...

Maybe they’re only single threaded decoding

Thankfully someone gave them some numbers

Also can't assume they're using lossy files, since they only said 'High Resolution'

Yeah, that was me. I can't image they were using lossless AVIF… But who knows?

Wouldn't be the first time someone uses strange settings without knowing what they do

im assuming probably lossy as lossless 48 MPx images are huge

This is great! do you think 16 bit linear or regular 16 bit would be better for codec tests?

butteraugli can be more discerning than ssimu2 at high quality, simmu2 can be more robust elsewhere. psnr doesn't correlate with human judgement.

sit a healthy distance away from the screen and look at the image with your eyeballs.

As long as you properly tag them, it shouldn't make a big difference. In principle 16-bit sRGB can have more (visually relevant) information than 16-bit linear, but it depends on how the images were created, e.g. if they made the linear ones first and then derived the sRGB ones from that, then the linear ones will have more information.

that matches up with what I guessed. The linear zip is much smaller for some reason, though...

I think I know why, though

I don't know what the proper terminology for it is, but the linear version probably has a lot of numbers that are of a similar magnitude.

The nonlinear one is probably more evenly spread out from a statistical, numerical pov and less compressible because of that.

PPM with no colorspace info :( and `cjxl -d 0 -x color_space=RGB_D65_SRG_Per_Lin fireworks.ppm fireworks.jxl` results in a black image

But I'm using v0.8

btw did you know the steam deck comes with libjxl installed ootb?

but not kimageformats :)

it's only used for ffmped and oddly enough gdk-pixbuf2

Then I suppose the linear one was derived from the sRGB one by just undoing the transfer function. Best to use the sRGB ones

The purpose of the nonlinear transfer curve is to better utilize the full range of possible digital values.

So it makes sense if the linear image has a lot of values that are close together, compared to the nonlinear one

And numbers that are all pretty similar and close together are more compressible than numbers that have more variation across the full range of possible values

Do you think it's possible to customize the curves per-image to better utilize the values? Like, let's say a particular image has a lot of pixels around 300 and 1700 nits, could you create a curve that has more values of the range dedicated to around those specific points?

Do image formats allow for complex functions like that?

like another number per pixel

like... more bits

Yeah, I think? How I imagine it you would basically use your bits-per-channel budget more effectively because you're using less bits in the less common brightness areas. Like let's say you're using good old JPEG and there's obvious color banding because the whole image is very dark, so you're mostly only using the 0-20 range of 0-255. It would then adjust the curve so you can use the full 0-255 values to represent values with an actual brightness of in the 0-20 range. But it wouldn't be limited to just one range like that. If you have a nightscape and the sky is in the 100-130 brightness and the city buildings are mostly in the range 0-40, you could create a function that uses few values to represent anything outside of those two ranges because the image doesn't use them anyway

Same could be applied to color spaces, instead of shoving your colors into sRGB or Adobe RGB, embed a completely custom color space into the image, one that's good for efficiently representing the colors of that particular image

a custom transfer function depending on the image content is doable in principle by making a custom ICC profile (and not using XYB which would convert it back to the same absolute space anyway), though I don't think anyone has done that. It would make sense for formats like JPEG and WebP that are limited in precision. For native jxl there is no need to do this, there's plenty of precision.

(same with narrowing the gamut to only cover what is needed for the image, that would also increase the effective precision)

I suppose that's true. What you can do is use a high base bit depth, and more common values would already automatically take up fewer bits because of how the compression works

I’ve written, but not published, a program that analyses an image and tries to come up with an ICC profile that just covers its effective gamut

I gave it the very inventive name “minigamut”

hm, maybe a few too many dependencies

boost, Eigen, CGAL, exiv2, gflags, NLopt, OpenCV, lcms2

```c++ Eigen::Matrix3d chromatic_unadaptation; if (void* const chad_tag = cmsReadTag(source_profile.get(), cmsSigChromaticAdaptationTag)) { chromatic_unadaptation = Eigen::Matrix<double, 3, 3, Eigen::RowMajor>::Map(static_cast<const double*>(chad_tag)).inverse(); white_point = chromatic_unadaptation * white_point; } ``` that explains at least part of why Eigen is in there

But SteamOS' desktop shell is KDE, right? Which GTK apps come installed by default?

Do you have an example of its output on hand?

for this image, it prints ``` colorant,x,y white,0.3127,0.329 red,0.649333,0.327871 green,0.28773,0.616058 blue,0.165395,0.10438 ``` and generates the following ICC profile for it

(its output is not 100% deterministic due to the optimisation process)

KDE is qt, not gtk

I know, which is why I'm asking about it. There would be no reason to ask otherwise.

ah I see, I misinterpeted the question

while browsers use gtk, they don't use pixbuf. so im not sure

The goal is to have more accuracy for images who don't use the full extend of the color gamut ? What happens for an image (like a sepia) where all colors are on a perfect plane ?

I _think_ it shouldn’t degenerate too much, but indeed, it would be interesting to try

the idea was that maybe it could also help in gamut mapping

since then you can construct a perceptual mapping that doesn’t needlessly make room for unused colours

Ooo that's nice

This sounds very interesting ! Why nobody thought about it before !? I'm looking forward to see if it has an impact on the quality/size ratio

always nice when your silly idea is validated by an image format dev that implemented it already <:KekDog:805390049033191445>

What about matmut ? Already taken... 🤔

Ooooh, super-cool! I fantasised about such a feature (that would be able to choose sRGB or from a set of popular wider profiles depending on image data)… Currently, I convert everything to sRGB, which is increasingly sad (although picture agencies still behind, Reuters started sRGBing everything some years ago…).

Yes, I also want to implement something like that for cloudinary

To select automatically between sRGB, DisplayP3 and Rec2100 (PQ or HLG or both, not sure about that), which I think are currently the three most suitable/common/sensible color spaces to use for delivery, though that list might change over time.

Curious if it helps dark images at all, to avoid banding or if it's purely to allow better compression

i don't think there's any point to using HLG on the web when browsers (at least chromium) already treat PQ images as not having absolute luminance, but scaling them according to the brightness setting HLG just has more banding (due to the EOTF not being optimized like PQ) and less color volume (due to the weird way the EOTF is applied)

> already treat PQ images as not having absolute luminance, but scaling them according to the brightness setting. This is absolutely what you are supposed to do. PQ is absolute in a reference sense. The difference is in mastering and it matters, content that is made for HLG should be supported

well, last time i checked, the current state of chromium (specifically on windows) is that it treats PQ videos as having absolute luminance and PQ images as having relative luminance

I prefer to use PQ when you want a higher degree of accuracy to get an intended picture, and now HLG when you want it to "just look good" anywhere. Both are useful to have

now I personally believe scaling luminance should be optional according to the compositor

this can more or less probably be done using HDR10+ metadata

PQ images get displayed with their absolute luminance when you set the SDR brightness to 203 nits, but imo 203 nits is just too bright for SDR in a dark environment like the PQ reference one... and if you use 100 nits like the SDR reference, then your HDR image brightness gets cut in half. terrible decision imo

why does PQ brightness get influenced via SDR settings, that's just... wrong

because windows was the odd one out, with every other platform already doing something like that in chromium, apparently

Simple, just add JXL support and request whatever you want from libjxl :>

(now chromium is the odd one out as the only software on windows to do that)

compositor =/= applications, tho in some cases like chromeOS it can be a compositor

That's what's weird about it. And kimageformats is a smaller package too

But it's `Required By: gtk-update-icon-cache gtk3 libnotify librsvg steam-jupiter-stable`

because gcrap is always so much more interconnected dependency spaghetti by comparison

so basically gtk3 and steam-jupiter have it as hard requirements

https://dev.to/smartdev72/png-vs-jxl-235d

https://dev.to/smartdev72/jpg-to-jxl-choosing-the-right-format-for-high-quality-images-4a12

https://dev.to/smartdev72/jxl-vs-jpg-1h1f

If you want to make people think a human wrote that, then maybe it's better not to publish 3 articles on the same day...

https://fstoppers.com/landscapes/apples-secret-upgrade-iphone-16-pro-yields-incredible-results-682936

> On my screen, even the JPEG XL lossy version of the file, which is a fourth of the file size, renders better results than the less compressed JPEG version.

"less compressed"

Kind of weird that he claims lossy jxl looks better than lossless

does he? I believe he only compares it to the non-XL JPEG

Since the "JPEG" was 79 MB, I believe he's referring to the ProRAW compression option "Lossless JPEG"

ah, right

The lossless JPEG and lossless JPEG XL presumably look identical

Thus possibly d0.2 JXL looks better than lossless

I guess there are two ways in which lossy can be better than lossless: 1. If the criterion is not fidelity but appeal, then e.g. the slight noise reduction you get from lossy compression can be desirable. 2. It is possible that the bit depth used for lossless is lower than the bit depth given as input to lossy, and in that case it is possible that the lossy image is actually more precise than the lossless one.

does anyone have a lossy jxl proraw file I could look at?

To be fair, I've made forum posts in multiple tabs at once when they reference the same content, but mentioning the JXL-JPG transcoding, then not actually saying how to transcode it is strange

There is one in this server, it’s not of anything particularly interesting though

Lossy https://discord.com/channels/794206087879852103/822105409312653333/1286883166107340860 Lossless https://discord.com/channels/794206087879852103/822105409312653333/1286966095210876969

Don't forget color management, since apparently no one can get it right

Best random Telstra store visit ever 😄

He actually says in the video that the Lossless JXL seems to have more detail too, so I think you might be right about a higher bitdepth being passed to the JXL encoder

Lossy jxl: It's so high quality, it's even better than lossless

After I compressed some images with lossy jxl, I started noticing some details that weren't there before. Blurry smears started appearing everywhere that were previously imperceptible before lossy jxl compression.

Thanks to jxl I started noticing all the beautiful blurry smears I never would have noticed before.

Noise doesn't tend to bother people or be as distracting as low frequency distortion

(Like banding, blocking, smudges, color changes... all much worse looking than a little graininess)

The links to the JXL ProRAW files are only on the video, then behind a newsletter subscription to access a google drive link... So here's the link :P https://drive.google.com/file/d/1Yw5WNw3gnnKtAV2y_Gw58m2GEQaKCBQo/view

Whoops, forgot to disable ping

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

Why did a blog post from 4.5 years ago make the front page of hackernews? 😅

Maybe in a week you should make a post about the Pareto front blog post, and in a month the Modular blog xD

Not so fast! There's also this one from 2021: https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg and this one from 2022: https://cloudinary.com/blog/the-case-for-jpeg-xl

does cloudinary's websites use cloudinary CDN btw?

What's the status of webp2 ? Who's developing it ?

As if webp wasn't a bad enough mistake already

reminds me of this

In all seriousness it's probably good code though. It claims to have even better lossless compression somehow even though webp lossless is already essentially the best.

Someone should fork it and make the output jxl compliant

jxl is in dire need of a better lossy encoder and a better medium-speed lossless encoder

And a cleaner and more readable source tree

Yes

https://chromium.googlesource.com/codecs/libwebp2/

Features sound a lot like jxl

Not really imo, it's still very much a web delivery format, not really suitable for authoring workflows.

Bumping up the precision limit from 8-bit to 10-bit...

Lightweight container, lightweight incremental decode/preview, variable block sizes too it looks like, multithreading.

Sounds very jpegxl

Like they made webp more jxl-like

Incremental decode is just like what webp1 already has: you can get the image loading sequentially, top-down, like baseline jpeg

Then what's an "ultra-light previews?"

And multithreading

seems like previews are just like preview frames in jxl https://chromium.googlesource.com/codecs/libwebp2/+/refs/heads/main/doc/format/#preview

https://chromium.googlesource.com/codecs/libwebp2/+/refs/heads/main/src/dec/preview/preview_dec.cc

Looks like some kind of triangulated blurhash

oh then not quite like jxl

We had something like that in very early versions of jxl, back when it was still just pik+fuif

We got rid of it since having dedicated coding tools just for a preview didn't seem like a good way to go.

<@794205442175402004> Maybe you also know what they mean by "improved lossless compression"?

I suppose smaller than webp1? I dunno

I'm curious because lossless compression is the field where webp1 is already strong, so my main interest is whether these webp2 improvement can be 'borrowed'

https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?gid=174429822#gid=174429822

WebP2 was included in these benchmarks

Do note that this comparison is a bit old

libjxl 0.7 was used

So it doesn't have quite the same density, but it could be faster.