JPEG XL

and as general as it can be

Yeah, if you're generating a fingerprint, it's super useful, because it's not very common/generic information

every other Linux user...

Every other, yeah. As long as they are using Firefox 128

It's the exact same pattern as this Mozilla/5.0 (Android 12; Mobile; rv:128.0) Gecko/128.0 Firefox/128.0

Well you did it to yourself for using the odd setup

It doesn't need to give the version numbers for android and firefox

uhh they are very important

If you want detailed information it should ask for permission first and get consent.

like knowing which versions you can target for features

There should be an API to get info which asks the user for consent just like it does for getting your geolocation

anyway fun arguing with armchair webdev

you need the versions because some versions have broken support for stuff

for example, imaging writing a source set of images, including a webp image. But oops, one user is using an old version of Safari with broken webp support!

Checking version numbers is even discouraged by all of the docs and manuals I've ever read about web dev

So why even provide it?

How would it know that it can use the API??? <:clue:1247768672739659786>

or imagine having an avif variant, but a user is on android 13, which has broken avif support

It would try, and fail, and then the web page could say that it wasn't able to automatically detect your system.

how would it know it can try and fail?

what if the user's JavaScript engine acts differently

or what if they disabled javascript

I guess we need to send a header

to tell the server what features we can use

I also personally believe they should have made a way for a web page to request consent to run javascript in the first place, so it can be disabled by default by all browsers...

and it can't just be a list of features and formats, that's too specific and fingerprintable

OS+browser version oughta do it

Whole system for knowing features outside of header and JavaScript? That's too complicated for my embedded kiosk

I mean browsers that don't have a newish feature will typically just gracefully ignore stuff they don't recognize...

that's a bad assumption

That's how new HTML tags work

Assuming unrecognized tags will be ignored by older browsers

Do you not think many people are thinking about this and many people came together to decide the current standard?

Sure, but apparently quantity does not account for quality... Anyone who's taken a look at the "web platform" knows it's a train wreck.

it's fine

If you think you can do better then by all means

go for it

and quit complaining

That's why there's healthy competition in the web browser market, eh?

Because the standards are fine

yeah that's why jxl is useless

That's why web browser competition is flourishing

I need to go get something to eat. I respect if you have a different opinion than mine. Not everyone gets everything right 100% of the time and I could be mistaken about some things, but I hope you don't mind me sharing my current opinion. I'm sorry if I annoyed anybody here.

At work we have to make a ton of exceptions for firefox

soon have to also target safari and that will be horrible

slowly the exceptions for ff go away

but we do use the user-agent to tell what exceptions are needed

esp .for crash logs, knowing the exact setup to reproduce a bug is very useful

I'm sure for most websites it's used for something like that

and I'm sure it can only be used for that since it's so general

I just think browsers should have less dubiously-useful entropy in their headers for both performance and privacy reasons.

Debugging scripts on a remote machine without the owner's consent or knowledge is something web devs take for granted in this crazy world

I know that is going to be unpopular with a lot of web devs, but nowhere else is that even remotely a thing that's considered normal or acceptable

?

It's kind of off-topic, but I think the web platform is broken by design because it takes for granted that you are running scripts on someone else's machine and you don't need consent or permission to do all kinda of things that would bother most people.

and you don't need consent to load a bunch of images on a web page

what's your point

There should be a difference between a user browsing a page or article for information, and a user consenting to run an app on their machine.

or you can just not go to the web page?

It isn't designed with consent in mind

jeez why do they ask for my id when I go to x place

At least they ask... they don't just reach into your wallet and take it...

Still have to give them the info

or I can not go

Web browsers and web standards are designed by advertising agencies and so it is no surprise they are designed to violate your privacy and consent by default

humans are designed to consume water and pee it out after

??

I wish privacy and consent wasn't a punchline in this world

It's not a cause of big water it's just consequence of other factors

you have a very tunnel vision pessimistic view point

No, it absolutely is because the people who made the browsers and the standards want to sell you ads more than they want to consider the ethical implications of consent

it's not that they want to sell ads

they just want to make money

by selling ads

I can't even tell if this is supposed to be a point or not lol

web browser Ladybird upgraded its jxl support from its basic inhouse decoder to an integration of libjxl 2 days ago (currently 0.10.2). reportedly it works great - no animations yet but coming

Support for animation was merged yesterday 🙂

They... They built a basic inhouse decoder?! Nice...

firefox base or chromium base

