JPEG XL

are you on a computer with AV1 hardware decoding?

Yes, but not enabled by default, in my case at least

On my computer, the AVIF was using 200 to 300 % CPU, the JXL was using about 180%

Interesting

CPU is comparable if viewed in an Image viewer for me. In MPV AVIF is around half, without hardware decode

What software did you use to view the images?

gwenview

i will try mpv

mpv used 300% for both

In gwenview I have ~33% CPU for jxl playback and ~23% CPU for AVIF

YUV is not just one colorspace

if you have an ICC profile of the underlying colorspace, you can attach it to an APNG, AFAIK, no?

Most images you find on the web (or create yourself) do not have an ICC profile. If I go and want to turn an image sequence into a JXL animation I would have to go and use GIF or APNG as an intermediate format. Using either GIF or APNG will alter the colours depending on the content, correct? I have tried turning sequences of JPEGs into a JXL via APNG only to notice slightly different colours between Input (JPEGs) and output (JXL animation). Are you suggesting the use of an ICC profile to mitigate this change in colour?

if they don’t have an ICC profile, they’re interpreted as sRGB by default

I’m not sure where YUV support comes into it

could it be that the JPEGs you tried did in fact have an ICC profile and it just wasn’t preserved, causing the issue?

oh, or perhaps you used ImageMagick and hit the bug where it puts a gAMA chunk in its PNGs but without an sRGB chunk?

I would be curious to reproduce the problem to try and look into it

Ok, let me try to not be too long. The reason why I am currently being interested in JXL animations is due to Pixiv. Pixiv, a japanese art platform, distributes animations on their site as separate JPEGs, that, when downloaded, need to be "processed", so that they can be used as an animation. At this time I use lossless AVIF for that. I am hoping that in the future those JPEGs could be recompressed to JXL and muxed together, because the saving in filesize would be enourmous. At this time the only way to get a JXL animation from the aformentioned JPEGs is converting them to APNG and passing that to cjxl. Not only will the size be inflated massively, but the colours were different as well. We can ignore the colour part, because I really mostly care about the recompressing/muxing of JPEGs into a JXL animation.

Using some very non-scientific testing using ffplay set to 5 loops then exit AVIF```PeakWorkingSetSize: 943.2 MiB QuotaPeakPagedPoolUsage: 728.6 KiB QuotaPeakNonPagedPoolUsage: 38.2 KiB PeakPagefileUsage: 1.056 GiB Creation time 2024/09/11 23:05:14.937 Exit time 2024/09/11 23:05:23.106 Wall time: 0 days, 00:00:08.168 (8.17 seconds) User time: 0 days, 00:00:01.937 (1.94 seconds) Kernel time: 0 days, 00:01:35.984 (95.98 seconds)``` JXL```PeakWorkingSetSize: 480.5 MiB QuotaPeakPagedPoolUsage: 728.7 KiB QuotaPeakNonPagedPoolUsage: 31.16 KiB PeakPagefileUsage: 727.6 MiB Creation time 2024/09/11 23:05:32.633 Exit time 2024/09/11 23:05:46.971 Wall time: 0 days, 00:00:14.337 (14.34 seconds) User time: 0 days, 00:00:18.921 (18.92 seconds) Kernel time: 0 days, 00:02:27.156 (147.16 seconds)```

Bearing in mind I think libjxl has limited threads in ffmpeg, even just that half memory usage is worth it for me

The JXL is also significantly smaller in filesize

Trying to re-encode the JXL directly with cjxl didn't end so well :P

Sheesh

```wintime -- cjxl l3rvhz.jxl Test.jxl -d 0 -e 3 JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 169177.2 kB (7.832 bpp/frame). 3600 x 2400, 0.778 MP/s [0.78, 0.78], , 1 reps, 16 threads. PageFaultCount: 5645907 PeakWorkingSetSize: 5.359 GiB QuotaPeakPagedPoolUsage: 35.7 KiB QuotaPeakNonPagedPoolUsage: 25.49 KiB PeakPagefileUsage: 5.446 GiB Creation time 2024/09/11 23:10:24.412 Exit time 2024/09/11 23:10:57.816 Wall time: 0 days, 00:00:33.404 (33.40 seconds) User time: 0 days, 00:00:37.031 (37.03 seconds) Kernel time: 0 days, 00:01:50.671 (110.67 seconds)```

Was trying e3 to boost decode speed a bit

The file is also a bit unusual after all, overly high resolution and 100fps, so no wonder it takes a long time to encode

100fps but 20 frames total, guess cjxl is loading all of them into memory at once even though it only encodes one frame at a time. About 173 Megapixels total

Extracted a single frame.... Hrmmm

The jxl is e3, same as above?

e3 is 7.8 bpp, e4 is 1.6 bpp. I know long ago palette was disabled for e2 and e3 but the fast palette from e1 was ported to them ages ago too

Pfft

```wintime -- cjxl Test.png Test.jxl -d 0 -e 1 JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 448.0 kB (0.415 bpp). 3600 x 2400, 156.884 MP/s [156.88, 156.88], , 1 reps, 16 threads. PageFaultCount: 15051 PeakWorkingSetSize: 53.76 MiB QuotaPeakPagedPoolUsage: 35.7 KiB QuotaPeakNonPagedPoolUsage: 8.086 KiB PeakPagefileUsage: 50.58 MiB Creation time 2024/09/11 23:28:20.604 Exit time 2024/09/11 23:28:20.721 Wall time: 0 days, 00:00:00.117 (0.12 seconds) User time: 0 days, 00:00:00.046 (0.05 seconds) Kernel time: 0 days, 00:00:00.312 (0.31 seconds)```

Guess that fast palette is still doing work

What about e10?

xd

