JPEG XL

I hope devs could improve libjxl based on this feedback! The ease of integration would boost adoption

by “a proper CMake target file”, I think they mean a file such that users can eschew pkgconfig / `pkg_check_modules` altogether and just use `find_package(JXL)`

they posted an issue on the repo for vcpkg: https://github.com/microsoft/vcpkg/issues/33390

Seems they joined the server, hopefully we can help

yeah cause when I was trying to look into the build system stuff myself I honestly didn't know what I was even looking for

fun fact, with pkgconfigure `libjxl>=0.7.0` will break on windows since it treats >= as library name

FYI, AVIF got dropped again because the libavif library was crippled without libyuv.

And the latter was incompatible with MSVC.

Now, does libjxl compile properly on MSVC? I couldn't get the pkg-config files from vcpkg to work properly.

Correct.

The library is certainly supposed to work, many Windows applications use it. I'd help try to figure it out, but I no longer use Windows.

Might be worth opening a GitHub issue about it?

Yes.

And it needs to concern vcpkg's libjxl port.

I'd attempt providing a libjxl CMake target entirely on my own, but I don't have that much time to devote to it.

most libjxl developers are in Europe (I think), so they'll probably see this tomorrow

indeed, even all 😛

i never had to do with vcpkg myself though

even more specifically, currently all in the “Central European Summer Time” (CEST) timezone

(but also in the weekend)

oh yeah, currently being jobless I've lost track of weekdays and weekends

It compiles properly when I use it from within Visual Studio for my Paint.NET JpegXL plugin: <https://github.com/0xC0000054/pdn-jpegxl> I use the vcpkg Manifest Mode (<https://learn.microsoft.com/en-us/vcpkg/users/manifests>) with the `x64-windows-static` and `arm64-windows-static` targets.

That's for MSVC solutions. Whether the CMake way works is what I'm asking.

Yours also appear to rely on MSBuild getting things right with regards to vcpkg static libraries so that's essentially dark magic.

Perhaps, but as vcpkg was originally designed as a package manager for MSVC; the MSBuild integration should be extensively tested. When I installed the `libjxl:x64-windows-static` package it did not display the cmake package name in the console, but the cmake package name is displayed for most other packages (e.g. libwebp). I am not sure why that is.

I thought games used DDS, KTX and other GPU-dump texture formats? Unless it's for user-editable skins or user-viewable photos.

GZDoom is basically the Doom engine (from 1993) except with more advanced scripting and graphical features. So usually for textures there’s only single albedo map with all the shadows and highlights painted in, instead of modern games with normal maps or PBR stuff. It’s very old school

Doom was made before GPUs were even a thing, it was originally software rendered with palette indexed textures. With GZDoom, you can use PNG true color textures if you want and the engine also supports shaders but some people prefer not to use the more advanced graphical features because it’s too far from the visual design of the original game

GPU texture formats kinda suck

They only make sense if you have certain particular high perf needs.

I mean id Software's Rage game used JPEG XR compression.

Interesting! The whole megatexture thing was a cool idea but I guess it never really took off

A lot of that tech was still used in Doom 2016 afaik

But yeah GPU texture formats have rather poor compression ratios. If you want to compress stuff really tight, like with the megatextures, you gotta use something else.

there is also Neural Texture Compression (NTC) with better compression, but most likely it is a proprietary format only for last gen gpus > The continuous advancement of photorealism in rendering is accompanied by a growth in texture data and, consequently, increasing storage and memory demands. To address this issue, we propose a novel neural compression technique specifically designed for material textures. We unlock two more levels of detail, i.e., 16X more texels, using low bitrate compression, with image quality that is better than advanced image compression techniques, such as AVIF and JPEG XL. At the same time, our method allows on-demand, real-time decompression with random access similar to block texture compression on GPUs, enabling compression on disk and memory. <https://research.nvidia.com/labs/rtr/neural_texture_compression/>

The Nvidia game overlay still uses JpegXR for HDR screenshots, windows renders the thumbnail and can 'read' the file too but tends to mess up the colors and read the HDR data as a comment instead

Megatextures are mostly used for terrain, since smaller objects might be replaced or updated in future

Generally to still have support for older hardware, most games are limited to BC1 - BC7, then usually compressed into larger game packages that bring the size down to reasonable levels. You'll find PNG textures on procedurally generated or highly moddable games too, since they only need to be read once and then stored in memory, would be quite a good spot for JXL to take over

Oodle is often used in games: http://www.radgametools.com/oodle.htm

As far as I understand, now it is used in the Unreal Engine 5.

Decompression performance is extremely critical for games with a lot of large textures.

Oodle is still just BC compression, difference is they preprocess to make it more efficient, then use Kracken or similar on the files after

https://www.gumlet.com/blog/jpeg-xl/

