JPEG XL

So a color that is for example very bright red and a little bit of blue would not be representable, since the gain factor would have to be large to get the red but then a nonzero value for blue would also become larger than desired?

It's a nice compromise for a transition period where most displays are still SDR so at least you can control the tone mapping and efficiently get a tone mapped image...

But I wouldn't call it "Ultra" HDR

It's more like "compromise" HDR

MediumDynamicRange :P

according to the android docs, the gain map can be single channel or multi channel, but the rest of the document assumes single channel. unsure if that's because that's the norm, or to simplify documentation...

"better than nothing hdr" doesn't sell, i suppose

(seen in Mozilla Connect) I hope they would at least merge remaining patches in Nightly

is there a need to do so? I believe the patches still apply except for maybe 1 line

yeh someone else can do it

the only issues that are present is no/broken HDR support (there was never a patch written for it) and also color handling doesn't conform to the apparently broken/wrong handling that all other image formats in firefox/gecko conform to which leads to JXL images with no embedded profiles looking different to all other image formats with no embedded profiles

AFAIK, JXL images can’t not have an embedded profile – can they?

they can have ICC profiles inside them right?

I meant ICC when I said "embedded profile" as I assume it means the same thing. EDIT: I misread what you said.

they can't have no embedded profile

it doesnt conform to being wrong because it can't

ohhh I understand now

my understanding of color handling and other related things is very poor

Does someone who is familiar with the issue explain it?

there was a small discussion about it a few months ago: https://discord.com/channels/794206087879852103/794206170445119489/1091589188937334934 https://discord.com/channels/794206087879852103/794206170445119489/1097782188449222726

^ first message is me curious about it and posting screenshots while the second message is the start of the discussion

honestly some of it went over my head as does a lot of color related things

ff has a different behaviour for image files with no color profile. JXL image files always have a color profile

There was some folk who ported it to waterfox. Maybe they can volunteer?

jxl defaults to jxl srgb

there isn't really anything to be done in that regard as the port to waterfox only changed a single line to conform to more recent firefox changes

it was me and <@146411656174501888> who did the pull request for waterfox and we really didn't do anything besides checking if it works and submitting a pull request

hi

it assumes untagged input is sRGB and prints a warning

then does what it normally does

Current Krita nightly (5.2.0-prealpha) have basic JXL layering export/import capabilities now 🙂 : https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ (should be available for other platforms too) Albeit only works with normal and *experimentally* addition (`MULADD`) blending mode while the rest is coalesced on import. Additionally, it can also retrieve image with original ICC profile when it's in XYB.

Hopefully it fixes the import errors I've had occasionally with JXL files too

Awesome! Even works with CMYK test

Is it possible to import a lossy jxl, add a lossless layer, and export without the lossy layer being recompressed?

I imagine Krita just converts to and from pixels

technically yes, layers are encoded independently so you could add/remove layers without touching the rest, in principle

but to make a library api / tooling for that... ugh

but yes, in principle you could have an api for "insert frame number N from this other jxl bitstream now, without touching it, into the jxl that is being encoded"

I think some photo editing software has support for using layers to represent some non-typical resource like an already compressed file. But yeah the libjxl side of things may be annoying.

It's a feature I've always wanted with layer supporting formats

Maybe I'll have to learn C++ so that I could contribute this feature...

I know my Krita files use PNGs for layers, it'd be work but could split the JXL layers and store them separately, merging them on export. That's with a lot of assumptions though

Actually... I wonder if I could convert all of them into JXL and edit the .kra file to still read them

Known issue for now: opening files with spot channels can trigger infinite loop.. >< thanks <@736666062879195236> for reporting!

May I know which file in particular? Last time I got an error is when opening xyb cmyk~

||I did not expect to see a great kemono artist here <@274048677851430913>, i love your work||

<:hagUuh:1039211741277589584>

wha- thanks~! xD

<:hagYes:1039211737532092437>

It's happened a few times over the months of messing with JXL, but I'll let you know next time it happens or try to reproduce it later. I know when it did happen changing settings did nothing, so maybe it was getting labelled incorrectly as unsupported or something

alrighty!

Well that was fast, first photo I tried errors out. Here's the original jpeg so you can try converting it yourself, refused to import whatever options I used (lossless transcode, lossless, lossy, reconstruction data removed) and even on the latest cjxl from Github Actions

it seems to import just fine on me, I'm using libjxl 0.8.1

oh it fails on Krita 5.1.5, seems like it got fixed on 5.2.0

Alright, so I'm not insane but it's already been fixed too. Guess maybe it was more than just xyb cmyk that was affected

it was failed on getting the box type, I do pushed some fix regarding that bug some time ago~

Ahh nice, wonder why some files still worked at all then... Very odd

~~oh found it, the box type was `exif` with lowercase e, in Krita 5.1.5 it was hardcoded to detect `Exif` with uppercase E as defined in libjxl docs~~ scratch that, it was correct uppercase E

how do you do this? libjxl can't, iirc, unless you request it in some space like sRGB and then call a CMS engine yourself

roughly yes, requesting it as F32 linear sRGB so that the out-of-gamut color are preserved and converting it back to original profile using CMS, in krita's case it's using lcms2

kinda expensive as it involves an extra conversion step and extra F32 buffer though