```wintime -- cjxl Test.png Test.jxl -d 0 -e 10 JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [Modular, lossless, effort: 10] Compressed to 211.6 kB (0.196 bpp). 3600 x 2400, 0.109 MP/s [0.11, 0.11], , 1 reps, 16 threads. PageFaultCount: 3674465 PeakWorkingSetSize: 842.6 MiB QuotaPeakPagedPoolUsage: 35.7 KiB QuotaPeakNonPagedPoolUsage: 15 KiB PeakPagefileUsage: 947.6 MiB Creation time 2024/09/11 23:29:55.919 Exit time 2024/09/11 23:31:14.941 Wall time: 0 days, 00:01:19.022 (79.02 seconds) User time: 0 days, 00:00:03.703 (3.70 seconds) Kernel time: 0 days, 00:01:23.078 (83.08 seconds)```

Beats the PNG now at least

Ant it *only* took around 1.5 minutes 😆

`0.415 bpp, 1.522 bpp, 7.838 bpp, 1.612 bpp, 0.301 bpp, 0.286 bpp, 0.251 bpp, 0.244 bpp, 0.241 bpp, 0.196 bpp` bpp of every effort level 1 to 10

e3 is tonights biggest loser

Considering the PNG is a 2 bit palette, e3 isn't just a looser, it's a saboteur

True

Very weird that there's a bump around e3, with e2 and e4 also being much higher than the rest

It sometimes happens, for some reason

Some code somewhere living it's best life

I don't think I have ever seen a discussion around GIF compression since I joined here, but i have a 100MB GIF that will always be worse with JXL unless e8 or higher is selected

Maybe even e9, I'd have to check

Maybe I should create a GIF dataset

currently the encoder doesn't really take advantage of what the JXL spec supports animation wise, so that's probably why GIF ends up winning since the encoders for GIF can blend between frames and whateever else

My way to work around it is using gif2apng, and then encoding with cjxl since then it can use the transparency, different frame sizes, ect

It is also understandable that current efforts are focussed on still images

Let me try that real quick

Ah, I don't have it installed

Oh well

Here a link https://we.tl/t-wprMvEnN76 Viewers discretion is advised

It is SFW though

https://discord.com/channels/794206087879852103/803645746661425173/1283560872928612443

https://beebom.com/what-is-jpeg-xl/

_Both JXL and AVIF encoding times are almost similar, but on average, AVIF does seem to be leading a bit_ how ?!

the article also claims that WebP goes up to 12-bit

They are also not specifying encoding settings, so not even repeatable by the reader

You cannot just claim "A is fast er than B" without giving that information

Seems to be a not very well informed article

> When compared to lossless PNGs, lossless JPEG XL images can sometimes be smaller but almost indistinguishable from PNGs. <:Thonk:805904896879493180>

I wonder if chatGPT wrote this

Not even close to similar encode times. Literally everyone who has tried both will say the same. AVIF is slooooooooooow.

AVIF s9 is pretty fast. It's also worse than jpeg though.

Yeah, much worse. That's why no one uses it. It's also worse at dividing an image into tiles compared to jxl.

You could tell libavif to use tiles in a similar way as jxl but that's not the default and doesn't help you when decoding an existing image. And it can't smooth tile boundaries like jxl presumably does

Most importantly though, no one uses libaom at speed levels faster than s4

Because avif is worse than webp after that point

We use it at default speed, s6. Slower speeds are too slow for us.

It still beats webp at s6.

I am talking about lossy.

Seems that website just re-posted it

I could recall Beehom posted a joke article long time ago

doesn't appear to have fixed any mistakes tho?

Lossless but I removed the noise moment

its rarely elaborated on but testers commonly use high efforts that end up making avif look competitive performance wise. anything higher than post 0.10 e7 should be discouraged, or users better educated about how good the defaults actually are

The sweet spot for lossy libjxl is at e6 in my opinion: going higher effort doesn't bring much except taking more time, going lower effort doesn't speed up much but does bring worse results.

For libaom, you have to pick your poison: you need to go to very high effort (s1-s2 or so) to get close to the best results, so either it's slow or you have to accept worse results. The region between s3 and s7 has substantial improvements in compression at every effort step, but also the speed differences are substantial.

Do you think there is room for improvement for efforts higher than 7? Like better patches and the usage of splines?

Right now the miniscule gains in quality is not worth the significant slow down. Can jxl achieve avif-like gains where slower speeds come with significant upsides?

Maybe, yes. Patches could be used in more ways than what we do now, and splines are not used at all. Also I imagine we could do things that involve trying different block subdivision strategies instead of just the one strategy we have now. I think e8+ is mostly spending a lot of time exploring one specific part of the search space deeply (varying adaptive quantization while keeping all the rest fixed) and might be more effective if it would explore more parts more shallowly.

better patches could be done also at not too high cpu cost, I'm sure

the current heuristic is... uh, a hacky job by an intern 😛 (_whistles_)

In particular, the current heuristic only looks for repetitive stuff on a solid background. Patches could probably also be useful for non-repetitive stuff where near-lossless is more effective than DCT, like places where avif would use palette blocks.

As in compress certain parts of the image in VarDCT and some in Modular?

that's something you can certainly do if you figure out what to do with the seams

iPhone blending?

Alpha

Are these plans in the near future or far future? Like pre or post v1.0.

Maybe Cloudinary's X account is also written by ChatGPT.

at this point, are you ChatGPT?

`djxl --no_noise`

Post

what does 1.0 signify?

Finalized library API is the only thing it really means.

so we can keep changing the internals and optimising after 1.0?

Replied to that X post

or is it effectively semver?

Yes, semantic versioning.

so this '0.x' phase is kinda like beta and once 1.0 hits, then it's semantic?

