JPEG XL

even then, I think the bright screen in the darkness might do better than the sheet of paper in sunlight

The point is, paper DR scales. Screen DR does not. It's limited.

The only limit of paper is the point where it ignites from too much light

I’m not sure the DR scales; more incident light raises the higher bound but also the lower bound

But the higher bound raises faster than the lower bounh

well, does it?

I doubt it

That is the nature of ink

that its reflectance varies with incident power?

The amount of light absorbed by ink can be simplified as a percentage that mostly stays the same

if that is the case (as I was implying) then DR would also stay the same

Maybe so...

if the white parts of the print reflect 100%, and the black parts reflect 1%, then DR will be 100 in an office and in direct sunlight

Indeed...

although there may well be perceptual effects that will still make it look better in sunlight

Indeed again.

(or the “office” DR gets more limited at the low end by “I can’t see that dark anyway”)

I stand corrected. But yes that's exactly so.

PDF is good because everything else looks bad

Formats that are just content which the viewing program does the layouting for never look as good

What about .ps.bz2

Does pdf have any advantage?

PDF really helps with making sure things look standardised

Can a postscript file embed images and fonts?

isn't PDF based on postscript?

Both PDF and HTML suffer from feature bloat and are very nontrivial to implement completely. But there are subsets like PDF/A and EPUB that limit the bloat again.

format lifecycle New format, pretty simple More and more features Really bloated, hard to implement Stripped down version Old format, only some things support different parts Someone makes a new format to simplify this repeat until XKCD 927

Full PostScript is a programming language with branching and looping, which is a security issue (you can send PostScript printers in an infinite loop). In PDF, you can only use a subset of PostScript that is not a full programming language.

so PDF is a subset of PostScript?

wow, I tried your link and now I cant access it 😄 maybe its because of windows version? I have windows 10

PDF is a superset of a subset of PostScript 🙂

Also 10

Well, in that case it's just weird 😄

every fact I learn about pdf just makes it worse :/

imo some features' adoption should be individually tracked (like lossless transcoding from jpg since its a huge deal with quasi-instant conversions that require almost no system ressources to complete), as well as the quality of integration

on an aside, updated adoption from **xnviewMP**. in 1.8.0, they updated libjxl from 0.8 to 0.10.3

Trying to find info about that I noticed they added jpegli in the last version, although people seem a bit confused about the 16bit input/10.5bit encoding https://newsgroup.xnview.com/viewtopic.php?p=197855#p197855

If someone already has an account, might be worth mentioning you only get the benefits when decoding with jpegli too

You know I'm not entirely sure...

oXPS (incompatible upgrade to XPS, both from MS) can but it has like zero adoption. the usual readers decode it still but pdf is better, its just most still generate new docs in old versions as if its a guarantee of highest compatibility

problem with any new standard that is backwards compatible, everyone will just use the base standard for extra compatibility

i would say this is one of the main reasons why JPEG XT pretty much got nowhere

If only pdf was an archive with xml and all resources as files, like .docx and other ms office files are..

ah the good old "stuff a bunch of XML in a ZIP"

Isn't odt the same way though? Literally just a zip

yeah

Right. I'm not so interested in xmls, but in all other files that are just streams inside pdf, and are extremely hard to operate

When you see how hard it is to layout a single font, you understand why pdf place letters one by one on the page in order to have guaranteed identical content on all readers

If you responded to me, then I didn't get your point

Partially 😅 we were discussing how pdf don't always contains the text itself. I saw your wish for zipped xml instead of pdf as a way to get this: the ease to extract text. My point was that pdf can't be like docx and guaranteed identical everywhere I think...

No, ease to extract (and place back) binary streams, especially images. I don't care about text, because it can be copied from pdf viewer, and, more important, text is not the thing that can be optimized externally

It's not much different than extracting (demuxing) subtitles and audio tracks from a mkv.

Question is not only about extracting, but about replacing. Just for example - lossless jxl was created by somebody, who cares about speed only, and uses -e 1. It can be recompressed with lots of savings.

test if this works on a browser that doesn't support JXL, like stock Chromium or something

it could be doing it on-browser

although Meta is known to be a supporter of JXL so maybe it is serverside

Just tried, it just sends a file, no preview.

If you upload it from the ios photo picker then I'm pretty sure the picker transcodes it to JPEG like it does with HEIC

updated adoption? labconut's android gallery decodes jxl since 2.1 and 3.0 (with newer jxlcoder decode library from awxkee) went stable https://github.com/IacobIonut01/Gallery anyone can check how it works?

Dolphin is KDE's file manager ( https://apps.kde.org/dolphin/ ) can see JXL thumbnails even on Windows in latest release: https://cdn.kde.org/ci-builds/system/dolphin/release-24.08/windows/

doesnt work for me, just crashes

happened here too on android 14, thought it was an issue on my side

fossify gallery supports JXL now, should be next release

Meanwhile Windows 11 still does not support JPEG XL.

Animations as well, or just still images?

anyone built a nightly for fossify? could be handy getting any lowhanging fruit implementation quirks identified and resolved before a release

I don't see any updates on F-Droid. Version from April is still broken (shows blur when opening jxl).