What formats does Blender support as export format for rendering (or as input format for textures)? It would probably make sense to add jxl there, especially since I imagine HDR and fast lossless are pretty useful in that use case...

I don't know the full list but off the top of my head they have: - PNG - JPEG - EXR - WebP (this was added somewhat recently)

JXL support in blender would be great to have

and If someone submits a full patch to add support there is little reason for them to decline

would be cool to add jxl (and layered jxl, I guess?) to that list

Yes yes yes

I don't think that Safari is relevant, but native macOS support is worth mentioning in the issue

Also animated jxl during animation export

oh, how about Ren’Py support?

as far as I can tell, it’s largely the dominant engine for visual novels

https://github.com/renpy/renpy/issues/3865

Visual novels use manga style. Did JPEG XL improve in that regard?

that depends on the kind of visual novel, I’ve seen quite a few use 3D renders

that’s actually why discussing Blender made me think of Ren’Py

jpeg xl don't perform well with anime style pictures ? I didn't feel like it does...

maybe multipage image for portraits would be useful

jxl does great for lossless anime and not bad for lossy (much better than jpeg), just not as good as avif

i don't think visual novels use very low bitrates with enough bitrate jpeg xl can also be better than other formats (though still needs some tweaking to avoid edge artifacts), avif tends to smooth out and lose fine details/textures even at high bitrates and anime like images also jxl has better lossless

I wonder how lossy modular fares against vardct on manga

3.6 bpp

imagemagick says q94, 4:4:4

for something like Blender, it would probably also be a good case for using synthesized photon noise...

What lossy modular artifacts look like?

I don't know who is the author of IrfanView JXL plugin, and all related reddit communities are private now, so maybe somebody is in touch with him? Plugin requires update, but the latest version available on the IrfanView site is built in october

It is told there that author of plugin does not visit this forum, so probably no luck there

I do not know

There is a thread on Blender's suggestion board about adding it, but the people who noticed it were not very ecstatic in favor of it, for quite honestly extremely pitiful reasons

But the idea of jxl being a supported texture format so you can have all texture types in a single file sound incredible

And exporting a render as jxl would also be nice, although I do believe an addon for that could be made

I mean, it had 90% approval rating

more specifically:

Probably he is using some old Photoshop

> but i guess im stuck with avif so no direct (without ACR) support for avif in PS does not bother him, but for jxl it becomes an issue > im dumb thats all At least honest to <@456226577798135808> no, there is no difference between avif and jxl handling in PS now, both automatically open ACR

100% it should, I believe

fun fact the person who made that plugin also made the paint.net plugins for avif and jxl

I don't think it will take a year before Photoshop will just have native jxl and avif export

And loading them already works out of the box

So, I think I finally found what it would take for JXL adoption to properly rocket.

Have dedicated cameras that output JXL, and phones that output JXL 🙂

HEIF "works"™️, but licensing, patent BS and HW encoder limitations make it non trivial to implement and use.

having a mobile gallery app that has jxl support would help a good chunk lmao

Unfortunately I doubt wb is in a state to start up a camera manufacturing company either

First of all, we need a decent gallery app with jxl support on Android

I want to take a look at it when slint or dioxus get decent android support

😂

I guess I could get Opencamera and Aperture camera(LineageOS) to support JXL?

Actually, that would be a wonderful idea!!! Add JXL support to LineageOS <:FeelsAmazingMan:808826295768449054>

I am not, but within JPEG we are collaborating with Shikino to make a hardware jxl encoder intended for cameras and phones

I briefly looked into viability of adding support in bliss and I dont think it would be too hard

Absolute majority of FOSS Android gallery apps use system decoders only. The only exception is Aves (TIFF), but they don't accept PRs.

Ahh, nice

Footprint in terms of gatecount/die area should be pretty small compared to video codecs, so I expect it will be kind of a no brainer for camera/phone vendors to add hw jxl. But it will take time, the hw design isn't even done yet...

aves doesn't accept PRs?

thats... interesting

I find it weird that Android world pretty much doesn't have any universal image decoder libraries. For Delphi there's Vampyre Imaging Library, for python there's Pillow, for other languages there's also a bunch of stuff supporting pretty much all formats. I guess there's SDL_Image, but that's for games.

Sometimes a person just wants a personal project, not community project, while still opening source code to allow forks. Perfectly understandable.

you would use the decode library associated with your UI kit, typically

one of the issues with flutter is that it doesn't really allow you to add plugins to their image framework sadly

Just noticed a slight quirk with Krita... You can set the effort and the decode speed from the first/main saving menu, but you can't set the distance/quality anywhere

They do though?

They use it through mediacodec though, so only HW accel.

Huh? I don't mean built-in codecs, I mean libraries.

java?

I like how the proposed solution for the size of the patch is “just stop gating it on a flag”

I'm not sure if Brave is gonna be able to easily use the thorium-libjxl to have continued JXL support since from what I have seen the thorium-libjxl repo is kinda a mess

also it seems like the thorium devs are also trying to keep highway up to date but is that even necessary anymore?

it's not as moving a target as it used to be

it seems to have largely stabilised

<@274048677851430913> not sure if you'd know how to add a UI selection for that, but seems like a good idea before 5.2 releases

5.1.5 didn't have any quality setting and defaults at d1 non-XYB, added that on 5.2

Ah, perfect