Also https://github.com/libjxl/libjxl/issues/2784

Jon gets to disable the cryptominer in libjpeg-XL and still feed his family <:Poggers:805392625934663710>

The "first CDN" made me wince a little, since Cloudinary has been running it

Did they turn it on by default?

Testing on Waterfox, both CDNs are sending JXL automatically

tried the cloudinary blog in firefox stable (serves the jpegs and pngs as avif images) and thorium (serves sometime heavier jxl for the same, whole page is still lighter and faster to load)

their demo is broken, lmao

it serves `https://demo.gumlet.com/sea.jpeg?format=jxl&v=2` when it should serve https://demo.gumlet.io/sea.jpeg?format=jxl&v=2

indeed 😄 .io instead of .com

https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idc-p/39463/highlight/true#M22999 "jxl flag was pushed to the stable channel but it’s a flag, and jxl animations don’t work 😅" ?

Not seeing much movement on here, but there are issues open for all the missing features at least https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

It's a little confusing, but > ... but it’s a flag JXL is still not available in stable Firefox, despite the presence of the flag :c

It won't be in stable until the other issues I mentioned are fixed. Not much use being in stable when it has less functionality than a bitmap

It's been like that for two years already.

food for thought. jxl supporters do a lot of asking when IMO jxl patches should be contributed to projects that might be lacking the expertise to implement it themselves

even with firefox a more current patch couldve helped, and demonstrator unofficial builds of firefox. perhaps something folks from firefox forks could help with ?

the issue is someone has to review it. An up to date patch isn't going to change that

a working patch is far easier to accept upstream

it should be made though, not necessarilly merged

a lot of firefox forks have up to date patches, that is not the issue

im not sure but the patches that are sitting in firefox tracker might even still apply cleanly

it's not about just accepting. Someone has to be assigned and spend paid time on it

clearly to expensive for firefox xD

it's typical. When it's not priority it'll basically never be seen

mozilla pretending that they "prevent chrome from dictating the direction of the web" is massive kekw

webkit supremacy confirmed xD

my company (Corel) has never heard of jxl

I'll tell them to add it when it's released on macos/iOS

pain

I think they're open to it

is it still in beta? I dont follow mac products much

I thought I read here it should be fully released sometime soon

what was that new completely independant browser called again? I wonder if that could get jxl support

please dont say its Arc

ah ladybird

https://github.com/SerenityOS/serenity/tree/master/Ladybird

oh it does support it kinda

Kinda is the word, it only supports a subset of modular images

iOS 17 will be released on the 18th, so JXL will become available to millions of people next week.

why ?!?! doesn't Corel does some technology watch ?

webp was just added

that's nice 🙂

😂

webp being more than 10 years old, jpeg xl could be expected in a few years 😄

How well will the jxl support work at launch? Alpha, proper color management, animation, HDR?

in Safari Technology Preview on my macbook, it looks like SDR images work, animation works, but alpha is broken, proper color management is broken (or clamps things to sRGB, I dunno), and HDR is broken too

animation didn't work on iPadOS 17 public beta

tested with animation_icos4d in jpegxl.info test page

wide color gamut worked

wide gamut meaning P3? or BT2100?

since iirc the displays are P3

On the test page, everything except animation works on my ipad

Funny, webp animation has rendering artefacts, but apng does not.

Very small images don't render either

Odd, I just said on another server how webp has suddenly seen mass adoption in the last few months after being stagnant for a decade

considering they are fully colormanaged, as long as the image is supported via apple's management pipeline it should be mapped properly I would think no?

well as properly as possible anyways

yea I was just wondering what they meant

heres to hoping wayland colormanagement wont be trash so we can actually have a good thing in the color world for one xD

JXL support indeed is a mess on Apple platforms from what I am reading here.

Not that it will ever reappear in Chrome.

why do you think that? predicting the future is hard...

is support for the additional features mandatory for spec compliance? I feel there a huge case to be made for simple jpg-tier jxl images (flat, no transpartency or layers, no animation, within resolution/colorspace limits of jpg and png) since its a target for lossless transcoding from jpeg

that is a pretty risky and undesirable thing to do as it creates fragmentation and if a reduced version of the spec gets popular then there's a chance that only some programs will support all the features

I think the original spec for JPEG 1 had support for up to 12-bit but no one implemented it so we are stuck with 8-bit JPEGs because almost no one followed the full spec

There's a reason why mozjpeg has a flag "pointless spec compliance" it does a bunch of things no decoder written in this century cares about due to the implementation deviating from the spec

so undesirable for the decoders, but it seems a provider could still encode simpler lower complexity jxl images if just for consumption by their own decoder (for say a desktop/mobile application or game or an image host service recompressing images uploaded)

At that point Jpegli probably wouldn't be far off, or just JXL transcoding

Probably instead of using more it uses less

