JPEG XL

laptops are usable for tens years

I can come around and say that I want to limit myself to 50MP, then you wont be able to use your 100MP

what's your solution

No, I'll just resize them to 50 mp if necessary.

and if I say 1MP?

i think limits aren't great. tho may limit to the display resolution, and display some scale

no you will not say

yes I will say

😄

I don't see any problems why can't I work with everything that has come out in the last 10 years. it's just that the new people in the development teams are very stupid, very, they have sin gluttony, they have a lot of money and expensive equipment. they don't think about the rest.

djxl on a 24MP image uses 340mb memory...

👍

well tell me how to open a JXL image on android

money is relative thing

I don't have an issue opening 24MP in tachiyomi

🤬 phone hanged when writing MacBook: replaces windows and linux and does the job allowing everything Windows: universal Linux: ♾️ possibilities meanwhile: Android: laggy and poorly maintained after phone release noone cares iPhone: cant change ringtone or share files, CRINGE

you get what you pay for

i'm happy with my 2019 s10e, still feels very fast

well, because the cell phone market is driven by parameters which do not please the geek : trend and pure benchmark... that's how we have 24 MP sensors of 1/10 inch

which make crappy huge pics

yes

i have an idea

camera with gsm module

that was tried and have all failed spectacularly

why did it fail?

because people want a working phone

No, tiktok didnt exist then

thats the reason

<:trolw:1015162529225392128>

needs more postmarketOS tbh

usually open source devs are completely incompetent in UX design

there are exceptions like kde

gimp does the same that Photoshop and abit more but UX blender is excellent 3d software but we have a reactor control panel interface

i kinda been wanting to get xperia 10 iii & try sailfish x

i think that one could b decent ui wise too

<@693503208726986763> Thorium jxl patch was relicenced to BSD. So you can edit your Vivaldi post, so they dont have to fear GPL 🙂 Interesting enough, Thorium itself was changed to BSD licence

thanks !

there is also an app patched or modded (or whatever) by <@886264098298413078>, acting like a galery (you can see more than one image at a time and browse). I repost here since I did not find the original Discord message Link to Pix 2.1.2 apk (**expires in 3 days**): https://litter.catbox.moe/a7twr1.apk

The app used 32bit libraries, there is a limit for JXL images to 8192 * 8192 pixels and max 65535 in one dimension.

I put there a limit because libjxl called abort() after memory allocation failure.

64bit build is possible but there I have 16384 * 16384 pixels limit. Still too far from 100k*100k

libjxl abort()ing is a real pain for clients

Avoiding aborts and doing full color management out of the box in the decoder are the two main things I think still need to be done before 1.0

Well, I opened my image... waiting.... 30 seconds passed and it crashed.

🥹

Okay. I obviously got the name mixed up with something. this app just doesn't work as an android app. I can't, for whatever reason, send a photo to it from another app, using the standard android forwarding method

and each time it opens, it scans the entire phone for photos. each time you open it, it takes about 20 seconds

Well

It decoded the image. and then I touched the screen....

wft

okay. we still haven't found any program that can show JPEG XL

All I see is the software in which put the library and didn't even check anything for workness

this look like a modular file incompletely decoded

this look like a shit

Yesterday I checked all browsers with Jpeg XL support - all of them without exception work great. That is: pale moon, Thorium, Basilisk, Waterfox, firefox nightly

None of these browsers except firefox nightly on android

Can you send me this JXL file?

<:Thonk:805904896879493180> with hentai

Wait, I'll build a SFW file for you

Okay... I think I can take a size a third smaller

I wonder if one jxl per page packed in a cbz shouldn't be the best solution. Why did you concatenated the pages? What kind of advantage did you expected? Versus split files or vs using one frame per page?

I want 1 file. instead of a million

Then why not use cbz?

Aren't the reasons obvious?

No. I see no "obvious" reasons not to use zip without compression.

Samsung galaxy j4 2018 android 8.0 arm v8l (arm v7)

Website.

Is it not more sensible to put them in a grid?

Huge images are challenging for software not designed for it, which is most of the software out there...

Older phones has lower display resolution. Our screenshots are .jpg and I think it makes the screenshot to look even worse.

The size I'm working with now is absolutely no problem, it's not a problem for any program. And if the program doesn't work, it's its problem, because I'm not doing anything that is forbidden somewhere

I don't understand what this has to do

I think that it’s not that “it’s your fault” or that “you’re doing something wrong”. It’s just that not all software is made for displaying really large images. It is “their fault” that they don’t support it, but it’s not like they claim to.

With http3 the use of separate file shouldn't be an issue for websites

And cbz would allow the user to pick one file... Except if you want to display scrolling graphical novels

Why do you say that? Can't you see how bad my image is?

<@226977230121598977>: I think putting the images in a grid (rather than in a column) might help. Conversely, separating them might be useful too. I.e. having at most e.g. fifteen pages in a single image.

And for a website, the loading of the full Manga at once could be nightmarish

HAHAHA. what does that mean? In that case developers should write that "we don't support images with 60000x and higher". So that everyone laughs at them together.