Oh yeah, a question (or more like a poll?) for the lossy quality setting on Krita 5.2 later on: Currently on nightly alpha, I capped the lossy quality at `d=0.5`.. is it better to leave that or should I use the same mapping that cjxl had and go further down to `d=0.1`?

Is the slider linear or exponential?

Exponential, made the curve to roughly match the cjxl. Only differs at that higher end

I think d0.3 or even lower still makes sense — not for the typical use cases though. For authoring workflows it's best to just go for lossless. For web delivery there is no point going even below d1. But for something like sharing a 'master copy' of an image, it might make sense to not use lossless (since that can be a huge file) but extremely high quality lossy so there's still plenty of precision for further editing and virtually no risk at all for generation loss.

https://github.com/immich-app/immich/commit/80d02e8a8d62b0b0738d25d9dd1b6987c1b5725d

The self-hosted image app Immich supports JXL it seems, as well as AVIF

i'd love to see transparent conversion jpg->jxl and back

i.e. upload a ton of jpegs, they all get converted to jxl to save storage and converted back on the fly for clients that can't handle jxl

I am literally working on exactly this.

Progress is slowed by not having a jxl encoder in Rust. Progress for that is slowed by my inability to read other people's code.

<:Poggers:805392625934663710>

for immich or in general?

I'm writing a hobby image server that almost exclusively works in JXL. Obviously an image server that only serves JXL is kinda useless, so I have plans to allow the client to choose the target format.

I was going to say, I'm sure someone was already working on a Rust encoder

Have you worked on the decoder?

I've not touched any real code at all

I plan on doing something similar, but transcoding would just punt the image to cjxl

I would, I would, but C dependencies are a goddamn nightmare on my dev machine (Fedora).

the use case I would be doing is just writing a png to /tmp and using cjxl binaries lol, lazy is sometimes fine afterall

LOL epic

If I was smart, I'd do the same thing. This is why I'm only a hobby software dev and not a hobby software engineer.

it is a bit better now that cjxl will be working with stdio again IIRC, the big issue is portability, cjxl isn't exactly portable sometimes so you rely on whatever server you are deploying to have it

exactlyyyyy

Do they have prebuilt binaries, preferably statically linked?

not sure

I doubt we'd make any difference since *Chromium*, but interesting wording https://creator-support.discord.com/hc/en-us/articles/14346342766743-Media-Channels-for-Server-Subscriptions-BETA-#:~:text=Our

soo, start uploading JXL on dicord and they hopefully add support? 🙂

Start polluting those event and admin guilds run by Discord with JXL <:KekDog:805390049033191445>

Suuuure

If they had a system like telegram, matching file hashes to hardlink them together, then stopping the bulk of reuploads would be easy at least. In the end there'll always be a way around it

Literally no service like this (Patreon, Fanbox, SubscribeStar, etc) has anything to prevent leaks.

Had a random thought, would it be worth adding Telegram to the list of supported programs? Because it already has massive adoption, and it does work immediately, albeit missing animation and probably some other features

Uploading without re-compression even lets you use telegram's image viewer on desktop to see the file, just a shame it doesn't work on mobile too (Although I find it funny they turn 30 byte JXL art into 130KB jpegs 'compressing' the image)

Was it changed in the second beta?

Also what's the UTI output of `mdls -name kMDItemContentType -name kMDItemContentTypeTree -name kMDItemKind FILE_NAME_HERE` for jxl files?

Thought I'd ask, could someone on the new IOS beta try opening a JXL file sent on telegram (As a file)? Usually it only works on desktop because of mobile using the device's gallery app, but seeing as the OS now supports it, I'm curious what happens

second beta? I don't remember an update since switching

We are going to release a new development version of GIMP in the near future. If someone wants to help testing, links for installers are in https://gitlab.gnome.org/GNOME/gimp/-/issues/9653

Thought I'd copy this here https://github.com/libjxl/libjxl/issues/2640

Obviously nothing guaranteed, but I'd say this gives a decent chance for Apple to add metadata support eventually https://github.com/libjxl/libjxl/issues/2666#issuecomment-1636930650

probably just clueless, it is evident that JPEG XL should hit at least 5% of the market share in any scenario possible because of Apple

iOS 17 is in public beta if you want to get in on that juicy JXL goodness on your phone.

Still there are no gallery apps with jxl support for Android

I was working on adding it to a framework, but I put it on pause because libjxl is actually kinda hard to cross compile statically

tachiyomi is a bit more specialized than a gallery but it does support jpegxl

https://bugs.chromium.org/p/chromium/issues/detail?id=1451807 Surely this needs some attention ? > ### Issue 1451807: Request: Re-open JPEG XL issue > @Reporter: Could you please provide your update as per c#4 > If there is no response, issue may get closed after 30 days > > Thanks..!

I don't think anything that goes on in any Chromium bug tracker ticket will have any impact on anything.

When it was decided to add APNG support, amount of stars in the ticket was considered. I saw a document somewhere where Chromium devs were analyzing top issues by amount of stars.

APNG support was added by Firefox in 2008. Chromium was ignoring it for many years. Suddenly, Apple added APNG support to Safari in 2014. And Chromium added support in 2017 after some analysis of top issues and noticing that they are the only engine that doesn't support APNG.

Maybe they don't do it often though. That ticket was in top 10 for many years, but they noticed it in 2016-2017 only.