We will likely at some point define a lightweight profile, which will be what hw decoders can handle

But for SW implementations it would be best if they just implement everything.

There is a tool called fjxl that does this. It gets ridiculously fast encode and decode speeds.

Though it does lossless IIRC.

fjxl has since been incorporated into cjxl e1

Including the fast decode?

there never was a specialized decode in fjxl 😛

So it was just really fast anyway? Nice.

there are some special-cases in djxl that make it a bit faster for fjxl-produced files

That must of been what I was thinking of.

iOS 17 with JPEG-XL support released today

That was fast

the wikipedia page lists JPEG XL as just being added to Safari even though it's system wide from what I remember

although now that I think about I'm not sure if Apple directly said anywhere that JXL is supported outside of Safari despite the fact it is

Yeah, it's not listed in the IOS 17 features at all, including the 'full' PDF. Suppose they think it's only usefel to developers

as far as I know its added everywhere due to how ios, macos and related handle image formats. safari can decode it in websites, gallery can read jxl, games and apps can display jxl images and have them decoded without any extra library added by developpers from apple or the apps

it works in image viewer at least

can 'save image' fine too. and uploading image in siskin (xmpp client) picks it up as proper unmodified jxl

as in ``` % b3sum IMG_0006.jxl F255Eaga0AAwJGk.jxl 1e37b822ad206eb88f3cef6b29fd017675c61282135fafd73b0f818f66da940f IMG_0006.jxl 1e37b822ad206eb88f3cef6b29fd017675c61282135fafd73b0f818f66da940f F255Eaga0AAwJGk.jxl ```

though siskin doesn't show preview which i suppose is something client-specific

'files' doesn't show thumbnail, but opens it fine. a bit inconsistent but it mostly works

like, thumb is visible in camera app

Best way to view or create JXL on Android?

Shit

likely not best, but as a reader: oupson's jxlviewer, available from fdroid and izzyondroid (fdroid repository with lots of recent apps not qualifying for fdroid's own store)

theres frameworks such as imagemagick with decoding available but the gallery apps using them need to update them first and then ensure jxl is enabled

thorium for android is a browser but hey if it works it works

firefox nightly for android also allows you to enable the experimental flag, and probably even the desktop addon that claims to add third party support which i haven't tested (you'd need to put it in a collection using a firefox account). natively, it only really works for images that are 8bit channel depth, without transparency or animation (which is true of nightly everywhere)

I honestly don't understand why imagemagick is used so much when there are such better libraries available

Mainly libvips. And to an extent graphicsmagick as well

at some point projects need to reinvent themselves. its not easy ditching all that legacy and new cleanroom created equivalents rise, no issue with that

Same reason why the upgrade from IM6 to IM7 is taking ages — once an application has integrated a library with a certain API, it's work to redo the integration now with a different API.

There's also the fact that if someone search for some solution, it's almost always on archived IM6 forums. It's never IM7. Plus some changes don't even have any clear reason (why reverse alpha?)

It also helps that imagemagick is very well battle tested now (in part thanks to imagetragick). imagemagick gets some decent cve bounty payouts, this makes imagemagick, even if slower, realtively more "safe" to use

not to say that libvips or graphicsmagick don't enjoy a large amount of the same support, it's just if they do, it's not as publicized

The 0=opaque thing in IM6 is confusing and I think it was only that way so zero-initializing a buffer and then not touching alpha gives you an opaque image instead of a fully transparant one. But IM7 went from fixed interleaved RGBA to planar, if I understand correctly, so no longer needed to have a wonky alpha convention.

also i dont think libvips or gm have polar/ewa resampling, though i doubt most people care about that

The day after the iOS 17 launch (Tuesday Sept 19) we counted 181 million user agents with image/jxl support, up from 34 million on the same day a week before (Sept 12).

Curious to see the numbers next week.

how can that be counted?

the 34 million are already slightly surprising, do that many people install the iOS betas?

sorry it's just request counts

so in hits, not unique user agents

Cloudinary's servers logging the requests for images coming in

shopify is probably a bit happy right now since they're adoption is paying off now hehehe

does anyone know a shopify shop I can visit to see it in action?

iirc arace.tech uses it

Do you have statistics for how many requests an average useragent generates per day?

yeah arace.tech uses it https://arace.tech/products/milk-v-mars

I got a webp from that page RIP

I get jxl, how do I know? because on vanilla firefox the jxl extension is bugging it out lmao

lol

I have that extension, and I get a webp

interesting

iirc I modified my firefox header to always report jxl support so maybe it's that? I have no idea

not right here. Anyway absolute numbers don't say that much maybe — we went from 0.18% jxl supporting user agents on 2023-09-12 to 1.16% jxl supprting user agents on 2023-09-19

that number will go up as people are still doing the upgrade, of course