I will say: What you’re expecting to work is not unreasonable at all. But most software is simply not made for it. It is unfortunate, but the work necessary for certain use‐cases to be covered might require a lot of work, and not every developer is willing to put that work in, when most users simply won’t need it.

I'm not interested. That's exactly what I want to destroy, because I already keep images that way. and I don't like it it's about half a million images + 20 thousand pages of html for each manga. i'm tired. it doesn't suit me

I don’t think anyone would laugh at that kind of claim. Images with dimensions higher than 10000 pixels are quite rare, and it’s completely understandable for someone to not care to support that. The program might simply not be designed for it, in which case you can’t expect for it to handle them.

But if they are in a cbz any decent manga reader should display them the way you want. Even as a vertical strip)

Look, if the program doesn't work, I say it sucks, and I say why it sucks, and I don't use it anymore. because whoever makes it is a bad developer. It's as simple as that.

You can’t claim someone is a “bad developer” because you found a single bug in their program.

E.g. if you're supporting zooming in and out, like most viewers do, you need to be able to either keep multiple zoomlevels in memory, or do the scaling on the fly as you're displaying the image

Doing downscale on the fly is feasible if the factor is not too big, but not if it is big

I guess dzgas will implement soon a better solution

Specially when the bug you found is obscure and doesn’t affect over 99% of people.

Some software might use gpu textures so they can let the gpu do the rescaling

One issue with plain jxls is a lack of a file-wide TOC, which makes it difficult to request specific ranges to target a frame without knowing frame boundaries already, which requires many requests and parses

But then those will have limits too

Several jxls inside cbz makes range requests easier

Yeah that's what we added the frame index for, but there is of course no guarantee that it is available

I think GIMP handles really large images fairly well. Anecdotally (from trying things out and observing it), it will save parts of the image to disc, and will then render the large images in chunks to the screen when you try zooming in and out.

But in a manga, all pages may not be of the same size...

Bug? Typical bug? He didn't even test his program. He makes it and hasn't tried its maximal possibilities, of course he's a Disgusting developer.

Typically old enough software like gimp or imagemagick will have ways to deal with huge images simply because they were written at a time when images not fitting in memory was quite common

IMO if another edition wants to standardize using jxl as a multipage image format, jxli boxes should be required with a rule that jxlp cannoy cross frame boundaries

edition of 18181-2

Otherwise the risk of weird files is too great to implementors of software

Yeah that would make sense. Or even require one jxlp per frame

Everything I've seen works like this 1. wait for the movement to stop 2. Scale only the area to be imaged

I'm going to support whoever's better.

I understand where you’re coming from. It’s always frustrating when our use case isn’t covered by a program we want to use. But that doesn’t mean the person is a bad developer. In this case, I feel like you need to realize that your use case is fairly niche, and that most people won’t need it.

In terms of compression do we gain something significant to compress everything in a single image?

Not really

In jxl, frames are coded mostly independently but e.g. theoretically patches could be shared across frames/pages

each 2048x2048 tile (LF Group) is gonna benefit from being in the same frame but coding tools don't cross frame boundaries and rarely cross LF Group boundaries

Yes, it is very bad. But your display is probably 720x1280 and mine 1080x2400. Zoom is probably below 100%. Then Qt::SmoothTransformation (bilinear filtering) + saving screenshot as JPG... Maybe different scaling would help in this specific case.

Could be interesting if we find a way to put the letters in patches 😊

Can you please make the Nearest-neighbor interpolation when scaling more than 200%

manga letters are often different enough that patches don't work for scans

only for web og content like kcomics

Indeed but I was thinking that, for translations, if the editor is properly aware of the fact that it will be used in jpegxl, it could carefully apply the same rastering rules, kerning etc. to letters so that they are exactly the same

Would be harder for kanjis, but English only have 26 letters

👍

Patches should already work quite well to detect identical letters atm. As long as they're on a solid background.

I'll have a try then! Thanks

It would be good to tell the original developer about it. https://mauikit.org/apps/index/

🥱

I didn't like the software that much (especially in my case, it doesn't work as it should at all) what would I ask for this further than here for you

Not original editors but amateurs who scan and translate may

The highest the resolution, the easiest it is to align the fonts with a good result for the readability of the text

Regardless of resolution, it is probably a good idea at the authoring stage to pick font sizes so they align well with the pixel grid, if rasterization is the target.

Do you confirm that in a single file, all frame have the same size?

Is there any adoption other than jxlatte it’s a bit slow for me

you mean, like the official libjxl/djxl ?

No, frames can have arbitrary dimensions. The canonical way to display a sequence or layered image though is to crop frames to the image canvas.

But even with current libjxl, you can extract frames as they are (by disabling coalescing)

A frame can be larger than the image or smaller, just like in Photoshop or Gimp

version 2.1 of Affinity Photo has added JPEG XL as a option in it's batch export function (Affinity Photo already supported JPEG XL i'm pretty sure it just didn't have it as a option during batch exports) https://forum.affinity.serif.com/index.php?/topic/183963-webp-and-jpeg-xl-now-available-in-batch-export/

Feedback is important. Developers need to know that there are users using it. There might be no quick reaction but without any feedback, things will not change at all.