I was following the related merge request and related code review. This relatively small change (less than 2000 lines) was in development and review (surprisingly) for many months (at least half a year), there were dozens commits over this period of time.

It's weird that this issue is still open. Isn't it intentional duplicate?

Not really. The original issue is about adding JXL to chromium. This issue is about reopening the original issue.

Since the original issue is closed it means no new discussion or re-evaluation. But it was closed based on outdated state of ecosystem. For example one reason for closing was not enough interest. But since then Apple added JXL, meaning it's no longer true there is no interest. And for re-evaluation to be possible the issue has to be reopened.

And how else should I request reopening of the issue other than to create new issue?

<https://jxl.moe> quick link to the original issue

I even wrote email to all the people responsible for removing JXL. No response.

I also added them to this conversation https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/q6NWLS59AwAJ

I think that's how you end up annoying them, I wouldn't be surprised if they got a lot because of the removed support in the first place

I just ask to reopen conversation about JXL in light of new events. They already flagged the original issue as "wontfix". That's basically dead end. I don't see how it can get worse even if they get annoyed.

I mean worst case scenario is they decide never to add JXL. But that already happened.

Unlikely. But even if so: they could say something publicly

<@456226577798135808> will you reply to this issue as asked there? Looks like you were added to CC early last month but maybe you did not see the mail?

it seems like they don't use discord since they have no messages in this server and are also on the old username system which means they haven't logged in for a while

They might get a mail when pinged

ok, I commented so they wont close it 🙂 https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c8

i dont understand why its such a problem to simply reopen old issue...

because politics ?

I don't think the reason is purely technical

maybe android devs will be more understanding? https://issuetracker.google.com/issues/259900694

speaking of android, hopefully media_kit will have libjxl support soon, I dont think ill be able to get it in before next release sadly tho

https://twitter.com/nekohayo/status/1682391130376208387?t=r0gRNMW2QpwEJO9Fa1c7MQ&s=19

“oh yeah? no industry support? well, look at this: we’re in **gnome-backgrounds**” 🤘

Is it better that GNOME selected 0.9 snapshot instead of released 0.8.2 ?

They changed the backgrounds to reduce filesize, makes me wonder how much better `-e 9` would've done since it seems they just did default

Would be nice to add some jxl art backgrounds - they take nearly no space

Yeah, I saw some 40 byte results in the size comparison to webp, but I assume it was just a solid color image <https://gitlab.gnome.org/GNOME/gnome-backgrounds/-/issues/29#numbers-please-bar_chart>

Does that mean Eye of Gnome can view JXL files by default now?

hasn't it been able to for a while

yeah, at least for me it is working for a while now

I think gdk-pixbuf for jpeg xl wasn't installed by default or something. But that was a while ago

In the Flatpak it works fine

0.8.2 better in In some moments that have broken in 0.9 and are still being fixed

I would wait for the 0.9 release

Eye of MATE can, so I'd presume so

you just need the pixbuf loader installed

Stupid opensuse tw. They don't shop jxl pixbuf.

ship ?

Keyboard autocorrect 😭

I already asked them. No progress

I will wait for sometime since gnome will use jxl for wallpapers, I think that will force them to include jxl pixbuf.

The reason why the JXL pixbuf-loader was not present in many distros is that it requires SKCMS in released 0.8.2 version but SKCMS is usually not packaged. In development snapshot of 0.9, the loader already uses LCMS2, so the loader is more packager-friendly. Majority of maintainers will just wait for next release of libjxl.

Found two Mac apps that support reading comic book archives containing JXL: EdgeView 3 which is a paid app ($7) that specifically touts JPEG-XL support (among many other file formats) as a feature, and Simple Comic which I think is just getting JPEG-XL support for free by macOS Sonoma supporting it. Now if only my quest for an iPad app would turn up anything...

iOS adopting new features before Android. 😞.

Considering ipadOS will natively support JXL soon, I'm certain it is gonna be a reality soon

Yeah I’m on the iPadOS beta so I’ve been searching in hopes of finding a comicbook viewer that just magically gets free JXL support through the OS in the way that Simple Comic does on Mac, but no dice so far.

just build one and sideload it

> Freeware 😃 > Arc is based on Chromium[4][5] and is written in Swift. It supports Chrome browser extensions, as well as using Google Search by default. 🫤

It says webkit on iOS. Jxl might work on iOS

Tested it, JXL does seem to work on iOS 17 beta

But I imagine that’ll be the case for every webkit browser on iOS

I think every browser has to be WebKit due to App Store guidelines

Yes, so even Chrome on iOS should support JXL

might not be the case in the future though: https://www.theregister.com/2023/02/07/mozilla_google_apple_webkit/

People have reported that even on iOS 17 beta, non-Safari browsers don't support JXL.

Just tested it myself and as of Beta 4 Firefox on iOS does support JXL.

Nice. What about Chrome?

Yep, working too

Could you make a screenshot of that? Would be fun to taunt Chrome devs by saying iOS Chrome is more advanced than the Android one 🙂

I was going to say, IOS may support it but the browsers might not be updated with the accept headers

this could be good argument. they should want to keep parity between different versions of their browser. it looks bad if chrome on one platform behaves differently than chrome on another platform

I have just updated Safari Technology Preview on Ventura and JXL support is finally working