that extension needs an update, even on the info site it doesnt display all jxls available though they exist and has trouble with sites spoofing the real type of their images (ie claiming jpg are webps)

maybe it's going by accept header order /j ``` Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5```

Did any of the core team respond to this?

Yes

pain

<@794205442175402004> crypto promotion

Thanks, deleted it and kicked the spammer

what about with the updated patch that someone posted in the comments [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1709814) ?

ah I see

That looks like it is using a non-premultiplied buffer and rendering it as if it is premultiplied

waterfox renders it fine

works on my firefox

yes that one fixes it

wait what about D122159?

are these patches applied by the official firefox ?

I missed something... is the official 117.0.1 capable of displaying jpeg xl ?

nightly versions of firefox have had basic support for jpeg xl for a while but there are pending patches to make the support better however mozilla has not merged them into firefox

ok, it didn't changed overnight 😄

I didn't know open build services 🙂 I'll have a look. I understood the sources of firefox and the build itself takes some space on the disk

I don't think the order in the accept header matters

but I guess it's up to website on how to interpret it

This is the header Safari sends: ``` Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5```

you should modify accept headers should present the format you want first, this simply helps because programmers are not gods and people can make mistakes.

yeah but first to last or last to first

Also depends what order the HTML is listed in if they're just using picture tags rather than automatic CDN

it says that values in the Accept header are prioritized first by q value (which is 1 when not specified), and then by specificity

``` MIME type q image/webp 1 image/avif 1 image/jxl 1 image/heic 1 image/heic-sequence 1 video/* 0.8 image/png 1 image/svg+xml 1 image/* 0.8 */* 0.5 ```

so it's asking for webp/avif/jxl/heic/png/svg with equal weight, then just any image or video, then any file

picking between webp/avif/jxl/heic/png/svg is fully up to the server, sometime they're smart and send whichever one they have they think is best, sometimes they're dumb and just send the first one listed they have

A server can basically always do what they want with the Accept header

Yeah we only use it to know what formats are supported, not to prioritize one over the other

Priority is useful for something like the (human) language of a page, but for formats, not so much imo.

Unless it would really be a user preference or if it makes the difference between hw decode or not (for video)

Uh...

So I'm using the moto camera app and it takes pretty buttfugly blurry images...

Does anyone have a camera app they recommend?

JXL support would be nice obviously but I don't expect anything nice from the globohomo ecosystem

Sometimes known as Google Play Store

Discord

Simple camera

https://play.google.com/store/apps/details?id=com.changpeng.pro.camera.hd

it seems i can never get a straight answer for which android *devices* support RAW though

Expert RAW Camera by samsung works on a small number of galaxy flagships. once installed, it can be invoked as a mode in the regular camera

tfw app says raw but its still denoised T.T

i *can* turn off denoising in open camera, but i can't save truly losslessly (the png option converts from 100% quality jpeg)

the images being in dng raw isn't going to magically make them look good

at some point you just give up because you're dealing with a tiny phone camera

imo it's better to have the processing esp if you can get Google's processing

Does this support jxl?

If gcam works on the phone, it should support raw.

it does give more flexibility however. I used to use an app called motioncam which let you record raw (dng sequences compressed with zstd). am impressed with how much you could phenagle out of it

just focus on taking the photo

that's a group that doesn't completely overlap with what HCrikki said, especially through official channels for gcam (which only allow pixel devices) so > it seems i can never get a straight answer

camera2api reports whether or not the device supports "raw" capture

nearly all modern devices should

i have partial camera2 support on this 2019 midrange samsung (a30, android 11) arguably since it's near OS EOL, it's not modern? but i plan on getting another year-of-release midrange samsung next time and i just get the feeling it still won't support raw

download a camera2api checker app and see

with this one? i did. with future phones i just. want to check *before* buying. and i've been having this whole conversation in the wrong channel

ah you can chheck here https://camera2probe.com/list

not all devices are on this, but most popular ones are

I understand that JXL support on iOS/iPadOS 17 doesn't include many useful JXL features. Is there a page with image demos for all these features to quickly tell what's there and what's missing?

The raw on this app is ugly

Not even 1mpx of full resolution

Unless you want selfies

But selfies chenpeng is the only one good

But zero filters

You will see 6mpx of ugliness

The ones i recommend are more updated

Freedcam is also on the store

But the app i have are on another level

A30 good for panoramas

If you want to take photos phone shouldn't be used

Focus on get a better app that is a ssexons in to do

Opencamera noise denoising even at 100 iso it is broken

It saves full resolution

But it crashes

Literally is worse on every version

But I have bad Xiaomi with Samsung gn1

My phone is for selfie filters

Not for doing what Samsung does

thanks for the advice, i'm just a hobbyist that likes to mess with image data. if i needed good photography i'd use a DSLR

JPEG XL just do s9 d 0.823 i 0.4