truly independant (started as serenityOS' html renderer). all components were before made from scratch, really fast improvement pace putting to rest the myth of browsers needing a billion dollar. what changed recently is theyre now open to using existing equivalent libraries where it makes sense

that remains to be seen, ladybird is impressive, but it's still waaaaayyyy behind

How about we all just use gopher or something

Web browsers were a mistake 😂

My advice: NEVER remove Accept-Encoding header. It will break many sites (but not all, so you'll notice it way later), and you'll spend years hunting down the cause.

I left accept-encoding alone, because there isn't any non-braindead alternative yet.

I wish more websites used accept-language instead of detection by geoip (sorry for offtopic)

Absolutely. I get annoyed that YouTube gives me ads in French just because I live close to Brussels, and last week when I was in Japan, I got ads in Japanese.

looool and me being near Liège I get many times my ads in Dutch <:kekw:808717074305122316>

well, same stuff for website language (even big ones like Amazon) can't they see my whole browser and locales are in French ? <:KekDog:805390049033191445>

ip stuff is annoying in general

I would prefer personalized ads over local ads

i prefer no ads 🤷‍♂️

On twitter you can block accounts making ads but when traveling it's basically reset every time

Lots of sites still believe that if your IP is in ex-USSR countries - russian is the best choice, despite the fact that my Windows and browser are in English. It is just terrible

same same, I often get punted into quebec with my geoip which changes everything to french

all the people who get punted into russia geo ip and software suddenly goes malicious, RIP

EA is like that, too. It backfired badly when they decided to block that region from buying games.

I know 😔

FYI, JPEG XL is now available in supported browsers at www.theguardian.com (most of images on the site).

I guess they stayed true with their support... now if only browsers other than Safari could make use of it 🙂

I still get JPEGs on Cromite

what's your Accept: header for img requests?

i just visited with safari, and got a jxl

does anyone know if shopify actually serves JXL files?

I've only gotten webp files so far

this list still applies: https://discord.com/channels/794206087879852103/803574970180829194/1090307010253308057

Shopify seems to only make medium-smallish images as JXL files

ah!

I hate when they don't just use it to determine ads but automatically change the language of the _whole website_

and if there even is a manual language selector to overwrite it, I can't find it, because it's in a language or sometimes an alphabet I don't understand (:

to add: i visited with floorp, got jxl

Thorium; got jxl

text/html,application/xhtml+xml,application/xml;q=0.9,image/jxl,image/avif,image/webp,image/apng,\*/\*;q=0.8

is there a list of known encoders anywhere (and decoders too would be fine) the only ones I can think of off hand are libjxl, hydrium and zune-jxl

As long as you're sending a referer header, it should work...

Any good image viewer for linux that supports jxl? My machine defaults to using GIMP which isn't the best user experience for just viewing stuff

Which DE are you using?

Well GNOME but I don't have any of the GNOME apps installed.

There is a gnome package that gives gtk apps access to jxl, avif etc. I don't have the name of that package though

most of them do, gwenview, loupe (kinda bad dont use it) koko photoqt etc. I personally like oculante but it's lacking colourmanagement and large picture support

gwenview requieres the kimageformats package to decode jxl IIRC

loupe is gnomes new image viewer but it sucks with a capital S

It has no settings lmao

I found gwenview, loupe and koko from my package manager. Which would y'all recommend?

personally I would reccomend gwenview, it's popular enough that it's got good support. I like koko better but it lacks ICC support

loupe is extremely simplistic with no settings to speak of. use it if that is your jam

i wouldn't recommend it tho

loupe is horrid, it actually lags when rendering gifs on my tablet, I didnt even think that was possible, but it does.

if you are fine with Qt applications, nomacs is a competent image viewer like gwenview but with a nicer gui IMO

Bruhhh installing gwenview would install 63 packages and koko would 57 packages. Loupe only needs 3 packages

loupe is statically linked since it's rust

Ah

Loupe actually seems good enough

Thanks!

koko would be so great if it supported icc

left video is rough

yeah that's not the video, the app is just like that xD

i have the flatpak of it installed, it works fine there

the flatpak has no support for avif or jxl though, sadly

Every image viewer on linux supports jxl from what I can see. gdk-pixbuf adds support to gnome, if anyone still uses that aging piece of junk.

yes, but there is no flatpak package of gdk-pixbuf, so no support in flatpak apps unless directly packaged by the maintainer

the issue is it performs like complete crap

My primary issue is the lacking settings, you cannot even disable the hud

but it's not my main image viewer anyway

there's also `pqiv` for minimalistic (keyboard-oriented) people like me

It's interesting... They're serving them with jpg extensions in the address bar

O_o the width is adjustable, so I think they're encoding them live???

Their encodes are pretty blocky. I think they're using something close to e1, but I think they should really use e5 because that's when deblocking kicks in

I think they're using distance=5

For reference, on my PC e5 is 20ms slower than e1. Not a lot!

To that, is there a table of features available from certain `effort` anywhere? Also, is it expected filesize grows with `effort` (tested e3 vs. e6 and filesizes are consistently larger…)?

https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md

Thank you! This also answers my second question. > This means that for lossy compression, higher effort does not necessarily mean smaller filesizes for every image — some images may be somewhat lower quality than desired when using lower effort heuristics, and to improve consistency, higher effort heuristics may decide to use more bytes for them.

also I would recommend [Squoosh](https://squoosh.app) to be able to do quick visual comparisons between quality and effort levels, but going towards what Firepal said e5 or higher is probably what should be used since if you compare e4 and e5 the visual difference is pretty big

Basically the low effort lossy settings are mostly useful for very high quality encoding (say d < 1). For lower quality, the coding tools that get enabled at higher effort settings (like bigger blocks / adaptive quantization / better heuristics) and the extra effort spent on entropy coding really make a difference.

I second the Squoosh recommendation, despite some WASM limitations imposing speed limits it's great. They should add jpegli sometime...

yes this is how CDNs work, they use accept headers to serve you a different image instead

MacOS is having big issues trying to load giant jpeg xl images using Preview

`djxl` decodes it fine in `0.3s` but Preview gives the beachball trying to zoom into anything

if you install the gdk-pixbuf loader, then it works with eye of gnome and eye of mate

and the like

Right now Squoosh is in a low activity state libjxl is already [a few years old](<https://github.com/GoogleChromeLabs/squoosh/issues/1402>) (2022) so I wouldn't bet too heavily on jpegli making it in anytime soon https://github.com/GoogleChromeLabs/squoosh/issues/1408

It'd probably be a good idea to update that chart with the new streaming modes and e10 at some point too, but I'll leave that to someone who's more familiar with the heuristics since as I mentioned in <#840831132009365514> the palette was also extended to e2 and e3 just to name an example

Had to do a bit of work to get animated JXL in 129, so I figure I'll send https://github.com/Eclipse-Community/r3dfox/releases/tag/v129.0

are these the changes?

Yeah I just had to replace PostDecodeDone with PostLoopCount in the patch It doesn't sound that hard, but I am retarded so first beta release did not have extended JXL

https://bugzilla.mozilla.org/show_bug.cgi?id=1901076

People mind helping to check this? Seems like Irfanview can't see metadata unless it's at the start of the file and not Brotli compressed https://www.reddit.com/r/jpegxl/comments/1er3ok2/comment/li23yci/

It does not. So no exif, no color profile

Also ACR opens non-srgb jxls incorrectly. Active image is in prophoto, second - srgb. Colors in non-srgb image are correct, but gamma is not. Maybe updated ACR fixes that, don't know

Color space info is not separate metadata in jxl, it is part of the codestream. So if an application shows wrong colors, they're using the decoder incorrectly.

In case of jpeg-in-jxl too?

Yes

Every jxl codestream has obligatory color space info, which can be as short as a single bit to signal sRGB or it can be a compressed arbitrary ICC profile, but there has to be something, it is not possible to make a jxl where it is ambiguous how to interpret the image data.

For JPEG recompression, the color profile is taken from the jxl codestream, it is not part of the jbrd box (except to indicate _where_ in the reconstructed jpeg bitstream the ICC profile is supposed to go).

I'm asking because IrfanView correctly displays 'true' non-srgb jxl, and fails to color manage non-srgb jpeg-in-jxl. I thought that in latter case IV can't read metadata and get profile from there, but it seems that problem is somewhere else

Could be that it just asks libjxl using JxlDecoderSetPreferredColorProfile to return an sRGB image if possible (which iirc means that it will do that if the image is XYB or if it is RGB that is already-sRGB, but not if it has to handle an arbitrary ICC profile) and assumes the result will always be sRGB (which is a wrong assumption). With the latest libjxl API you can call JxlDecoderSetOutputColorProfile instead and it will handle arbitrary ICC profiles if needed (using lcms2 or skcms), but with older versions of libjxl that function was not available yet.

As far as I can see - it is a total mess: IrfanView correctly shows non-srgb jxl, but fails to color manage jpeg-in-jxl, while ACR does the opposite: fails to apply correct gamma (and only gamma, looks like it is applied 'twice'), but shows correctly non-srgb jpeg-in-jxl. Also I found that Photoshop is stupid enough to accept only default extension, ignoring file content 🤦‍♂️

The IrfanView plugin could do with a major overhaul. Compressed boxes, mid-stream metadata loading, updated libjxl version... A long way down the wishlist, cropped decoding would be nice too

Considering the sheer amount of software that implemented jxl encoding/decoding "incorrectly", could it be documentation problem? Or maybe examples are bad? Or API violated the principle of the least surprise or something. If *everyone* does it wrong, it makes you think.

well colour management in general is hard, and most applications still just default to srgb or nothing, so unless the decoder actively converts to sRGB which is fairly rare all things considered, colours will typically look wrong, and ofc since conversion is rare, not many people even go out to look for it

windows applications have long defaulted on color management disabled so that can be an issue with jxl and jpegli+xyb

utilities like xnview dont leverage cjxl's quasi-instant jpg->jxl path when source is an unedited jpg so its stuck doing a long export/preview on a single thread

highest profile fail imo is firefox though. for some reason they think they had color management nailed when the tests they used were obsolete and flawed and havent reevaluated since

Most cases of jpeg transcode missing is simply due to the nature of the programs decoding to pixels instead of sending the data to libjxl

Out of curiosity tried IrfanView's color management on various formats - it is.. ehm.. strange. For example this is how it displays avif discussed few days ago somewhere in on\offtopic, when color management is on. The same is for svg

maybe this person has argyria?

Or ate too many schtroumpfs

Now we know their favourite song

apparently Final Fantasy 16 (a Video game) has support for JPEG XL‽ https://x.com/NotNite/status/1825577272943751288

thats dope

``` $ jxlinfo ffxvi_20240820_035122_001.jxl JPEG XL image, 2194x1234, lossy, 8-bit RGB intensity_target: 10000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Relative ``` 8 bit hdr :/

what does the JXR come out as?

16 bpc (half float) scRGB

also seems to be lossy from the size, though idk if/how you can check that

based scrgb usage

and the PNG files are just 8 bpc sRGB and look bad, not entirely sure how they're generating those but the HDR highlights seem to be clipped + they take absurdly long to encode, like ~10 seconds

here's one of my jxl screenshots

That's a screenshot of "decompiled" code lol

I can see a little bit of mosquito noise in the parapets but otherwise cool. Too bad there's no quality slider

with lossy, bit depth is metadata, not prescriptive

you can decode it to 16-bit just as well

just pass `--bits_per_sample 16` on the djxl CLI

right, forgot about that. doesn't it suggest that they encoded it from an 8 bit source though?

I don't know

Interestingly, when opening it in Krita, it's set as 32bit float

it's a part of linearizing HDR images in krita, I believe it also did the same when opening an HDR AVIF. internally, jxl still get decoded with the same bit depth as the metadata defines.

nah, internally it's decoded to whatever you request from the library

which is 32-bit float with libjxl, downscaled

bit depth is just metadata

I mean in krita, it's requested the same as the metadata

oh, huh

which is indeed got me thinking if it's a good idea to request it as f32 instead hmm~

if the intention is to conert to float32 to linearize then I don't see why it wouldn't just request float32 in the first place from libjxl

I'll gonna take a look on it~

krita can finally work in linear now?

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

it has been there for a while, yes https://docs.krita.org/en/general_concepts/colors/scene_linear_painting.html

I mean for converting things comming into krita

last time I tested krita it blended without doing linearization https://cdn.discordapp.com/attachments/719811866959806514/1216585057112821851/image.png?ex=66c755e0&is=66c60460&hm=b1f34e13405b298c278f21e941e9a35d7d2c4eea10a805cc20cf42458c48e7f9&

oh for that you indeed have to work in linear color profiles indicating with `-g10` in their profile name

no plan on changing that, afaik

The new [Zen browser](https://www.zen-browser.app/) based on Firefox apparently supports JPEG-XL: https://github.com/zen-browser/desktop/commit/8a87e3a0afb124c1f31201c5177435b54ee88931

Did they do this correctly?

eh I would say nah not really, it's missing the unmerged patches (which to be far require a tiny bit of work to get working in newer versions of firefox like zen is using) and all I can see from this patch is support for JXL being built into the browser and not enabled by default

Is it worth making an issue? I'm not aware of the unmerged patches, but I think Waterfox merged them, right?

yeah Waterfox, Floorp, and r3dfox all have them merged which is why pages like https://jpegxl.info/test-page/ and https://google.github.io/attention-center/ fully work in them

I don't think Zen is worth caring about. It seems to being trying to do closed source stuff on top of Firefox

update: the developer was just clueless about copyright licensing, someone talked with them and got the to fix it

Do you think it would be possible to change the libjxl request based on the current canvas settings? Request an 8-bit buffer when imported to an 8-bit canvas, ect Currently it's increasing the memory usage and import time using f32 when (supposedly) it was only 8-bit to begin with anyway

Could do the same using jpegli and 8-bit or 16-bit canvas' too then

the wikipedia page for floorp says : _Floorp[a] is a partially free and open-source (open-core)[2][3] web browser based on Firefox_. I don't even know what partially free means 😄

It means some parts are closed source

The Mozilla Public License allows mixing with proprietary code

If it's for importing a layer, I'm sure it'll just converted back to the canvas setting (eg. 8-bit, should be the same for reference image, but I'm not quite sure yet, haven't dive that deep xD)~ And krita is already requesting the same bit depth as the metadata (8-bit, with that screenshot example), it's krita's own internal conversion that convert them to f32 buffers for HDR contents

non-HDR images should be left intact, though~

When I made an 8-bit canvas, and imported the JXL as a new layer, it was added as 32f, judging by the memory use going to 130~ MB, instead of the 30~ MB after converting back to 8-bit Riight, hence the idea of requesting 32f to start with, since Krita does it anyway for HDR

GIMP is similar iirc

you can work in linear with an icc profile

or in sRGB but if you work in sRGB only scaling with full image scale is done in linear light.

Cromite has temporarily disabled JXL (https://github.com/uazo/cromite/pull/1362/commits/767a4e1ede6880461daba3624110c6b6aa8e1ee1)

well that bites

Why doesn't this work in Safari, and how hard would it be to make it work? (Progressive JPEG XL demo)

libjxl (which most software and all browsers use for handling JXL files) has the ability for handling/doing progressive decoding and it's what the JPEG XL support that was in Chromium does/uses and also what this unmerged patch that some Firefox forks have uses/does https://phabricator.services.mozilla.com/D122159 It seems like someone has already reported progressive decoding for JXL not working in WebKit/Safari https://bugs.webkit.org/show_bug.cgi?id=272350 (4 months ago). however they don't point out the [Progressive JPEG XL demo](https://google.github.io/attention-center/) which makes testing and validation easier and they also don't point out Firefox working with the unmerged patch that forks contain.

OK, yeah… I knew progressive decoding didn't work in Webkit, but I was hoping it was something in their code. Off to file another bug report

wait how did you interpret my message? I was trying to say it seems like a WebKit/Safari problem and that they/it should use libjxl better. and where are you filing a bug report? because I linked to one that was filed for WebKit

does webkit use libjxl or their own implementation?

libjxl however depending on platform Safari might call libjxl directly or call for support from the OS which also uses libjxl. or well at least this is what I assume because I don't know what else would cause the weird differences between platforms like animations not working.

however in all cases the core image decoding is done by libjxl because I'm pretty sure Apple didn't develop their own implementation

its odd that it can't process animations then, as Core Image itself is able to handle them

(eg. GIF)

also i find it funny that the Chromium JXL bug implies that JXL is "obsolete" where it hasn't even had the oppertunity to properly exist

When trying to do some of the work for the new website, I asked <@794205442175402004> about it and I thought he said he figured they'd rolled their own since there were so many things that didn't work that jxl handled. I filed a bug report for Safari right in the Feedback app on MacOS.

in the includes theres mentions of libjxl (0.8 last i checked but it should be 0.10 now)

decoding shouldnt require an updated libjxl. files generated using 0.10 should normally decode fine even on 0.7 since the bitstream and spec is stable - can anyone confirm so or exceptions ?

the bitstream is frozen so excluding bugs

No, I don't think Apple made their own jxl decoder. I think they integrated jxl support in Safari in the simple way (passing a full bitstream to CoreMedia and getting back pixels) rather than the somewhat more complicated way that is needed for progressive decode.

iphone 12 mini open jxl art in telegram

relevant: https://github.com/uazo/cromite/issues/1365

likely. Is cromite using this patch or do they maintain their own?

no, I think their patch is newer

seems "Special K" is adding jxl support (for hdr screenshoting?)

the more things that support JXL, the better

software is a reshade-style improver for pc games. notably can upgrade sdr visuals to hdr. seems it improves ff16's jxl screenshot support on an aside

Wait WHAT ```* Default quality level is 99%, this is primarily a lossy format. * JXL lossless compression ratio is poor, but not as poor as PNG. * AVIF or PNG are better choices for sharing lossless reference images.```

https://github.com/SpecialKO/SpecialK/commit/967eebc156423bad619daece79402ecaf4dce5f2

people arent familiar with the format, adoptions and integrations need handholding. they dont even know fast lossless exists

Even if you're not familiar with it, how do you end up with that conclusion?

> lossless compression ratio is poor Did they even do testing?

result looks expected with d=0.1 / q99

why not just use -d 0 -e 4 or something?

why -d 0.1 ? that just sounds silly

Because they think the lossless is awful

what would make them think that? speed?

id suppose they had effort 7 (default) or higher and made em think it playing with distance sounded itd give better tradeoff

either way i suppose they only need to be made aware of fast lossless and shown it works super well

is fast lossless `d0e3`

The only thing they said was the compression ratio is poor, so finding out what they were trying to do and showing them the actual results would probably do

they probably were doing `-d 0 -e 1` and expecting a 3 MB png to go down to 20 kB

or something

its effort 1 i think. fast lossless is no longer separate but its optimizations got rolled into e1

I'm just skimming the code at the moment, but having it be a general screenshot option instead of only HDR would be nice too

I joined their Discord server recently because I am able to actually join Discord servers again and I had been meaning to join for a long time and some of the stuff they are saying in there is just baffling

did you reach the 100 server limit?

or 200 if you have nitro*

yes I have been at it for a while and decided to give in and allow a friend to gift me temporary nitro because I got tired of leaving servers to make space

so uh now I'm pretty much only allowed to join servers if I have nitro now

oop

maybe make a second discord account

If my brain worked differently then I would probably do that

You gonna brave the storm and try to show the lossless is actually pretty good?

maybe although I've only been in there for less then 2 days and anxiety might get the best of me

try current build first maybe. going aggro on early adopters probably not good

I was thinking of posting screenshots of some of the stuff they are saying but something tells me that falls a bit too close to talking behind someone's back so idk if that would really be a good idea

I will post this though since it indicates more JPEG XL changes coming soon

more full context:

ummmm

If bigger is better, lossless AVIF is definitely better

if bigger is better, then all hail PPM

It is not the spec which needs to be distributed but a full integration guideline to teach them exactly what libjxl is doing and how

also probably things like best practices and common pitfalls

can you even do RGB in AVIF?

it supports lossless so I would hope so

it could be lossless YCbCr though...

yes, it aint great tho as expected

is YCbCr reversible?

how?

with enough depth, anything is 😆

ok, touche

avifenc with aomenc

as far as I know most AVIF encoders don't even support encoding RGB lossless or make it complex to do

but is 8 bit RGB and 8 bit YCbCr reversible?

why don't we just use an actual image format for images instead of a video format in a trench coat?

oh yeah, <:JXL:805850130203934781>

How with either aomenc or avifenc? Neither seem to support RGB...

dunno how to with avifenc anymore. I guess you could just use ffmpeg, it only supports gbrp

afaik yes but involves some colorspace conversion one couldnt call lossless. i think only libaom can, everything else is yuv-only (curse of video codecs)

yeah, not really an option then

you can do lossless RGB with no conversion on avif, but it compresses terribly because there's no channel decorrelation

<https://github.com/AOMediaCodec/av1-avif/issues/129> some relevant discussion here

Speaking of reshade, recently I give it a spin to give a jxl screenshot support~ https://github.com/kampidh/reshade/tree/jpegxl-support

why would I need screenshot support in reshade?

if possible please see if you can add a option to save the depth channel into the JXL 🙏

Ooh, good idea

still, I suppose it's nice that JXL is supported, since it has support for screenshots 🤷‍♂️

Oooh this should be interesting too~

hehehehe I wonder what effects image compression would have when done with a depth buffer, never seen it before, but I bet it would be pretty funky

are the extra channels stored alongside the main image?

Or are they stored completely separately?

I.e. can the depth buffer use prediction from the previous channels?

saving the various buffers would be useful, but honestly at that point I'd probably be using renderdoc

a big part of ReShade is depth buffer detection/handling and JXL natively has a spot dedicated for a depth channel so it kinda seems like a no brainer

but why stop at depth only then?

for Modular, yes. for VarDCT, no.

Lossy modular?

Maybe it's feasible to save depth in a different layer instead of channels

why do it like that though? it would mean any application looking for a depth channel wouldn't see/understand it

Yeah, the depth channel is a channel not a layer

Well that's true though~ anyway is there any app that already check for jxl depth channels to test it?

lossy Modular is also Modular, so extra channels are encoded together with color channels

Just curious - different layer can be vardct too? Channels 3+ can't, afaik, but maybe layer can?

Still very curious on how well lossy Modular works?

Is it better than VarDCT for non photographics?

Maybe there is some untapped potential

Best at extremely low distances, non-photo content and then there's Delta Palette https://fixupx.com/jyzg/status/1329067794995011585

Iirc, yes different layers can vardct

Thank you

sadly I don't know of any applications/tools that check for the dedicated depth channel (unless you count djxl's `--output_extra_channels` option and jxlinfo from libjxl) which is probably partially because there also aren't any tools that encode depth channels into JXLs yet either, though maybe having something like ReShade encoding in depth channels *could* encourage other programs in the future to understand depth channels for JXL.

So is VarDCT next gen JPEG and Modular next gen PNG and then JXL is when you add both together and they work together?

Pretty much

The jpeg side is good at photos, the png side is good at everything else, and lossless photos

And the PNG side is also used to add entropy coding with some of the parts of the JPEG side?

Like the DC coeffs?

Maybe an option then, I'll try to take a look~

so lossy modular is like near-lossless webp?

Or there's delta pallete, which I linked a small thread for

delta pallete?

Stores a limited amount of colors, and then mixes them to try and reach the same number of colors as the original file

oh also do you have the ability to test games with native 10-bit HDR? because ReShade supports injection into HDR games and it seems like some users have been requesting the ability to take HDR screenshots as well https://reshade.me/forum/suggestions/9582-hdr-support-for-screenshot-capture-feature-in-reshade although this seems like it could be a bit more complex to implement

so pallete but then take a rolling average?

<@532010383041363969> has the details, since as far as I'm aware this specific way of encoding was all his idea

i feel bad for him for people barating him about WebP images

i don't particularly like WebP (mainly against the idea of video codecs as image codecs in general, if anything prefer lossless WebP over lossy WebP) but it's not his fault that companies suck at adopting formats

reading the spec, lossless WebP seems like a decent upgrade to PNG

it is, but it's more limited

main annoyance with webp is the encoder uses at most 2 threads 😮‍💨

you can't pull a PNG and encode multiple slices and concat?

🤷‍♂️ not sure, but even if you can, it likely wouldn't be worth it

can `cjxl` do multhreaded modular?

very much so

Haven't test it yet

i guess not when using `-e 10`

that's why it seemed to be broken for me

ignore the cjxl effort 1 value, as it's often too fast to even be recording a useful execution time

just tested, `-e 9` uses all 14 cpu cores

e1 encode is faster than e1 decode

lol

it should with e10 too 🤷‍♂️

maybe it's an ARM thing

are you using `--streaming_input` and `--streaming_output`?

are those not default?

not to my knowledge

im using PNG input so `--streaming_input` doesn't work and `--streaming_output` doesn't help

😔 hrm, try with ppm then; other than that I'm not sure why it wouldn't

this is with PNG

that just has a blank value for cpu%?

oops

It said 1295.3

I suck at screenshotting

Enabling streaming input with ppm fixed cjxl not multithreading

It happily used all cores

Odd that it only multithreads with streaming on

yeah, it's annoying that you have to do that, but still much better than not supporting MT at all <:CatSmile:805382488293244929>

Why can’t it just convert to ppm internally? I guess RAM usage?

you'll have to ask a dev here...

Also ppm doesn’t support storing any metadata so I lose all my metadata when doing that

well there are ways to copy metadata over

How?

We should just make streaming input work for PNG, at least for non-Adam7 ones, so you can do streaming decode.

streaming input for png would likely have fixed the one image that was sent a few days ago

I think exiv2/exiftool will let you extract metadata from one image and put it into another, IIRC

Is streaming input default for image formats supporting it?

If not, is there a reason why not? Decreasing efficiency?

Adding exif/xmp metadata to jxl should be doable with tools like exiftool. For the color profile, you have to encode the ppm with -x color_space=icc_path:bla.icc, or something like that (going by memory here, probably flawed)

Oh yeah that 800MB one that nothing wanted to handle

yeah, it was painful finding something to decode and convert it

libjxl 0.10 added chunked encoding and streamed PPM input, that meant e 10 was added to re-enable the non-chunked features like patches, dots, ect Using the streaming input flag means e 10 essentially reverts to e 9 as far as I'm aware, while also disabling some other encoding tools

It is easily viewable, but encoding it to someting else.. ehm

So e10 is 0.9 e9 and e9 is 0.9 e9 without patches?

So basically e10 + streaming = e9?

I think so... Roughly...

I don’t think this has been updated for 0.10

https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md

you mean = e9 *without* streaming?

Yeah

I created an issue several months ago and no progress has been made 😔 https://github.com/libjxl/libjxl/issues/3517

It's been mentioned a few times recently. I'd try but I don't know enough about the 0.10 changes or the underlying heurestics to trust myself

you can try and if you write something wrong we'll say it during review

😛

https://github.com/zen-browser/desktop/issues/726

opened this issue for Zen browser - let's hope it is addressed, as I think the browser is very cool

Just reminder that you can vote for JPEG XL idea in Windows Feedback App. And I dont know any other way Microsoft recieves feature requests. Link: https://aka.ms/AAk3a38

wait, I can't access it from my browser ?

app only, log from a windows vm

You need feedback app on windows and windows account I think

Yeah, it's pain in the ass but it is what it is.

And to be on the Insider branch

https://github.com/Beep6581/RawTherapee/releases/tag/5.11 Rawtherapee 5.11 released two days ago, now supporting opening jxl files. Exporting jxl is currently in progress

I am not insider and even then I could post feedback.

Huh, for me it said I don't have access

Seems they've been having some issues with non-sRGB color spaces in this PR https://github.com/Beep6581/RawTherapee/pull/7097

It is on the roadmap for the 6.0 release, so there is a few weeks or even months to get it right

> Building with libjxl 0.7.x why are they building 0.7.x [av1_monkastop](https://cdn.discordapp.com/emojis/720662879367332001.webp?size=48&quality=lossless&name=av1_monkastop)

is ubuntu that far behind?

Even Fedora 40 only has libjxl 0.8.3 in the repos <:PepeHands:808829977608323112>

the only thing more out of date than Ubuntu is Debian

Debian is also on libjxl 0.7.x, same as Ubuntu

0.10 in 24.10, supposedly some symlinking to a newer libjxl build in the 24.04 lts

I mean, in general, not just libjxl

true

to be fair, debian kept asking for help packaging. fresher builds there trickles to a massive number of derivative distros

The PR I linked bumps it up all the way to 0.10.3

Maybe if creating a debian package and reading their documentation didn't make the average person want to throw themselves out of a window, they would have more help with packaging.

Just curious - are there any news about introducing jpeg xl to pdf?

I would love that too

honestly I'd love to just get rid of PDF altogether

And replace it with what?

"Your account doesn't have access to this feedback"

What

ok, this is weird... now I cant find my own feedback post in list of posts I created... and when I search for jpeg xl it doesnt shot this feedback

but i can still access it with link

html <:CatSmile:805382488293244929>

of course we need browsers to support JXL though 😮‍💨

If you cant access the previous windows feedback post I found another one someone created. Maybe this will work. https://aka.ms/AArzb7k

There is a fundamental difference between PDF and HTML though. PDF is all about doing page layout in an interoperable way. HTML is about representing information in a way that can be adapted to various media, mostly screens (with wildly varying viewport sizes). One is about having a fixed layout, the other is about having a flexible, reflowing layout.

sure, but who uses print media these days?

When I search for car manual online I prefer pdf instead of html pages even if I don't print it

epub for text documents. jxl for graphical documents. docx or odt for documents that need editing. Not sure about forms

the only niche pdf is good for is combined graphics/text that must be displayed in a predefined manner and is not supposed to be edited in any way

unfortunately, it got used for everything

including delivering malware

Document formats such as odt or docx don't appear correctly on systems where fonts used in those documents are not present. PDF embeds the fonts, so the document will look the same in all viewers, systems, devices. EPUB is a nice, variable format, but OOTB support is sparse.

It may be possible to embed fonts in odt or docx, but it is not default behaviour

That one still says no access, but just searching "JXL" gave me this <https://aka.ms/AArzizt>

Everyone...?

Print media is still vastly superior to screens... requires zero active power consumption, vastly superior dynamic range, lightweight and convenient... Everyone still uses it and it's not going anywhere.

Less eyestrain too

eink screen ftw

isn't eink patented to hell and back

DR depends on both lighting and the contrast in the media. Even on the whitest of white paper, with the best inks, and reading in direct sunlight, you'll still have less DR than even a half-decent display.

it's quite an annoyance when printing, believe me 😩

there are some special inks (or pigments, really) for printing on metal that can be better, but that's the exception and not the norm

Then why do half decent displays look so much darker and harder to read in direct sunlight than a cheap piece of paper with cheap ink from a cheap office printer?

If it actually was better, then it would be more legible, but it isn't, so it's not

well you're comparing the most optimal setting for print vs the least optimal for a display

if you're going to compare, at least do apples to apples

because in those specific conditions, its backlight has to compete with the sunlight, whereas the paper benefits from it

The backlight can't compete with sunlight at all. That is the whole reason why paper has better dynamic range.

A white sheet of paper in the sunlight is brighter against the black ink, than a digital display's maximum contrast. Unless you have a screen that is as bright as a white sheet in the sun.

And if the screen really was as bright as a white sheet in the sun, you could take the screen outside and compare it

in sunlight

move indoors and many screens have a distinct advantage in DR

or at night

or on a cloudy day

It seems incredibly obvious to me that, screens actually have really bad dynamic range, compared to... the dynamic range of real life.

screens and paper+ink are both part of real life, so why would that be obvious?

dynamic range is pretty much the ratio of maximum to minimum signals; most displays emit their own light so that already means that the higher bound of DR is probably going to be higher than paper’s in dim environments

if the lower bound is closer to black than “black” ink is, as it can also be with many current displays in dim environments, there’s no contest DR-wise

The dynamic range of paper is only limited by how bright your light source is, but the range of a screen is determined by how bright the backlight is compared to the ambient light, and the difference between the darkest and brightest region on the screen at the same time. There's a lot more limitations there

no, it’s also limited by how black your ink actually gets

Of course, but it scales with the brightness of the light source, whereas a screen backlight power is fixed at birth

and the fact that the reflection is diffuse means that “how bright your light source is” might have to be _much_ brighter than it would have to be for a screen

Mayybe <#806898911091753051>, I can see this going on a while xP

Your eyes will always tell you immediately what is easier to see

(which will also reveal how not-black the ink is)

hm, are we talking about different things? (me: simultaneous DR, vs. you: overall range across all environments)

Well, a bright screen in the darkness will definitely do better than a sheet of paper.

Unless you put that paper in sunlight.