JPEG XL

yes, with some app markers in both of them, in the original UltraHDR it's xml-based (XMP) stuff, in the new ISO version of it it's a more compact binary syntax

Or at least enforce a layer limit of 2

so the jhgm or whatever it's called box contains another JPEG XL file, but that sub-JPEG XL file can't contain a jhgm itself

why would the gainmap need a gainmap?

it can only be infinite if the bitstream is infinite 🙂

is the ISO version just UltraHDR but ISO?

you can't pull a TIFF and self-reference itself in its own field im guessing

You want to know how much heap space you need ahead of time

the ISO version is an attempt by Apple/Adobe/Google/etc to unify their various flavors of gain maps into a single spec rather than them each doing their own thing that is very similar but with different syntax

Memory allocations are a big deal

I think defining this in the spec should fix the problem of infinite nesting gainmaps

It should be feasible for decoders to know ahead of time how much memory they will need and control/limit it during the decoding process for security and embedded hardware reasons

Dynamic memory allocation is not always possible in every environment

we may want to do something slightly more generic that can also deal with motion JPEG and multi-picture format (MPF) files, which can have an arbitrary amount of JPEGs concatenated. If we want to handle that though, we'll probably need to find a way to embed multiple recompressed jpegs and their jbrds, probably best not by arbitrarily deep nesting but in some flattened way.

maybe nested boxes

one layer deep

an array of files

and just forbid nesting within nesting

like each nested file cannot itself contain nested files

Motion JXL wheeeeeeeeeeeeee

this is what I'm currently having in mind, but it's still to be discussed and will probably not be for the third edition of 18181-2 (which we plan to have quickly, just to add the gain map box) but rather for a fourth edition.

what does the `k` stand for? is that just what enum items prefix with

this mechanism would then allow you to basically have a "reconstruction" for multi-frame jpegs but also just arbitrary stuff that doesn't need to involve a reconstructed jpeg, like putting a brotli-compressed svg in there that can be "reconstructed"

yeah all enum values are prefixed with `k` for some reason, that's something we do consistently in all of 18181-1 and 18181-2

great, we can losslessly pack jpeg comic pages into single multipage jxl and add gbrd for all pages

Can I just store random data in gbrd?

well this is just a proposal, still needs discussion before it becomes spec, and still needs implementation before it can be used 🙂

Also maybe file extension shouldn’t be limited to 4 bytes

my proposal would be to allow that, yes, so you can e.g. rasterize a vector image but still embed the source file in there too

\*stores a zipbomb in your jxl\*

or you could take an iPhone DNG file, recompress the JPEG preview as the main jxl image and put the rest of the dng file in a gbrd box (minus the jpeg preview, which would be done via a kJPEG instruction)

How would you splice the jpeg preview back in?

yeah obviously there are security implications/risks, but there's nothing preventing you from adding a random box with random contents to a jxl file anyway

I’m just worried that if too many features are added, it will become too powerful

you'd just have some brotli-compressed dng header bytes, followed by an instruction to reconstruct the main image jpeg, followed by uncompressed bytes for the rest of the dng file

Like with what’s happened with USB C

USB C can do everything but it’s a nightmare knowing what a specific device/port/cable can do

JXL already supports multi-layered animated multi-page images

The gbrd box can be completely ignored by a jxl decoder, just like the jbrd box. It does not have any impact on how the image or animation is rendered. It just adds another mechanism to construct some other file from the jxl file.

jxl is just like BMP

Just add an entire bytecode interpreter instruction to the gbrd so it can generate digits of Pi to add to the end of the file as EXIF metadata

I'd prefer to keep the "instruction set" of gbrd small and certainly not Turing complete.

100%, I was joking

Overall I do think this is a good idea, although things like security need to be thought out, like we don’t want JXL to be able to write out an EXE file

Would djxl “run” the reconstruction automatically or would it be opt in

But yeah there are security risks with arbitrary 'metadata', now already: nothing prevents you from putting malware in the "Exif" data blob and then software extracting the Exif will write a file containing malware. I guess no harm should happen as long as no applications make the output an executable file and run it.

I think for this kind of thing it could make sense to do it based on the extension: if you request a .png then it just decodes the image, if you request a .svg then it looks if there happens to be a gbrd box that can make that. That way basically a jbrd box becomes just a special case of a ".jpg" gbrd box.

Still think lossless png reconstruction would be nice, using something like preflate

but API-wise it would of course be opt-in, there would be a new function to do generic bitstream reconstruction and applications that don't know about it will just decode to pixels

that would require a more complicated reconstruction procedure, not sure if it's worth the hassle. For bit-exact archiving, sure it could be useful. But unlike jpeg recompression, the alternative of just encoding the pixels losslessly (and preserving all the metadata) would be effective too and semantically equivalent.

I guess it could be left as a vendor specific thing

https://google.github.io/styleguide/cppguide.html#Constant_Names https://google.github.io/styleguide/cppguide.html#Enumerator_Names

I still wonder why "k" though

Apple’s Carbon API also used that style https://developer.apple.com/documentation/coreservices/carbon_core/carbon_core_enumerations/1556432-anonymous

konstant

Not everything needs to be bit reversible. There are different levels of lossless :)

And simplicity shouldn't be sacrificed if it's nontrivial

I think it would be nice if there was a lossy jpeg mode that guarantees smaller files

I always thought the (most common) standard was to use capital letters for separation for classes and underscore for variable names

konstant sounds like constant but from KDE