(previously it reported jxl support to the websites, but it didn't actually work)

I mean, considering all web browsers on iOS are based on Safari, that's not hard to do 🙂

Are there any good JPEG XL viewers for iOS without having to upgrade to iOS 17? My iPhone doesn’t get that update 😦

Or should I try to program one myself for the fun and challenge of doing so

https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c15 > As the issue seems similar to crbug.com/1178058 adding firsching to cc list for more inputs. I am starting to think these people are actually bots. It seems they dont even read the issue and just react based on keywords like "jpeg xl".

what's the issue? the comment you linked is just a project contributor adding moris firsching to the CC list for this bug

that's not exactly a brainless thing to do

Linking firsching is all good, it's just how they talk about it that it seems to me they didnt even read it. what I basically write in the issue: "please reopen previous JXL issue" what they say: > Issue seems related to previous JXL issue > Could you please confirm the OS details > As the issue seems similar to previous JXL issue

i mean... this is captain obvious level... it seems to them that my issue where I directly link to the previous JXL issue and say they should re-open it could be maybe related or similar to the previous JXL issue...

Does jxl work on ios 17 outside of safari? ie the native photos app?

Yes

even better, arguably (supports HDR unlike in Safari)

the file browser was a bit buggy last time I checked, though

it showed previews correctly but would only show a blank image fullscreen

but that was the very first beta and I only just upgraded to beta 4

(after installing the beta, I opted out of the beta channel so that I wouldn’t accidentally end up with iOS 18 beta later, but it turns out that it actually opted me out of updates to even iOS 17 beta)

it does seem fixed in the latest beta, although pixels that are too bright get clipped

there seems to be no HDR->HDR tone mapping

(the previews are displayed “HDRly” but clip sooner than the full images somehow)

incredible. I've been holding onto ios 15 for jailbreaking, but jxl is too good to pass up. Seems it's only a matter of time before jxl is used for camera

This is slide 57 of my jxl overview slides (https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit?usp=sharing)

I just updated it yesterday 🙂

Should give the nightly logo a black background, since the current implementation doesn't even support alpha ;P

haha yes

+telegram on windows, linux and apple platforms

updated it

also rearranged the text a bit and added something for firefox

love the use of comic sans

maybe for firefox it would be funnier to change it to > "We are neutral" > (meaning: we do whatever Chrome does)

it's the only appropriate font for such statements 🙂

also needs gnome logo

Added, thanks for the suggestion!

https://twitter.com/jonsneyers/status/1686770495725641728

The chromium team change the status from closed to untriaged and are requesting more info. Does this mean they are considering adding JXL back into Chrome/Chromium? 👀 https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c16

I wouldn’t read too much into it

Yeah, probably different staff seeing it compared to the original

and then phoronix https://www.phoronix.com/news/Chrome-JPEG-XL-Seconds

yeah, that seems like a slightly disproportionate response to a triager not fully sure of what to do

I kinda figured it might be someone new since I'd never seen them and their history only goes back a few months, but it's still something. Even still, if there are new people involved it may eventually tip the scales. I'm sure the person was largely confused seeing a closed bug that had a massive number of votes on it.

It's getting very out of hand

tbh, when I created that issue I fully expected it will be closed as duplicate in a week 😄

but hey, maybe we wil bamboozle some new dev and they will actually reopen the old issue 😄 at least it would generate some new news articles about JXL, which is always good

hey phoronix covering this puts more pressure on google

it's frustrating seeing Chrome be the new IE tho

using their market share to ignore standards and force web developers to create exceptions for IE vs standards-compliant browsers

huh that sounds like a monopoly to me

i thought chromium was open source?

it is, but just like firefox, they are free to ignore your contributions

being open source just means you can view the source code

all the other things about "browser with major market share who is controlled by a major corporation with direct interests in having it do specific things"

that still applies

welp

time to commit cyberterrorism

(/j for the NSA)

it's worth noting firefox hasn't been exactly stellar here either especially since their biggest selling point is "preventing the chrome monopoly from dictating the direction of the web"

tbf that's always been Mozilla's thing back when it was Netscape vs IE

"You can view the code" is Source Available license, like Ms-RSL.

Well more specifically you can also modify it and fork it

which people do

but my point is that being open source doesn't mean that it's a community project

free not as in freedom

thats one of the largest issues with firefox, it keeps trying to come off as a community project when it really isn't anymore. at least with chrome it's expected they will turn around and flip the bird, when firefox does it, it feels a lot worse

when was it ever a community project

a long time ago, at least back when it was in winxp days, I havent followed much of firefox development since I migrated to vista

netscape navigator wasnt even free

in Mozilland, issues report you

So you're saying we need a new browser that's community driven.

never gonna happen

I wouldn't be so sure, servo is looking very promising lately, I did look at the embedding API briefly and it doesn't look too hard to work with. and ofc, I already have had JXL working in it with minimal work

well kinda, stills only

except it's as "community driven" as firefox and jxl are

it is, keep in mind that servo is a rust first ecosystem, that means to contribute to servo all you need to do is contribute to the packages it relies on. also due to servo being oriented (currently) to an embedded design, they will be quite open to a mirad of feature stuff. ofc right now the sole priority is getting servo up to speed, CSS2 is still an issue, for instance danbooru "works" now but layout is still messed up

Would be fun if servo killed chrome like chrome killed IE

I don't think that will happen lol, ill be happy with a usable browser lmao

Yeah, just a fun thought 🙂

I mean, to play along with the thought, Servo does have the potential to steal away decent market share from electron/blink, which I suppose could be the small ball thrown down the snowy mountain

Have you ever heard of Ladybird?

no

<https://youtu.be/dQw4w9WgXcQ>

<https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/> That's a simple introduction but you can easily find more by yourself

I doubt either of those are going to take the place of Chrome. **Servo** is a layout engine. It was started by Mozilla with the intent of replacing Firefox's Gecko engine with it eventually. That fell through after the pandemic & layoffs caused them to largely abandon the project. You still need a JS engine, UI, etc. to make a complete, working browser. Servo is already designed to work with SpiderMonkey (Mozilla's JS engine). So you're pretty stuck with going with a Mozilla-controlled component right there. In the end there is still A LOT of work to get an actual, working Servo browser and you're likely still going to be at least partially controlled by Mozilla in some form. **libWeb** is a library embedded inside the library of a linux distro. It needs to break out into it's own separate repo both so there can be more autonomy rather than being "the SerenityOS engine" and so you don't have all maintenance - issues, development, discussions, and code intermingled with SerenityOS's.