https://distrowatch.com/?newsid=11800 Open Mandriva is out, with jpegxl support: "In addition to the previously released images, ROME 23.03 adds server centric images without GUI (also released as qcow2 images for virtualization), images featuring the LXQt desktop, [snip] kernel 6.2.6 (built with Clang); LLVM/Clang 15.0.7, systemd 253.1; Chromium browser 111.0.5563.64, **with JPEG XL support patched back in**; LibreOffice suite 7.5.2.1, Krita 5.1.5, DigiKam 7.10."

https://community.signalusers.org/t/jpeg-xl-support/50331/4

not on java

its kinda tough situation on java

its use Java19+ and bundle your own natives which doesnt seem to work atm or use JXLatte and hack in ImageIO support and a working build script

Not sure how to add in ImageIO support, otherwise I'd add it

also wdym by a "working build script"?

you just build it and add the jarfile to your classpath

Like I said in my issue

Maven publishing

My fork has image io support it’s a bit hacky I’m sure if you put time into it that it could be faster

Copying data from your buffer thing is slow

Anyways yea your method takes 800ms average

Which is an issue

I can provide a profile if you wish idk if you use a Java ide for your project

These are my results including the 150-200ms for imageIO copying

The reason copying is so slow is probably because the jvm can’t optimise it due to the weird array layout

float[colour][y][x] is a bit odd

I did some changes on my ImageReader side and got it to 550ms-750ms average

I hope this code is thread safe (Gonna try run multiple decoders at once to make up for lost time)

what's wrong with that? it's planar

just use the appropriate SampleModel in your WritableRaster

You don’t have control over that with buffered images

Yes you do

BufferedImage(ColorModel, WritableRaster)

each JXLDecoder instance is self contained tho it multithreads automatically

I haven't added an option to disable that yet

Oh okay so best I don’t run multiple then

Huh good to know

https://twitter.com/jonsneyers/status/1642039947719745537?t=HV1TA90KMykEXrXyYtJj2A&s=19a

if the library will be already there, will there be reasons not to accept it also as img?

today is quite the *special* day ;)

some might even say it's a day that's arrived for some in the world before others

Don’t all days arrive for some in the world earlier? 😄

well yeah but it's more noticeable for this specific day in particular

f

he got me, NGL

https://github.com/mullvad/mullvad-browser/issues/7

seems like they're citing the same reasons as tor browser

https://gitlab.gnome.org/YaLTeR/identity/-/issues/44

I'm starting to feel like the fork authors should start pressuring Firefox devs...

I mean, there is clearly a lot of demand for native JXL support 🙂

That's a bit of a problem with most browser forks: they are often forked for one specific reason (e.g. privacy), and they are willing to do stuff to improve that specific aspect, but anything else they'll leave for upstream to handle.

It'd be nice to write an open letter to Mozilla or others and garner as much industry attention as possible. At this point pressuring Mozilla might be possible, optimistically, and I don't know what else to do

If getting signatures from larger orgs would be possible it might create enough buzz

it would be nice if Mozilla published results from their tests like they used to years and years ago back when WebP was still new

At the very least, an open letter may get them to do that

They haven't done any tests yet afaik.

oh yeah I think your right because I just looked back on the github pull request and issue pages where they announced their neutral position and they don't really say that they have done any tests and they also say that they came to their conclusion based on results and tests outside of Mozilla

I updated the chromium patch with a fresh version of libjxl just now: https://chromium-review.googlesource.com/c/chromium/src/+/4255409 Ready for the chromium derived browsers like thorium to use... There were some refactoring in how we handle includes, so this was not completely trivial. Hope it helps

Would talking to Louis Rossmann or talking to his parent company FUTO help with the adoption of jxl? They might be able to inform a larger audience of the current issues facing the adoption of jxl. https://youtu.be/vawcnCv1_1w https://futo.org/ https://futo.org/grants/legendary-grants/

https://github.com/celluloid-player/celluloid/issues/856

https://github.com/flathub/io.github.celluloid_player.Celluloid/commit/cf09308f20e1c83749077d15affd9fa4db385fac

Cool devs. Didn’t even mention Chromium <:Stonks:806137886726553651>

https://gitlab.gnome.org/GNOME/epiphany/-/issues/2040

**Thorium **decodes JPEG XL with progressive incorrectly. It makes 3 layers, and stops. That is, my 8 layer images are displayed on layer 3, no further decoding takes place.

Another browser, Palemoon, does everything perfectly.

I am not in a position to help solve this issue however I would like to see it in action so would you be able to post the JXL files you have with more then 3 layers?

that's surprising and weird. can you share an example?

well no, it definitely works here.

my bad

checking the files in the tabs I didn't notice that I had an open blob:https://google.github.io / which I have been testing at the moment, which does the decoding sequentially

But still, I found something to scold Thorium for - it does decoding only in 1 thread. While Palemoon does on all thread

librewolf should now have better jxl support in the next version https://gitlab.com/librewolf-community/browser/source/-/merge_requests/53

😲

let's see if I get a response this time...

i really hope you do