[av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

I think it's a nextstep thing

I was going to say, if they're just using standard JPEG upsampling, then being a transcoded JXL could help quality a little bit :P

capital case for classes and camel case for variables

snake case is too new

capital case? you mean PascalCase?

or do you mean SCREAMING_SNAKE_CASE?

this is what i mostly do now

It's more important to guarantee smaller files than to guarantee perfect reversibility back to an objectively worse format.

In general, yes, especially for lossless formats

For JPEG specifically the specialised jpeg to jxl mode is nice but for any other format it’s not important

Just cause ther are so many JPEGs out there

Hi! Hyprpaper (the wallpaper app for the Hyprland) now supports JPEG XL: https://github.com/hyprwm/hyprpaper/pull/212

any jxl viewer on Android exist? <:Android:806136610642853898>

https://github.com/FossifyOrg/Gallery

It does not support animation. it does the decoding and displays the last frame. but it does not paly the animation frame by frame

Yeah, I think there are no viewers on android right now that fully support jxl animation.

Wait a second, let me test Tachiyomi (now known as Mihon)

nope, no animation support

in fossify its a limit inherited from the library it uses. having base support is already great, animation at this time is optional good to have

try a nightly of oupson, it was a rebuild of an old fossify that unexpectedly had better support of some bits. i expect any useful findings there to be shared with upstream

https://github.com/oupson/jxlviewer

(autopromotion <:kekw:808717074305122316> )

I do have a few images that dont work in fossify that do in jxlviewer

eventually I want to look into making a rust viewer maybe using slint so that would be compatible, but unless the doc finds some meds that can take rsi pain away, that aint happening

I thought there were keyboards for people suffering from RSI no?

they help prevent issues from getting worse, but they don't make it any better

I see

Seems like someone took notes out of SpecialK's book thinking lossless is bad <https://github.com/Lyall/FFXVIFix/blob/d7fd303c66b7ae0d79fb217a73b25875c1e33265/FFXVIFix.ini#L76>

well I mean these settings where literally taken from or suggested by the SpecialK dev

I forget which exactly

That certainly makes sense

I tested mpvKt, it does not support JPEG XL. Weird, desktop mpv supports it, looks like some libraries weren't compiled or something.

I don't think I made the PR to MPV android enabling jxl, I don't think anyone else did either

I thought it was a port of desktop version, not a complete re-implementation?

you have to setup build scripts and what not

I heard people who switched to Dvorak after developing an RSI tend to claim it helped.

The keyboard layout

It has significantly less finger movement when typing which takes some getting used to compared to how much your fingers usually have to travel back and forth when typing

It almost feels like your fingers are nearly still by comparison

(I switched from qwerty to dvorak)

I don't have an RSI but I heard a lot of Dvorak users claim it helped

For me personally it felt very weird for my fingers to hardly move when typing and took some getting used to since my fingers were used to traveling around a lot instead of being nearly motionless

I use a dvorak-inspired French layout called [bépo](https://bepo.fr/wiki/index.php?title=Accueil&oldid=28893)

I also heard there's a great german layout called Neo2 or something

adnw (and its variants) are significantly better because they're actually optimized

source: i've used both for years each and i can type fast (<https://monkeytype.com/profile/dogelition>)

With split ergo or "column stagger" your fingers travel even less to the side. I couldn't quite get used to it after a lifetime of qwerty

Optimizing a layout is a tricky and unintuitive thing since typing involves a lot of different finger movements that aren't really comprehensively and formally studied and documented. Simply optimizing with a monte carlo system like carpalx and looking at a few objective metrics doesn't tell the full story of how it actually feels in practice... and it's also dependent on what you typically type. But basically, qwerty/qwertz/azerty or Sholes layout is very easy to surpass and anything else is a huge improvement

At least not yet

Is that another German layout?

equally (iirc) optimized for german and english

What's your experience and opinion comparing the two?

Reading about ergo keyboards also made me wonder if you could specifically design a programming language for fast typing. Like python but a single space for indentation that gets increased by the editor code formatting. There is a ton of things that could be improved but we're stuck in local maxima by convention

Well it would have minimal brackets and braces

Or parentheses either

Those are a pain

Ruby?

I guess it would be ruby

Easy to type with the hands but hard to type with the brain because of all the OO baggage

Lots of overcomplicated baggage attached to everything with getter/setter methods and whatever

neo2 has fantastic extra layers for special characters and stuff (which adnw just copied), and it sure is better than qwerty/qwertz

it's been many years since i used neo2 but i'm pretty sure adnw is significantly more comfortable to type with

just because the letters are actually arranged optimically according to some statistics, and not just ~randomly

maybe the linked pdfs here help in visualizing what that means http://www.adnw.de/index.php?n=Main.Grafiksammlung

I don't think any of the layouts were arranged randomly, even Sholes put some thinking into qwerty, even though it's worse than twice the finger travel compared to every other layout.

I think it started out as a simple, alphabetically-ordered layout with a few key swaps made afterwards.

Hence the D FGH JKL MN

That's just alphabetical order with some vowels moved and some other significant letters moved

Earlier prototypes of the Sholes typewriter were in alphabetical order too.

Sholes' business friend convinced him to move some letters to the top row so that all the letters to spell TYPEWRITER were in the top row

So it's similar to typing on a completely randomly arranged layout, or maybe slightly better

It's too bad Dvorak isn't more common... it took me a lot less time to learn it compared to how long it took to learn qwerty. Despite typing all the time at home and school as a kid I couldn't type without looking at the keys for years!

And apparently that's really common for people to never learn how to type without looking

> a single space for indentation that gets increased by the editor tab

This format really needs to take over the planet already... It's been a long time without any news about Windows support or Firefox/Chrome...

Blame that guy from the chrome codec team /hj

Firefox was waiting for jpegxl-rs, though I dunno what's the current situation is, considering a lot of people were fired since then

Hopefully it won't affect it

Firefox is open source, so once jpegxl-rs is complete someone could just submit a pr

You could probably modify the Waterfox JXL patch to work with Firefox and Rust

Wait what? Even more people were recently fired?

from Firefox or general Mozilla?

Mozilla

yeah nothing to indicate anything effecting firefox

Mozilla Foundation, to be more specific.

finally got around to working on this (sorry, it's been a year)

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13460

here's the patch btw

Zsolt Vadasz got a Co-Authored-By as well

since I looked at what they did when I wrote my own

Why is the *literal leader of the webp/avif project* Jim Bankowski allowed to unilaterally remove jxl from chromium, and unilaterally declare that there's "no interest from the wider community" like he's gaslighting all the major corporations in the bug tracker that expressed enthusiasm and support? Can anyone from the Chromium project answer this question?

I know he's the head of the newly created "chrome codec team" because of his expertise and experience in leading the webp and avif team but, seriously, how is he allowed to do this?

How is there no scrutiny from anyone else on the Chromium project for like 2 years over that decision that's holding the entire internet back?

Imagine if Chrome were to enable the format by default shortly after Apple did.

'origin trials' for chrome and firefox shouldve been activated long before or from beginning. itd have been more useful for adoption than verbal statements

it allows specific sites (*even* small test ones) to basically have browser enable certain flags for their visitors, with logging of performance and stuff

Now that even Apple of all people is totally on board, with their entire ecosystem and product line, there's absolutely no excuse why it's not taken over the world by now the same way avif and webp were fast-tracked and artificially crammed into our mouths with no oversight or planning except for Jim's unilateral decision making. He must be some kind of self appointed God of the Internet to be able to declare which formats belong in the browser (formats made by him obviously) and which formats need to be deliberated upon indefinitely.

How has no one else from the Chromium project commented on this utterly shameless abuse of his position?

web services delivering mainly or only to their own apps can go jxl anytime, regardless of what browsers do

thing is, even if so many libraries already encode and decode jxl, many deployments of those still ship with it disabled by default as legacy defaults in need of change

If Chrome had flipped it on by default shortly after Apple did, imagine how much more common it would be. Many bytes saved. More developers becoming aware of it and more software being written for it.

i did numbers before and default in chromium wouldve pushed numbers up by around an extra 70% overnight, slightly below 90%

So many things are based on Chromium and depend on Chromium to render the UI.

electron missed its chance to have people rebase their chromium dependency onto electron/edgewebview

we focus so much on a percentage that obfuscates that while users tend to use one browser, they have multiple chromium-based apps - each separately counted, as web analytic services used for those track them too as if they were actual browsers (another reason firefox % 'decreases' despite user count stable since years)

Is anyone asking the rest of the Chromium project why specifically the head of the Chrome Codec Team is allowed to unilaterally fast track his own badly designed meme formats into the browser while getting rid of better designed formats that weren't made by his team?

Why he's specifically allowed to do all this with no oversight other than his own ridiculous "avif comparison" where his own graphs show avif losing badly at ssimu2 and butteraugli scores?

His only token justification is his own ludicrous comparison page where he claims to welcome feedback and improvements but completely ignores people like Jon Sneyers when he offered feedback?

Every day that passes where no one from the Chromium team can explain why Jim Bankowski is allowed to do this without any oversight is a day in crazytown

Maybe I should make a youtube video about it. It's surreal how stupid it is

Lots of people should be making youtube videos about it. No one really goes into detail about the specifics and the specifics are what's the most outrageously ridiculous about it

The same guy responsible for fast tracking webp and avif unilaterally yanks out of Chromium a better designed future proof format that wasn't made by him. Tells intel/facebook/spotify to their faces "there just isn't enough interest from the wider community honey" like he's gaslighting his wife.

Crickets from the rest of Chromium project, he publishes a comparison to cover his ass but his own graphs show avif losing, he claims to welcome feedback but pretends like Jon's feedback doesn't exist.

That's the story

It's wild

Isn't there anyone else from the Chromium project who's allowed to explain whether that's appropriate behavior from the head of the Chrome Codec Team?

https://en.wikipedia.org/wiki/Chromium_(web_browser)#2008_to_2010 > Arguing for it won't make it happen. 'A bunch of people would like it' won't make it happen. Our design decisions are not democratic. You cannot always have what you want

I think that is still the approach. Chrome/ium design decisions are not meant to be democratic, and it is our mistake to think that they would be.

https://about.google/philosophy/

> 4. Democracy on the web works.

The democracy they mean is something about the "patented PageRank™ algorithm", not about browser design decisions.

yeah, it's best to get as many other things to support jxl as possible, chromium will eventually be forced into it. firefox would be the next goal, then smaller ones like servo and ladybird

Can't someone else from the Chromium team say whether or not this is an appropriate way for Jim to exercise his authority and lack of oversight?

everyone knows it isnt. when people point out in too much detail why the excuses were bs, all it does is make them clam up - pretend they heard nothing, criticisms dont exist or theres 'no interest from the ecosystem'

Someone else from the chromium team really needs to weigh in on whether it's appropriate for someone in his position to fast track his own half-baked meme formats while unilaterally deciding to sabotage a more thoughtfully-designed and future-proof format that wasn't made by his team.

Whether that's an appropriate use of his unchecked and completely unaccountable position

i dont think thats the proper angle to pursue, it can be likened to pressure or a character attack to imply jxl positiy is just a vocal small mob

recently many large webhosts did meetings about updating their stacks to guarantee out of box support of certain libraries (so web scripts can have guaranteed support for certain features). has anything of the sort been given thought ?

if not webhosts, cdns like cloudflare, fastly. whatever can maximize jxl consumption even partially (ie you dont need *all* your billion imgs converted or with a jxl copy, just the top most accessed or a fixed % to safely work out any deployment or workflow kinks is a good start)

additionally formats dont need to be decodable by browsers. sites like deviantart can offer a **downloadable** jxl in addition to whatever is rendered/previewed inside browser

But it's literally down to just one man with unchecked power

That is the problem

There isn't another angle here

One man and his weird ego

even if this doesnt change this still need to be bypassed

That's the whole reason it's so ridiculous

The whole reason it's so ludicrous is because it's all down to some random guy's ego as supreme lord of the internet

It needs to be addressed

Not bypassed

It's the elephant in the room

web services and apps are pragmatic, long ago the bw/storage savings shouldve been pushed. consider this example: our img-heavy app loads our content much faster and consumes less bandwidth than using a browser even though it shows more ads

The absurdity of the webp lord telling us there isn't enough interest in jxl

That is the angle

webp sucked until jyrki and some other jxl fella made it any good with lossless. even then all it had going for it is being served by cdns as substitute for recompressed jpgs - a substitute that can be replaced anytime with another final delivery-only format

Plus jyrki was told to intentionally place arbitrary crippling limits on the lossless mode to match vp8 and the codec was named vp8ll... again all to appease Jim's ego as the head of vp8 team

If Jim is the sole decision maker as he seems to be, then Chromium will never have jxl support ever again since there's absolutely no reason for him not to continue doing what he's doing forever since he isn't accountable to anyone else

The ego problem needs to be addressed

The bigger picture imo is that the two major browser engines (chromium and safari) are controlled by two big companies, and that companies (at least in the political-economical system we currently live in) are not controlled in a democratic way, at all: typically the structure is hierarchical, bosses are not elected and if they want to act like dictators that is considered totally acceptable since it is "just" a private enterprise owned by private capital, not something like a public service paid for with taxpayer's money.

I don't think the bigger picture is that people shouldn't be allowed to create private corporations and choose how to fund it and what to buy. I think that misses the point entirely, actually. I think the bigger picture is that "web standards" are a joke and controlled by advertising agencies whose job is to spy on us rather than to make a well designed standard that respects our consent and security and privacy.

And the standards are so bad that no one can follow them and Chromium is an Enterprise-grade monstrosity no one can afford to maintain except a trillion dollar company

The bigger picture is why is it impossible to write a web browser (well aside from Ladybird maybe) and why are the standards so bad that we are forced to depend on Google and Chromium

Google is hardly a private corporation either. They basically own the government.

The government only exists to give google your money

That's what it says when Jesus signed the constitution

Clearly the answer is to render all sites as <:JXL:805850130203934781> server side for maximum efficiency and ease of implementation

The thing about power structures is, you have to ask, why does that dependency exist? What causes it to exist?

The cause isn't because people are allowed to start and own their own private company.

The cause is usually because people are NOT allowed to do their own thing or depend on anybody else!

Government and corporations both seek to make you permanently dependent on them alone.

Or, at least, control freaks do. Control freaks want control and dependency.

And they usually do it by force like pirates and terrorists. Like how Sony utterly destroyed some kid's entire life for installing Linux on his own offline Playstation

The problem isn't an economic system, the problem is control

Control and dependency

My point wasn't that private corporations shouldn't exist, my point was that maybe it's not a good idea to put them in charge of defining the web platform. Back when the monopoly of Microsoft Internet Explorer was ruining the web platform, it was bad, and we hoped that with Firefox and later Chrome things would get better. But in essence nothing really changed in how web standards are defined: still basically one big corporation decides what goes in or doesn't go in.

No browser engine should have over 50% market share. When Chrome passed that mark, it was foregone conclusion. (government dictating standards is not really a solution: look at US vs RISC-V fiasco)

It should be made by engineers who want to design a simple and secure standard that's easy to implement. With the user's consent and choices driving the design. Instead the users are the ones getting used. How/why did it get this way?

The standard is intentionally designed to make it impossible for competitors to appear, and to completely ignore the user's consent and intent

And yet it's the dominant protocol for browsing information on a network

Usually the whole point of a "standard" is to allow competitors to make their own implementation

While remaining compatible with existing ones

Users with disabilities like blindness are now a complete afterthought too in modern web design

not necessarily competitors, but just interop in general

it's why, say, barcodes for products are standardized. that way people in the same industry but different parts of the chain can function

i.e. the grocery store can scan both coke bottles and pepsi bottles since realistically they're going to carry both

the issue arrises when companies use monopolistic (or almost monopolistic) market share to force the standards to be in their own interest at the detriment of other interests but this isn't an issue with standards or the web platform. this is just an issue when a company has too much market share. which alreacy causes problems

Well it's an issue that web "standards" and the "web platform" is designed poorly on purpose because of a monopoly where the user is the product being sold rather than having the user's consent and intent in mind.

I mean isn't that kind of what I said

> the issue arrises when companies use monopolistic (or almost monopolistic) market share to force the standards to be in their own interest at the detriment of other interests

Sure yes but they're both a problem, you’re giving the reason behind the problem, but they're both still problems

But I don't see any major push or impetus to move to better standards or overhaul them to better respect users basic dignity

I don't see anything like that coming and the only people who talk about that are very fringe

Gopher/Gemini communities

the solution is simple, invest in more browsers, Firefox is a failed project

Firefox lit itself on fire and jumped off a bridge

It had a lot of promise and potential and it was intentionally destroyed for some reason... Hmm... Maybe the CEO is a Google asset? 😂

Maybe someone from Google gave the order to utterly destroy firefox and fire anybody capable of maintaining and modernizing the codebase. If I wanted to go tinfoil hat mode I would say that's how it looks like lol

Either that or it was just eaten from within by vulture capitalists

It would be interesting if there was a conspiracy to get vulture capitalists to hijack command of Firefox to benefit Google

well most of its funding comes from Google so...

its not like they cant find funding else where

google just wins the bids

apple couldve funded entire mozilla's spending from the 20 billions it gets from google for search default

best way mozilla couldve made any other search engine default even for free or rolled its own (ie rebranding brave search/index - remember, its actually a continuation of what was previously mozilla projects)

mozilla wouldve covered the platforms apple doesnt focus on to weaken chromium monoculture

why would apple do that tho? zero incentive, Being realistic, there are other engines that will pay mozilla, it's just about winning the bid

depending on how the monopoly stuff goes, this may wind up happening anyways

getting back at google that way would be way cheaper than frontally attacking it. itd be basically google funding its own weakening without apple needing to micromanage its rivalry in the spaces moz covers

apple wouldn't want to do any of that, and mozilla always have had alternatives to google for payment, google is a non factor, the only factor is that firefox is a project on life support

if you want to remove power from google, make good products, it's that simple

Mozilla used to be known for collecting all the top genius engineers but now it's just corporate vultures eating the hollowed out corpse

speaking of mozilla collecting top engineers, have you seen the ladybird news?

There's news?

massive news, goliath news even https://ladybird.org/posts/mike-shaver-joins-board/

mike "ten fucking days" shaver joined them, AKA one of the OGs behind old firefox

Don't know who that is, off the top of my head, but hey, sounds pretty good. If he's one of the OG mozilla founders

yeah, he is one of the dudes who was directly responsible from turning firefox into a fork of a janky piece of crap, to the top dog browser. so it's actually super exciting news

so you have igalia and co working on servo, and you have shaver and co working on ladybird, it's a good time to be a fan of browser tech

But the standards themselves are bad since they are designed for advertisers to hijack your computer rather than being designed around your intent and consent when browsing

They are way too permissive and allowing by default without user input or consent

well, that simply depends on implementation, it's not like these things will time out

The priority is "flashy graphics and scripts that run by default and hijack control of the window position and anything else on the web page at ant time" rather than accessible information retrieval that respects user intent and choice and users with disabilities.

It's a problem with the "web standards" themselves because if you design a browser that behaves differently then 97% of websites don't work

Or more

Blind accessibility is an optional afterthought that is ignored most of the time too

It's because of priorities.

The priorities are the priorities of advertisers, not users. Users are the product being sold

you know, these could probably be solved by a simple web extension, I imagine something like modifying noscript to ask perms would work [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

browser like chrome and firefox just do that anyways internally so it's not like it makes a massive difference,

there needs to be more granularity in user consent baked into the protocol and expectations of web developers.

I don't really see a need, nor a real want for it to be in the protocol, I don't see how that would help.

https://twitter.com/imgproxy_net/status/1866158801000534073 https://bsky.app/profile/imgproxy.net/post/3lcv5nbotcb2f https://github.com/imgproxy/imgproxy/commit/3f4edb91f7c805c9a81341af7bcd0946c27e0860 https://github.com/imgproxy/imgproxy/commit/d9abf2d3d73a6132989edec59f45cb8b644201b6

Effort 4, Quality 77 by default

I should make my own cdn software that just uses native encoders directly so I can just feed jpeg right to jxl

doesnt transformimg cover that ?

Isn't getting consent already part of the protocol for accessing certain JS API features?

There just needs to be more consent and less expectation that you're allowed to do whatever you want to someone else's machine.

Nobody consents to a web page suddenly changing itself and interrupting them in the middle of reading the content of the page. Or autoplaying sound or running cryptominers and draining the battery.

But you can't design a browser that respects consent without breaking like 95% of websites

That's why standards and expectations of web developers need to change.

Some more info about the imgproxy implementation from the docs > The priority is as follows (from the highest to the lowest): JPEG XL, AVIF, WebP > Default: jxl=77,avif=63,webp=79 > IMGPROXY_JXL_EFFORT Default: 4 Though I also noticed this which is, annoying... > IMGPROXY_JPEG_PROGRESSIVE: when true, enables progressive JPEG compression. Default: false

Effort 4 is not a great default imo. I would go for e6.

For lossless I think it would be a good default

Users might be surprised that the default speed setting for lossless is much slower than for lossy

5 would probably be best as a middle ground. Then you have the Var of VarDCT and generally good lossless speed too

no

Why does lossless have to have the same default as lossy?

the default effort level for lossless can be different...

What matters more is that one isn't significantly unexpectedly slower than the others

imo the *default* effort should adapt to resolution, not be the same for all images. small images could be crunched more and itll barely take any longer time or ressources, and the opposite would accomodate large images better (decrease effort spent by 1 or even 2 so as to maintain encoding performance if its not adequately multithreaded)

Honestly though I would be even happier if it was easier to predict or set constraints on memory usage so it doesn't DoS your system when you give it a large image

memory exhaustion is a pretty serious and annoying problem to deal with

Memory usage is surprisingly consistent when chunked encoding is enabled

Without it memory usage balloons into the stratosphere

many seem to use effort 10 and even 11 for even lossless transcode from jpg for a potential gain of one kilobyte - imo everything above e8 shouldve been an expert/dev option whose use is discouraged except in very specific situations or really powerful hardware

perhaps updated documentation and comments could include reference numbers for relative performance and ram consumption between efforts?

Effort 11 doesn't actually do anything for jpeg transcode, it just falls back to effort 10 same with VarDCT and Lossy Modular. I do agree that anything above effort 8 is kind of a foot gun, especially for lossy.

Ooo that sounds fun! Now that I know the limits of chunked encoding, I can properly test memory usage. If I get consistent enough results, I'll be able to post them somewhere.

Also, I want to measure BD rate comparing all effort levels, I feel like it should illustrate how little efforts higher than 8 improve quality.

Acorn 8 supports export to JXL: https://flyingmeat.com/acorn/

How "strategically" was Adobe move on adopting WebP to "Save as" option and JPG XL not (JPG XL was only adopted inside Adobe CameraRaw export option)? <@794205442175402004> ?

Adobe has been acting... Strange... For instance, they added JPEG XL to the DNG specification, but not using the premade bayer channels to store it and with bad defaults that hurt the compression...

A strategic move could be for JPG XL to highlight its ability to compete (=add market real value) with simplistic multi-layer images that can be saved as JPG XL. In this case, it seems to be competing with Adobe PSD files, but IMO is not. JPG XL should be more strategic with Adobe, creating a valuable solution for many consumers of large files that need space and the ability to escalate in quantity. PSD and JPG XL as multi-layered source files could benefit everyone. What do you think <@794205442175402004> ?

for adobe, expecting psd will eventually leverage jxl in a future version. what would make sense is a high efficiency mode, and a legacy high compatibility mode not rebuilt on jxl)

integrations seem to need more support from jxl experts so as to avoid newbie mistakes out of unfamiliarity with what are many novel or barely documented approaches

I am dreaming of having Krita, Gimp, Photoshop etc all save images to layered JXL plus some box with additional data that cannot be represented in JXL itself (such as weird blend modes, text/font info for layers that are rasterized text, etc). So if the image is sufficiently simple (only normal blending of image-only layers, nothing fancy) it's just a standard JXL; if additional features are used like text layers, but only features that basically all major image editors support, then that goes into a semi-standardized box (that is, it's not part of the JXL standard, but there could be an industry standard / convention on the syntax of this stuff); if any exotic features are used that are specific to a single image editor (e.g. funky layer effects that exist only in Photoshop), then that goes into a proprietary box that's only supported by that image editor.

I would say for if this becomes a thing it would be most likely / understandable for the “spin-off” formats to have a different extension, like how there are lots of files which are technically just .ZIPs but the different extension help classify them. Like Krita could just .krxl or something and it’s still a 18181-2 file but it makes it obvious it’s a Krita project and not just an image from a camera or something.

Take Affinity suite, their 3 file types are literally identical; you can rename one to the other and open it perfectly fine, which is by design, however it is still helpful for them to have different extension

Especially if there is possible proprietary data that should not be messed with

And then there could be some standard interchange JXL format (could just be want we have now) where all the proprietary image effects were rasterised and baked into the file, and so can be opened with any compliant editor

I think the extra image editing related data could be a use for the extensions feature

As it is not integral to viewing the document (a preview frame could be stored or something)

yes, using different extensions does make sense for end-users and for OSes to know what application to open it with, but for basic image processing pipelines (viewing or "generic image import") and interoperability, it's very nice to have a standard file format where you can just ignore the stuff that is only needed when opening it in an editor.

basically a rasterized (but still layered, with proper layer names, etc) interchange image in the jxl codestream, and then some box(es) for all the other stuff that goes into editor project files (which is typically not a lot of data compared to the raster image data, and the generic `brob` mechanism can be used to Brotli compress it). Preferably some box with open syntax for the common basic stuff, and then some proprietary box specific to the specific editor (which has a syntax that probably changes at each new version of the editor, as new features get added etc).

So like when opening with a generic program a vector layer will display a rasterised version however when opened using the correct software it will be replaced with the actual vector layer?

yes

Full layer support is kinda impossible, because JXL does not support common blending modes. Multiply blending mode, for example, is used by nearly 100% of artists when coloring lineart.

There are certainly blend modes and layer fx that jxl does not support — but you can always just encode the layer image data itself and add an explicit merged image, just like how Photoshop does it when producing "maximum compatibility" PSD files, or TIFF files.

I was initially about to add that specific box for layer info when working with layered JXL on Krita, since there are tons of blending mode inside krita that can't be represented with jxl. But I kind of afraid of that compatibility issues if I didn't include that 'merged image' preview on top layer (and for a reason of don't want to make another TIFF-like mess :p). Therefore the result was a pretty basic layering support for it. +1 for using different extensions, maybe putting a todo for the near future.

It's a shame KRA can't internally use JXL, since it just uses raw bitmaps which are deflate compressed in the ZIP file

`.KRXL` sometime?

Adobe Fireworks did this with PNG files but it made it impossible to tell what was a fireworks project and what was a basic PNG

if so it would have to have some kind of different file extension maybe

I remember some game using PNGs as save files

Spore using Stenography

😲 That seems like a strange decision for Maxis to make when the already had their DBPF archive format, but I am not familiar with Spore.

Adoption should go through the roof after mid-2025 👍😃https://discord.com/channels/794206087879852103/822105409312653333/1320983484017152050

well assuming firefox follows through, it will take some time for chrome to implement it likely afterwards. we will also see what will happen on the android side of things, since android recognizes JXL's as images, image galleries will be able to implement jxl easier, not easy, but easier.

That comment on github does say they are willing to implement it in *browsers* not just in *Firefox*, so maybe Chrome could also be swayed to add JXL support if they don't have to do it themselves

Chrome has had a JXL patch maintained since it's removal

a complete one at that

Yes. For libjxl. Not jxl-rs.

But the libjxl integration is great. Among the best.

If libwebp is allowed in then why not libjxl?

Double standards

because libwebp was added like a million years ago?

I mean to say, it doesn't really matter if it's written in rust or c++

libwebp is c++ too

And a language doesn't protect anyone from badly written code. It can only make it more convenient to write good code and less convenient to write bad

I think putting it in the domain of convenience undersells it quite a bit. Google and Microsoft both independently reported that ~70% of their critical security vulnerabilities were memory safety issues,[[1]](https://www.chromium.org/Home/chromium-security/memory-safety/)[[2]](https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/) Google Project Zero reported that out of all the 0-days used in the wild, 67% of those were memory safety related,[[3]](https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html) and Mozilla reported that 94% of their critical/high bugs were memory safety related.[[4]](https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/) So you're effectively avoiding a huge portion of all your critical issues that you would have had, by using a memory safe language from the start

It's not like the reason those numbers are so high is because it wasn't convenient enough to write safe code, implying that they could have written safe code but just didn't want to. I'm sure they wanted to and tried to write safe code, but made mistakes. Mistakes which are impossible to make in memory safe languages

But it is convenience, though. That is all a development tool is capable of doing. Rust was designed to make it less convenient to encounter memory bugs, and more convenient to prove at compile time, with static analysis, that memory allocation has a safe and valid defined lifetime. Which is a good thing for a language to do. But it's not anything greater or more magical than that... tools to generate static proofs of memory correctness are not a new thing iirc, and it's possible to statically prove the correctness of code written in C too. But making it built into development tools and the language itself and making it less convenient to write dangerous and unproven code is the right direction to take things. But people treat Rust as some kind of magical silver bullet. I don't think the language even allows you to handle memory allocation failure like other languages do.

Rust does make it more convenient to write safe code, and it also makes it impossible to write memory unsafe code outside of unsafe blocks. Zig also makes it more convenient to write safe code, but unlike Rust, it doesn't give you the guarantee that your code is memory safe. If people say Rust makes bugs impossible or makes it impossible to write bad code, they're giving people the wrong idea, but saying Rust makes it more convenient to write safe code, while true, also gives people the wrong idea, imo, because memory safety is an objective feature of Rust whereas convenience is sort of, a personal experience

I would say that rust does make it more convenient. but rust is better explained, not with "Rust makes it easier to write safe code" but rather "rust makes it harder to write technically bad code" since that excludes things that are "just dumb" things to do like trying to get the same number from random generation lol

yeah that's a good way of putting it, I think

IMO the best thing about rust is that it lets me be lazy and achieve a a level of code quality that would be impossible in something like C or C++ given the level of effort I put in

It provides a lot of convenience that doesn't necessarily directly translate to better code, like a first party built system, integrated unit tests feature, etc. Then it also has convenience features actually that make writing good code very convenient, like the a type system that allows you to make invalid state unrepresentable. And then it has objective features that prove your code is safe, and then it has more convenience that allows you to write potentially unsafe code if you want to

For me personally I don't think I could even pick a favorite thing since I haven't written anything else in years, so I don't have a reference anymore <:KekDog:805390049033191445>

I hate coding, so languages that make it easier matter a lot to me, dart and rust are my two favourite langs

too bad flutter sucks on linux

I can reason about things I'd probably miss a lot though: good error messages (rust treats bad error messages as compiler bugs and will fix them as such), `match`, `Option<T>` and `Result<T>`, and `enum`s that allow values in their variants. These are the things I personally like and use a lot, but the most virtuous feature imo is memory safety and thread safety. It's hard to imagine, but Rust would still be a great language without it I think, it's just that memory unsafety has collectively cost us so much work and caused so many problems, and being able to just remove that entire class of bugs, effectively for free, in a systems programming language, feels like such a revolutionary thing

I know it's a bit silly to praise Rust for its memory safe because yeah, no shit, but still 😅

Oh I tried Dart a couple years ago, it was a surprisingly pleasant experience

> impossible to write Memory leaks are always possible

Well it makes it more convenient to have static compile time guarantees. You can have that in other languages too but it's better for it to be built into the language like it is with Rust

It's more convenient to guarantee allocated memory has a valid life cycle

not impossible https://github.com/zyedidia/transmute

more like "if it is possible it is considered a bug" 🙂

Memory leaks are possible. It was actually a bit of a discussion point during Rust's development, for whether memory leaks should be prevented in safe code. If they would, you would lose out on a lot of convenience and the language would be even stricter. So it was decided that the possibility of memory leaks should be minimized, but the language model doesn't easily allow the compiler to verify that they don't happen, and so it doesn't eagerly block anything where it can't say with certainty that it won't leak memory. Ultimately what Rust really cares about is memory safety, and memory leaks don't have the possibility to cause memory unsafety. So while it's very rare that your safe code accidentally leaks memory, it's not a *guarantee* that it won't happen

`Vec::leak()` can be called in safe code :)

_memory leaks are not considered memory unsafety_ Depends on your definition. Under some definitions even Pascal is memory-safe language.

I don't think anyone uses a definition of memory safety that considers memory leaks on their own unsafe. Memory unsafety revolves around bugs arising from memory accesses. For example an out of bounds read could allow you to read memory you're not supposed to, and an out of bounds write could allow other code to read data it's not supposed to. Memory leaks can cause unsafety in conjunction with these, and Rust's guarantees say that no memory that is leaked could ever accidentally be read from safe code. I'm not very interesting in arguing definitions of memory safety, so long as we're both aware of these facts then that's fine and you can call it whatever you want, though again, I personally think saying Rust isn't memory safe because an uncommon definition of memory safety is chosen is a bit misleading

Rust kinda reminds me of PaleMoon. Anyway, I'm excited for jxl-rs. Aside from FF, hopefully it would mean more performant thumbnailer for Windows.

I would count it as more than plain convenience, since non-trivial memory safe C programs essentially don't exist. Any random program in Rust is very likely guaranteed to be memory safe. Any specifically chosen because of how well engineered it is C program likely has memory bugs. There are no tools to *generate* proofs of memory correctness for C code, but there are tools for writing the proofs yourself. The problem is that random general C code usually can't be proven safe, you have to write your code in a way that makes the proofs easier to write, and now your C code will be super restricted in how it can look and be structured. Let's look at Ada as an example. There is a subset of Ada that allows for static verification of correctness called SPARK. One of the limitations was that you couldn't use any pointers (called access types in Ada) at all because SPARK couldn't prove that there wouldn't be any undefined behavior. In 2021, SPARK allowed pointers finally, by copying Rust and adding a borrow checker.

Preventing memory leaks is in general supremely difficult. If you have reference counted types and you allow types to refer to themselves (e.g. a struct T that has a pointer to T) then it's trivial to leak memory by simply creating a cycle of reference counted values, and now suddenly you need a GC to get rid of leaks. Any strategy to prevent leaked values from continuing to exist without GC would surely be really effed up! Even worse if you use the stricter definition of leaking: that values continuing to exist indefinitely after the last time they are used is a leak. By this definition, GCs don't prevent leaking, since you can forget old values in a hashtable or something forever.

I would say rust makes it difficult to write memory unsafe programs

You have to explicitly try to break it

If you use `unsafe`, it's easy, but if you don't, it's basically not going to happen.

Yeah

Icaros is apparently getting JXL support soon! Though, the last update was on November 1, hopefully more info will come sooner or later. > Icaros is a collection of lightweight, high quality, Windows Shell Extensions. > > Icaros can provide Windows Explorer thumbnails, for essentially any video media format supported by FFmpeg, this includes popular filetypes such as: Mkv, Flv, Avi, Mp4, Mov, Rmvb, M2ts, Ogm etc. https://github.com/Xanashi/Icaros/issues/24#issuecomment-2451762286 **Xanashi** commented on Nov 1: > JXL support will be added quite soon to Icaros. > Thank you all for chiming in on this feature request. > I personally can't wait to get JXL added, as I agree that it's a really nice format.

seems opencv merged support into 4.x (no release yet) https://github.com/opencv/opencv/pull/26379

This question comes up a lot... I don't have a cringe reddit account so I can't answer but if someone wants to convert a large amount of files right now, I would recommend a process that does sanity checks on each file to make sure lossless files are truly pixel-lossless, and for lossy files, that the maximum amplitude of distortion at any point in the image doesn't exceed an extreme and unexpected power. To catch weird errors in lossy compression too like missing blocks or completely wrong colors or some other rare bug.

Ideally, the encoder itself should have some sanity checks like this built in, in order for it to be a truly unattended tool like it's trying to be.

To catch rare bugs and corner cases where the image encoding process fails silently and produces bad output without alerting the user

It would be much better if you didn't need to use an extra tool like gm or magick

But if cjxl produced a warning or the library produced an error state

"Output error, lossless verification failed" or "Warning, extreme distortion detected"

"Major lacerations detected. Morphine administered. Power level is, forty percent. Have a very, safe day."

happy to see this getting addressed in the next version of the plugin! 🎉 https://github.com/0xC0000054/pdn-jpegxl/commit/bd05b8f900acd3f405a944d448b1897f35e00ec2 https://github.com/0xC0000054/pdn-jpegxl/commit/b480fed89c47889b69e32f7609dd07ffa4524ab6

The plugin still doesn't support HBD, but there is also benefit to improving color management.

One thing that I am considering, but can't implement due to Paint.NET not supporting load dialogs is allowing the user to choose the preferred XYB color space on load.

But there may be a way to auto-detect which color space to use for XYB images.

I thought xyb is an internal part of the codec that library users don't need to worry or think about

It's just the internal lossy quantization space and when you decode an image it gets decoded to whatever color space is specified/attached

Presumably you would open a lossy jxl in whatever color space is written to the input file? Since that's "the suggested color space for the file"

When you encode a file with cjxl to a lossy file, it embeds the original color profile so when you decode the lossy file later, you know what the original color space was and can decode it back to the same space as the original file.

At least that's how it's supposed to work

Sometimes there are bugs where it doesn't do that...

Like the famous bug where it decodes an 8 bit srgb image to 8 bit linear. Idk if that crazy bug has been fixed yet

These should both just be treated as output errors ideally at the library level... to avoid silently writing bogus output, which is a serious concern

Even the lossy encoder should have some sanity check option and try to verify it doesn't contain common types of errors like extreme distortion in specific regions/blocks or near the corners/edges of the image borders, completely wrong color/brightness throughout the whole image compared to the input, maybe even also extreme color banding that isn't present in the original image.

for lossy, its more effort to do those tests so maybe it should be user-controllable, for lossless a simple hash should be pretty fast

I don't think it's more effort.

But that's just a theory

My theory is that lossy already has to do similar tests anyways because of the nature of lossy

When you specify a quality level, the lossy encoder has a perceptual model of how much distortion is acceptable and tries to make sure the maximum distortion doesn't exceed a perceptual-based threshold.

So maybe it can re-use some of that code when doing a final test at the end, to try to catch silent errors.

And make it an optional switch, if it takes too much time.

`-V` for example

wait that's version

meh

maybe just make the existing -V behavior the default "no arguments" behavior

instead of -h

IIRC lossy uses a butteraugli heatmap of the image to decide where to spend the bits, so if it was already wrong once it would just repeat the same output

Ssimulacra2 could help, at a huge memory and time cost

XYB is just an implementation detail, user would never see it when decoding. I dunno what's the problem is? From the cursory glance, [example](https://github.com/libjxl/libjxl/blob/main/examples/decode_oneshot.cc) keeps the original color profile.

The more time passes by, the more convinced I am that the JPG XL name was a bad move: - the name destroys the message that JPG XL is not a mere JPG upgrade. We see lots of photographers talking about JPG XL but using JPG name only - to stand up a clear message on the uniqueness of JPG XL as a brand new advanced product (compatible with the JPG), the name JXL as a new product and not an upgrade would be more precise to newbies and the market in general Google WebP benefits from this marketing misalignment.

I personally believe JXL should be the format. Actual name in JPEG XL should be just what it expands to but not actually used most of the time.

jpreg

Although “jpeg xl” has pretty unambiguous pronunciation “Jay-peg excel” where “JXL” has many different pronunciation: - “jay excel” - “jexel” - “jay-xel” (same as above but longer first syllable) - “jixel” (like “pixel”) - “yixel” (some languages pronounce J as Y) - probably way more

We don’t need another GIF vs JIF (unless it can spread awareness, hmmm) 🤔

GIF vs JXL when

jay-forty

J-"ten"-L

When we have iPhone "Ten"-R and JPEG "Ten"-R

I wish an iPhone was only a tenner

j40 be like

https://www.youtube.com/watch?v=Nrk8sqZfsgI

Every one cares about GIF versus JIF, but no one cares about PNG versus Ping.

I do. I do....

Because everyone universally agrees that it should be pronounced pee-en-gee, no exceptions

apart from that one wikipedia editor who wrote the introduction to the PNG article

The PNG spec says it is pronounced ping, iirc. Or maybe it was some libpng history document, not sure.

If it is POrtable Network Graphics, of course "pong" would be a more logical pronunciation. But unofficially, PNG is really a recursive acronym for "PNG is Not Gif", which explains why it is pronounced "ping".

I do say pee & gee myself, but I have a lot of respect for those who say ping.

> I do say pee & gee myself There's a quote

the real question is: how is the GIF in "PNG is not GIF" pronounced

The working 3rd edition of PNG spec still says this > This specification specifies a datastream and an associated file format, Portable Network Graphics (PNG, pronounced "ping"), for a lossless, portable, compressed individual computer graphics image or frame-based animation, transmitted across the Internet.

PNG is not Gif afaik was a backronym from back during the LZW compuserve patent days issues

most of the people who work on PNG are unrelated to the people from way back when, except I think mark addler

i wonder who is that above me lol https://github.com/FFmpeg/FFmpeg/commit/f3c408264554211b7a4c729d5fe482d633bac01a

Oh, yeah. They announced it in <#794206170445119489> instead of here

Not sure if anyone else has pointed it out, but because the Telegram desktop client for Windows uses jpegli, sending a 16bit PNG will encode with the extra bitdepth you can recover as the recipient

that's really cool

I hope other big social media platforms adopt jpegli (and jxl) <:logo:829708783336816671>

In this case, I think it's just because it's open sourced on Github. The other clients are closed or hidden and don't have jpegli

Or JXL...

afaik telegram seems to use jpegli and jxl everywhere

Nah, you can tell because the files from other clients use subsampling

Telegram desktop uses jpegli on Linux. On Windows, mozjpeg is used.

I thought it was the other way around?

What on macOS?

https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/build/prepare/prepare.py According the build script I think it is very close to Windows build. So mozjpeg.

Maybe there's no big difference as they should've chosen the quality below 75

macOS actually have a native swift app for telegram, but they also seems to use mozjpeg? https://github.com/overtake/TelegramSwift/blob/539b85f909080f003cf41fad66af035bb5dd26e5/submodules/Mozjpeg/Sources/Mozjpeg.h#L4

> stage('dav1d' > stage('libavif' > stage('libjxl' Why it does not recognize .avif files as images?

I tested and I am wrong. I was basing it on quant tables but looking again they're completely different

For me, AVIF works in Telegram Desktop: https://github.com/telegramdesktop/tdesktop/issues/28829#issuecomment-2572903255 Can you show me what AVIF doesn't work for you there?

> version 5.9 probably this is the reason why it's not working for me

Some avif's working, some not. The second one is large: 4800x7014 pixels

Can you send me the second AVIF file which didn't work?

I think it is because the app is built using Qt6 and there is a default allocation limit 256MB.

If you use 8-bit depth for that image, it would work.

Yes, 8bit is working

thank you

Works fine

This is probably not Linux desktop client and not Web client

Correct, this is Windows one

Because Telegram Desktop for Windows uses Qt5 and it doesn't have the Qt6 limit. Qt5 is used because it works on Win7.

Qt6 renders text so much better, though

I will say that this is something that exists https://github.com/crystalidea/qt6windows7/

Noticed that XYB JPEGs were getting heavy chroma bleed on Telegram. Turns out it's preserving the XYB colorspace but using YCbCr quality and quant tables

on upcoming adoption, Kavita merged jxl support *and* transcoding in canary, basically allowing comic-style sites to store and serve only one image format (ie jxl) but live transcode to another supported format if the app/browser doesnt support the main choice - or say keep pngs stored and serve live-transcoded jxl in priority if supported without needing to transform the entire library (sounds handy for incremental conversions taking forever to swap the source images)

https://github.com/Kareadita/Kavita/pull/3489

Intriguing

Set environment variable QT_IMAGEIO_MAXALLOC=512 to increase Qt6 default limit.

Using env variables is really annoying

Huh... How do you have so many server levels having only joined today?

they are a long'ish time member in the server however they have changed their username (I'm probably not going to say what the old one was out of respect) and they keep deleting all their messages which is incredibly annoying because there are dozens of pre-existing conversations in this server that now have missing or broken context. I'm pretty sure I know what event caused them to start deleting everything but honestly this all feels like an overreaction to said event. (just to be clear it's perfectly fine that they changed their display name and keep rejoining the server it's just the breaking of old conversations I have a problem with.)

I see

<@238552565619359744> got that EPF bug on krita fixed, just merged into stable branch as well https://invent.kde.org/graphics/krita/-/merge_requests/2309

Thanks, Krita is almost better than cjxl at this point, with a nice GUI and annotated options

Needs a macOS user to verify if this Quick Action can convert multiple images to JXL and display the whole progress on Terminal

<:JXL:805850130203934781>

Yeah, it's already on the website at the bottom <https://jpegxl.info/resources/supported-software.html>

dupe cleaner czkawka handles jxl since october's v8.0, xnviewmp is the one supporting jxl (not the old xnview classic)

mention for android users - Fossify Gallery (available in play store, fdroid). successor to Simple Gallery (wich became abandonware)

Fossify Gallery sadly has issues displaying certain JXL files, but at least some work

afaik a limitation from the upstream library used. oupson had a FG rebuild based on its old code that seems to not have some of those issues so i guess it could be contributed to FG's current code if identified

for more universal enabling, the only option almost as good as inclusion upstream is use or preinstall of a jxl-enabled webview so any app/game with jxls available could display them without extra changes. cromite had it for a while until a change upstream got its patches disabled for further research. i wonder if dev just forgot to reenable it since noone asks

**hydrus** apparently now supports jxl through a pillow plugin (version 606) https://github.com/hydrusnetwork/hydrus/releases/tag/v606-future-01

its used to build, sync, redistribute and power the backend of booru-style image libraries dev asks jxl enthusiasts for feedback

Maybe I'm kinda impatient, but why is mozilla waiting for jxl-rs to be finished when all they need to do is just enable their existing jxl decoder that's in the nightly build?

And merge the patches that fix the transparency, animation, and color profile support