Unless JPEG XL 2 comes

Codecs will evolve and Jon will publish an updated standard before AV4

Developers don't spoiler work

To get raw only cameraraw works

Photon camera is just 32bit with opencamera based downsamples

And without 41 frames motion and gn2 Samsung and higher processor than i3 330m or snapdragon 780g

It will take nothing

Only a photo

With ugly quality

And also need to be downloaded on Telegram

Also it get updated every 2 year by university of china

wIth Java code

Imagine encoding 200mpx hp3 photos on mit13

It will not open and you need february 2025 to get a build

I don't know even if it has Android 14 API

many require rooting to bypass increasingly common chiplevel filtering (chinese brands mainly) and capture raw

imo the only player consistently excelling in pro photography is sony with their xperia pro line. raw, 12bits (most raw-capable phones capture in 10bit), hdr, expert options and everything. so damn good most system info apps fail to report everything

hence the quotations on raw, not that raw really makes sense as a term, raw is more of a marketing buzzword at this point

That would be great, but I'm not sure how complicated it would be to create. It would be nice to have even just a reduced list of things like animations, progressive decoding and whatever makes sense to have working in a browser

There is a vivo or 24 ultra with 18bit pipeline and hdr to raw

Those are rumors but vivo has 990imx sony specialized

And the Galaxy s24 ultra said is even Better

Like 52 mpx

The iPhone takes 24mpx photos

I don't know the quality of s24 ultra

Is from may that HDblog said its retrocessed

And that has two hardware options

And also the camera was destined to be used on another year

So s25 ultra will have s24 ultra cam

And anyway the processor it doesn't change nothing relative to camera

Samsung has already the s25

And s23 ultra

Is s23 ultra more efficient

So you need a battery charger

And only 20watt charge

600 euros more than the iPhone

Those aren't rumours

At least 7 months we know them

And official photos from Samsung not leak by an author were released 2 months ago

So we knows the colourations

And price super high

an alternative to python http server is miniserve

You pay for the nm

miniserve is super nice

And qualcoom gen 3

Will be out on 26th october 2023

On October

And no rumours about the location and requirements for the processors

And on September gen 3 is already deployed

So s24 ultra will enter italian market on november

Thanks for the testing! I hope we can soon finalize the new decode API w.r.t. color management, and then update the integrations so they do everything in a correct way.

Does it support http resume

Ok. So twisted (twistd) is good enough for me now.

I think image booru will love jpeg xl lol, it should reduce costs of running such a site in a very real way

And those are webmasters that don't have a lot of money to begin with

Honestly I am real surprised there isn't more support from booru software and administrators

thats because most boorus are old or just dont care. a software called blazebooru uses image-rs I have a fork of that using the image-rs work. and it works ok

the cost difference is pretty negligible even on the terabyte scale

I think it may only matter if all individual images are really big and actually affects ux

and if they are originally png

sometimes Ill open dozens and dozens of images on booru type sites and it's annoying watching them all load in incredibly slow and in some cases ill even get rate limited by the site which is also annoying

sites retaining original copies of the files are still better off internally storing them as jxl versions in place of bloated png and highest quality jpg

what one calls bandwidth is another's storage. higher efficiency would help imageboards and image hosts (like say photobucket) increase margins or simply stop taking a loss

storing/serving jxl? do you have a link to a live install?

not atm

I know of the Doujins and LiveBooru sections on <@288069412857315328>'s site, also displays space savings and encode options per image/manga https://grass.moe/

only traffic is me and it is not worth it even if it were 10000 people

but it's fun novelty

Seems like a good weekend project for the more experienced coders in here, while also giving a nice boost to adoption https://github.com/OpenImageIO/oiio/issues/3908

I was looking into oiio support awhile ago, shouldn't be too hard to add but I never got the time to look into doing it

someone knows the currently popular manga/comics readers under windows ?

just use tachiyomi under WSA

I was looking for the ones which are NOT compatible with jxl yet to flood their issue trackers 😄

but popular amongst non geeks in order to maximize the efficiency

(I didn't even know WSA was a thing... I'm so 2010)

Wouldn't the space savings from JXL directly reduce the cost of running the image board by that same proportion?

either fixed cost or not that much of a difference due to fixed base cost

and egress is basically free now

i imagine it's more like you have options of 10tb, 50tb, etc. and you choose 10tb

it's not like you can choose 7 tb

just because your data is only 7tb

even for object storage the savings are fractions of pennies

I see

Approximately the cheapest rates for reliable bulk cloud stuff is $5/TB/month for storage and $10/TB for egress bandwidth.

it depends a lot on how you are hosting and your traffic and how you store the images

for some people jxl would be peanuts, but for others it could make a massive difference

Yes, storage and bandwidth are often major expenses for actual proper websites that lots of people visit.