firefox totally abandoned "servo" itself, but it was recently picked up by igallia. also I wouldn't say that being using spidermonkey means with will be "partially controlled" by mozilla, that specific component is (lots of components are still mozilla governed) but they can be forked and worked on, (servo is indeed planning on vendoring a few components.) but there is nothing stopping a dedicated user from making a PR to add boa support to servo, for instance. servo will be more or less in the same state that webkit is when it becomes an actual useable product.

You're suggesting a person is going to single-handedly develop a patch to convert everything over from supporting spidermonkey to boa just like that? Seems like more than wishful thinking. There needs to be support and energy put into it by a large part of the development community. Energy that doesn't seem to exist: https://github.com/servo/servo/discussions/29100

there is very little energy for doing anything outside of getting servo up to speed, but should spidermonkey become an issue for some reason, (which I doubt it will) then yes, I could see a port of boa happening

I originally said servo's not community driven just by one look at the commit history and it's website

Because why would anyone in their right mind do anything for free

why would for profit exclude community driven? for profit can still be community driven if the community gets involved

> I doubt either of those are going to take the place of Chrome. I never said that LibWeb is a Chrome killer but it does check the community-driven new browser part. > **libWeb** is a library embedded inside the library of a linux distro. It needs to break out into it's own separate repo both so there can be more autonomy rather than being "the SerenityOS engine" and so you don't have all maintenance - issues, development, discussions, and code intermingled with SerenityOS's. I don't understand wdym by a library embedded inside the library of a Linux distro. It wasn't even designed with Linux in mind, I don't know how it can be tied to a distro. Moreover the engine is just cross platform, it works on SerenityOS as it works on macOS or Linux.

in fact, servo is actually trying to increase community involvement, but that's not something I have enough skill for, too many bits lol

good luck to them then

maybe by then the year of the Linux desktop will also arrive

go to sleep

I'm trying

I assumed SerenityOS was another Linux distro. It looks like it's a POSIX-based OS (though I assume it's still based on some long-since-defunct UNIX OS; Virtually no one builds an OS from scratch these days). What I mean by separate repo is that the code for libWeb is embedded into the SerenityOS GitHub repo. It should break out into a separate one instead of making people dig into an OS repo to find it. One part of a separate repo is that it should work across platforms. Having it embedded into a specific platform's repo gives the impression it will not. As well as the other issues I listed. If it's not going to compete with Chrome then it defeats the purpose of displacing Chrome with an alternative that will listen to the community instead of corporate interests.

I would love to see that happen but it doesn't look all that likely. If as many people contributing to Chromium & Firefox would switch to Servo, it would probably be a viable browser by now.

well, considering project enablement only really started happening around februray, servo has a LONG way to go before people start using it, servo doesnt even render CSS2 yet properly don't forget servo has pretty much been dead for years. there is still a lot of stuff they need to catch up on (even updating deps is proving non trivial)

POSIX-based doesn't mean much, it's like saying that Chromium is ECMA-based. I guess that you mean compliant here. And no it's not based on something else, writing everything from scratch is really a part of serenity's policy. Everyone says that it's impossible to build an OS or a browser from scratch but still people do it.

> It was started by Mozilla with the intent of replacing Firefox's Gecko engine with it eventually. I don't think that that's accurate. Some Servo devs had such aspirations, but no one working on Firefox and no one in Mozilla leadership ever considered Servo to be a replacement for Gecko, rather an RnD platform since Gecko was kinda jank and not at all modular at the time. When various components of Servo were ported to Gecko, the two things that took time were: 1) making Gecko modular, and 2) making those components actually correctly handle 100% of websites in the world ever. Today, since Gecko is very modular now, experimental components can be created in Gecko and disabled in normal releases, making Servo much less useful to the goal of making Firefox better.

> Everyone says that it's impossible to build an OS or a browser from scratch but still people do it. Making an OS from scratch is downright trivial compared to making a modern web browser.

"OS" can mean anything from core kernel to full distro, it's a rather vague term imo

I haven't been involved enough in both kernel and browser development to say more than an educated guess. But even if web browsers are complex, I don't think that something like Linux can be called trivial

Linux is not trivial

no, but I could believe browsers being *more* complex than that still