For the current Librewolf release JXL patches have been witheld: https://gitlab.com/librewolf-community/browser/source/-/commit/29964a30ff7a4f859dac34610d0a532855f2b8ae

any indication why?

Not really sure, but I suspect possible browser fingerprinting

dang

I just got a response from the AVIF team. Something very long about decode speed, and then this about the other points: > Progressive rendering > > > AVIF format itself does support progressive coding. We’re looking into whether the feature makes sense for web use cases. > > > Encode speed > > > At this point we don’t have anything to add besides the results already published in AVIF comparison. Site includes a comprehensive set of results that hopefully helps developers to pick the speed setting that works best for their use case, including single vs multi-threaded encoding. We do believe that the results showcase why AVIF performs better than JPEG XL. > > > Quality > > > Contemplating Codec Comparisons correctly states that assessing the quality of lossy images is hard. For this reason AVIF comparison includes a comprehensive set of results for many different objective metrics, thus developers can look at objective metrics they care about.

imo none of those responses provide actual answers to the things I'm raising, and are basically deflections. If AVIF does support progressive coding, as claimed, then please show me the results of how well it performs at it, i.e. what is the overhead for doing progressive vs non-progressive, how many intermediate refinement steps can you get, what's the evolution of the image quality vs % loaded, etc. Otherwise I'm inclined to think that it doesn't actually support it in a meaningful way. "We’re looking into whether the feature makes sense for web use cases" almost sounds like a joke. Before WebP, _all_ image formats used on the web had one way or another to do progressive loading: GIF has interlacing, PNG has Adam7, JPEG has progressive, which mozjpeg btw decided to make the default. I think it's pretty obvious that at least in _some_ web use cases, progressive decoding is very much a desirable feature. Encode speed: they're just ignoring my points and saying "we don't have anything to add" Quality: again just ignoring my points about subjective being the only real way to test codecs and saying "you can look at the objective metrics you care about" (while also ignoring all my points about the relevant quality range etc)

💀

<:Thonk:805904896879493180> https://www.reddit.com/r/AV1/comments/12re20c/why_browsers_will_probably_skip_jpegxl_imo/

Anyway, I don't think I'll bother with writing a reply to the AVIF team. If that's all they came up with in 4 months, then I think it's clear they don't actually want to have an honest and constructive dialog about the actual technical merits of AVIF vs JXL, and this is their way to politely tell me that they just don't care.

It may be worth it to lay into them & lean as hard as possible into their missteps here just to see if by some miracle u can get an answer out of them. But it is probably very frustrating & I understand that is not a great use of time

Tbh, at this point in time it seems to me most logical to make sure that Adobe doesn't change its mind and implements jpeg xl as export format. When that happens it will be easier to convince others about jxl.

IMO you should still write a reply. Maybe somebody else will have a look there. Well and even if you get another bs answer, you have food for media that could report about the incompetence of the AVIF team : D

Big corporations start to care about something only if it makes them look bad in media.

I would publish their response

Yeah, publish the mail file or something

I will forward it to golem.de to get coverage on a big german site focused on IT

(I forwarded some other stuff in the past that got an article after that so I know authors are open for that)

> Something very long about decode speed Does at least this bit have some merit? (as other bits you shared, I agree, do not, really)

It's basically trying to figure out where the difference in measured decode speeds between my measurements and theirs comes from, with the conclusion apparently being "it's not clear" but they still consider their measurements more correct than mine. There's no reaction to my point that it's not just decode speed that matters, but also when the decoding actually starts (jxl has a streaming decoder while avif only starts when the full transfer is done), and also no reaction to my point that basically both codecs decode "fast enough" for still images on the web so it doesn't really matter that much exactly how many MPx/s you are getting. To be honest I don't really understand why they want to focus so much on this particular point — I suppose they spent a lot of time making av1 software decode fast enough for realtime decoding and they're so proud of that that they now consider this the key point to test when comparing codecs? I dunno, just guessing

<:KekDog:805390049033191445> >`AVIF format itself does support progressive coding.`

https://aomedia-review.googlesource.com/c/libavif/+/173341

https://github.com/AOMediaCodec/libavif/commit/ac024b0afc8ff3095762edac87c2e397cb643019 `If --progressive is specified, avifenc will encode a progressive, layered image. The current implementation is hardcoded to use two layers. The --progressive option is marked as experimental because it doesn't work properly even though it produces a correctly encoded layered image. Refactor avifEncodeImagesFixedQuality(). Move the big while loop in avifEncodeImagesFixedQuality() to a new avifEncodeRestOfImageSequence() function. Then change avifEncodeImagesFixedQuality() to call either avifEncodeRestOfImageSequence() or avifEncodeRestOfLayeredImage() depending on whether we are encoding an image sequence or a progressive, layered image.`

Yeah, "supported", and it is plain inferior to freaking JPEG progressive due to how it works.

so for now it's two-step decode?

Two step decode, that doesn't work

Is it technically actually different from encoding it as a two-frame animation where the first frame is just more lossy than the second?

because if that's what it effectively does, you could just as well claim that webp supports progressive

great news everyone, webp supports progressive!

it also supports 10-bit! the two least significant bits have to be zeroes, but that's just a small technical limitation