Not sure how I feel about OpenImageIO given the apparent lack of APNG support.

At least they seem to be very open to pull requests

comicrack

it has a plugin that adds decoding of jpeg-xl and avif (separately downloadable?). based on old code though https://github.com/faqy003/ComicRack-Plugin-MIFS

author kinda disappeared with the site this year but you can grab comicrack wherever

theres also YACreader. actively developped, seems a quick dll insert adds jxl decoding (not part of regular install yet?)

https://github.com/YACReader/yacreader/issues/385

yac has an upcoming release, maybe worth asking to add jxl out of the box or handing him working updated code to merge ?

macos 14 'Sonoma' releases tomorrow, with jpeg-xl read support available across all operating system

some articles coming up oddly dont mention jxl. its like they go the extra mile to deny its existence and importance

🤷‍♀️ Normies don't care about a new file format that much especially if it's not going to be the default

the gains are passively obtained even if you dont care about those at all and have no idea what formats are even used

with image formats the public discourse is commonly about bandwidth but whats bandwidth to is someone else's storage. take dvd, bluray and newer codecs, noone ever opposed their introduction even though they had no web-facing use at all back then

I think most of that is from Apple not listing JXL in the features, or anywhere in the changes when I tried to look

apng is more or less a toy for oiio's usecase and userbase, but they would indeed probably be open to a pr

I don't understand what you're trying to say. Why would anyone care about the web in relation to DVD or Bluray? Newer proprietary codecs are used by TVs and broadcasting if nothing else, so they get a lot of use regardless of the web.

I would also love to see a test page with wide color (P3/adobe RGB) and HDR images. it seems that in general apple operating systems handle wide color spaces and HDR really nicely compared to Android, Linux or Windows

https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php

thats because apple is the only system with a fully colormanaged pipeline, linux kinda has some hacks with colord but it's crap, android kinda gets away with it since everything pretty much runs fullscreen it means each app can more or less take exclusive accsess for the color pipeline. Windows has opt in color management however this only kinda works for applications that are colormanaged themselves, it's not that great but better then linux which has, like I said colord and thats it, Wayland should hopefully change this sometime in the next twenty years xD

kinda reminds me of HDPI stuff in windows. it's today better than in 2016 but you way too often run into apps that have broken UI unless you go to the compatibility settings and force them to use system DPI management. but apple was like "fuck it, render everything at 2x then and scale the framebuffer to monitor resolution" and basically all the apps ran pixel doubled until the developers implemented HDPI support with an explicit flag

windows now also has an option to do system-wide color management

oh? I wonder if it's any good.

also https://gregbenzphotography.com/hdr/#gallery1

pre-Windows 11 color management is similar to what it’s like on Linux/X11 as far as I know

it’s the equivalent of what you get with colord+lcms2

you can ask for the ICC profile for the output device (as with colord), and then you can create and execute colour transforms to that profile (as with lcms2)

but besides doing color management correctly, does it have > 8-bit buffers?

ill have to look into how win11 handles it for sure

Just got macOS Sonoma installed, it seems like JPEG-XL images open in Safari by default? Seems kinda weird

I guess it doesn't list Preview as an app with JXL support, even though it opens sRGB JXLs by default without issue

Feel free to open bug reports (with Feedback Assistent or how do they call it) so these things get sorted out — that's probably an easy fix for them...

Now we are at 3.61% of user agents supporting JXL.

AFAIK there is new PNG draft with APNG being part of it

Wayland is part of problem, not a solution. What's wrong with colord?

how's wayland part of the problem? they're working on color management as we speak

colord relies on the applications to do transforms and conversion. applications cant even decide in when to use a srgb curve or a pure gamma2.2. its even worse when the application does not support the display profile because then it doesn't become color managed at all

completely unusable

Hello 👋 Since there are now devices in the wild supporting JXL, is there a a recommended idiomatic approach for transitioning images on websites to prioritise the JXL version, and what the appropriate fallbacks should be?

The easiest way is to use <picture> with a jxl image and a jpeg fallback (or if it has alpha, you could do jxl with webp/avif and png fallbacks).

~~only serve jxl so we can spam report sites as broken to firefox and chrome~~

that they are only doing this now is somewhat illustrative of the problem, see some of gwgill’s (argyllcms author) and fhoech’s (DisplayCAL) replies in this thread: https://discuss.pixls.us/t/wayland-color-management/10804

they recently posted a doc detailing the general process that a compositor should (could?) take https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/bb44957a29c49232c3f94530e92617f6e8fc9d36/doc/color-management-model.md

it's still pr stage

it's not the most useful document in the world, but at least there is some progress, in the end I feel like any color work is still gonna be forced to use stuff like decklink still

Well, only application knows color space of original picture. AFAIK there is libcolord for converting colors between color spaces and it supports all color spaces that colord supports because it is colord. And if some color space is not supported, then same thing can happen to wayland.