lot of transitional adoption woes could be resolved with nightly binaries and unofficial builds - code going into upstream is only the ideal outcome but should not be the only way

between no binaries and no sources of existing jxls ('generate your own') its an endless chicken-egg mess

stills

I posted a build a while ago, on phone tho

is this the same code? 2 month old build though iinm

yeah, it doesn;t have some of the newer commits, but they were all just translations updates

well and one minor dep version bump

i recall seeing a reference to jxlcoder 2.2, is 2.3 a negligible dep refresh?

I dont believe there was a bump in that, Im not seeing anything in the commit log

ah the library itself had a bump, it didnt get pulled into fossify

seems like a bump from libjxl 0.10.2 to 0.10.3

on android10, builds loads in some way all jxls i had in a test folder (thumbnail and image, native jxl and reconstructible). rotating and resizing bring java error message or silently stop. alpha's fine, no animation. large images seem to not decode in full resolution (noticed jaggies in whats 20mp clean art)?

https://github.com/mozilla/standards-positions/pull/1064

sooo, ~~jxl-oxide?~~

But a rust implementation already exists ! 😄

`Rust decoder from the original team`

it seems like an odd distinction, but im assuming they simply want "officially supported" or something

research before suggested a from scratch rust decoder would take no more than 2 months. starting with jxl-oxide would save lot of effort and time

if it just means "which have a seal of approval" from the main team, jxl oxide have it, let's go to production !

lol immediately locked

not a fan of conditioning adoption to rust code since a working integration of libjxl already exists that needs but a few patches added to nightly and enabled by default there

they know lmao

is it nobody talking or everyone silenced...

they locked it ahead of time

realistically, I understand firefox not wanting any more C/C++ deps shipping, since firefox is already a massive security nightmare

Because of lack of interest ©

Nice to see that this news is now out in the open, I was having a bit of a hard time keeping my mouth shut about it 🙂

something I gotta wonder is if it's even worth it to write a new rust decoder or just use jxl-oxide since as far as I understand jxl-oxide is really mature

haha I would assume

related: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287 https://github.com/web-platform-tests/interop/issues/430#issuecomment-1811972676

jxl-oxide is fine in terms of conformance, but I think <@179701849576833024> has some ideas to get better performance (ideas that also require some improvements to the Rust compiler, iirc)

interesting

I mean it's not like my PRs are secret 😛 https://github.com/rust-lang/rust/pull/129881

Not sure if the license of jxl-oxide is compatible with the Mozilla license

I am fairly sure it is, it uses the standard Apache+MIT that rust itself uses and that was set up by mozilla initially 😛

I forgot why we switched to BSD at some point, I guess it was not because of Mozilla then

Tirr's right here if anyone wants to ask about licensing. But if it's MIT license then it couldn't possibly be more permissive and unrestricted for anyone's needs

yeah jxl-oxide was critical to the rust ecosystem since the only maintained libjxl bindings/crate are gpl'd

<https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287> so is the decoder already being developed for some time or just started right now, after approval from mozilla?

I said this in the other channel already but mozilla's take seems really arbitrary. Why the specific qualifier "from the original team?" Why is rust more suitable compared to wuffs for example? https://github.com/google/wuffs

A rust implementation would be less useful than a wuffs codec that compiles to C

Yet another rust implementation, that is

firefox has been pivoting hard to implementing as much as they can in rust, they probably want some semblance of homogeneity in their codebase

That's baffling that they want a second one

I doubt firefox cares as long as it's "officially supported"

because mozilla uses and created rust and it's more widely used than wuffs

C code would still give them homogeneity...

not really, the vast majority of firefox code is rust, and increasingly more so

tldr on wuffs (at least IMO): I have not yet seen evidence of wuffs being a good language to write something more complex than PNG, and the safety properties of wuffs come from its compiler, which receives orders of magnitude less attention than the rust compiler

What's the difference between an official real certified person and a fake person?

one has a degree of certainty when it comes to support longevity

I hope one day I get to be a real boy too

~~get a job as a rust dev and maybe they will consider you one eventually~~

xD

I wish I may I wish I might have this wish I wish tonight

No, being a rust dev doesn't make you real enough cuz otherwise tirr would be real

I think you need a fairy godmother

but yeah, in the end I don't blame them, I actually rather support it since media codecs have had a history of being a pain point for security, Im just curious what decoder will come out of this, jxl-oxide, a fork of jxl-oxide, or something new entirely, in any case, i'm fairly anticipating it

in the end, they need the level of support behind it

most likely because it will be maintained by someone from google and the original creators of the format and not by some volunteers who do it for fun and may not have the interest or resources for further support or fixes

I know from previous jobs, that implementing something like jxl-oxide would be a hard sell unless I could convince management to sponsor tirr or someone else to work on it

JPEG XL

Wuffs seems to have more safety guarantees and it's unable to allocate memory for example. It's a lot more simple than rust so I don't think having less scrutiny is necessary a problem compared with rust. Although whether more complex codecs will be practical to implement, remains to be seen, as you say

At the end of the day Google Research Zurich and Cloudinary could just add jxl-oxide to the libjxl project and source tree and say it's another reference decoder

ʲᵖᵉᵍ ˣˡ

