JPEG XL

mozilla or at least reasonable people there should be petitioned again, if just for making jxl default in the Developper edition and letting volunteers updating the already existing working patches. even google didnt make a decision final and conditioned reevaluation to industry support

I still hope maybe they change their mind when jxl is finally 1.0

The industry already supports it. Chrome codec team is actually just giving us all the finger and blatantly lying through their teeth when they said they would look at ways to improve their broken comparison.

Their own data said avif lost to jxl at ssim2

They made it clear that Jim Bankowski and his codec team have unilaterally decided to destroy JXL and they don't owe anyone an explanation or anything.

And mozilla are not reasonable or neutral either. They explicitly state that they do not think JXL should be part of firefox.

And that they will parrot exactly what Jim says, except with even less accountability and even more vague language and use of the royal "we"

"**We** have talked about it and thought long and hard and **we** discussed it with '''our partners''' who say such and such and **we** can't do it because someone said something to us behind closed doors and we are going to keep being vague about it and avoid saying who's responsible for making decisions about anything. Yay open source web lol!"

Pure horseshit weasel language that uses a lot of words to say absolutely nothing but "I don't owe you a real explanation, fuck off, official decision from on high, let me pretend to care."

The people in fact making the decision deny having any personal agency or will of their own

Mozilla is cringe. I stopped using Firefox

based all browsers kneel to ladybird

my company never heard of jxl

(oldest drawing program)

At least it allows to switch tabs in recent order, not just as they are in tabbar, and disable autoplaying videos 🤷‍♂️

Why didn't you advertise for it yet ?! 😁

they added webp like last year

Wearing t-shirts "jpegXL rocks" for example

Which tool is it? Corel?

But you said they never heard of it? I understand the implementation lags behind, but they should at least hear about it 😊

MS Paint?

Mario paint?

Deluxe Paint? The Amiga drawing program from 1985? Or MacPaint? That one had its first version in 1984...

macpaint ! I drew stuff on our apple 512k when my father had finished to work !

no greyscale, just dithered black and white if I remember

it was corel

they never heard of it because nobody asked for it

I think it will stay that way until someone asks for it

and by someone i mean another company

I don't know much about Tachiyomi but how did it support JPEG XL when it looks like an aggregator from multiple comic sources which are unlikely to support JPEG XL by themselves?

it's a library and reader

you can make your own sources and use jxl

so Tachiyomi the app is gone, but Tachiyomi the library is still there? makes sense then.

no the app is a library and reader

the project leaders just bailed because of the scare

huh

so the minimal possible change was to avoid that comic source, but that lead to developer burnouts that caused the entire shutdown even though that was not necessary, right?

anyway, should go to <#806898911091753051>, sorry about that

What's the problem? I'm using it and it works.

I think it went down as part of Kakao's recent crackdown on piracy.

neither change nor shutdown were necessary but you gotta respect dev for not chaining himself to a fight

no more updates if any api changes or fixes are needed

Sounds like yet another target of Kakao.

they can try it lol, the reason why kakao won is because tachiyomi devs straight up didnt even try

do note that the way american copyright law applies to github repositories is that each individiual project is considered separate, including forks

and every fork must manually be sent a DMCA takedown notice. github won't purge forks of the original

https://docs.github.com/en/site-policy/content-removal-policies/dmca-takedown-policy#b-what-about-forks-or-whats-a-fork

tachi devs just pussied out because kako threatened them like mafia

shouldve published the emails and told them to get lost. the issue is with the websites themselves, even if extensions get deleted its meaningless

thepiratebay

https://www.phoronix.com/news/GNOME-46-Alpha-Released

https://r2.community.samsung.com/t5/CamCyclopedia/JPEG-XL-Image-Codec/ba-p/15356525

safe to assume the preinstalled samsung gallery app will be updated with read support across their android lineup

that seems like a relatively big jump, isn't that a community website?

> Now, with the adoption of the JPEG XL codec in Expert RAW on Galaxy smartphones, professional-quality images can be compressed into very small file sizes, alleviating concerns about storage capacity and enabling extensive photo shooting.

is this real though, needs cross checking

googling just gets you to that page

theres another for the s24 gallery update https://r2.community.samsung.com/t5/CamCyclopedia/Introducing-the-Galaxy-S24-Camera-Gallery/ba-p/15350511

posted 16 hours ago, about when news articles about the S24 started dropping, so probably written before then.

guess we'll see when it's released?

which is apparently on the 31st

the korean regional version of the same site got updated with the same information from a different moderator

👀

Apple and Samsung represent 40% of the smartphone market, this is pretty big.

I guess they are almost 100% in south korea

Cloudinary's FLIP, lol. My wife has one of those Z Flip phones 🙂

anyway, great news!

let's start a betting pool. how many big tech companies need to adopt JXL before Chrome re-adds it?

if/when PDF spec includes it the browsers with preinstalled pdf readers will eventually have to

It will eventually be added to the PDF spec, but Chrome could still decide to leave it to the pdf decoder to implement jxl decoding (or to just not support the latest PDF spec) and keep not supporting it natively / in an img tag.

eh, probably better to just wait until it's released

definitely wait for more info, no need rushing

on an aside, maybe promotional materials could use an update, individuals not savvy enough with the format tend to improvise information or fail to mention jxl even when support is added

https://shoptalkshow.com/598/#t=27:43

They are quite popular in Easten Europe

and in western europe too. For france it's one every three phones (https://gs.statcounter.com/vendor-market-share/mobile/france)

I like what she has to say about it

Here proportion is a bit different as many people prefer the cheapest phones like xiaomi, and other china phones, but samsung is very popular too