as well as the subset of 4:4:4 that can survive a 4:2:0 roundtrip

I wonder if AVIF progressive mode utilizing P frames would be possible, and if it would yield any good results

is avif even going to have any form of incremental decoding like non-adam7 png, baseline jpeg and webp?

like I don't understand what kind of "progressive" decoding they are trying to add is

i always imagined it to be just a video where it starts low quality and gets higher quality with subsequent frames

> We do believe that the results showcase why AVIF performs better than JPEG XL. Okay, I'm convinced.

https://tenor.com/view/you-have-to-believe-me-warren-flack-believe-me-have-faith-in-me-gif-22013692

https://bugs.chromium.org/p/chromium/issues/detail?id=1416530&q=Jpeg-xl&can=2 So chrome might reconsider it afterall? I don't have hopes as the bug issue was created in February.

oh that isn't to re-add back to chrome sadly, it's just there for chromium forks that want to try to bring back JXL support.

It feels like a fairly useful thing in any case! It’d probably make it easier for such forks to integrate it, and might also encourage more Chrome variants to do so.

unfortunately it appears that the lead codec team of chrome has zero interest in jxl or being even remotely open to the idea

is it even possible to get them to reconsider? because it seems like they are absolutely dead set on making sure that chrome does not support jxl no matter what anyone else says

like how would you even go about getting people like that to change their mind?

by getting rid of them

Do you think the flash fiasco is to blame for this?

Also

yes, this is why I made this bug and the patch...

well it's two things right: 1) making it easy for forks to get/keep jxl support, 2) make sure that if chrome would change their mind at some point, it's easy to do that

https://github.com/Fyrd/caniuse/pull/6673 🤔 ...

Of course, the request coming from an AVIF proponent...

Ah, that PR was also opened on Friday. https://discord.com/channels/794206087879852103/806898911091753051/1053680322258161765

Next Chrome feature: automatically removes all sentences containing the words "JPEG XL" from all websites you're viewing, so you don't get "confused" and start to question the party line.

Not even gonna respond. Not worth it if they won’t do their research

y'all have no idea how hard it is to resist commenting on these posts 😛

More likely that they just do s/JPEG XL/WebP/ so that it doesn't look like some sentences are missing <:KekDog:805390049033191445>

For the progressive decoding - the last I heard there was just the developers on github saying it is possible, but not a priority. As far as anyone knows, the there is not even any code submitted that does that (maybe I'm wrong and there's a patch sitting in someone's basement?). The fact is, there is no way to progressive rendering in even a development build of the encoder and I don't think theres any decoder code in place either. Instead they spent months claiming that it wasn't needed, just set the quality low enough that it takes a split second to load. Eventually, after a large number of people complained (cause 90%+ of the internet's images are not low quality), they finally said it was possible but don't appear to have even tried to code it. I know more recently when pressed they told people to use WebP... except WebP doesn't have progressive either. At this point I'm waiting for them to get sued for false advertising.

When it comes to the speed, I've not seen any independent tests verifying the AVIF team's data... likely because it's probably BS. Netflix has said they have a TON of data since they use it all the time... but won't release any of it.

<:FeelsSadMan:808221433243107338>

It wasn't made by google lol

Lol what? That's so random

I don't get what everyone's problem is. Being better doesn't mean you have to drop everything and switch immediately.

exactly, just bc google's research team contributed doesn't mean it was Made by Google ™️

Otherwise it'd be called Gjpexl

Or WebXL lol

>Beta >Got ffmpeg support before AVIF

Software being slow to adopt is normal and it's the kind of inertia that can be expected. But Chrome already had all the code to make jxl work perfectly fine, and then AVIF proponents at Chrome deleted that code. That's not just the normal inertia (people being lazy to implement new stuff), that's actively blocking adoption (the avif team removing jxl code because in their opinion avif is good enough). I guess this is why this is so controversial.

Ahhh so avif is too prideful. I wonder if they feel stepped on and hurt. I mean, they worked very hard to create and optimize an open standard, from what I've heard. And then comes along this new standard with a bunch of hype and no obvious effort to create it. Prolly stings a lot.

you forgot the <sarcasm> tags 😄

Oh f- I forgot to reconsider that might come off as sarcastic lol I actually meant that

Nobody likes it when people say their baby is ugly (or that another baby is prettier). That's quite understandable. What I don't really understand is why they want to push the image format that much, when imo it's actually the video codec that is great.

It's a dog that's great at tracking, but they're trying to make it eat at a dinner table, it's gonna end up sloppy

exactly. it's a very nice race car that they insist can also be used as a farming vehicle for harvesting potatoes in muddy soil, to the point that all tractors should be destroyed

Ah

I'm trying to think of a parallel so I can see how others solved similar situations

If you know of a way to get it to do progressive rendering, by all means post it.

Resist the impulse to resist 😜 .

What app is this?

Ice Cubes, for Mastodon

I use Ice Cubes on iOS & Fedilab on Android

No no I meant that Netflix didn't release anything

Like, wat