-# jpeg xl

I don't think there are bad intentions on Mozilla's side here, it's just that they know there are libjxl core devs who would be willing to work on a high-performance Rust jxl decoder. Whether the best starting point for that is jxl-oxide or not is a technical question and doesn't really have any implications one way or the other for the merits of <@206628065147748352>'s work. It was an impressive accomplishment in any case to create the first fully conforming independent jxl implementation.

We already added jxl-oxide to the official JPEG page on jxl: https://jpeg.org/jpegxl/software.html (that doesn't make it official reference software but it can be considered as a milestone in terms of conformance/completeness).

I comment I found elsewhere on the topic of the libjxl devs making a Rust impl 😄 > I just hope it will not be as hideously complex and unsafe as the C++ one if written by the same people

from a ex-corp standpoint, the issue is, if tirr goes offline for whatever reason, now we have to support it, and it's better to just not support it at all, ofc this is an issue with many libraries, but libraries developed by independents get scrutinized hard. "hobby" projects by independants are almost never used, "professionally developed" projects by independants are used, but hesitantly so

ofc I can't say for sure this is moz's reasoning, but it's been the reasoning of pretty much everyone I have ever contracted with. so the pattern is strong

but at least this is some progress, even with a completely new decoder, also there are many other companies who think that something on rust is automatically good and safe

it may not be "automatically good and safe" but it is automatically better

If the Google team started officially contributing to jxl-oxide, then Mozilla would presumably accept it. So the question is simply whether that is desired. Is it the best option from a technical PoV? Is Tirr interested in being the maintainer for such a project, or to give the project to someone else? Etc.

well that comes back to if they even want to go that route. > jxl-oxide is fine in terms of conformance, but I think veluca has some ideas to get better performance (ideas that also require some improvements to the Rust compiler, iirc)

<@179701849576833024> so, friendly question, are the plan to have a nice and sound jxl decoder in rust, or to have something crazy unsafe and messy? :p

Regarding recent Mozilla news - is jxl-oxide coming to Firefox?

dunno, read up,

Guess 😛

Well, considering the fact that you seem like a competent Rust developer, I'm gonna say, probably very sound and nice?

Probably a higher rate of unsafe blocks than most projects *if needed*, but presumably well checked.

https://github.com/google/rbrotli-enc

I'd expect not needed

But working on it 😉