.

Discord... Never works properly.

> the compositor does on-demand color-corrections from buffer colorspace to display colorspace only for visible frames (saves a lot of perf), possibly on GPU (for now, AFAIK, graphic libs are not multi-threaded and super slow). Hmm.... Sounds nice

Brute force way of doing this. I suggested this way before, but it's a nuclear method and could likely cause issues.

isnt that the point

But that's what Google did to force webp down our collective throats

And it apparently worked

They started using it with no fallback

only when the user agent was chrome, I thought

And then everyone cucked and adopted it even though they were "against" it

yes only application knows, but the application should merely say "this is what the image is so render me like this please"

This sounds more like X-way than Wayland-way

That would make it even weirder for browsers like Firefox to adopt it when they invested money into making a jpeg encoder to prove webp sucks and can't even beat jpeg

nah, the x way is to just crap itself

issues are intentionally the goal

The app should not be expected to be aware of and manage hardware such as monitors.

webp does beat jpeg at some quality levels, and webp lossless beats png by a good bit

sadly though most websites and CDNs don't make use of lossless WebP, the only thing I can think of that uses them is Fandom wikis

Webp lossless would be nice if it wasn't part of webp and all the limitations it has and the useless lossy algo that was the original form of webp

I dont think the app should be expected to do much, app devs can often be stupid, relying on them too much

Tumblr uses lossless webp for animated content

The lossless mode is literally a completely separate codec that was added to webp later instead of being its own format like would make sense

All that apps and app developers should be expected to do is, pass along the color space information of the content they are displaying so that the graphics pipeline (video driver, compositor, whatever) can convert that to be displayed correctly on the attached video devices. Remember that the app usually doesn't even need to know if it's being displayed on multiple monitors simultaneously for example in mirror mode. That is really up to the compositor to manage which windows show up on which monitors

Or even have a window partially on two monitors as you drag and drop across monitors

Obviously all that should be seamless and managed by the video drivers and/or compositor, not application. That is absolutely braindead to expect the application to have to be aware of that

Unless it is a monitor calibration application...

well, kinda, I think that is the approach most general software should use, but software using things like ocio ofc will do internal conversions themselves, it will be up to the user to properly specify output and stuff

All the application should do is announce, "I'm displaying content in this ABC color space," and that's enough information for the rest of the system to display it correctly. And if an app doesn't announce what color space it uses then maybe there should be an implied color space to assume if not specified, plus a warning somewhere that the compositor can throw saying that a window was displayed with implied color space information.

If an application displays content in multiple color spaces then it should be the job of the application to convert everything to a single color space for display.

you would typically imply a pure 2.2 if it doesn't respond with a color profile

Or maybe create a sub region of the window with a different color space

that should be possible with wayland surfaces I don't really care enough to look into that yet since the color management protocol is still far away lol

as a related side note to that doing "dumb" stuff could break things like xyb profiles

I guess if you have mixed content with different colorspace information within the same app, then the app has to be responsible for converting everything to 1 color space for display, and there should be a way to ask the compositor for a suggested color space maybe...

Or maybe a simpler solution exists, but if there is I can't think of it

> there should be a way to ask the compositor for a suggested color space maybe... This is a GREAT solution, too bad you are talking about wayland developers

too insecure for them LOL

Like having multiple regions of different color space within the same window seems like it would be overcomplicating things compared to letting the app be responsible

Well it should be an optional suggestion... the app should be able to just announce what color space it wants to use and the compositor should ideally just deal with it...

yeah optional things are still no go, wayland cant even agree on how to handle privileged extensions. wayland is super frustrating in general since its like it has the potential to be so good, but then there are so many boneheaded decisions holding it back

Like how it wants to replace X without actually doing any of the actual effort of making a replacement for it?

It's all just theory, not useable software like libweston

If libweston was actually useful for making Wayland compositors, people would actually use it...

Pretty sure more people use third party libraries like libsway since they actually do more useful work and effort that people actually want done for them when writing a compositor

There should be a way for the compositor to change its color space suggestion too

To the app

in the end, both X and wayland are just both crap

Yeah, that's why you can't convince people to use Linux, because convincing people to use crap is hard

Also it isn't all about Linux either

everything is crap, I miss the days of windows xp where I was satisifed with computing T.T

Linux users should keep in mind that one day they might want to use a different kernel

Instead of sticking with the same old code forever

And the same old mismanagement

Not saying that there's anything wrong with Linux right now, although there probably is a lot of things wrong at a technical level that will not get fixed because of compatibility with old crap

But you know, other systems are out there besides Linux and they do a lot of things better in certain specific ways, like OpenBSD for example.

So if X is getting replaced then its replacement should ideally work everywhere X is currently used. And it shouldn't require Linux-specific stupidity like dbus