at least with the huge amount of complexity that HTML/JS/CSS and all the browser APIs bring

An OS ranges from a couple thousand lines of C for an RTOS on a microcontroller, to many millions of lines of code in something like Linux or Windows.

So it's sort of like comparing [Lynx](http://lynx.browser.org/) to Firefox or Chrome.

This simply means that modern web is too bloated. Reading SMS? Recording user screen? Accessing USB devices? When enough is enough?

wait, what? Browsers can access SMS?

https://developer.chrome.com/blog/cross-device-webotp/

i'm waiting for tpm api in JS

but unfortunately so many people are against web integrity

There is no way to implement something like that that isn't terrible

we live in a society

Noone wants digital GULAG

I don't think anyone is against web integrity. Security is directly at odds with convenience, and if it's inconvenient that means someone else controls it. The people in control would most likely be browser vendors. TPM would most definitely be misused if say, one browser became a monopoly.

i'm against web integrity

idek what web integrity is

https://arstechnica.com/gadgets/2023/07/googles-web-integrity-api-sounds-like-drm-for-the-web/

ah

If it is not a secret, where are you from? I mean country

Apple has already implement something with the technology, https://support.apple.com/en-ca/guide/iphone/iph4f43a30c9/ios

I think web integrity could be good if it verifies that you got what you asked for. That website downloaded correct html, css, js and assets. But once it's on my PC and verified I should be able to do whatever I want with it. Including removing parts of website I don't want to see.

Except TLS already exists for this

i want to be able to remove passwords

just use webauthn

but fido2 sucks

I want authentication and authorization in one go

Wdym

But in any case they could just invent a better protocol

Web integrity has completely different goals, and cannot work anyway.

asymmetric authentication

user keys are stored in keyring server encrypts challenge with public key client recieves this, requests decryption from keyring, and sends it back encrypted with the server's public key (probably done automatically by the browser) server verifies challenge matches and voila- logged in

yes this still requires a password for the keyring but the important part is it's just one password locally

that... is just a password with extra steps

still doesn't have authorization to the authentication

then take the password off the keyring 🙃

basically described a password manager

yeah, but better

umm

yes?

I conclude the only solution is a tpm based device

that's overkill

just use yubikey

What does this have to do with the adoption of jxl

it's very important

gotta make sure its new home is secure when it's adopted 🥺

I don't see at all how a TPM would differ from something like a Yubikey for this use case.

it's soldered on 🙃

or etched

because I would need to buy like an 80$ yubikey

yubikey does exactly what i desrcibed earlier, just in hardware instead of keyring software

well the keyring software doesn't work because there's no attestation

so if the TPM did the same thing as what a yubikey does, that would be ok?

the point of the tpm is the attestation

if we're talking about logging into websites and stuff, not really

well, a point I guess. the yubikey also provides this

so does the software keyring

fido2 does allow you to say whether you care about attestation or not, and 99.9% of websites do not

what's attestation?

cryptographic evidence that nothing has been tampered with

basically authorizing the usage

I want to be able to encrypt and decrypt data using it

wouldn't tampering only be a problem *because* it's hw-based?

and with the software one, any random program can take advantage of it

technically speaking, if your OS is that permissive, it isn't too hard for programs to use your TPM or Yubikey to do whatever either

yeah

tpm is just corporate-controlled password store

the tpm can do a lot of things

though the amount of evil usage would be limited to the point where you think there's something funny going on with having to press the button the yubikey (as for tpm stuff, would depend on the tpm)

well good talk. looks like we'll never have anything good for another 30 years

I'n happy enough with my yubi (+ 3 redundant backup yubis)

can we talk about yubikeys in <#806898911091753051>?

For really good security we need OSs actually designed for such.

sure

Are you sure you want THAT?

Proving that you do not own computer

attestation is useful

what youre saying is what gamers on r/hardware say

not everyone is a gam*r

(except everything that is not remotely-operated server with no physical security and tons of sensetive information)

what?

I named the only one valid use-case for attestation

it doesn't have to be remote or a server. I just want to know what I do is what I do

I guess I'll go continue gaming my GCC

😔

Does/will iCloud Photos have JXL support

I have an iPad running the beta, would you like me to test it? I have iCloud but only use it for device backups, so I do not know how iCloud Photos works

Can it open JXL files?

I'm not sure what you mean

Can the iPad open a .jxl file

yes

almost all apps can open jxl files

the photos app displays them fine

I don't know how it interacts with iCloud

It probably wouldn’t, not at least until official release

Any news? AFAIK nothing on Firefox, and Chrome went full beaurocracy.

Just updated to iOS beta

Let’s go!

Do you have a Mac? What Uniform Type Identifier was assigned to JPEG XL?

That’s on iPhone, I just used .jxl extension

https://support.imageengine.io/hc/en-us/articles/16739209580301-JPEG-XL-jxl-in-ImageEngine

Zoner supported jxl decode and creation since mid-2022. Never saw it mentioned anywhere

they never mentioned it in changelogs. oddly it seems to generate less efficient files than expected. running ancient code?

zoner's a strong rival for adobe's lightroom and acdsee

https://manual.zoner.com/supported-formats-3b987c0/

the PDF association is currently investigating a futureproof hdr-ready image format for future revisions of the PDF specification past 2.0 and it looks jxl is a strong contender already. any chance folks familiar with the technicals could weight in its favour?