i heard in another discord group of the samsung mobile phone adaptation this makes me wonder when standalone cameras will implement JXL, and whether the standalone cameras samsung manufactures will follow suit after the mobile phones

not 100% sure but it seems like Samsung might only export JPEG XL images inside of DNG RAWs?

is there even a way currently to convert a JPEG XL DNG into a normal JXL? (without re-encoding the actual image data)

seems like every reference to JPEG XL on those Samsung articles states it as being used inside of DNGs

>not 100% sure but it seems like Samsung might only export JPEG XL images inside of DNG RAWs? That would be something new, because now samsung produces non-compressed dngs

Yeah, I was about to say I don't want to burst everyone's bubble, but it's sounding like DNG 1.7 rather than actual JXL support

Still great, considering my phone only does uncompressed too, and doesn't even bother with thumbnails or non-essential metadata

I have managed to extract the JXL codestream out of a DNG using a hex editor, although this was back when Adobe first released DNG 7.0 so I can't remember the details

DNG 1.7?

Yeah, sorry, I had 7.1 in my head

> 200MP high-resolution Something tells me that's not going to look very good

what kind of jxl are they using where it doesn't take 10 hours and 5 gorbillion ram

i mean, my current phone, just to take a regular JPEG photo, uses so much ram that all background tasks are killed by the OS

music player, VPN, everything

The Expert Raw app that uses JXL seems to have a max size of 24MP

They can use heavy binning, but even without it source image is so bad and processing is so heavy, that it is nothing more than marketing

Yeah, there's so much AI and cropping packed in that post that JXL Raw might be the only way to get the original image xP

And it will be VERY disappointing, sadly. I tried to do at least comparable to what my 3-years-old phone does, and failed, despite I have some experience in raw postprocessing

Huh, okay so it turns out DNG 1.7 only added JXL lossy as an option, it was DNG 1.7.1 that added distance, effort and decode speed. That's probably why some couldn't find the options until I posted them here

I assume getting a jxl payload out of a dng should be just a matter of removing a wrapper. I kind of wonder why to put a jxl in a dng instead of putting dng metadata in a jxl file.

If it's simple enough, we could make libjxl parse dng to see if there's a jxl payload and make it decode such dng files directly.

Yeah, like I mentioned earlier I got the codestream out using a hex editor and simply copy pasted to an empty file. The brotli compression would certainly help with the large amount of metadata, although DNG can use JXL for tiles with no headers so it may not be so simple

Part of me does wonder what kind of requirements Blender would have to add support. It *is* open source, but it's always seemed fairly closed off to me. But maybe that's just because I'm used to Github https://projects.blender.org/blender/blender

I think WebP support was a random pull request? not 100% sure

I assume the only requirement would be a well put together pull request

Yeah, seems like you're right. Here's a quote from the JPEG XL article: > Recently, Adobe introduced the DNG 1.7 standard, defining JPEG XL as a new codec for raw image compression alongside lossless JPEG. Consequently, Expert RAW adopted DNG 1.7, compressing raw images with JPEG XL and saving them as DNG files.

I still find that exciting

Yeah, progress is progress, especially on the largest files around