I meant Akamai (I think Netflix uses them). There is a video of an Akamai employee praising AVIF and in the same breath says they won't release any of the data they have. Granted Netflix didn't really put out objective data either. They put out a bunch of subjective data that amounts to "It works for us!" - great! Doesn't mean other formats should be blocked from being implemented or that 80%+ of the internet are looking for only a ultra low bbp format.

Ye

Just because it works for you doesn't mean others shouldn't use something else.

Lol mfw we write size-optimized decoders to polyfill future browsers.

https://9to5linux.com/shotwell-0-32-0-image-viewer-adds-support-for-jpeg-xl-avif-and-webp-images

https://gitlab.xfce.org/apps/xfce4-screenshooter/-/commit/de32f2269a62909a2f6a481f9ec8e7f49b66f7c6

noice! can't wait to see this coming in debian

Nice to see support in Xfce environment

> software_support.md IMHO, "Image viewer/editor plugin" should be separate category. Paint.net does not support JXL by default, for example. Also, not sure why Photoshop even listed if there's no support.

once issue #1450 is solved then Paint.NET should support JXL by default soon'ish after

imlib2 added a JXL saver two weeks ago: https://git.enlightenment.org/old/legacy-imlib2/commit/a55f36133d575a46a19d45718b81378078085037 Usage: https://git.enlightenment.org/old/legacy-imlib2/issues/9#issuecomment-635

Adobe Camera Raw supports both opening and saving to JXL, so PS can open JXL, even if not "natively"

cool! I can indeed just open jxl files in Photoshop now!

any idea how I can save images as jxl? camera raw automatically opens when trying to open a jxl, but is there a way to save with it?

camera raw has its own export feature

Does anyone know how Serif's Affinity implement JXL? I can't find any references to libjxl and the files it creates can be big compared to WebP. Using cjxl yields much better results

I would assume they statically link some by now old version of libjxl (and I don't know what options they expose but they perhaps made some poor choices in their default encode settings)

I just hope they add lossless JPEG XL as compression option in TIFF. That would save a lot of space.

Or just use layered jxl...

Tiff is already such a hairy kitchen sink of a format

When was Mac big endian? Was that PowerPC, or further back to Motorola?

According to wikipedia, PowerPC is bi-endian (can do both big and little endian)

PowerPC was usually big endian when it was running macOS, iirc

Big endian was more popular in the past, that's for sure.

iirc macOS used to have "fat" binaries which were mach-o binary files that contained compiled code for x86 and for PowerPC

with their transition to "apple silicon" aka ARM, I'm not sure if they've revitalized that

as far as I'm aware the last used big-endian popular architecture is MIPS because it's much cheaper to fabricate than ARM processors so a lot of embedded systems use MIPS instead of ARM

https://en.wikipedia.org/wiki/Universal_binary > The new Universal 2 binary format was introduced at the 2020 Worldwide Developers Conference.[5] Universal 2 allows applications to run on both Intel x86-64-based and ARM64-based Macintosh computers, to enable the transition to Apple silicon.

"Universal" is a funny name if it means "runs on 2 different combinations of OS and cpu-arch, out of the hundreds that exist"

Almost as much hubris as I had when naming FUIF 😅

ah

the rollout here has been funny

i recall seeing some apps which provided one intel binary, and one universal binary

combining the bloat of 2 architectures in one binary with the inconvenience of having two binaries <:galaxybrain:821831336372338729>

i guess that might be necessary if old versions of x86_64 macOS can't run universal binaries? but i really hope apple would have made it in a compatible way

trying out the jxl export in adobe camera raw, looks like it needs some work

in particular, it's not using XYB for lossy compression, which is very likely a mistake

for lossless it seems to produce results pretty similar to what libjxl e3 does, so I'm assuming that's exactly what they do (which makes sense)

for lossy it looks like they disabled xyb, which makes it produce quite poor results since libjxl is not at all tuned for working well on lossy rgb

<@604964375924834314> do you know already about this? can you help Adobe fix it?

<@795684063032901642> <@179701849576833024> this is not the first time that I see people accidentally using lossy jxl without xyb — it looks like this is a major pitfall in the encode api that applications are consistently getting wrong. Can we somehow make it less likely that this happens? Maybe it's just the api documentation that is not clear enough.

https://github.com/libjxl/libjxl/blob/e6559ab06bfca0521bb63f68e48fa3c297bddc51/lib/include/jxl/codestream_header.h#L176

I think people are still setting that variable to `true` just because things are too complicated and it kind of feels like if you if you set it to false, you will lose the color profile and everything will be wrong

The description needs a big fat TL;DR saying "SET THIS TO `true` FOR LOSSLESS AND TO `false` FOR LOSSY"

> JPEG XL image, 2560x1256, (possibly) lossless, 8-bit RGB+Alpha > Color space: 596-byte ICC profile, CMM type: "lcms", color space: "RGB ", rendering intent: 0 This is a JXL exported with Affinity Photo 2 at 85% quality. I guess this is wrong too like Adobe Camera Raw?

Serif's Affinity was quite early in adopting JXL so I think it'd be great to reach out and help them get JXL done properly

oh wow so adobe got it wrong too..

<@794205442175402004> how about their hdr jxl exports?

looks like if you enable the "enable HDR display" save option, it does use XYB and compression seems fine — but something seems weird with the color management when I look at the image in Thorium

(the jxl looks darker/duller than it should)

when I open it in Camera Raw it is OK though

``` JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 667x1000, lossy, 16-bit RGB intensity_target: 289.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Perceptual Uncompressed Exif metadata: 164 bytes Brotli-compressed XML metadata: 1881 compressed bytes ```

it might be related to the intensity target they're setting to 289 for some reason

(i'm just taking an SDR image here btw)

does Thorium use the intensity target for anything at all?

Chrome didn’t, AFAIK

Oh, maybe then that's the problem, maybe it should...

can you provide a sample? I'm curious how libplacebo handles it

these are the files it produces when saving avif, jxl, png in rec2020 PQ

this is how Thorium renders them (avif, jxl, png)

the jxl and png look the same, the avif looks brighter

when viewed in Camera Raw, they all look the same

actually there is a difference in Camera Raw too when I look at the histograms

the original image (just an SDR sRGB image)

the AVIF it produced

the JXL it produced

somehow the AVIF goes a bit into the HDR range

what could be going on with the AVIF

is it 10 bit?

yes

``` Image decoded: pexels-cihan-oğuzmetin-4505269camerarawhigh.avif Image details: * Resolution : 667x1000 * Bit Depth : 10 * Format : YUV420 * Chroma Sam. Pos: 0 * Alpha : Absent * Range : Full * Color Primaries: 9 * Transfer Char. : 16 * Matrix Coeffs. : 9 * ICC Profile : Absent * XMP Metadata : Present (10144 bytes) * Exif Metadata : Present (152 bytes) * Transformations: None * Progressive : Unavailable ```

yuck, my avifdec produces a PNG that doesn't seem correctly tagged at all (maybe I'm using a version that is too old)

like discord, it just makes things sRGB without conversion, it seems

anyway, it does look to me like 1) the JXL file itself is fine 2) Chromium/Thorium for some reason renders it a bit too dark/dull (the PNG too) 3) the AVIF file Camera Raw produces is actually not fine: colors are brighter than they should be (though I cannot see that on my Macbook 2019 screen, which is SDR) 4) Chromium/Thorium renders the incorrect AVIF incorrectly and those two wrongs make a right somehow