Where would be a good place to do that?

Lemmy may apparently support JXL in an upcoming release (technically its 'pictrs' that seems will). Might be handy since the exodus from reddit resulted in a massive boost in the number of sites running Lemmy

for pdf https://pdfa.org/overcoming-ossification-advancing-pdfs-imaging-model/ private discussion amongst association members initially, 17 october for a public conference on the subject in san francisco

I thought lemmy already supported it?

<@174118775753408512> are you involved in the pdf association?

since recently linuxmint supports jxl read out of the box. oddly the initial blog mentioned avif and jxl but later blogs and the reposts across the web mentioned only avif. slip of the keyboard i suppose

no, just a regular noname user

I do kind of regularly see Leonard from Adobe at JPEG meetings, and Leonard is chairing the TC doing PDF at ISO.

Currently uploading JXL to Lemmy doesn't work

so 2 days ago [GZDoom](https://zdoom.org) merged support for both WebP and JPEG XL however a day later JPEG XL support was reverted because libjxl is apparently "not really usable on vcpkg."(?), I myself know almost nothing about build systems or package managers so I am asking here if anyone has any insight. here is the commit in question: https://github.com/ZDoom/gzdoom/commit/53d8a5bb2cb3b4f5576d9286731ad5a4bd972949

actually they might not be saying that libjxl is not really usable with vcpkg and instead are saying that the reliance on vcpkg for libjxl is the issue?

I honestly don't know

actually yeah it might be the latter since the commit for WebP support doesn't rely entirely on vcpkg like the JPEG XL one does EDIT: I have no clue I don't have enough info

here is a discussion from today: https://forum.zdoom.org/viewtopic.php?style=12&t=78113

hmm looking at the github and other things it seems like they are in the process of doing build system changes and adding support for multiple other formats like QOI, as of 4 hours ago AVIF support was rejected and nothing has been said specifically about JPEG XL since the support for it was reverted it's unknown whether or not currently it's planned to be reimplemented

[hmmm](https://github.com/ZDoom/gzdoom/pull/2134) maybe this could be a clue of some kind?

I have no idea how vcpkg handles the pkgconfig files, that would be a question for the vcpkg maintainers. The above commit does not do anything with pkgconfig files.

It appears that GZDoom is using pkgconfig (a *nix dependency finder) to get the libjxl compiler settings (headers and libraries), and the vcpkg version of those files do not have the correct information. I have no idea why they are doing that instead of using the built-in functionality that cmake provides for that purpose (perhaps the vcpkg version of libjxl is named differently in cmake?). As far as I know, the intended method for using vcpkg with cmake is to use the cmake toolchain file that vcpkg provides, see <https://github.com/microsoft/vcpkg#using-vcpkg-with-cmake>

GZdoom <:Poggers:805392625934663710>

DZdoom

this was the response I got

most of this build system and package manager stuff goes over my head so if anyone here is able to help find what the root problem is then it would be really appreciated since otherwise it looks like GZDoom won't support JXL and will go with just AVIF which is a somewhat big deal since GZDoom is really popular and people have even started using it as a base to make commercial games with

On the plus side, if whatever issue only gets resolved down the line, all the code is still around and can be re-merged

it seems like the GZDoom folks either don't know much about JXL or have a very negative outlook and opinion on it as most of the talk about it I have seen in their server is people asking what's it's for or devs saying it looks completely dead and getting annoyed at the simple header structure

People asking what it is should be expected, devs saying its dead depends what they mean, github is active and Apple is on the way, header structure *is* simple but almost to the point of being complex again packing everything into bits rather than bytes

^ this is whats specifically being said <@238552565619359744>

oh also when they mention "old setup" I think they are talking about the build system since it seems like right now GZDoom is in the middle of getting a bunch of build system changes

So, in other words it's the usual. JXL isn't widespread enough to be used and misinformation. If I recall they removed AVIF support too because it doubled their binary size anyway

they are trying to add AVIF support again since it seems like they managed to find a way to do it that doesn't bloat the binary size

i think it's dumb to think everything should adopt jxl

like bro chill wtf even is gzdoom

these people will just use bmp

and nobody will care

they are adopting QOI, WebP and AVIF also GZDoom is being used for commercial games

wavpack and flac exist yet every daw still outputs pcm wav by default

I mean I understand you are saying that most people flatout do not care about formats and will just use continue to use stuff like PNG but Idk how that relates to this since like I said GZDoom is in the middle of adding support for a bunch of other formats, also they are seemly also planning to add support for HDR and HDR textures soo

hdr texture

now that's schizo

I don't specifically know what they are planning but having a format that supports HDR as something the engine can take in as a input seems like it's on the table

don't know if "texture" was the right word

asset packs tuned for jxl fast decoding should be handier than in other formats

I am still unclear on why they are using pkgconfig in the first place, but I have also never tried to use libjxl with cmake. From the second screenshot you posted:

This makes it sound like the libjxl is not generating the required pkgconfig files as part of the CMake build process (or there is a bug in that process).

I took a look at libwebp (which GZDoom is also using), and it has template files for pkgconfig that are filled in as part of the CMake build process in CMakeLists.txt.

If it is a bug in libjxl they should open an issue on GitHub with the appropriate details.

I don't have the experience with CMake or pkgconfig to know exactly what the problem they are seeing is.