I was tired of android for today, so I may have implemented jxl support on [chafa](https://github.com/hpjansson/chafa/) 😂

I will make a pull request once the code is cleaner

I found an app on Android that lets you view/convert JPEG XL! This implementation is pretty good for most basic users and encodes/decodes fairly quickly compared to AVIF.

Good point, I did notice the ads tag but I'm using adguard so I don't see anything. As for the location it hasn't collected anything yet, but thanks for the notice. How would I install your recommendation? I'm used to basic apks and not much more as a basic user, but I'd assume it's on Github?

Sorry if it seemed like I was promoting the app. Just searched on the Play Store and this is what I found. Looking around this Discord it seems like most people are advanced experts so I apologize for my lack of knowledge on the subject.

https://github.com/oupson/Jxl-Gallery

https://news.ycombinator.com/item?id=39064820 Samsung joins Apple and Adobe in supporting JPEG XL

the regular gallery app (v14.5) already decodes dng **1.6** raws. safe to assume 1.7 decode support is next and gonna reach more devices than just s24 or the premium lineup, even if they cant take raw photos

that might be indeed where JPEG XL actually went, because DNG 1.7 includes JPEG XL bitstream as one of compression options

I wonder if they'll also support jxl files not wrapped in a dng...

Would be silly not to support that too if you're shipping a jxl decoder anyway, but I can imagine some silly reasons why it wouldn't work

if they wouldn't add bare jxl support will you plan to add dng container support to cjxl / djxl ?

I dunno how much work that is, definitely not full dng decode support, but if it's just one jxl payload somewhere easy to find, that should be easy enough to add. Might cause some confusion though if libjxl can handle some dng files but not others...

It would not have sense in case if they plan to compress bayer planes with jxl

that will be the first device producing jxl compressed raws so I guess we'll see how they'll do it

I assume dng just uses separate grayscale bitstreams for each Bayer plane. In jxl we do have an extra channel id reserved for Bayer data but it's not yet defined how to use those (that is, where/how to store the Bayer pattern layout, and how to do debayering). The idea was to put R,avgG,B in the normal color channels, and deltaG in such a Bayer extra channel. Then a naive decoder can show a reasonable preview at half resolution, and for full resolution you need to reconstruct the two Green channels and debayer...

Btw, I tried to recompress lossless jpeg bayer dng to lossless bayer jxl, and surprisingly size change were really small, ~10%. However it was default e7, not tried e9

How did you do that recompression? I don't think any tool is producing bayer jxl currently...

Adobe DNG converter in console mode

<@794205442175402004> you've shared user agent request stats here a few times, but can you share how many of those requests are actually being served with JXL files right now? Or is that private and/or harder to figure out.

I wonder what it does. Does it create jxl files that decode to something usable in a naive viewer?

No

I can share such file if you want

Not many yet, since it's still opt-in, so only f_jxl and only customers that opted in to have jxl in f_auto

yeah, I'm basically curious about how many have opted into jxl, weighted by their popularity

Here what exiftool says about it: c:\Program Files\Adobe\Adobe DNG Converter>exiftool CF028078_1.dng ExifTool Version Number : 12.73 File Name : CF028078_1.dng Directory : . File Size : 103 MB File Modification Date/Time : 2024:01:20 20:04:53+02:00 File Access Date/Time : 2024:01:20 20:05:40+02:00 File Creation Date/Time : 2024:01:20 20:04:53+02:00 File Permissions : -rw-rw-rw- File Type : DNG File Type Extension : dng MIME Type : image/x-adobe-dng Exif Byte Order : Little-endian (Intel, II) Make : Phase One A/S Camera Model Name : IQ180 Preview Image Start : 66288 Orientation : Horizontal (normal) Rows Per Strip : 192 Preview Image Length : 17794 Software : Adobe DNG Converter 16.1 (Windows) Modify Date : 2024:01:20 20:04:53 Image Width : 10328 Image Height : 7760 Bits Per Sample : 16 Compression : JPEG XL Photometric Interpretation : Color Filter Array Samples Per Pixel : 1 Planar Configuration : Chunky Tile Width : 704 Tile Length : 720 Tile Offsets : (Binary data 1469 bytes, use -b option to extract) Tile Byte Counts : (Binary data 1154 bytes, use -b option to extract) CFA Repeat Pattern Dim : 2 2 CFA Pattern 2 : 0 1 1 2 CFA Plane Color : Red,Green,Blue

I think the biggest customer that is producing f_auto jxl currently is FC Bayern München.

aha

I'd be curious about % of requests, but I understand if you can't share that 🙂

RawDigger is also currently not aware of such dngs

Still very low, we are delivering something like 1.5m jxl images per day out of 15b total.

But if we would decide to push the button to enable it by default in f_auto, we would be delivering something like 2b jxl images per day.

honestly doesn't seem too bad this early for a feature that needs explicit opt-in on a CDN whose whole selling point is basically "use f_auto and we'll figure it out for you"

pushing that button will be a huge moment when it eventually happens

Looks like for lossless jxl it just ignores -jxl_effort param, so I don't know what effort is used for such compression

maybe we need a `dng_jxltran`

Yeah, libRAW isn't updated for DNG 1.7 yet, there's an open issue for it but no replies yet other than me mentioning Samsung

The command line DNG converter is... Finicky... The order of commands seems to matter along with random "Error: File not found" messages when I tried

For me it was a surpise that it requires full path even if file lays near exe 🤷‍♂️ So yes, it is not very comfortable

Yeah, even using a full path it would randomly... Do nothing... No error, no output, just a second and then blank console

> -losslessJXL Uses Lossless JPEG XL compression. > Implies -jxl and -jxl_distance 0.0 and -jxl_effort 7

<https://helpx.adobe.com/content/dam/help/en/camera-raw/digital-negative/jcr_content/root/content/flex/items/position/position-par/download_section/download-1/dng_converter_commandline.pdf>

Right, missed it, thank you

I was staring at the DNG spec wondering where all the command options went, then remembered it's a seperate document

Aaand " -jxl -jxl_distance 0.0 -jxl_effort 9" produces... jpeg dng 😆

I may as well just post the entire JXL related section ``` -jxl Use JPEG XL compression, if supported by image type. Implies -dng1.7 -jxl_distance Set JPEG XL distance metric (see libjxl documentation). Valid values are 0.0 to 6.0. 0.0 is lossless and 0.1 is very high-quality lossy Implies -jxl -jxl_effort Set JPEG XL effort level (see libjxl documentation). Valid values are 1 to 9, where 1 = fastest. Implies -jxl -losslessJXL Uses Lossless JPEG XL compression. Implies -jxl and -jxl_distance 0.0 and -jxl_effort 7 -lossyMosaicJXL Uses Lossy JPEG XL compression with Bayer images. ```

So it is broken, I believe, only -losslessJXL really switches it to JXL mode

Yeah, I *think* losslessJXL switches it into Modular, so it can then use lossless, otherwise defaulting to VarDCT. Where distance 0 is then invalid so defaults back to Jpeg. At a complete guess

Considering the program barely functions in command line I wouldn't be surprised

I do remember getting lossless at different effort levels, just need the right combo and order of arguments

And probably a blessing from Alan Turing while you're at it

PTGui is! https://ptgui.com/versionhistory.html#:~:text=Added%20support%20for%20DNG%20files%20with%20embedded%20JpegXL%20encoded%20data%2C%20as%20created%20by%20recent%20versions%20of%20Adobe%20LightRoom%20and%20Photoshop%2E

I should also point out, the Samsung DNGs are only made in the "Expert Raw" app from what I can see, so there likely won't be as many as we expect being created, but hopefully 'universal' support on their gallery still comes

If only they had lower price.. 😢

> Give PTGui a try! The trial version is fully functional, there's no time limit, but stitched panoramas have a visible watermark. Well, that's not as bad as I expected

Although I imagine I'd immediately make my 16GB of RAM cry trying to actually make a panorama xD

it seems to peak at about 5.5GB of memory used when stitching the starting panorama of https://sami.photo/pano/golzernsee/ (as measured by the very scientific method of “watching the task manager while it does its thing”)

although that’s with the control points already set up, haven’t tried to see how much RAM it needs to find those

let me try that

I saw it go up to 7GB while loading the images (but maybe that’s influenced by the amount available), but then no more than 5GB during “Align images”

input was 19 TIFFs, each 24 MP

Switzerland 😍

(more photos from that day: https://sami.photo/2023-05-06-Golzernsee.html )

I love taking photos of nature, but I've never been to Switzerland 😦

as you can see, it tends to be sort of a “domesticated nature”

rocks can fall, but there’s a sign to warn you (and stairs)

the road can sometimes only sustain 2 tons, but there’s a road (and a sign)

(you could almost reenact https://youtu.be/phJKQcvZ3sE)

(okay, maybe not)

Me at work 😅 (in phototour, actually)

that also looks breath-taking!

Faroes

Okay, the DNG converter is just witchcraft. Use the example command, perfectly fine. Try to set it to lossless, it discards the JXL commands or prints a missing file error (And at least for me, the example "High quality lossy" command results in even larger files than lossless)

missing file almost sounds as though it might be trying to interpret one of the flags as a filename

chafa now support jpeg xl !

https://twitter.com/lake_utuqaq/status/1751250428375769494?t=X3A4OP3SpZcbvDl4DgDttw&s=19

twitter doesn't allow people to see replies without an account here is the main tweet: https://twitter.com/teroalhonen/status/1750957377292062735

(I don't have an account I had to ask someone for this tweet lol)

So WDYT, is this an indication that jxl support is coming in Windows?

it seems so? [wincodec.h](https://learn.microsoft.com/en-us/windows/win32/api/wincodec/) only really refers to a default Windows API header and from looking at what other posts that person has made on other platforms (I can't see everything due to lack of account) they don't seem to be making this themselves.

I am curious as to where this copy of wincodec.h was spotted though

I'm not well versed enough to really know

a bunch of Nitter instances have been going down recently it seems which is why I didn't use it in this case

I have found the header shown in the tweet. https://www.nuget.org/packages/Microsoft.Windows.SDK.CPP/10.0.26031-preview it's in `c\Include\10.0.26031.0\um\wincodec.h`

3 days ago this was seemly added

seems to also have an encoder?

man... even windows will get official jxl support faster then firefox

https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&name=cheems%7E1&quality=lossless

well maybe I can enable insider preview to test that, build 26031 seems bleeding edge though

hopefully they get HDR down right as it seems like a lot of implementations of JXL have broken or non-existent support for HDR and high bit depth

> It is still in Preview (Windows) / Nightly (Firefox) so both are on the same page. are they? MS is actively working on it apparently, firefox has left it to rot

I wouldn't recommend enabling insider builds on your main PC because iirc it's really hard or almost impossible to revert to normal builds of Windows

yeah I'm aware of that, I've once enabled insider before

like, I need to prepare clean install just in case

other (costly) option is to buy another copy of windows and use VM

do the insider builds require a key? with normal windows you can just make a VM and it will work without a key and then after 30 days still work but have some small features disabled

ah yeah that might work too

it does require a licensed copy of windows

well, VMs work right? I can spin one up soon™️

This would probably be the biggest JXL news, even surpassing Apple, if true <:FeelsAmazingMan:808826295768449054>

seems like there isn't wic codec for jxl in build 16040, maybe only headers

windows photo viewer cannot open jxl images

which one? Photos app or classic Windows Photo Viewer?

classic one using rundll32

jpg images were okay so I'm using it in the right way

can you give the full build number? I thought 23620 was the most recent build?

oops it's 26040

watermark at the bottom right shows "Build 26040.rs_prerelease.240122-1157"

it shows something generic like "JXL file", but I found something interesting: it shows media metadata UI in Properties window although it cannot be edited

well it's shown in stable version too

my desktop is not clean so I'm not sure

in `WindowsCodecs.dll` located in System32 do any strings like "jxl" or "jpegxl" appear inside?

nope

I found a table of signatures, it doesn't contain `ftypjxl ` either

<@206628065147748352> it seems that that file doesn't contain WebP implementation either. in fact, the GUID `{7693E886-51C9-4070-8419-9F70738EC8FA}` is mapped to `mswebp.dll` in my system (Windows 10). so I guess you should rather search for `fc6ceece` from regedit to find the actual dll?

oh there it is!

it registers two patterns, one for bare codestream and one for container format

take a look at InprocServer32

it's `%SystemRoot%\system32\MSRAWImage.dll`

WAT

inb4 Windows only ends up supporting JPEG XL for DNG containers and nothing else

possible

well, at least with Adobe making DNG utilize JXL for compression, it should be easier for software that already supports DNG to also support pure JXL files, if they so wish

although, this does seem to point to ".jxl" files specifically with its FileExtensions and MimeTypes tag

indeed, so it might get both

the patterns are also for pure jxl files

this is one of those

i'm on regular Win11 release

can you paste the reg path?

`\HKEY_CLASSES_ROOT\CLSID\{fc6ceece-aef5-4a23-96ec-5984ffb486d9}`

thanks!

is there any `.jxl` key in the registry? (or `jxlfile`)

more concretely: https://stackoverflow.com/a/39397932

there is `.jxl`

at the very least `HKCR\.jxl` should exist in order to be supported

(take two) stable win11 build 22621.3007 with jxl-winthumb, i have the registry key too

`{e357fccd-a995-4576-b01f-234630154e96}` is `IThumbnailProvider`!

so we are at least going to get a thumbnail, probably?

it says `{C7657C4A-9F68-40fa-A4DF-96BC08EB3551}` in that

yeah that should be the standard Windows default

in my system both `.dng` and `.webp` have same subkeys and values

so maybe support is planned but not implemented

yeah that sounds the most plausible answer

hm, on my machine, only InprocServer32 has values, Patterns is blank

i guess that's new in the new builds?

so the implementation itself lives in `msrawimage.dll`, but it additionally handles `.jxl` as it's easy to add

yeah that's a recent insider build of Windows

Adobe pushing JXL support ftw (hopefully)

it's canary build, it may take a while to get into other channels

yea, i was just kinda surprised traces of it even exist in release builds

i guess msft has been planning this for a while?

maybe there's an internal build flag to enable it in codebase, who knows

anyway this is quite promising

This was a good way to wake up

And now I have a second reason to get a new CPU along with 7 year old performance, Windows 11 for the JXL

maybe it's a codec pack in the store, like for avif/webp and others?

weird thing is wincodec.h defines WebP, HEIF, and JPEG XL but not AVIF

windows actually does have webp support built in, it just doesn't recognize the .webp extension

like rename a webp to .jpg and it'll open fine

i mean <https://support.microsoft.com/en-us/windows/media-feature-pack-for-windows-10-11-n-february-2023-2aaf89b8-f9d3-4322-98d0-612c9bea9c01>

freezing a nice API for 1.0 will become the next critical step! Gambatte developers!

Are they using libjxl or own jxl decoder?

not sure, but for example when twitch was testing new codecs almost all viewers from different regions had to install hevc and av1 extensions, otherwise such streams didn't work for windows and edge (and hevc in any other browsers)

At least on Windows 10, those are still 'add-on packs' that you need to get from the store

Including RAW (DNG) viewing

I think it's add-on from the store (found in `msrawimage.dll`)

Interop 2024 proposal response will be published on Feb 1st <https://github.com/web-platform-tests/interop/issues/625#issuecomment-1912268785>

Thank you!

My birthday is the 30th, so hopefully it'll be a late present :P

Also huh, JXL making a cameo on the WebP addon too

Why it has 261 dislikes for that extension?

There's a lot of irrational hate for webp for no apparent reason

because for a long time, nothing but Chrome supported it, so you'd download an image and it wouldn't work in any program

even today, even thought libwebp literally ships inside windows, the built in photo viewer won't open any webp file unless you give it a false name (like .jpg) or if you download a codec pack.

yea tho that's got nothing to do with the image format

it's just normies inventing a reason to rage

and directing their frustration at the wrong thing

the magistrally wrong thing, given that it’s the precise thing that fixes their gripe

They vote it down because it shouldn't be an addon that people have to go out of their way to install

well the ecosystem around webp is... not that great to say the least, GDK doesn't have official webp support, Android's webp used to be so attrocious that gallery apps would disable webp support outright since it was better to not support it then deal with the bugs and complaints

that's interesting, because microsoft uses libraw (without jxl support) for this extension <https://github.com/LibRaw/LibRaw>

a bunch of online services also used to have really poor support, even up to like 2 or 3 years ago people would find that <insert crappy webservice here> didn't support webp properly

I remeber some software my pops used for buisness cards also didn't work for some reason, but yeah, the poor ecosystem around webp and the bugs with so many implementations kinda burned it for a lot of people.

Discord, despite being electron, and using webp for profile pictures and emojis, only started supporting it for attached images like a year ago.

>tfw we had animated pfps, discord took them away, then added it behind nitro, so people used apngs, they fixed that, and then we used animated webps, and they took that away too

T.T

I wonder how much it has to do with the fact that `cwebp` and `dwebp` are a little awkward

I mean, I just ran `cwebp --help` to see if it was as I remembered it, and already: ``` $ cwebp --help Error! Unknown option '--help' ``` (it still printed the help, though)

the options are shown with little apparent ordering (see where `-lossless` is described)

it’s all a bit overwhelming

I couldn't say much about webp/libwebp itself, but at the very least, I do understand where the... lets say misplaced anger comes from. for a lot of people, webp was just simply broken. it's not so bad now, ofc there certainly still are some bad apps ofc, but the reputational damage is already done. it's always nice to say "just use good applications" but this is the general people we are talking about.

And at the same time it is the default bitmap format for android developers. Android studio even contains tool to losslessly convert project's pngs to webp if it gives size reduction

speaking of android, I wonder if JXL could be provided as a module, typically its handled by skia iirc

I'm wondering more when (if) it will be allowed to use jxl as resources inside app. But we all know Google..

I was going to say, this is still JXL <#803574970180829194> after all rather than WebP

Nothing in Windows 10 unfortunately, at least as far as I could tell

TBF, Windows 10 is EOL in a 20 months. Though they still want to add their AI stuff so who knows.

Well, I'm glad that MS Windows team is at least experimenting with support. Gives us hope

well if you ship your own decoder you couls, but yeah once android adds support for JXL its a global thing pretty much. It may be possible to create a codec2 interface for it, if so then you could easily, if root, add support yourself, and vendors could potentially back port it to android 12+ devices.

Not at this price, really. And in any case these resources would not be rendered in android studio, so no, until it happens as global thing - no way 😦

So, more user-friendly than `cjxl`.

that’s not how I perceive it, at least in terms of basic usage

`cjxl --help` has you understand three options, two of which are explained to be equivalent and the remaining option usually not needing to be changed

from that, you can do lossy and lossless

don’t have to wade through dozens of options (`-segments`? `-sns`? `-sharpness`? `-sharp_yuv`?) just to find the `-lossless` option

(and figure out which ones, if any, are relevant to that mode)

Do cwebp/dwebp still ignore ICC profiles? That was something that bothered me a lot

by default, yes, but you can tell it not to

``` -metadata <string> ..... comma separated list of metadata to copy from the input to the output if present. Valid values: all, none (default), exif, icc, xmp ```

also with cwebp it pretends to work like cjpeg but doesn't

``` $ cwebp test.png test.webp Could not read 0 bytes of data from file test.webp Error! Could not process file test.webp Error! Cannot read input picture file 'test.webp' $ cwebp test.png >test.webp No output file specified (no -o flag). Encoding will be performed, but its results discarded. ```

if you run `cwebp input.png output.webp` it fails cause it can't read from `output.webp`

so you're like "oh okay it's like cjpeg, so I'll just redirect stdout"

and that doesn't work either

it also tunes for PSNR by default in lossy mode

yeah, outside of dedicated media consumption apps, I doubt it will be a viable solution for anyone to implement their own jxl decoding, perhaps browsers and a select few other apps. That being said I did try and take at some of the code for Android's new modular codec api, and it does seem like it could be possible to see JXL implemented like that, so thats neat

It prints the help even when you don't know how to ask. `cjxl` makes you ask, then makes you ask very, very, very, very nicely. It's quite suspect that you typed out `--help` in the first place, who has time for anything other than `-h`? Asked properly, `cwebp`'s basic usage is more straightforward than `cjxl`'s.

So cwebp strips ICC profiles by default, but can preserve them with an option. But then dwebp doesn't even have an option to preserve ICC profiles in its output.

How do you mean, `cjxl` makes you ask? If you just type `cjxl` without anything else, it shows help. Same if you add `-h` or `--help`.

`cjxl --invalid_option`

`cjxl`, `cjxl -h`, `cjxl --help` all show the same basic help. `cwebp`, `cwebp -h`, `cwebp -help` all show the same basic help. To get the full help, for `cjxl` you add more `-v` while for `cwebp` it's `-longhelp` or any invalid option.

I personally prefer it when entering an invalid option doesn't barf the help on me

because it means any kind of typos clutter your screen

cjxl's current behavior which prints the help if you pass no options, but not if you pass an invalid option, is the ideal design IMO

the CLI user interface for cwebp leaves much to be desired but I also don't believe that normies who randomly hate on webp and misdirect their hate even know what a command-line interface is

re: this, probably very little

since services and software are using libwebp, not cwebp

and people who use those services and software are using neither

barfing a long help screen on invalid options, like cwebp does, is annoying imo — it feels like I'm getting slapped with the manual for making a typo

I agree

granted, cjxl isn't perfect notably in the error reporting area

``` $ cjxl test.webp test.jxl JPEG XL encoder v0.10.0 27500251 [AVX2] ./lib/extras/dec/decode.cc:140: JXL_FAILURE: Codecs failed to decode Getting pixel data failed. ``` for example here, "getting pixel data failed"

why? it should say "Unrecognized input file format."

but it doesn't

Yes, people who dislike webp dislike it because they save an image from the web and get something in their Downloads folder that doesn't work if you double click on it

^ this

but that's not the fault of the webp format or its creators, and hate is misdirected

You're both right, but I had to emphasize the irony.

It's partly the fault of those webp creators who considered it a good idea to have a "Web Picture" format that works in browsers but not necessarily anywhere else since it's just a "Web format". This kind of was the design philosophy of webp: to make a format "for the web", with a scope limited to what the web needs (hence the limits in dimensions, only 8-bit, etc: this was all considered "good enough for the web") and with adoption goals limited to web browsers.

Basically: "webp" = "inferior copy of image re-encoded, artifacted and scaled down by some CDN and you have to use voodoo to get a real thing";

There's no "first party" webp.

I mean, at Cloudinary we produce a lot of webp; most images are downscaled from high-res originals, and for images where 4:2:0 is not problematic, webp can be a good choice (it's cheaper to encode than avif and has near-universal support).

is it actually better than just jpeg though

iirc mozjpeg was created specifically to demonstrate that legacy JPEG is still a better and more expressive format than lossy webp

(I assume you're using lossy and not lossless here)

webp's encoder has been improving since then, so webp almost always wins over mozjpeg and libjpeg-turbo

jpegli, on the other hand, seems to consistently defeat webp across a range of quality levels

Perhaps if Cloudinary deploys jpegli after its official release, the use of webp will go down.

cloudinary has all the originals so that seems feasible

not clear to me if XYB jpeg can be done on the web easily

jpegli doesn't need XYB to beat webp

that's true

I was about to say the same 😛

you'd have to scrub the user agent to check if they can do color management properly

might be simpler to just use nonXYB

XYB does make a difference, but IIRC the webp->jpegli YUV delta is a good deal bigger than the jpegli YUV->jpegli XYB delta

makes sense

lossy webp isn't even a good web format compared to legacy JPEG, notably because it lacks progressive loading

legacy JPEG truly is a great web format

alien technology from the future

the only relevant cases I can think of where browsers don't support color management is versions of Firefox before v108 (although the toggle has existed way before then) and WebKit in certain scenarios

Re-encoding of jpeg => webp (which always happens) is always worse than just plain jpeg.

not always worse if the JPEG was encoded originally with an unnecessarily high quality

or if you want to produce a downscaled version

lossy -> lossy is usually not what you want but sometimes it makes sense

e.g. suppose you receive a 18000x12000 JPEG with quality=98 and need to serve a reasonable version

18000x12000 is a nonhypothetical thing btw, I actually had one of them recently

I'm not sure if jpegli beats webp in the q60-70 range. At the higher end, jpegli does seem like a good idea.

Nowadays people resort to uploading pictures in RAR archives when they want to upload print-quality pics, because uploading them as png/jpeg always means that app/website will meddle and downscale/re-encode/etc them.

that's not always the case

it's a reasonable assumption though: if you share something via whatsapp, facebook, twitter, etc, it will get downscaled and re-encoded

Sometimes years down the line

sure, but that's not what people send to CDNs

I've noticed that when sites generate a lower quality preview,but shows the original non-reencoded version when you open it in full, people still complain about supposed quality degredations.

lossy -> lossy is usually not a good idea but it often can be

``` big.jpg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=7, orientation=upper-left, xresolution=98, yresolution=106, resolutionunit=2, software=Adobe Photoshop CS6 (Windows), datetime=2021:04:13 10:33:48], baseline, precision 8, 18000x12000, components 3 ``` Here's a JPEG I had to work with recently

18000x12000 is not a joke

the image is like 213M

lossless JXL transcode takes it down to 177M

the fact that the original is JPEG doesn't matter much if I need to serve it

in cloudinary, if you upload a jpeg and then do q_auto on it (without any modifications like downscaling), it will estimate the jpeg quality from the quantization tables, and do one of these things: - low quality: keep the data as is, only optimize the huffman coding - high quality: re-quantize some of the DCT coefficients (but keep those that are already quantized enough as-is) - very high quality: decode to pixels and encode in whatever way the pixels would be encoded The first two cases are guaranteed to be stable regarding generation loss, since everything remains in the quantized DCT domain.

what if you upload an incredibly massive JPEG

probably on a free account you'll hit some megabyte or megapixel limit; on an account where those limits are relaxed, I'm not sure: maybe it'll work, maybe it'll go OOM and return 500

I've got a few hundred 12000x6750 jpegs at quality 90, always fun to stress a few CDNs when they try to handle it

couldn't you at least in principle do that whole thing mostly with O(1) memory usage?

(well, it would be especially hard for the pixels path)

Yes. But I'm pretty sure that my code is not doing that 🙂

😛

not sure what q60-70 corresponds to, but I'm looking at the graphs I generated, and it seems that in about half the test images, jpegli just wins everywhere, and for the remaining images webp wins by a big margin at around 0.2 bpp and lower, where you start getting to SSIMULACRA2 < 60 or so.

that second group of images are ones that all the encoders had an easier time with, while the ones were jpegli consistently wins are those that end up a good deal bigger no matter which encoder. In the second group, mozjpeg actually ends up beating jpegli below a score of 60, though even down at 30 the difference is smaller than 15%.

yea, I've found that jpegli is more effective than mozjpeg only at higher qualities

mozjpeg's model works better at lower qualities

I think also at lower resolution/scaled down but i would like someone to test that

I wonder if Windows will move over to JXL instead of JXR for HDR content...

One can always dream...

JPEG XL sadly wasn't selected for Interop 2024 https://github.com/web-platform-tests/interop/issues/430#issuecomment-1921864485

concerned about the insinuation there. it feels the modern way for corpos to put down positive initiatives they know have overwhelming support is by declining to reply, deliberately not participating in discussion and preventing discussion

Ultimately, interop is a collaboration between different browser developers, and public opinion doesn't actually matter *at all*.

Browser devs like to claim that they are listening to web devs and end users though, and interop being open to proposals from external people does imply that they care. But yes, it looks like in the end it's just a way to prioritize stuff that is already on their TODO list, not a way to put stuff on that list.

https://frontendmasters.com/blog/the-popular-vote-of-interop-2024/ it would be interesting to see which proposals were selected from this list

while protocol may keep votes secret, supporters of proposals are free to publicly announce their own support and the reasons they believe it shouldve gone through

from the top ten by popularity at the end <https://foolip.github.io/interop-reactions/>, two were selected: Popover <https://github.com/web-platform-tests/interop/issues/423> and Relative Color Syntax <https://github.com/web-platform-tests/interop/issues/426>

So the popularity doesn't really correlate with likelihood of selection, then. Maybe even negative correlation? JXL is not an outlier in that regard then...

I would bet insignificant changes proposals will lose the popular vote (due to a lack of visibility) and win nonetheless (due to ease of implementation)

There are also things like localisation improvements, that are only relevent to a small set of people, but none-the-less important.

What's the status of JPEG XL in gnome-backgrounds? I remember that it was temporarily disabled, but what happened after? Were issues resolved?

it seems like it's back on? I also remember it getting disabled but I stopped paying attention then recently I heard about JXL in gnome-backgrounds without it sounding like it's disabled

hmm I'm checking the repo and it seems to show a timeline of it getting turned back on again https://gitlab.gnome.org/GNOME/gnome-backgrounds/-/commits/main?ref_type=heads

it seems like what happened is JXL got disabled/removed for version 45 but is now apart of version 46 just fine

Looks like Debian eventually will support JPEG XL by default because it's used by gnome-backgrounds

https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1948925.html

I'd appreciate it if someone did. I lobbied hard to get support included and, thanks to help from Alex (Thorium Dev) and some of you here, it was successful. Been using Cromite ever since and it works great.

i've been wanting to make an update to jpegxl.info but have been too distracted with other things

main thing I wanna do is make it more clear what type of category each software listed is

because people aren't really gonna know what stuff like "Cromite" is unless they click on it

I was planning on doing this but just dividing things into big groups with simple lines

Kinda like the software list on the libjxl GitHub?

I keep forgetting there's a list on the libjxl repo but yes something like that but more minimal

problem is uhh I'm not a web dev and have no clue how to really use html or css

Yeah, the "more" link at the bottom of the current jpegxl.info page links to it.

Sorry, bottom of the software list. Not the whole page.

minimal as in have the dividing lines but without the text saying what each category is since it would take up too much space and be kinda messy to directly say that Firefox and Chrome are web browsers and such

That would probably be fine.

:D I remember seeing you in the GH issues. Very happy that worked out, as Cromite is now my browser of choice on my phone

Yay! I'm glad to hear that. I jumped into looking at CVEs for the first time in order to help change the dev's mind and I still don't know what CVE stands for. Lol Awesome that my effort paid off for more than just me.

Its back on for 46. I recall seeing a discussion somewhere to make jxl a required dependency of anything in gnome (yet to be decided what), likely to ensure all gnome installs include the support onward

Any chance you could provide an anonymized copy of that for use in the cornerstone demo for progressive loading? I'd like to trancode that to JXL and then test it with the progressive loader. My guess is about 1 second to first display, but then quite a bit longer to lossless.

No, because it's copyrighted

I have license to use it but not distribute it

I can send you some of my own. i've got some massive photos that I can public domain but someone's gotta host them. 1.3gb TIFs

What are people using now?

Waterfox I assume right?

or librewolf

FF Nightly seems to support some kind of JXL but I remember hearing that it's might not last long or something?

a lot of people just use chromium based browsers now, I personally do on android, on linux I use both chromium and firefox

I use Mercury, which is a firefox fork

I'll probably switch back to firefox OG when it gets JXL support

Thorium on desktop and Cromite on phone are my main browsers.

I use msedge. Even on linux computers. I use thorium to view jxl websites

I stopped using Firefox when they refused jxl support

firefox with jxl add on 😄 can't use chromium based browsers as they struggle with multiple gmail account login...

the addon is wayy too buggy and unreliable for me

I also remember a friend installing the addon and then wondering why they where getting problems

That doesn't make sense, considering jxl is not suppoted on msedge

I just go to the physical machine hosting the page I want to visit.

I used them because I don't want chrome monopoly. Now they are following chrome team decisions I don't find a reason to use it anymore.

https://chipp.in/security-privacy/this-chrome-ai-tool-submits-all-urls-and-titles-of-open-tabs-to-google/

chrome does it too fwiw

except edge is literally chrome

I know it is chromium based but they are not owned by Google. So I feel good.

firefox is also not owned by google

I think the key part is that firefox showed that the one real major merit firefox had for many people is no longer the case. at least that's how it is for me

I'm not sure I understand how that makes sense

it just seems like "I'm not using firefox cause it's too much like chrome" and then switching to chrome doesn't seem to fix the issue

the only real merit of firefox for a large part of users is that firefox "prevents the chrome monopoly and pushes technology the users want" which has been proven over multiple cases that this is no longer the case. Firefox has no other major merits, it's not faster, it doesn't have any major features that chrome doesn't have (chrome on the otherhand has things like HEVC support, something becomming increasingly popular with VOD services and streaming services) etc.

> the only real merit of firefox for a **large part of users** is that firefox "prevents the chrome monopoly and pushes technology the users want" doubt

Besides, what's better about Chrome?

The only thing I can think of is that neat tab group feature.

Other than that Firefox just seems better.

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox

I don't think it's fair to say "firefox has no other merits"

firefox by and large is more spec-compliant than chrome in either case

Firefox doesn't do HDR at all.

Chrom{e,ium} is much more efficient then firefox browsers are, especially on low end hardware, It's better under ram pressure scenarios, it's gpu renderer is far more efficient, to the degree that it can actually be the difference between being able to barely play 1080p content and being able to comfortably play 4k30 content. Chromium has more features out of box that people actually use, HEVC is a major feature now as streaming services like twitch are begining to allow it, and it allows VOD services to serve HEVC DRM'd content via browser. HDR support, and more

Well I don't have an HEVC patent license and my computer doesn't support DRM

the key word is major.

and me too, however we are a vastly insignificant population all things considered.

I used Chrome for a while, but it was slower and more resource intensive than Firefox.

I like the concept of having an alternative to the Chrome/Safari duopoly, but Firefox seems to neglect its actual browser development and focus more on paying its CEO and other managerial staff very well.

Just recently I saw a post from a Firefox developer about how Firefox dev budget has been going up over the last year and his team is getting more resources.

And Firefox development is still by far their largest budget item.

resource intensive yes, slower on average no, chrome makes efficient use of the resources given to it, there is a reason why chromium forks are often still used on degoogled devices.

I saw this too, I am *hesitantly* hopeful about it

not that hopeful though, the new post about the new CEO doubling down on firefox has me hesitantly hopeful too

I'm on an OS that doesn't do HDR at all 😎

And last I checked, HDR on Windows is really bad. So I guess that leaves Firefox's lack of HDR as a problem really only on macOS?

thing is Firefox doesn't tonemap HDR content either......

Wake me up when Chrome learns switching tabs in the recent order, not left to right. Idk, so easy to implement feature, but no way for years

well the point isn't really about individual preferences, Im literally using firefox too on my desktop, but on my tablet (arch) and phone (s9+) I need to use chrome since firefox simply isnt good enough for me

Firefox got HEVC support on Windows a few months ago https://bugzilla.mozilla.org/show_bug.cgi?id=1853448

> phone (s9+) I need to use chrome since firefox simply isnt good enough for me But afaik mobile firefox allows adblocker, while chrome - doesn not?

hm, looks tonemapped on my computer (though not tonemapped in Discord, hilariously enough)

has this actually shipped? last I checked was about a half month ago and it didn't work on stable

oh, I guess I might not have the defaults

no clue if HEVC actually works currently in Firefox but they have been working on it at least

not sure, I use cromite now

wonder when they're gonna change that

<https://www.mozilla.org/en-US/firefox/100.0/releasenotes/>

For me - not

a shame, hopefully they get on that since it's going to be pretty big for twitch since some users still have issues with av1 decode.

Maybe it can be turned on somehow, don't know