<@604964375924834314> do you have any insights on this? it's all so confusing...

https://cdn.discordapp.com/attachments/766815322236911619/1109632456153374741/FvayhJNaYAEMsFJ.png

There is also WebKit / Safari. But yeah, true...

Gecko (even less servo) didn't made it into a full fledged integrable component as did blink... Which is a shame

Reminds me of this blog post I read a few years ago: <https://thehistoryoftheweb.com/how-a-browser-engine-dominates-the-market/> (I feel like it was a joy to read!)

Nice read... We could wish blink was governed by an open comity, but it is clearly designed to answer the needs of Google... And the manifest v3 goes in this direction

JXL support (kinda) in Revolt

https://github.com/Floorp-Projects/Floorp/pull/268

Will be coming to Floorp version 11 (based on ESR 115) if this gets merged

Nice! I was thinking of trying make a pull request for floorp myself but this is way better put together then what I would have most likely ended up doing

hopefully they don't decline it for "privacy" related reasons as I remember looking through some random parts of the github in the past and it seems like they are worried about fingerprinting but i'm not sure/don't remember to what level their worry is

something interesting about floorp I noticed is they have avif support forced on

<@707907827712131102> maybe you should add JXL to the list in this pref here (it's in 000-floorp.js)

^ looks like the list of allowed file types to be used for new tab backgrounds?

ah so then it likely is

oh, good thinking, thanks, I will do that

I still find it strange how they have avif locked on but not webp

maybe they use avif somewhere for some asset(s) or something?

You might be thinking of another Firefox rebuild. Floorp is privacy-aware but not very concerned about it like LibreWolf. Kinda like Pale Moon

When I pitched them the idea of JPEG XL support they're actually more concerned about whether I'd be reusing Waterfox code, which is a big no for them for some reason

They said that Waterfox doesn't write license notices (about:license), so they think it's difficult to tell which open source software Waterfox is using.

I was looking over this a bit more and it seems to create a duplicate entry in "nsExternalHelperAppService.cpp"

Huh, I could've sworn I checked first if there's a jxl entry already... Thanks, fixed.

wwdc 2023 safari features

?

apparently they're adding jxl to safari in the next macos version

Wait what?

in the event going on now they showed a screen full of minor safari features they didn't feel like talking about

Wow cool if that's actually going to happen

is this stuff that they actually fully intend on adding or just stuff that they are interested in?

adding, afaik

Would be weird to show something they're not intending to add

So this is very good news

Would be nice to have a somewhat firmer announcement but I will take it 🙂

This will make it a lot harder for Chrome to keep blocking jxl

does this mean chrome on ios will get jxl support? <:KekDog:805390049033191445>

Haha yes, when they add it to safari it will also be added to iOS chrome 🙂

hopefully it doesn't end up like a JPEG2000 situation where only Apple supports it, although it's been decades and times are a lot different then they where many many years ago

<@164917458182864897> I don't really keep up with Apple or their schedule but around when should we be seeing more about this?

the next macos version will probably come out sometime in the fall, and there will be a few betas before that

i think usually they have a beta within a couple weeks of the announcement?

but i'm not sure if they would have jpeg xl ready in time for that

oh there are also safari technical previews which might include this independently of a new macos version

are macos and safari are intertwined?

Yep

Safari uses CoreMedia for decoding

ah so a OS update means a browser update then

Same library that is used in the OS tools like Preview and Finder

I think this is the kind of news that is worthy of an @everyone ping. Sorry if you didn't want to get that notification. But it looks like Apple just announced that MacOS/Safari will be supporting JPEG XL. And that means that the likelihood that Chrome (and Firefox) will follow just increased by an order of magnitude. So it's a very big milestone for jxl adoption and the utility it will be able to bring to the web in particular.

YESSSSSS

YAHHOOO

chrome devs btfo

WHAT?!?!?!?

WHEN

that's huge

LINK

SCREENSHOT???

I wonder if they're integrating libjxl, or if they're brewing an in-house decoder

I'd like to see an in-house decoder personally

because more decoders = good

nice

Scroll up 🙂 thanks to <@164917458182864897> for spotting it first!

what arstechnica article or video is this a screenshot from?

.

WHAT'

NEW HEIC

for them

HOLY FUCK

RIP HEIC YOU WILL NEVER WILL BE MISSED

https://live.arstechnica.com/apples-wwdc-2023-keynote/

it's from apple's keynote, i'll get a timestamp link once the recording is available

i didn't get a screenshot of the whole frame myself, just the part that said jpeg xl

woah

<https://live.arstechnica.com/apples-wwdc-2023-keynote/#post-1944940>

thats a gift for me

amazing

Who would have thought that out of those three, not Chrome, not Firefox, but Safari would be the first to add jxl support...

didnt chrome have an experiment for jxl at some point

safari is the best browser lol

Is there a slight possibility for safari having jxl?(ok I didn't get the ping)

... I'll believe it when I see it

Should make an annoucement on Reddit too <:BlobYay:806132268186861619>

We'll have to see when Safari will actually have jxl support working, but I don't think they have a habit of announcing stuff they don't actually already have more or less ready to go

thats what I call unlikely ally

Could still be that Chrome beats them to it though 🙂 they can if they want to, <@795684063032901642> kept the patches warm 🙂

technically, they _could_ block it, though

they've announced it for the next version of macos

planned feature, not slight possibility

When I typed that text, I didn't see wb's pinged message.

Do you have a yt timestamp for when they announce it?

I actually paused the livestream and got really excited when I saw that "JPEG-XL" text on the very left side. 😆

Not sure if they actually can. What would be the mechanism? Remember, on iOS, all browsers are just safari with a skin...

Really good news!

https://youtu.be/GYkq9Rgoj8E?t=3224

We win!

<:JXL:805850130203934781> <:Stonks:806137886726553651>

<@416586441058025472>

Woot, I missed it in the cloud of text

Someone has to post the news on 4chan and hackernews 😄

And Phoronix 🥲

and bugs.chromium.org

Wow. honestly I never imagined apple is having such a following. 1 M concurrent viewers on yt is insane

I was in the process of making a pull request for the jpegxl.info site which would mention jxlatte and jxl-oxide, I should probably get around to finishing it since a lot more people are about to hear about JPEG XL

https://news.ycombinator.com/item?id=36202088 already on hn

lol hn won't even load for me rn

seems to be slow... the jxl fans must be overloading the site

true, but jxl has lots of features and it would be a little bit inconvenient if the decoder only supported a subset...

This was the least expected outcome

Google is way more evil than people expected and Firefox is way more feckless :)

Firefox is lacking fire nowadays

Fantastic. For Windows what is the first step to support? For the jxl org to produce a WIC, of for Microsoft to decide to support? Microsoft tried to introduce Jpeg XL but the attempt is long dead.

hmmmm maybe start using safari on windows <:megapog:816773962884972565>

Firefox is less feckless and more basically running on fumes

They can't even keep up with Chrome on features much less innovate anymore.

That was Jpeg-XR (Photo HD) -- we supported that for a while but dropped it. Not Jpeg-XL ;)

who's we?

last i checked windows game bar hdr screenshots are jpeg xr

Sorry yes I meant xr

POG AS FUCK

"we" = Goanna/Pale Moon

I tried commented here https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433/ but even my week old comment is still stuck in "unmoderated items" so i guess moderators stopped aproving new comments?

the unpleasant fact is that jpeg XR is worse than webp

but it can yuv444, so I've been using it for 8 years to archive photos in q95 quality.

fun fact the game "Rage" uses JPEG XR for it's textures

JXR was never completed beyond primary stages because of the refusal to adopt by all big players despite being standardized

https://tenor.com/view/yes-yas-wwe-scream-gif-17625417

JXL combined the good things of PNG, JXR and WebP, so why I've been pushing pretty hard for it ;)

imagine if they only supported 4:2:0 JXL

people actually browse /g/...?