well until a 2.0 comes along [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

Apparently never found this before, but a nice little blog post, outdated or slightly wrong commands for the files too https://www.s-config.com/jxl-jpegxl-and-the-web/

"JPegXL"? Hadn't seen that spelling before...

is JPEG XL going to be the new GIF vs JIF?

first time I hear about the format JIF, I wonder what it is || /s || Jpeg Infinite Floating-point-precision? <:KekDog:805390049033191445>

https://discord.com/channels/794206087879852103/794206087879852106/804429947090632777

GIF vs JIF, "Pee N Gee" vs "ping", "heef" vs "hayf", "aye-vif" vs "Aye Vee Eye Eff" — we're not the only format where people pronounce things in different ways

anyway in French everyone I know says GIF (G-E-F)

i just call HEIF/HEIC letter by letter

JpEgXl when?

i know someone who unironically calls WebP "we-be-peh"

jpEGxL

actually no jPE-gX l

JP🥚-XL

I tend to say either "jay peg ex ell", or "jay ex ell", at least when speaking English. In Dutch I would pronounce it more like "yay peg ex ell".

In Mandarin Chinese, X is often pronounced as "chā", as a cross is often called a "chā"

i pronounce lossless AVIF as "bad idea"

Most of people here can't pronounce "L" well so XL would sound like "cha-eh-loh"

are you chinese?

From Taiwan

im from Hangzhou mainland

So you should've understood what I meant

yeh

The J in Jyrki, Jon and Jan (Wassenberg) is not a dzj sound like the J in English. It's a voiced palatal approximant (https://en.wikipedia.org/wiki/Voiced_palatal_approximant) , not a voiced postalveolar affricate (https://en.wikipedia.org/wiki/Voiced_postalveolar_affricate)

although my chinese isn't amazing, been living in 🇦🇺 most my life

so more like the "y" from "yawn"?

At some point, I was (mostly jokingly) saying that we should pronounce jxl as "yixel", rhyming with "pixel" and starting with the <j> sound

so "JXL art" would be "yixel art"?

that's actually cute sounding

i'm all for that specifically

yes, in English the letter Y (at the start of a word) is used for this, in other Germanic languages like German and Dutch the letter J is still used for that sound

The <x> sound is different though

so the English "yes" and the German or Dutch "ja" actually start with the same sound, <j> in the international phonetic alphabet

Eastern slavonic: zjpeg (ex el), but dzje ex el (also pe en ge, and geef) 🤷‍♂️

about the camera component of android : https://issuetracker.google.com/issues/177918194#comment9 _RAW/RAW + JPEG/HEIC/AVIF image capture is on our roadmap now. JPEG XL is the next thing we consider exploring._

(I bought a "recent" phone and it can support only RAW or jpeg with nothing in between with some HDR capabilities <:PepeHands:808829977608323112> )

that just means they haven't looked at it yet. ~~plenty of time for them to shut it down~~

remeber folk, ask your phone vendor for JXL support, not aosp devs, because the vendors are the ones with power

i thought the electricity company was the one with the power :/

I can't find an adequate sony support forum

in the EU/UK area it's support.sony.co.uk in USA and canada its us.community.sony.com

canada and us are the same site just s/us/ca

Tempted to leave a comment along the lines of "DNG now also uses JXL internally, so being able to save as a standard JXL file would be very nice too" But I fear starting another thread of random people chanting about JXL on an issue tracker

<:Thonk:805904896879493180> https://9to5mac.com/2024/09/13/iphone-16-pro-lets-users-capture-proraw-photos-in-jpeg-xl-format/

So your name isn't the English "Jon?" I didn't know that... Jyrki on the other hand, I always thought it looked like maybe "Yerki" is the most likely way to say it.

A better transcription of my name in English would be "Yon", yes

https://www.msn.com/en-us/news/technology/iphone-16-pro-is-said-to-support-jpeg-xl-format/ar-AA1qxjEl?ocid=socialshare

Is it known how HEIC hardware encoding speed compares to JPEG XL software encoding speed? If we were to hope for JPEG XL to replace HEIC in general on the iPhone at some point in the future

HEVC hardware, if utilized, would drain the battery less.

...but then again, <:JXL:805850130203934781> encoding can be extremely simple in theory, faster than JPEG

Without a big sacrifice in quality

I think that iOS uses hardware acceleration for HEIC photos, which is why all HEIC photos from iPhones are tiled.

Is it confirmed this is only for iPhone 16 pro?

Quick, someone go and buy an iPhone 16 Pro to test

Are they at the Apple stores?

I can go check today if so

No idea

Good idea!

Is this new firmware out already?

I think it was supposed to come with iOS 18?

iOS 18 isn’t properly out yet

Is it?

I’m not sure

I’m on RC

Thought it was gonna release next week

I think it is supposed to come out later this month

Or that, maybe

If so, then the iPhone 16s, if they are at Apple, would still be running iOS 17 I roiled yhonk

Would think*

We will see how it is when it releases

I am kinda hyped and I never even owned an iPhone

What part are you hyped?

Possible JXL support

If it’s the AI, get a Galaxy or Pixel

Fair

Although it’s still most likely just JXL in DNG

Not full proper JXL

Likely, but one can hope

Also I have typed JXL so much that my phone now auto corrects it

xd

Now if only there was some software outside of Adobe to edit those DNGs (on linux). I have some of them myself but can do literally nothing with them lol

Can’t most libraw based?

Dark tables?

No, since libraw hasn't had a release containg the dngsdk yet and most software do not build against the snapshot

In fact, there is no software on linux at all that currently supports JXL DNGs. If there is, I am not aware of it

And support on windows is sparse as well

Someone with a Mac or a macOS VM could decrypt and extract the already available OS image to check

Haven’t tested on Mac yet

I can, don’t know how to though

Someone I know checked the image for iOS 18 for iPhone 16 Pro, but not the one for non Pro

I have 14 pro max

I'm about to fall asleep but if you search my posts here you'll find links to the relevant tools

Where is the JXL option meant to be?

Good night 🙂

Here are the steps the person I know took to extract the data from an encrypted iPhone OS image. The aea file below is the encrypted image for iPhone 16 Pro. The second tool I posted earlier has a way to find and download the version you want to check out, I think. also repro steps if you want to follow along at home (on latest stable macOS 14 on ASi, but if you don't have a Mac, i don't see why this wouldn't work in an x86_64h macOS VM): ```bash mkdir ~/OTASU_Crystal22A3351_D93_dst && cd ~/OTASU_Crystal22A3351_D93_dst curl -O 'https://updates.cdn-apple.com/2024FallFCS/mobileassets/032-87820/49E96347-486E-47BD-858A-202BD5A90E0B/com_apple_MobileAsset_SoftwareUpdate/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aea' git clone https://github.com/dhinakg/aeota.git cd aeota python3 -m venv .env source .env/bin/activate pip3 install -r requirements.txt python3 get_key.py ~/OTASU_Crystal22A3351_D93_dst/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aea # idk if HPKE is needed but /shrug/ make HPKE=1 ./aastuff_standalone -i ~/OTASU_Crystal22A3351_D93_dst/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aea -o ~/OTASU_Crystal22A3351_D93_dst/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aar -d -k '<wkms key snip>' ./aastuff_standalone -i ~/OTASU_Crystal22A3351_D93_dst/d9faf503145b73e746c27e075c48af44bfa02f15731649242930e38c98c5fe39.aar -o ~/OTASU_Crystal22A3351_D93_dst/dst cd ~/OTASU_Crystal22A3351_D93_dst/dst/AssetData/payloadv2 # dumb way to extract AppleArchive files from the OTA but it works for i in `seq -f '%03g' 0 26`; do aa extract -i payload.${i} -d fs_dst done cd fs_dst ```

libraw supports dng 1.7 with jxl codestream since a beta, but most apps ship only its stable releases so their support can outdated by a year (next stable is months away). windows' raw extension is based on a libraw beta snapshot currently so its supposed to decode dng1.7 with jxl now (to be checked)

There was no mention of quality improvements in the 0.11 release notes. Someone should make a blog post showcasing the difference in quality, with before and after pics. Then maybe that can be published on an official channel so the press could pick it up and report on it, generating more positive press attention for <:JXL:805850130203934781> Or am I being too optimistic?

Also, more definite language like, "No longer calls abort() in release builds" would help clarify, with actionable confidence, that libjxl is now ready for those projects that were holding off on including it for that very reason.

Somebody should inform the paint.net dev. He can finally include libjxl by default since it no longer calls abort()

Exactly. That's what I was referring to actually

Positive press attention is important for getting people aware of and excited about a new image format

:)

I heard that Jyrki was working on lossy quality improvements but idk what bitrate or what type of images he was trying to make improvements on. I would like to make some before and after comparisons to showcase the difference between 0.10 and 0.11 so that the new release could get more positive attention across the broader world.

https://discord.com/channels/794206087879852103/803645746661425173/1284355399667027968

I wonder how the improvements have gone since my last test in May this year

I also have yet to test the color shift/desaturation as well

There is no mention of this in the issue: https://github.com/libjxl/libjxl/issues/1450

The dev plans to include the plugin made by 0xC0000054 by default. The problem is, the plugin is officially abandoned at this point. So no, Paint.NET won't support JPEG XL.

PTGui should

Officially abandoned?

Oh, I suppose you're referring to this

Thank you for the suggestion. I will just be patient until DNG 1.7 is supported by darktable etc.

Yeah, it's unknown when 1.0 comes out, so it's an indefinite hiatus.

Setting up the lossless foundation is still better than that infamous HEIF

lossless JXL DNG is nice for people who only take RAW

Unless there's any iPhone fan who wants RAW based on lossless HEIF

NO

I don't think Apple's hardware HEIF encoder can do lossless. In fact I think it only does 8-bit yuv420.

basically it's like webp but with patents

And probably slightly better compression wise

iPhone can record 10 bit HEVC

Apple is probably using the HEVC hardware to encode HEIC

well, better with lossy yes since H265/HEVC is better then VP8 but for lossless it probably doesn't come close to "VP8L"

Can HEVC even lossless?

Yes, hevc itself supports it.

I think so yes. It decodes 10-bit yuv420. For still image, for some reason it uses only 8-bit, plus a gain map.

(the reason is probably that this simplifies on-the-fly jpeg transcoding)

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

probably also helps with compatibility with pre-HDR systems

that's what I mean — the main image is tone mapped for SDR, so when converting to JPEG to share the image, it can just convert that and forget about the gain map.

yeah, makes sense

That FollowingTheDao

it's funny cuz he sorta has a point but then he says a bunch of nonsense lol

who?

From the link

> If Apple is giving you JPEG-XL they are compressing the file, so it is not RAW. JPEG-XL is lossless compression. What? so ZIP is now RAW?

it's the same idea

There seems to be confusion about what lossless means, but also about what "raw" is supposed to mean.

I don't think there is any consistent definition of what raw actually means between manufacturers

The wikipedia definition is: (https://en.wikipedia.org/wiki/Raw_image_format) > A camera raw image file contains unprocessed or minimally processed data from the image sensor of either a digital camera, a motion picture film scanner, or other image scanner.

"unprocessed or minimally processed data" is of course a bit vague: how much processing can you do while still being "minimal"?

in the past, Nikon has received some flak for hardcoding the black point subtraction, which truncates read noise

Sony, for its hot pixel suppression which has occasionally removed actual stars from image (search for “sony star eater”)

recently, Canon, has started applying mild but forced noise reduction to its raws at low ISO settings

theoretically you can just DMA the CCD data to an SD card but how practical is that really

I did not expect that from Canon

https://www.dpreview.com/forums/post/65858159

I also vaguely recall Sony baking in vignette correction in some instances but I don’t remember the details

and Pentax, going from the K1 to the K1 Mark II, has started applying noise reduction at _high_ ISO settings (unlike Canon’s low) https://www.photonstophotos.net/Charts/RN_e.htm#Pentax%20K-1_14,Pentax%20K-1%20II_14

(“triangle down indicates noise reduction”)

although now, with the EOS R5 Mark II, it seems Canon now does it at all ISO settings? https://www.photonstophotos.net/Charts/RN_e.htm#Canon%20EOS%20R5_14,Canon%20EOS%20R5%20Mark%20II_14

Thank you. I have not looked into modern cameras world, and this is really disappointing..

Old cameras were more 'honest' in this aspect. Sometime even too honest, hehe

what the hell

In my opinion all "processing" should be metadata only

So the user can decide with their RAW processor

Raw of the flatfield shot from my camera without sensor 'parts' alignment applied

ah, I’m now remembering Nikon’s lossy compression as well https://photonstophotos.net/Emil%20Martinec/noise-p3.html#NEFcompression

The problem is that none of manufacturers want to share information how to use this metadata

That's the problem indeed, they all are proprietary

takes advantage of photon noise to discard the lower bits (which are below the noise anyway)

I think processing specific to the details of the camera technology is probably best left to the camera manufacturers, anything else is best left to the photographer. Things like dealing with dead pixels, sensor alignment, various corrections, even debayering: I don't think it really makes sense that authoring software like Lightroom/darktable has to bother with those things and have big databases with how to deal with each and every specific model or even setting of every possible camera or lens.

so like Apple ProRAW level of comprimise?

speaking about raw and compression... can JPEG XL compress even non-demosaiced raw? I would think the answer is yes if it's used in DNG which is raw format

it's just pixels so yes

DNG I believe just stores 4 separate JXL images or something like that

either way it can store arbitraty pixel data

ok, thanks

`kCFA` is RIGHT THERE <:AngryCry:805396146322145301>

someone didn't read the spec / api before implementing it

I disagree at least in debayering and some corrections. Metadata should be open and documented, but not everything should be done in-camera

Let me say it this way: whatever they're not going to document, let them do it in-camera so we don't have to deal with it. That's better than having rawer raw files but only Adobe knows how to cook them.

*only Dave Coffin. But yes, in such case it should be done by camera. I just hate that secretness too much

In my case I actually deleted Adobe's database for DNGConverter, since copying what my phone does just results in over smoothened and washed out images, which is exactly why I set it to RAW in the first place

I don't like secretness/obfuscation that only serves to give FOSS a hard time and proprietary software a competitive edge. I don't mind if cameras want to innovate with new technology and choose to keep some things secret/proprietary, but 1) they should produce a raw output that is fully documented and doesn't require reverse engineering to figure out how to interpret the data, 2) they shouldn't be doing things to the 'raw' that can just as well be done afterwards (such as noise reduction filters).

as in do the fancy propreitary stuff in camera?

As I already said somewhere here, one of corrections required for my camera, can only be done by proprietary converter. Adobe and libraw does not know how to do that. Thanks God this proprietary converter produces bayer dngs with that correction applied. And that camera (camera family, actually, that suffers from the same issue) is released in 2008. So this correction is not reverse engineered for already 16 years

what camera is it?

All Phase One backs based on Dalsa CCD sensors

Mine is IQ180, but it does not matter, they all suffer from the same

<@167023260574154752> they really did 😅

lmao

Dear lord he's dense.

My goodness

He's gonna loose it when he discovers cut and paste

reminds me of a discussion I once had with a photographer who was claiming JPEG's generation loss is a feature, not a bug, since it acts like a DRM mechanism that prevents limitless copying

Mozilla developer Mike Conley talked about Firefox supporting JXL when a Rust implementation is completed in this week's live stream: https://www.youtube.com/live/le58LIsJH0Q?si=2hc8RcaihEt1tkbP&t=516

And *that* reminded me of a video I saw yesterday about how AI keeps adding JPEG style mosquito noise to generated images, but in all 3 channels with the same pattern so you can tell it's fake

Nothing new, but slightly annoyed they had to say `100,000 Lines of Multithreaded C++` when that's the entire Github repository and not just a decoder

True, and also important to note that a large part (estimated 50-60%) of Firefox is written in multithreaded C++. It's disingenuous to expect anything getting added into be Rust... but you also have to realize that Mozilla built Rust and has been pushing it down everyone's throat. It ends up being a marketing ploy. If you get more components written in Rust, you get more exposure and support for the language. I'm sure all the Mozilla employees have been "informed" that it's in their best interest to push it as much as possible.

Well as long as the only remaining obstacle is security concerns and a Rust implementation can alleviate those, and we do have volunteers in the community and at Google Research who want to deliver such a Rust implementation, it's a huge step forwards. Technical obstacles like writing an implementation in another language can be overcome much easier than political obstacles. The previous Mozilla position was worse than the current one, since it was basically a political position: they didn't consider it justified to add support since it was not "enough better" than AVIF (according to the codec evaluation done by the AVIF team). Now they seem to have changed their minds and do consider it justified to add support, just they want it to be in Rust to mitigate some of the concerns regarding security — which is in the end not a completely unreasonable ask; perhaps a bit unfair since when adding AVIF they were perfectly fine with adding lots of multithreaded C++ and even tons of assembler code, but ok.

> It's disingenuous to expect anything getting added into be Rust why? Pretty much everything new in firefox these last few years has been in Rust. > but you also have to realize that Mozilla built Rust and has been pushing it down everyone's throat ??? > If you get more components written in Rust, you get more exposure and support for the language. Mozilla doesn't even develop Rust anymore, they laid off everyone working on it. What exactly would they gain from "exposure" for Rust? Especially considering that Rust is seeing massive adoption all of its own among people who don't give a single shit about what code is in Firefox. > I'm sure all the Mozilla employees have been "informed" that it's in their best interest to push it as much as possible. crazy-ass conspiracy nonsense right here

for av1/avif there is even a full libaom encoder (needed for webrtc) with a huge amount of multithreaded C++ code, not just a decoder

dav1d is lots of C, not lots of C++ :p > perhaps a bit unfair I agree, though it's been more than 5 years since they added AV1 decoding to Firefox, and it seems pretty reasonable if their requirements for new stuff have changed in that time

> dav1d is lots of C, not lots of C++ Not really different in terms of safety, I guess

I don't think firefox supports AV1 in WebRTC

A rust implementation is complete technically, someone just needs to integrate it into Firefox and see how well it works...

The AVIF comparison done by the avif team showed avif doing very poorly

should be, at least for decoding because it's in the standard, for encoding maybe it depends on the configuration because even h.264 is not always available, even through openh264

I thought OpenH264 is only the decoder?

encoder and decoder

> why? Pretty much everything new in firefox these last few years has been in Rust. No, some things have. The majority are modifications of existing C++ and JS already existing in the code. > Mozilla doesn't even develop Rust anymore When people think of Rust they still think of Mozilla and they push it very heavily. > crazy-ass conspiracy nonsense right here That's what they called people who said that Google was playing politics with respect to JXL less than a year ago. Your personal attacks amuse me.

It's great that it's getting done.

It's a lot easier to encode jxl than to decode. I’m surprised there are so many decoders.

Encoding can be easier than decoding?

<https://github.com/mozilla/gecko-dev/tree/master/media/libaom>

I've heard talks of them potentially looking at RAV1D in the future.

Decoders have a lot more work. They have to be able to decode any valid file. Encoders are way easier and can be as simple as you want. Simpler and faster than JPEG

Browsers were kinda forced to implement av1 one way or another, and rav1d wasn't even a concept then

Encoders don't have to support every feature and encoding method. Not even libjxl's encoder uses all features

> No, some things have. The majority are modifications of existing C++ and JS already existing in the code. modifications to existing stuff isn't new stuff. Also, this contradicts what you said before about marketing and mozilla management supposedly forcing firefox devs to push rust as much as possible. and *obviously* they're still using JS, it's memory safe. They've never had it as a goal to use Rust instead of JS. > When people think of Rust they still think of Mozilla and they push it very heavily. maybe people who don't know anything still think Mozilla, but 99% of anything having to do with Rust happens outside of Mozilla. And if people think of Mozilla when they hear Rust, well, uh, that isn't relevant at all? > That's what they called people who said that Google was playing politics with respect to JXL less than a year ago. Your personal attacks amuse me. it's not a personal attack it's a factual statement. There's literally no reason to think that Mozilla management are pushing Rust when they decided to gut Mozilla's involvement with Rust. We know that many actual programmers at Mozilla love using Rust (as well as many, many programmers outside of Mozilla) so maybe they're just using it because they want to use it. Like it's a pretty simple explanation. Also I like that you say "Google" rather than, say, "a handful of people on the Chromium codec team", as if opposition to JXL is some kind of high level commandment across Google.

yeah but would such an encoder actually be useful?

I know they have libaom in there, but I can't find anything about Firefox supporting AV1 in WebRTC.

I'm sure Firefox would accept go code too if go wasn't a pita to use stuff lol

Yes, Google. Read what's going on with the anti-trust case. 😆

why is google funding work to put JXL into Firefox if Google's high level leadership are against it ?

I think so, yes. Ultra fast jxl is still way better compression than existing lossless or lossy formats

Isn't google meet rolling out av1 soon, guess it will be a good test

This was a discussion the other day. It's in Google's interest to have Firefox around because it weakens their anti-trust case to have Firefox disappear. The JXL team is a separate research team whereas the AV1/AVIF team was tightly coupled with Chrome.

but ultra fast jxl encoding is already available. libjxl-tiny and fjxl can do high speed compression

You can have an ultra fast lossy encoder that is faster than JPEG but with better entropy coding and better perceptual quantization

maybe not exactly webrtc as a monolithic library, but webcodecs, but I've seen tests with moq and av1 that works on all the major browsers

I know the JXL team is separate, that's why I think it's much much more likely that any weird nonsense going on is happening inside the Chromium organization, not at a high level.

It would be great for transparent compression

It still happens at a high level AND in specific teams.

that's unfortunate. Is libaom completely necessary for this? Does it have a bunch of important features rav1e is missing?

rav1e is pretty bad and slow for rtc

No, rav1e is just way too slow

Not *bad* just super duper slow

Rav1e still good for high fidelity

Ah, well that's good proof that a fast encoder would still be useful :) even for lossy compression at high quality targets, you don't need a lot of speed to get good results.

It's at really low bitrates where extra computation helps more

at really high qualities, like -d 0.1, I think the effort setting in libjxl makes close to zero real difference

And really low quality

yeah, but not for low-complexity low-bitrate/fps fast encoding for talking heads, libaom is so far the most optimized for such tasks, even svt-av1 is worse, even though better and faster for normal encoding

Is it? Last I tested svt was better but it was a while ago

Oh, well. In any case, it doesn't really matter. The Firefox needed AV1, and there were no good rust alternatives at the time.

no, even meta uses and optimizes libaom for rtc, even though it's basically currently the main sponsor, user and contributor for svt-av1

Interesting,

But all this aside I commend Firefox for going a memory safe only approach, personally I would like to see them take that approach on all new libraries and even current ones

https://youtu.be/bCwWPFk2ZWg

I think so too. High-level Google leadership doesn't care about avif nor jxl, they care about things like the stock market, doing big layoffs, and which potential future competitors to buy.

~~don't forget taking over the world ~~

For the most part I agree, they shouldn't care about the software - but at times they do. Even Intel admitted that it came down from the top (meaning the AOM group) not to discuss JXL at one point. Now I doubt they care. There is enough data to show that AVIF isn't likely to become a big player in the web images: it hasn't even gotten 1%. But the anti-trust case is clearly showing politics being played even at the high level with respect to a number of things - ads, browsers, search, AI anything they have their hands in.

What's your source for Intel saying that?

Sorry, it was Facebook, not Intel. https://discord.com/channels/794206087879852103/803574970180829194/1040911985409261578

But Intel went silent about it at the same time.

so your source is the same guy you're arguing against right now

You REALLY need to learn that arguments are not just black and white.

Also _wb_ has been involved with JXL from the start and is a great source of information relating to JXL. Everyone can have their own opinions outside of that.

Anyway, probably the best way to promote jxl adoption is to focus on the strengths of jxl, rather than the weaknesses of 'competing' codecs (or their proponents).

angles getting no attention: - your ads displayed super soon even on slow net, bloated webpages (needs reference dataset for ad-type banners) - make *your* jxl-enabled apps load your content faster than browsers - serve em jxl, give chrome the bloated originals

I'm not familiar with iOS development, maybe someone knows - is jxl decoding is supported on system level? I mean can jxls be used for in-app resources and for loading images from BE? On Android there are add-on library for main image loading libaries, but it is not supported for in-app resources obviously

Yes, since iOS 17 it is supported at the system level.

Android system level matters less than iOS system level imo, since the tail of old Android versions is much thicker than the tail of old iOS versions. So you cannot really rely on system level stuff very much in Android. This is why e.g. Chrome on Android does not use the system level image decoders but ships its own copy of avif, webp, even jpeg and png decoders.

Yes, that's why androidx.* exists. But as it is developed by Google, I don't think we will see jxl decoder there, so for in-app images jxl would not be an option

For iOS apps it feels like a no brainer for me, is there any implementation effort or is it just switch the image and call a different decode function ?

Just switch the image, I don't think you even have to call a different decode function

Is there a reason you need specifically .NET instead of bindings?

Sorry, I deleted my question. But to answer - I believe our BE team would not use it, only native .NET

What’s BE? Also I have a mod that caches messages so I didn’t see it was deleted

BE = backend

Anyway, it is just curiosity, because they also serve that images to site, and there is a Chrome..

Continue to live Excel

Text

Voice typing sucks

Linking to LibJXL would probably give better performance

Wait, wouldn't timely addition matter more, not less? Because sooner it is added, sooner the 90% support comes. It should have been added years ago.

It matters less for mayfly formats like webp and avif, because by the time 95% support comes, the format is already discontinued.

from what I understand, because of the huge heterogeneity, Android apps tend not to rely much on system libraries anyway

ah, Jon already said that

Priority #1 is browser support after all

apps and games rely on webview a lot. a jxl-capable webview (like cromite's?) shipped by default or user-installable could technically extend existing apps without requiring changes in those as long as their sites can or do send jxl to capable clients. browser support wouldnt matter if those domains' content is served exclusively to the apps and inaccessible from browsers

Gallery and camera apps rely on it a lot. Only with awxkee's plugins things are starting to change for Coil and Glide based apps.

JXL support in Chromium would also extend to Electron though, which means desktop programs that use it as their GUI framework, like Discord, Teams, Slack, and many more, would suddenly find themselves with the ability to display JXLs and this might encourage these platforms to adopt it

Not necessarily, discord does not support AVIF even though chromium/electron do. There are multiple highly upvoted posts on their support forums requesting support

electron itself or windows' webview2 should do the change, so as to provide a discernable benefit over apps embedding their own chromium webviews

webview2 is Edge, right? Or it's pure Blink?

webview2 is mostly the engine part of edge, now natively integrated witrh windows 10/11 and reused by desktop apps with embedding and store apps

Then if Edge adds JPEG XL support, webview2 would support it automatically.

overnight even, and its running almost all the time - native and store apps and widgets would gain decode too. imo its webview2 that needs to add decode, as edge can be proprietary features exclusive to that browser alone

store apps are bloated with pngs so thatd help ms get apps more optimized and loading much snappier

I'm not saying this would make them adopt it without question, but it certainly would make it more appealing, even if the appeal won't be enough for all of them. Consider also that JXL has many more benefits to the platform itself than AVIF, HEIC, and other formats their users have been asking for. I mean, how many files in Discord's CDN right now are PNGs or JPEGs which could be losslessly reencoded (PNG) or losslessly transcoded (JPEG)? Maybe they wouldn't even have to use a separate WebP for image previews (as opposed to the full files you only see when you "view in browser") if they can utilize progressive decoding to only send enough data to render it with sufficient quality for a preview, without storing that as a separate file I know I'm preaching to the choir, but I think there's a lot more incentive than just "we could use this how that Electron supports it"

Discord would do so if they were smart, but they are too busy implementing 20 new ways to push users to buying nitro and worsening the platform in other ways

Hah, true

part of the problem of these platforms is eternal preservation of every trivial comment ever made. in time your costs end bloating so much it pushes you into faustian pacts like with forums

discord finally started supporting webp a while ago

Only for still images though

It loads endlessly for animated ones

Animated WebP only works correctly for stickers

it does?

Yes

Discord **purposely** breaks animated WebPs

I think at this point it's probably just incompetency

They used to do it intentionally, same for APNG

most of Discord's problems are however *some* of the image format stuff is deliberate

Discord has no clue how to strip metadata for WebPs or really do anything else with them *except* force animated ones to not embed (not even showing a still image)

it seems like they really don't want people bypassing the paid features to the point of forcing GIFs on everyone

So people can less easily get around using sticker packs if they don't have nitro I assume

Yeah that

They know people would rather starve than use GIF <:galaxybrain:821831336372338729>

Hrmm

https://github.com/discord/lilliput/pull/103

Oh, they do embed, they just never load, to the point that at one point the little discord poop appears lol

But yeah, Discord has supported WebP for years, uses animated WebP and APNG since they added stickers, but disallows either to be uploaded by the user

Have a look at this WebP, it will never properly embed

huh

No wait, it does, hm. I last tested this 2 months ago

test:

It shows, but only the first frame

oh damn finally there are embeds for just the first frame now

I'm pretty surprised tbh

Boost the server to level 2 to unlock the second frame!

Can't belive Nyan Cat would lie to me 😭

Never forget, we also had animated WebP and animated PNG pfps too, until Discord decided that would be a great nitro feature.

I've just remembered that I tested uploading animated WebPs some time ago - it showed the first frame as well

remember when they added animated emoji but had no size limit on them

i have the entire bee movie as a 4x3 grid of animated emoji

wel*ll*l it says "Your browser" and you probably wouldn't consider the Discord website as such. though I guess if you use the more broader term of "browser" then you could consider the Discord interface/site as a browser for the current context of the content you are trying to view which in that case would make Nyan Cat tonight's biggest liar

Let me test a different WebP

https://cdn.discordapp.com/attachments/1206620617873563730/1239250157921501316/NF1NvoQ.webp?ex=66e85a25&is=66e708a5&hm=44548e294f0deac99893b64e6356b3237cde0cc710459f5a9985b2ffb1ed66f6&

I'm not sure if I have this also because someone turned it into an emoji, but I similarly have one of the entire Shrek movie

It's just one 16x16 GIF tho lol

Ok, why does this one embed as webp instead of showing

doesn't for me

discord failed to generate a preview

discord never embeds the actual image itself, but rather their own encoded preview of it

no nvm I get what you mean

On a different server it looked like this, last time I tried

ah yes, AVIF generation loss

I kind of like having the ability to go back to stuff from years ago. E.g. you can get the entire history of jxl art in <#824000991891554375> which I think is quite cool. I wonder if I should somehow try to make a backup of this server, in case discord some day decides that it will start deleting old messages unless you pay them.

note I actually did get https://github.com/Knewest/embed-more-images working with a patched chromium to get jxl to embed in discord

https://evanw.github.io/thumbhash/

this is how dissent treats images without generated embeds lol

if you click it, it does open though

It never loaded though. It tried to, until discord just gave up and displayed the disocrd poop (it feels really stupid to write this)

This is what I used to use, exports to HTML for instant readability, or JSON for all the data to be used with something like this <https://github.com/slatinsky/DiscordChatExporter-frontend> (Doesn't use any compression on the database though so size is huge...) https://github.com/Tyrrrz/DiscordChatExporter

Can download assets and reuse them across channels too

slow typing fails me again 😔

Message so long the background color changed

I also realised with a JXL supported browser, I can just JXL encode a telegram export with the same filenames and sniffing figures the rest out for minimal effort

HTML export is not a good idea (I have used it before and the issues that arise from trying to view them are awful). JSON is definitely the way to go, along with asset downloading (plus reuse) and also turning off "Format markdown" since the frontend program recommends doing so

The HTML works if you partition based on the amount of content in the channel, but it is more work to avoid the gigabyte overhead of the frontend

Plus I can view it on my phone or anything with a browser then

for long term storage the JSON output is definitely the way to go as it can be converted to some HTML version at a later point. although I haven't really seen any software that lets you do the useful things that are very much possible with the JSON output sadly

Yeah, for power users naturally JSON is the way to go, for just ease of use and compatibility I've always gone with HTML

there should really be something that allows you to convert the JSON output to other formats like HTML

because the HTML output has personally caused me problems in the past that I'm not sure I would want to remember

I'm just glad they added a download assets option... That poor poor browser trying to download 5K embeds at once....

I just did a backup. What a pleasant surprise, it's 15.3 GB. I thought it would take up much more space. <:Stonks:806137886726553651>

Now time to re-encode as JXL

I personally just expose to HTML but should probably get to using JSON

Did you also include threads?

Mine download to 21 gb

Threads included

I used JSON instead of HTML

That may be why

So, the wording has been changed to not explicitly mention the Chrome removal, but I still feel like Apple should be mentioned too. Maybe a clarification of the different teams at Google but I'm not sure https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption

Argh hyphens everywhere https://9to5mac.com/2024/09/13/iphone-16-pro-lets-users-capture-proraw-photos-in-jpeg-xl-format/

JPEG Lossless ?! for HDR content ?!! I missed someting

For RAW format

Not for delivery

The codes from iOS 18 itself use JPEG-XL

So its usage is promoted by our beloved Apple

The DNG 1.7 spec (https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_1_0.pdf) does get it right, with a space and no dash.

But I guess marketing people and journalists somehow think there should be a dash there

Apple believes people should use USB 4 instead of USB4 so the same logic is applied to JPEG XL as well

if a dash is the last problem we have with its adoption... it is a small one

Chrome can call it JPEG——~~~××ו••XL if they want, if that's what it takes to get them to support it 😆

https://youtu.be/aj9FlmWg7y0?si=EuZySpSikYdVHqVH

JPEG一XL

That's the character for "one"

Maybe not the best thumbnail haha

They read "JPEG XL" from the title, "75 MB each" from the thumbnail and go "no thanks I don't need these Extra Large JPEGs"

JPEG二千

JPEG :-:/-:,@]*}+~€]{€~£ XL

> only coming to the Pro lineup Someone please make an app to convert them when you don’t have 16 pro

There are some apps already

Is this one good? https://apps.apple.com/au/app/jpeg-xl-toolbox/id6470681357

https://tinydng.com/

Don't even need to download anything

traditionally, only Pro models allow you to shoot in ProRaw, so JXL being used for ProRaw obvously doesn't apply to non-Pro models.

I meant I have a 14 Pro Max and the rumours say it’s only for the 16s

oooh right

I got that part, but other rumours say 16P +

Also I’m on 18 RC and there is no JXL

Good enough and I got the chance to have free Pro

Although I have no device that can produce ProRAW

Pro? It’s a free app?

Uh it used to be have a Pro option

Then it's currently the one choice

That supports Dark Mode and multiple languages as well, and optimises for the landscape mode too

ARGHHH