Or udev

Or systemd

Or any of that excessively-platform-specific and overcomplicated crap

It should work on Windows and Mac ideally like X currently does

I'm just sad that Inferno never when anywhere. Even Windows NT is heavily inspired by Unix, and I feel that we should be able to do better.

JXL in GNOME web is great!

Well now that I have a great experience on Mac and Linux, I think the obvious next question is how do I have the most seamless experience viewing jpegxl on my Samsung smart fridge?

why only WebP has watermark?

Testing color handling to see if it strays from the expected behavior?

Lots of parts are rewritten

Anyway linux ABI can be implemented with different kernel

https://github.com/web-platform-tests/interop/issues/430#issuecomment-1745728757

Yeah but legacy cruft like that only holds us back from better and simpler ideas

Thanks, do you know if there is a programmatic way in the library to detect alpha in JXL? I’m thinking about image pipeline use-cases of allowing users to upload JXL and automatically providing the fallback image.

JxlBasicInfo alpha_bits > 0

Apple Pages supports JXL in Pages documents

It's really cool how Apple has such great support for jpegxl

I think the only thing they are missing is animation iirc?

Animated JXL works in Safari

as far as I know, HDR is the main thing missing

(well, I guess I am a bit biased in my assessment)

images definitely look HDR-y on my ipad, otoh no animations

yes, in native apps, it works

but not in Safari AFAIR

could be a difference between computer safari and iOS safari?

iOS Safari is where I tested, I believe

ah

on an iPhone 14 Pro

I could get HDR in the gallery app

but in Safari, I think it was dark

Not sure how correct this is, but doesn't look dark or washed out

Eric Chan's images on csail mit look the same in Safari and the gallery. This is on an iPad Air M1

uh, that does not resemble my early experience at all

maybe they fixed it later on

for me, it’s currently tone-mapped

but if I “Save to Photos” and then open it there, it’s HDR

I distinctly remember loading that exact same image on Sami's macbook and it being awfully dark, uh, on Wednesday?

There probably is some difference in handling between Mac and iOS Safari, regardless of whether iOS Safari is actually doing the right thing.

here's a picture of exactly the same thing on the first beta and it looks about the same https://discord.com/channels/794206087879852103/803574970180829194/1115423466141794415

https://blog.adobe.com/en/publish/2023/10/10/hdr-explained

They've added import and export support to Lightroom officially. With this, the DNG 1.7 spec, and the github interop comment, I think it's safe to say that Adobe has 'soft launched' Jpeg XL!

🎉

🎉

<:FeelsAmazingMan:808826295768449054>

<:JPEG_XL:805860709039865937>

seems like they're using HDR JPEG for the blog post <https://blog.adobe.com/assets/hdr/media_1a2681319bc4a65c32a43fa4bbd9d0ec58e9dfc0b.jpeg>

seems to be jpeg+gainmap more specifically, as far as I can tell (which is not very far)

I thought I'd ask, can you import a DNG, then re-export using lossless JXL compression? Not used any Adobe products before so don't know what application you'd need or if it's possible at all, but I'd be curious how well it compresses if it can

it seems possible in principle but not yet offered by Adobe DNG Converter (unlike lossy JXL)

it accepts DNG as input, and recompresses them (or at least it made the DNGs I tested with smaller), but it doesn’t seem to use lossless JXL for that

with the lossy option, though, it produced 1.7.0 DNGs that non-Adobe apps (including RawDigger) couldn’t read, so maybe it’s using JXL for that now

hrm, I wonder how much better lossless jxl is compared to lossless jpeg. I assume the deflate option in dng has similar performance to png.

If they do eventually add lossless JXL as an option, then it could close a few DNG and RAW related issues floating around (Such as <https://github.com/libjxl/libjxl/issues/1492>)

Looks like Adobe might've wanted to wait for a settings dialogue to be ready before release, there's a few open discussions about poor quality with the new JXL switch (Filesize is roughly 1/5 of the old compression, you can find and compare the JXL file inside the DNG using a hex editor's search) https://community.adobe.com/t5/camera-raw-discussions/artifacts-with-super-resolution-on-lossy-compressed-dng-with-cr16/m-p/14149956

It does also mean Windows will fail to read any JXL encoded files, so who knows, now they have two reasons to add support. Both Native, and Adobe pushing

~~On Win11 built-in Photos show DNG preview only~~ It shows preview if it is present in file. If no - it seems to show real raw image.

eh, the quality of lossy DNG was already poor before

I'm on Windows 10 and in this instance I don't belive so, the DNG files my phone puts out don't seem to have any embedded preview at all, which explains why they take so long to even generate file explorer thumbnails

Here's the dump from exiftool, spent 20 minutes trying to just extract all preview files but nothing would happen, after comparing to a downloaded file it looks like there's no preview section near the bottom