(rbrotli-enc was sort of the first proof of concept that you didn't need that much unsafe for fast code)

I wonder if the reference jxl encoder/decoder was written in Rust if it would be more adopted nowadays.

https://tenor.com/view/rust-rust-lang-ferris-programming-jarvis-gif-7441835028842397805

I don't wanna look like some rust fan boy. It just seems that if anything is written in Rust it automatically means double the popularity

Is there no way to FFI c++ and rust?

There is, https://github.com/dtolnay/cxx

The way people treat rust differently than C++ is kinda strange and silly. It's not really what guarantees the language make but what guarantees the programmer makes. The language can only help make that easier or harder, but doesn't change anything fundamentally

there is

yeah because lots of people adore rust, and less vulns is always a good thing

But either way I think making rust implementation will help popularity.

The worst thing would be letting avif make rust version first and then Google will just say "we support avif because it's memory safe"

there is already a rust jxl decoder, and a rust av1 decoder

If i understand correctly what Mozilla said they want something made directly by jxl devs?

I wonder if next time someone will demand also encoder to be made in Rust

my company would rather have it c++ than rust

but wait, doesn't constructing those feature structs require at least a little unsafe? 🤔

I don't think that's what they said, but rather that they want x goals, and that the jxl devs are willing to help meet them

Firefox manages to do it

yeah, but you don't need *too much* of it

no, there's a rust AV1 glue around a bunch of assembly AV1 code 🙂

So it's just marketing 😄

It was always marketing

[av1_kekw](https://cdn.discordapp.com/emojis/758892021191934033.webp?size=48&quality=lossless&name=av1_kekw) yes, indeed xD, though I do think rav1d can be compiled with no ASM, i dunno how usable it would be \

I could test actually, after im done updating I think I will see how fast/slow it is

Pure ASM implementation of JXL?

now THAT would be fast

dav1d is exactly that (some c just as a wrapper), but jxl is mostly not slower even without a pure asm decoder <:KekDog:805390049033191445>

Could JXL get better performance if using pure ASM?

i think so, if optimized properly

in theory nearly everything can, but it's typically not worth it except in performance-critical areas

namely because it's challenging to write performant asm and even more of a pain to maintain it

https://youtu.be/a4uretCJh_4?t=120

Odd timing too, since I mentioned it earlier today (Or at least the old offer about making a rust decoder within a few months for browser support)

with Luca doing it, it'll probably just be a couple weeks

isn't there already a rust decoder?

https://github.com/tirr-c/jxl-oxide

https://discord.com/channels/794206087879852103/803574970180829194/1280625902165819476

Along with them wanting it from the original team instead of a single person

well it's unlikely it's going to be rewritten from scratch, even if it is adopted by the <:JXL:805850130203934781> team

and oxide has several contributors

in any case I don't buy the whole "Oh we're lacking a rust-based decoder" or "the rust decoder isn't fast enough yet" argument

<https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287>

same thing I said here

yeah, it feels like this is just another failed argument for the Mozilla team grasping at straws for reasons to not include JXL support

then again, maybe we'll see it implemented in a couple months, who knows? 🤷‍♂️

no, this actually makes a lot of sense, realistically speaking, unless mozilla wants to invest in tirr or another contributor to maintain it full time, it's not viable for them to implement it

well they've had more than a few offers of people willing to maintain it

well in the end, that's what this really boils down to, the jxl team has reputation and backing, so they can actually be relied on to deliver. whether it's a new implementation or jxl-oxide, they prolly don't care

at least it's moving forward and not something forever neutral and of unknown status

and i guess this is some more proof that the industry does actually care

(if we needed any more)

wait mozilla what

https://canary.discord.com/channels/794206087879852103/803574970180829194/1280621586583654504

while whether jxl-oxide or Rust version of libjxl would be used for firefox remains to be seen and/or determined, it's indeed very good news to hear as it means mozilla is actually willing to add JPEG XL on the reasonable condition

seems like this enables highway-style portable simd in Rust, am I getting it right

That's the idea yep

Exactly. Conditioning jxl support on a reasonable technical condition is a huge step forward.

well the extant rust JXL implementation is just a decoder (AFAIK)

which is all Firefox needs, but as such it cannot replace all of libjxl

I guess in most applications where security is a big thing, a decoder is all you need.

in many cases yeah, it's not like encoders don't pose a risk, but does firefox even using any jxl encoding stuff in the first place?

I guess if you want to return a jxl, zune-jpegxl could be a short term solution

you know, I wouldnt be surprised if firefox's decision isn't the start of a lot of people choosing to implement reference software for things in rust

Browsers do need JPEG and PNG encoders because existing pages rely on that. For other formats they can add encoders if they want but I would not recommend doing that, or if you do, only something simple that only does fast lossless or something.

sounds like what zune-jpegxl is going for lol

JXL -d 0 -e 1-3? Something like libhydrium?

d0e1 or d1e3 or something

(I'd say d0e2 is also ok)

has anyone benched zune-jpegxl?

Are the “effort” levels standardised or are they a libjxl thing

I understand they are only a libjxl thing. Especially due to the fact libjxl itself don't uses somes features of the format yet. Nothing forbids a smart folk to do better **and** faster 😁

zune-jpegxl seems to be equivilent for cjxl -d 0 -e 1 ```ps ➜ zune-image git:(dev) ✗ hyperfine --runs 20 './target/release/zune --input ~/Pictures/ina4k.png --output-format jxl --out ina4k.zune.jxl' 'cjxl -d 0 -e 1 ~/Pictures/ina4k.png ina4k.cjxl.jxl' Benchmark 1: ./target/release/zune --input ~/Pictures/ina4k.png --output-format jxl --out ina4k.zune.jxl Time (mean ± σ): 375.4 ms ± 12.1 ms [User: 546.0 ms, System: 120.6 ms] Range (min … max): 359.7 ms … 409.0 ms 20 runs Benchmark 2: cjxl -d 0 -e 1 ~/Pictures/ina4k.png ina4k.cjxl.jxl Time (mean ± σ): 320.1 ms ± 18.0 ms [User: 302.4 ms, System: 99.5 ms] Range (min … max): 296.8 ms … 366.9 ms 20 runs Summary cjxl -d 0 -e 1 ~/Pictures/ina4k.png ina4k.cjxl.jxl ran 1.17 ± 0.08 times faster than ./target/release/zune --input ~/Pictures/ina4k.png --output-format jxl --out ina4k.zune.jxl ``````ps du -ba | sort | rg -i ina 8858079 ./ina4k.zune.jxl 8858246 ./ina4k.cjxl.jxl ``````ps ➜ zune-image git:(dev) ✗ ffmpeg -hide_banner -loglevel error -i ina4k.cjxl.jxl -c:v ppm -f image2pipe - | b3sum 91b60ec67970d1ab4d1c46da43f886d9f401ea0b1090f3b3c7f1494f46e735fa - ➜ zune-image git:(dev) ✗ ffmpeg -hide_banner -loglevel error -i ina4k.zune.jxl -c:v ppm -f image2pipe - | b3sum 91b60ec67970d1ab4d1c46da43f886d9f401ea0b1090f3b3c7f1494f46e735fa - ```

I really doubt that considering they've been in contact with the libjxl team about it for months...

I think zune-jpegxl is actually a port of the old fjxl code, so yeah

<@179701849576833024> what are your thoughts on the portable-simd effort in Rust? Does struct target feature gating interact with it at all or do you intend on figuring out a portable SIMD story entirely separate from the portable-simd effort?

The second one! Portable-simd works well enough for common cases, but highway (and thus presumably highway-rs, when I'll get down to writing it) gives you more control... Also portable-simd doesn't really have a good dynamic dispatch solution as far as I can tell

alright 👍

I wonder if someone who wants to do dynamic dispatch with portable-simd might just use the struct target feature thing. I can imagine an "all-the-simd" crate that takes your generic portable simd code and monomorphizes it for all simd targets rustc supports, and then gives you dynamic dispatch functions you can call.

Yeah, that's definitely something you could do

Good point actually, maybe I should use that to get some help from the portable-simd people

That rust implementation of the brotli codec seems to be largely assembly or intrinsics. How exactly does the rust toolchain help with that? Wouldn't C do just as great of a job at being the glue code for optimized assembly?

at least you don't have to deal with cmake or something

cargo >> cmake

so much better

wrapping unsafe stuff like assembly inside sound interfaces makes your life much easier

Who's forcing anyone to use cmake?

cargo is bloat

it's like npm

much more reasonable than npm in that count, but if you don't npm for its general attitude towards dependencies, yeah you won't like cargo too

npm is a thought-terminating cliché, not useful in discussions

(saying as someone who constantly battles with Rust dependencies at the day job)

Just keep it simple and try not to overcomplicate. C can be as braindead simple as you want it to be, no one forces anyone to use Cmake instead of just plain make. Or anything in between.

Isn't the soundness of an interface up to the programmer and ultimately not the language?

The programmer needs to design a sound interface and implementation, but with Rust, the interface itself can enforce the contract needed to actually be safe.

I am no rust expert but I don't know if learning rust magically teaches a programmer about sound interface design

In C, you design an implementation and an interface, but to actually be sound you need to provide a bunch of detailed information about the exact correct way to use it.

common misconception

rust you still end up with garbage

In Rust, something is called *sound* if it cannot be mis-used to create UB.

and you can do the same in c++

Rust has compiler time checks for things like pointer ownership, but based on my admittedly limited knowledge, I doubt that will make a programmer have any better foresight or skill at organizing and structuring a software project and designing reasonable interfaces.

incorrect

At the end of the day as far as I know a language can only help make your job easier or harder but it can't make people suddenly good at design...

You can certainly make things in C++ that have way fewer footguns than C, but it's never hard to end up with UB in C++.

and i dont think it's hard for rust either

well no one said that

if you're using sound stuff, you have to use `usesafe {}` yourself to do it, which makes it pretty obvious you're doing something potentially dangerous.

It's good for a language to have compile time checks and to help prevent accidental mistakes and make it harder to forget to dot your i's and cross your t's for example. But someone who has no skill at planning and organizing or what features an api/abi surface should have, won't magically have skills they had no talent in before

I don't get the UB argument

you can still end up with garbage even without unsafe

from my limited time using rust it seemed the same as any other language

UB is usually unintended and it's good for a toolchain to detect and alert the programmer about it

hype appeared to be all marketing

probably not a good place to discuss that anyway, but you will need some concrete example to strongly say that

i mean bad code in general

this

if I want to write a bad code I can do so for a very long time, but we normally don't bash a language for the reason that one can write some bad code; we bash that when I want to write a good code but language doesn't help me and keep me eventually writing a bad code

Tools exist to help make our jobs easier. You still need to come up with the plan. Tools can't tell you the plan or make you better at constructing ideas, they can just make it easier for you along the way.

A good programming language can only and only needs to make it more easy and convenient to debug software.

C has a lot of shortcomings and let's say low-hanging fruit in that department, you can improve upon C but I would be surprised if a programming language could actually make programmers better at designing thoughtful and practical interfaces... Maybe if it required every possible error condition to be annotated and accounted for... undefined behavior, overflow, etc

The main issues with designing an interface is handling errors and maybe reading/writing/(de)allocating ranges of memory

But mostly it's the lack of explicitly knowing how every possible error condition will be handled

> Tools can't tell you the plan hey chatgpt, how should i plan this out? 😄

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

If that was true, the supply chain attacks from ... devs wouldn't have been an issue in npm.

Effort is not standartized, but it's not a libjxl thing. Even PNG encoder in Photoshop have effort levels.

Even "professionally-developed" libraries like OpenImageIO does not have basic stuff like animated PNG support.

this is because npm is a cluster fuck of crappy intertwined dependencies.

everyone I know is trying their damned hardest to avoid it like a plague

I know the concept of effort is not JXL only, I was specifically talking about the scale that libjxl uses

> Over the past few months, we’ve had some productive conversations with the JPEG-XL team at Google Research around the future of the format in Firefox. Does this mean that eventually chromium might adopt JXL too?

they will eventually, but google research =/= chromium team

with firefox supporting it, chrome will be the only major browser that doesn't, and that will force them to

you say that like it doesn't have more than half of the browser market share: https://upload.wikimedia.org/wikipedia/commons/7/7f/StatCounter-browser-ww-monthly-202312-202312-bar.png

yeah that's what i'm thinking

Edge also doesn't support it and that has more market share than Firefox

doesn't really matter, yes, it's a "minority market share" but implying that firefox has no market power is wrong, I mean just look at how long chrome put off the manifest changes. they still have over 150'000'000 monthy users which is not insignificant no matter how much anyone wants to downplay it

sure but Safari supporting it is still a way bigger deal, and that happened a while ago

safari can be ignored because apple is apple lol

...it literally has more market share than Firefox, Edge, Opera, and "Samsung Internet" *combined*

doesn't matter, safari does have "sway" but no one cares if safari implements a feature that chrome doesn't

Apple does random stuff all the time

that's the whole problem

what are the chances of Opera getting <:JXL:805850130203934781> support?

...or Edge, for that matter?

no idea,

I suspect Edge will only follow what Chrome does, so the odds are next to nil, but I could see Opera following Firefox if they implement it

possibly, but chrome really doesn't like it when people can go "oh this browser doesn't support X, just install this browser instead"

Brave might just to spite Google?

yeah but end users don't give a shit about JXL, present company excluded

And website will just fall back on AVIF or WebP

that's not true at all any more, my mom has been sent multiple jxl files from my sister lol

If it’s not more widely supported people will see it the same way as HEIC or WebP

The format that you will just convert to something else

okay well I'm sure your mom being sent JXLs from your sister will make Google implement JXL in Chrome...

people are now actually sharing jxl images now which is fairly important

literally both of them are normies

the point is, normies are sharing JXL images now

THAT will get chrome to implement JXL

Then why is your sister even using JXLs? Apple?

[av1_yep](https://cdn.discordapp.com/emojis/721359241113370664.webp?size=48&quality=lossless&name=av1_yep)

they tried that with HEIC/HEIF

look where it got them

heic was patented so no one could implement it

well not without paying anyways

true, but even without that hurdle I'm not sure Chrome's team will care

I doubt chrome even cares about cost, seeing as they did actually wind up implementing hevc support

Also HEIC is the really only an Apple thing

Firefox adding support will certainly help JXL's cause though, especially if it does get people to switch to Firefox over Chrome

More companies support JXL

but, well, *no one* outside of a few specifc apps really supported HEIC, practically everything outside of chrome and android are beginning to support it

Most people don’t really care about image format politics

~~inb4 windows support will never natively land~~

no, but if apple users send you images and you have to view them in Firefox instead of Chrome, it's possible it would get them to switch browsers

and nothing annoys Google more than ~~adblockers~~ people leaving Chrome for other browsers

Edge and Opera are both Chromium, so they might as well just fall under Chrome too

speaking of adblockers, watching everyone leave chrome, haha flag go brr

ah yeah, then Opera would only get it along with Edge and Chrome

I did consider messaging their slighly insane social media guy but doubt it would do anything

well, probably not anything productive

With firefox and safari, it would be 66% of all active browser engines supporting JPEG XL.

Edge does different stuff than Chrome sometimes. So the chance is not zero. Meanwhile, Opera, Vivaldi, etc, are all zero percent chance.

I love how google chrome is pouring gasoline on themselves with the whole manifest v3 fiasco

Gives me warm and fuzzy feelijgs inside :)

they took down LTT's de-google your life part 2 video

I'm fingers crossed that ff will not do the same, just as they do with everything from chrome

the funniest part about this is you get another year via corporate flag, easy to toggle, and it's not like mv2 code is going to get nuked any time soon

not me, I want both firefox and chrome to crash and burn as soon as possible so stuff like servo can get more support

There will be years of no-internet then

webkit?

why?

it talked about adblockers

there's a reupload though

that's prohibited on YT?

What browsers are based on it?

nah, alternatives are remarkably close

<https://www.youtube.com/watch?v=edbaR-HWVXA>

I don't actually want to watch it

just curious what excuse they used to take it down

"Community Guidelines"

but I don't recall that being prohibited on YT 🤔

so "we don't like it"

technically ad-block is against YT's ToS so showing people how to adblock may fall under the same category?

im pretty sure adblock stuff is against their stuff

sure but I didn't think it was in the ToS

I mean, on the one hand, I hate LTT, on the other, it's still a bullshit reason to remove a video

i need sleep

same 👋

gonna get my computer to batch convert JXLs overnight tonight

Well, it seems that only Safari is using it. So no, it is not a replacement for ff for me

speaking of that, I updated my mock up for a "gui batch converter", this time i pretty much just redid it entirely in slint's new gui editor, almost

https://cdn.discordapp.com/attachments/673202643916816384/1281042859562242079/clipboard.png?ex=66da47a2&is=66d8f622&hm=d66f53f81f93c6e694769d864a175432611d16397935db064cac904a400f7fbf&

only required a bit of code to actually get vscode to recognize it as a slint file

am I missing anything important? if not I think ill try to make a python and a rust backend to this for fun

A faster decompression setting and maybe a check box for `--brotli_effort=11`

For me, a good batch convertor would make a clear separation between lossy / lossless / jpeg conversion. And offer very different options depending on this preliminary choice (including the type of files to process)

for example if you select jpeg conversion, you get almost no choice, the batch apply on .jpg by default, no quality settings, etc.

yeah I was thinking about that, also having a tickbox for `progressive_dc=1`

Maybe have a warning about higher memory usage at e10, progressive_dc, jpeg reconstruction, ect. When lossless is chosen those disable the chunked encoding

For lossless jpeg-to-jxl it's important to verify by converting it backwards then comparing file hashes, especially if the original is being deleted

especially since it takes basically no cpu time to do so

it's like why wouldn't you

Safari, GNOME Web

Well, both are not usable for me

I could use some help here maybe https://github.com/nginx/nginx/pull/125 just keep in mind this is related to web servers and web browsers so **please** don't list off random unrelated software or hardware that has JXL support

> Thanks for the submission. However it's not clear whether the format is widely supported by browsers. Wikipedia says this: > > Support for JPEG XL in Chromium and Chrome web browsers was introduced for testing April 1, 2021[72] and **removed** on December 9, 2022 - with support removed in version 110.[73][74] The Chrome team cited a **lack of interest from the ecosystem**, insufficient improvements, and a wish to focus on improving existing formats as reasons for removing JPEG XL support. I did say we should update the Wiki page with all the recent info... Especially moving the Apple support into the same section as the Chrome removal, since currently you see the removal first and assume it's dead without expanding the category below it

why is there even such a high bar for adding a single line corresponding to an officially registered mime type

the cost of merging this seems minimal

I mean, bmp is in there

who uses bmp on the web??

Thinking about it, would a JXL being served with a PNG MIME impact progressive loading at all? Yesterday I was trying to view some of the old HDR test files in Waterfox and noticed they were almost all popping in instead of acting like the transcoded Jpegs they are, opening the inspector revealed them flagged as image/png instead of JXL *but at least not octet-stream*

The avif/webp team

Yeah, what about them?

That was a quote from the Github issue

People don't realize its not even the "chrome" team but specifically the "chrome codec team" aka the on2 vpx team or the webp/avif team who is claiming that there's "not enough interest" in jxl... as if they held webp or avif to the same standard.

The staggering absurdity and hypocrisy is missed when just calling them "the chrome team"

servers dont serve to just browsers but nowadays predominantly to 'apps' (if just through cdns). even if browsers ceased to exist, server software should still support notable mime since it will be consumed directly without a browser middleman

about browsers, there's Cromite

cromite is the continuation of Bromite and more popular than thorium

didnt cromite remove support temporarily?

temporarilly, doesnt change the support

well, if it's indefinitely temporarily it does

lot of stuff is disabled for a while until upstream's change is researched some more

I felt worried it could be used as auguring point if Cromite was looked into by the nginx folks and they found JXL support disabled which is why I didn't mention it

afaik one can build cromite himself with jxl on, its just the official distribution that temp disabled in its own builds

the app support doc needs massive updating. its nuts to require a cla and email made public for mentioning adoptions

about support on *mobile* (as tracked by caniuse), the 4 biggest mobile markets (us, uk, can, japan) have 30-39% support now (from iso and macos alone)

mobile per country is a meaningful stat worth keeping an eye on as those are large markets with strong domestic web ecosystems (ie regional sites or apple-dominated workflows)

modern formats are mainly consumed through a cdn anyway (nobody ever uploads webps after all lol)

There's absolutely no reason for nginx to refuse to add a mime type for jxl. It's absurd. They have a mime type for google earth and rar, but not jxl?

That's insane

main dev/founder who did all the carrying recently left. freenginx and derivatives would likely add it with no issue

image/x-jng is there too

I have never in my life ever seen a JNG file

apps like shopify could probably benefit from mime addition too - servers dont serve just browsers and the average netizen uses multiple on every device they own

Shopify already has their servers properly configured with the JXL MIME type from what I understand

maybe it fails to serve jxl in priority in some circumstances (does it serve jxl to its own app?)? personally i think jxl should always be the highest priority when decode capability exists, then other formats. change begins with helpful defaults - if everyone always served webp as the first format, no other format would ever get a chance at reach

nginx adding JXL to their default config would just benefit servers that don't manually add JXL to their config (which is a lot of servers). some examples being jpegxl.info and jpeg.org

iinm 'lemmy-powered' websites support jxl through pict-rs since v5 iinm. theres a few hundreds of those born from reddit sucking

only a few lemmy apps decode jxl for now, others dont load a fallback

lemme confirm

I understand the hesitation when it was provisional, but now it is as official as it gets. Is there any reason to not add an official image/* IANA media type (that's not prefixed with "vnd.")?

image/jxl is what most things use

Not sure what’s wrong wit it

It’s official, https://www.iana.org/assignments/media-types/image/jxl

What reason not to add

It has `application/java-archive`, `application/x-stuffit`, `video/x-mng` and even `application/vnd.google-earth.kmz`

Not having `image/jxl` actually breaks websites, unlike those other ones.

Well, maybe "break" is too strong a word for this. But it's certainly more consequential.

The most annoying thing is that if you do "open image in new tab", it will just download the file instead of showing the image

is there a way for interested parties like companies to obtain some form of commercial support? like participating in large migrations, adding decode support to specific apps

Isn’t this FOSS?

Why would they need a commercial ?

asking not for myself but similar concerns pop up. its a very new format almost noone is familiar with or integrates properly

Cough cough, adobe

well i said commercial since its a familiar method of guaranteeing progress. also its libjxl and other libraries thats foss, jxl is a spec and image format

Oh I misread, commercial **support**

adobe has dng sdk but i doubt they bother with but the biggest customers. even samsung botched its dng1.7 support in gallery and cameraraw

what i meant was, whats the solution if anyone wants some form of guaranteed support in their apps thats not 'figure it out on your own'

> integrates properly

foss is funded by commercial entities. FOSS is free, work is not

Also <@198765865494118401>, since we share the server, I made an issue a few months ago :P https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1562

awesomesauce :>

https://review.lineageos.org/c/LineageOS/android_packages_apps_Glimpse/+/392231?tab=comments > We will think about this once Aperture gains JPEG-XL support (we're waiting for Google)

well this sucks

also still obsessed with that damned hyphen!

xD

can we take a second to appreciate "we want our own apps so we aren't tied down by google, but we are going to wait for google for everything regardless"

i guess it proves "industry adoption" ?

it's a FOSS format, shouldn't they be all for it?

Seems the source of spreading that hyphen is Apple

The WebKit team knew what they were talking about

update on this. it seems like nginx is now planning on having **all** IANA media types which includes `image/jxl`, so uh I guess JPEG XL support is planned on coming to nginx after all? although due to them trying to include every single MIME type they are now getting conflicts between some of them and are unsure of what to do exactly yet. https://github.com/nginx/nginx/pull/145 (this pull request is official and not from someone random)

so uh nice to see them trying to do something about missing media types although this kinda seems like a brute force approach

although if they sort out how to deal with the conflicts then this would mean nginx will support whatever media type you can think of as long as it's registered with IANA

neat I guess

Is it based on file extension, or magic number?

https://github.com/nginx/nginx/pull/145#issuecomment-2343697998

https://www.macrumors.com/2024/09/09/iphone-16-pro-supports-jpeg-xl-format/

Not sure if posted already

But I guess the code is still there

<@703028154431832094> https://discord.com/channels/794206087879852103/822105409312653333/1283141538708455465

Second half of 2024, PTGui is introducing... JPEG2000 🤦‍♂️

after JPEG XL! https://ptgui.com/versionhistory.html#:~:text=Version%2012.24%20(5,LightRoom%20and%20Photoshop%2E

Only jxl-in-dng, because otherwise they will immediately fail on new ACR\LR files. Jxl as input\output format.. maybe in 2034

I'm really curious, who decided to use jpeg2000 now?

maybe jp2 codecs improved to the point it makes more sense to implement now

I still see jp2 distributed in pdf

Yes, because there is no choice for color images, only jpeg, jpeg2000, or 'png'. But for application that is not limited by format specs starting using jpeg2000 in 2024 is.. strange for me.

jpeg 3000 when?

It would be from google, anything to not implement jxl

XL is 40 in Roman numeral so JPEG 2000 should be much more advanced

but 2000 in decimal is 54, so not too much advanced

So someone got the idea much earlier

https://github.com/apache/httpd/commit/b5e9884a48f72cdfeddc60b121a24560ef8b88a9

Merged into Apache

im guessing this has probably been posted before

<message deleted>

I just want to add, that although Mozilla says they are worried about multithreaded c++, there is no reason for them to use libjxl's multithreaded code, since I _think_ the threaded stuff is separate, and there's almost no reason for a web browser to use more than 1 thread per image anyways

Browsers are more likely to decode multiple images in parallel, one thread per image, rather than a single image in parallel, with each image hogging all cores

Less RAM use that way too

our multithreading is also quite straightforward, basically a “parallel map” that is used where appropriate and which has been thoroughly tested by now

it’s quite unlikely that we have race conditions in there

it’s not like we’re using manual threads everywhere with inappropriate use of shared memory

tbh threads are not the part that scare me in ~any compression-related C++ codebase

fossify gallery updated its jxlcoder integration to 2.3.0 - no newer stable build yet, anyone got a nightly apk built ?

This was another hard release, it took a while. So I'll send here. ~~Mostly just me being a dumbass that is too busy~~ https://github.com/Eclipse-Community/r3dfox/releases/tag/v130.0.1rc

Oh I suddenly thought of Windows Vista or newer

Seems Photos in iOS 18 can display JXL with no background correctly, but the File app embed it with a black background

Do you think we'll see phone camera apps getting an option to shoot in (non-raw) JPEG XL any time soon?

I sort of expect Google Camera (the one used on Pixel devices) to be one of the first to support it, as they've been pushing innovation in their camera app pretty well

that one is going to be avif

or just gainmapped JPEGs

(it's over)

I haven't really heard much about interest in AVIF for general photography, mostly just web delivery, but I could be wrong

JPEG with gain maps is what they currently do for HDR yeah

google camera.... android...

they HATE jxl

they will do anything to avoid it

I already have a ton of these gainmapped jpegs on my phone already

Android support ticket https://issuetracker.google.com/issues/259900694

Just thinking about converting these jpegs to a proper HDR format is giving me a headache

As far as I know, there's no software for that, future proofing be damned

Do they hate JXL? Google is the king of "the left hand doesn't know what the right hand is doing" and it seems like only Google Chrome doesn't like JPEG XL, the rest of google likes it from what I can tell? Or at least doesn't dislike it

isnt media codecs team the same one for android and chrome

The only sides we've heard from are Google Zurich Research (The devs here), and the Chrome Codec team who removed it from Chrome

> "The left hand doesn't know what the right hand is doing" That's honestly a perfect description of what's going on right now

If it's any consolidation I believe Google's gain mapped JPEGs are in the process of being standardized. Downside is, that isn't going to accelerate JXL support