JPEG XL

My interpretation of their messages is that they've got some bias or other unmentioned reason for not wanting to support JPEG XL. They simultaneously think some formats not having open specs is fine, but it apparently only becomes an issue when it applies to JPEG XL. This basically tells me all I need to know, this is only something you'd say if you specifically held a grudge against it, it reads like they think something is being unfairly taken from them: > But I'd imagine some users may feel differently (especially JXL's "enthusiastic" supporters who hope it will one day replace all other image formats...) I could be wrong, but I'm not holding my breath

I wonder how someone gets into developing tool for decoding image formats if they hate new and promising formats...

this sort of attitude kinda proves that guy right ('"enthusiastic" supporters'). it might help to have a more contructive mindset

Ideally we could round up enough interested companies to make this happen for JPEG XL https://pdfa.org/sponsored-standards

We already want to make it open, it's just ISO rules that keep it locked inside this server

should I keep updating this? 🙂

I'd almost say we need an in-between section for both wanting browers support *and* already supporting it themselves. DICOM said they want browser support, but will make do with WASM. Naturally Cloudinary, The Guardian, Shopify and Adobe already support it, and just want wider adoption. Facebook, Flickr, VESA and Intel are all waiting before rollout AFAIK

Facebook/Meta already supports jxl as an upload format

Basically there is no clear separation between the two categories, but I just put companies on the left and products on the right

(for some broad definition of "products" that includes container formats and various kinds of software)

Ah right, I remember it being discussed here before but thought we came to the conclusion it was some kind of iOS transcoding rather than actual support

No, they actually support it, even since before iOS did. You can upload jxl images on facebook from any browser or any OS, it will work. Of course they will transcode them since they cannot deliver the images as jxl, but ingress as jxl works just fine.

Huh, nice

smugmug/flickr needs an update smacked out of em before photobucket steals their thunder. photography sites need to be able to handle current formats and raws. And even if theyre not viewable in browser it doesnt matter. The files should be *downloadable* - whats shown in browsers is lower quality recompressed versions in multiple resolutions anyway Additionally, web services that have their own apps can support jxl regardless of browsers. Serve bloated jpgs and pngs to chrome, fast small jxl to your apps as competitive advantage even

yeah lol. And move Guardian to "already support" :)

they merged jxl-oxide

Could Pixelmator Pro be counted?

Ladybird sure should, as an actually independant browser that first made its own jxl decoder as part of serenity then integrated libjxl. for android users, Fossify Gallery - people have been waiting forever for one and awareness needs to be raised (not even mentioned in supported software or the info site currently)

checked package lists, seems all editions of *ubuntu 24.10 ship libjxl (0.10) unlike the main edition?

Worth mentioning that JPEG XL runs on Doom <:KekDog:805390049033191445> <https://github.com/ZDoom/gzdoom/pull/2133/>

That one got reverted though.

Ah, damn

why?

wasn't it compiler issues?

yeah https://github.com/ZDoom/gzdoom/commit/53d8a5bb2cb3b4f5576d9286731ad5a4bd972949

I wonder if jxl-oxide could be used here [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

The library was also deemed too big, and unfinished.

I remember it's one of the reasons this pull request was created for libjxl https://github.com/libjxl/libjxl/pull/2766

but uh yeah iirc other image format support in GZDoom was put off as a consideration for the future when stuff is more mature

jxl-rs, time for a C api

can someone clarify this point?

PS can only open jxl via Camera raw plugin, but can not save as jxl

the recent 2kliksphilip video about image compression mentioned using photoshop to export avif and jxl, what's up with that? third party plugin or smth?

IDK, ps itself can't save or export to jxl or avif. Maybe it was told about lightroom? Lightroom can export to both

Lr

does it have the effort paramater?

No

that really sucks

Judging from the closeups in the video, it seems like effort 3... Which is essentially a glorified JPEG

what's the p;oint then?

I dunno, ask Adobe why they keep using such weird and arbitrary restrictions

speed?

It seems like they never did any testing and just chose random values. DNG is tiles between group sizes 2 and 3, with faster decoding which cripples lossless compression, fixed effort 3 export in lightroom and [incorrect distance settings](https://community.adobe.com/t5/camera-raw-discussions/artifacts-with-super-resolution-on-lossy-compressed-dng-with-cr16/m-p/14153772#M23367) at launch Strangely the last was by MadManChan, who has been on the libjxl repo and posted to Reddit about converting his gallery to JXL and supporting the format. Yet there seems to be misunderstandings about the settings

Could be that they based it on speeds before chunked encoding was added, so someone would need to tell them to increase it after 0.10, but there's so many strange quirks I'm not sure that's why

Apparently he's actually in this server, not sure if the account is active though

Adobe is just a deaf wall to speak with. I reported them a bug in Lightroom 2 years ago, guess what they did with it.

I ended up writing my own app to do what lr cant due to that bug

```Added jxl support - #1358 Added avif support(via external C library, not enabled by default) - #1358``` https://github.com/qarmin/czkawka/releases/tag/8.0.0

> Added basic libavif library support(only 8bit, used C library, not enabled by default) > Added support for jxl files (only basic 8 bit RGB/RGBA files, with not optimal performance - it is really slow)

originally for some reason I though jxl was added via gdk, but apparently its oxide

(without rayon)

Does AVIF require a separate implementation or is it using AV1?

av1

well it still requires libavif

or libheif

it's a separate implementation...

the only thing it's able to reuse is libdav1d, assuming that's the decoder being used.

but that isn't enough to handle an avif image by itself.

if you only care about a single frame, you can usually get away with just an mp4demuxer, but yeah, you need a full avif demuxer for a proper impl

for a supposedlyy open format it has a lot of reliance on the miaf heif specs

which cost more than jxl

Cool button, ignore me pressing random stuff

Lol, I didn't know that bot could reply in-channel, I thought I had configured them to output only to <#805414133788180491>

That will not work if there's an alpha channel...

i think it's because it has Admin permission

you could probably get away with treating any second track that is monochrome as alpha, It's not super reliable, but I wouldn't be surprised if plenty of apps would never run into issues with it

It could also be a depth map

who is actually using avif with a depth map though

I hate discord and I also hate discord bots

And I hate how no matter how many times you mute the bot spam channel it's never actually muted

It’s cause you’re getting pinged

Pings bypass the mute

Can't we get rid off the bot?

you could just make it not ping people

I vote for getting rid of the bot

I vote for it not pinging people

Otherwise how would things like levels work

the level things kinda silly, I mean look at me, I type in broken sentences a lot so my score skyrocketed lol

Yeah I do that a lot on mobile

Don’t do it as much on desktop though

(I’m currently on mobile)

Some levelling bots have a thing where it only counts once per minute to remedy that

Not sure if Arcane does

I believe it’s supposed to account for that by not counting messages within one minute of one another, or something like that

Not pinging would be enough for me if possible.

If it went well, it should now only ping you if you get a new role, not if it's only a level change.

Because discord sucks

Yes

And it gets worse every year

thankfully, the levels are more and more spaced out as you gain them

therefore so are the pings

Indeed the bot pings are too rare to be a real annoyance

I've been getting pings for every level, so now it's a reminder of "Oh god just how much did I talk about upsampling last night" since there's no roles higher

Why do some websites think it's a good idea to use quality 100 JPEGs on their website

might as well use PNG at that point

quality 100 jpeg: 1.2 MB png: 1.5 MB (probably would be smaller if source was lossless)

jpeg xl -d 1: 250 kB

I was actually talking to an artist earlier who's been using max quality JPEGs because the gallery sites don't support WebP or JXL. Pointed out that using PNG with a run of PINGO (That they already have installed) would probably be about equal or smaller since they do flat colors

depending on the site it might secretly support WebP (Edit: I just realized you didn't specify it as being one singular site but what I said still kinda stands)

currently im on the amnesty international website

-d 1 isn't really Q100

i know but you don't need q100 for a background on the web

my point was why are they using lossless / near-lossless for web backgorunds

develop locally on intranet or fast fiber and you lose touch with web performance

sites like epic are super bad at this, a single page can weight over 50 megabytes with giant pngs and jpgs exceeding your monitor's resolution

In my tests JXL d1.0 is closer to Jpegli q92

And that giant gif

Is jpegli the best in class jpeg encoder?

Absolutely the best for above medium quality

literally JPEG JXL

So JPEG XL with Huffman and 8x8 only?

And a poor man's version of adaptive quantization, and no gaborish/epf

And no patches or fun Modular stuff

Since when did JPEG support other colour spaces ? ICC?

Yeah it's an ICC profile that tries to squeeze XYB in an uint8 range

Though probably it is safer to use regular ycbcr so you don't get green images in viewers that cannot handle ICC profiles

(or a flash of green in those that apply it only afterwards)

What if the image is mainly green?

Like a photo of a grassy field

Then I want it to be green

Also JPEG XL should be renamed to JPEG cause now JPEG (comparatively) now has the eXtra Large file sizes

\*flashbacks to USB 3.0/3.1 Gen 1/3.2 Gen 1x1*

JPEG 2024 AI XRSTL - Trust Systems NFT DNA Draft International Standard

Leaked new spec name for JPEG and USB collab

Off _wb\_ JXL DNG . WebP

you know, this was never a real issue. tech dudes literally made it an issue

USBIF has always defined terms that are supposed to be used. USB hi-speed, usb superspeed, usb superspeed+ etc. then when usb-c did roll around, they revised the names to literally USB5gbps, USB10gbps, USB20gbps etc.

but techbros and media are idiots

the problem is that not everyone uses the data naming scheme, or lists all the compatibilities of the port (power, dp, data, tb)

Bloat

USB-IF certified products all list the port/cable speed

Mobos, Laptops etc. the exception being ports on devices that are properly color coded

that's not really the problem. The problem is the missing app14 header marking the file as RGB...

Otherwise almost everything would support XYB JPEG by now

It's almost the same as effort 3 lossy

I don't think that's right

Latest Immich update now uses Jpegli for jpeg encoding

In terms of coding tools I think it's more or less correct. But jxl still has better entropy coding, so there's still that ~20% gap.

what doesn't look right to you?

I was responding to jonnyawsom3 saying that jpegli is almost the same as libjxl vardct e3

ah

Yeah, in terms of quality they look quite similar, since it's 8x8 with adaptive quant and optionally XYB

> Better JPEG compression > Immich now uses [Jpegli](https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html), a new library leveraging the advancements of JPEG XL to shrink JPEG file size at the same (or higher) quality. This change narrows the gap between JPEG and WebP compression considerably, especially at high quality.

Jpegli even outperforms webp at higher quality ranges 😎

Strange thing is, there's not a single reference to `jpegli` anywhere else on the github

It does?

What cutoff?

I’m still telling it to use 480p WebPs for thumbnails

Quality 90

^

Would Jpegli help here?

So long as it's quality 90, it should do

I would say for visually lossless images, jpegli comfortably outpaces webp

How does Jpegli quality numbers correspond to actual perceptual quality ?

d=1.0 -> very good

D = Q?

Jpegli has the same quality and distance system as JXL, so quality 90 is distance 1

There's once or twice WebP beats it with specific method settings, but overall cjpegli set to the same quality number beats it https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_lossy_pareto_front

Someone could make WebPli? Or does the spec fundamentally make that infeasible we

using cjpegli you can target an exact filesize and it'll suit your bw/preload strategy for thumbnails or size for current webp versions and still be progressive

someone would need to figure out if there are any tricks you could do to improve it

Can Jpegli images not load properly on some systems? I think I remember hearing about that

dont use xyb, it just decreases filesize **further** but isnt necessary for more bit-efficient jpgs than files generated by mozjpg and webp

I can’t control what Immich is doing

I do not know what they are using

Yes, but making webp target the visually lossless quality range just doesn't make sense unfortunately

The format is hard limited to tv range 420 yuv, it literally can't reach visually lossless

So by nature webp performs really well in lower quality ranges

Does xyb break things?

It breaks things in the sense that a lot of apps are not color managed

as far as i know, xyb requires your app to have color management active at least. on windows, apps still default to lcms inactive. if you ship to only your own apps (ie youre running a web service to sends/displays images directly or only to your own apps) you could use it but its preferable to stick to mainstream accepted parameters

Is xyb default

You have to specify the `--xyb` flag

Good

Even without xyb is it still beating WebP ?

the graph above was not with xyb afaik

seemed so. moreso, within the compatibility constrainst of libjpg6.2 (the specification level that gained the most mainstream acceptance)

So they should be fine on compatibility front?

If still better than WebP why ever use WebP other than Google page rank nonsense

naturally always check. workflows change, and sometimes tools dont properly take into consideration new concepts

webp is mainly used as heavily recompressed cached versions of whats still uploaded and used as jpg/png original images

you can serve more efficiently smaller/resized jpg versions of the originals just fine without another format bloating your pipeline

So for image server where quality is important use Jpegli ?

depends on your project but its one way to get even more efficiency from your current use of the jpg format. at low compression/high quality, average user wont notice much difference and storage consumption difference is essentially a rounding error

progressive loading would be more important imo since webp completely lacks any form of it

I’m just wondering for my Immich server

Do Jpegli JPEGs progressive by default ?

Yes

Does Jpegli add any markers to the file that will confirm it is a Jpegli encoded file?

XYB JPEGs don’t need apps to be fully colour-managed, only to at least take image profiles into account and convert that to, say, sRGB

the Photos app on Windows 10 did that, iirc

(on Windows 11, at last, it seems to take the monitor profile into account as well)

iinm photos app does not take this into consideration when editing images - shows xyb jpegli fine, shows green mess when editing it. its just safer to not use xyb since by the time its support is no longer problematic jpegxl would have gained more acceptance

Why green though

One way to check is by seeing it it has a strange quantization table, since it does 'poor mans adaptive quantization'

The JPEG is RGB, but the ICC turns it into XYB, with the green channel being used the most

Like 1 2 2 8 4 3 9 4 1 4 2 2 3 9 8 7 2 2 6 5 9 8 1 1 Etc… V

For the Y channel?

Non-XYB is YCbCr, XYB is an RGB Jpeg

DQT right?

id too like to have encoder details in metadata, like when gimp, photoshop and libav specificy they were used to generate a file. much simpler to identify and manage a collection in need of (re?)compressing

OK ly problemvkeoigf

Ở lu problem đi PVE hà

wtf

Only problem is Overhead**

Điện thoại của em muốn nói tiếng Việt…

Comparing it to a mozjpeg file, it has 3 tables, one per plane, with two of them reaching quantization values of 200 while mozjpeg doesn't even hit 100

Can JPEG have multiple sets of quantisation tables per image

Like for different strips

Ie can you DQT after a RST?

> (or a flash of green in those that apply it only afterwards) Oh, interested: do any browsers do this?

None that I know of

Dont testing

Doing*

SECRETLY testing JXL files on a wiki with my customised skin on I2P

This even supports JXL and... QOI! https://compressjpg.io

that seems like a nice clever site

IrfanView plugin is updated, however no changelog is available. Exif and color profiles in jpg-in-jxl are still not supported

While still quite early, there is now active development in darktable to support JXL DNGs https://github.com/darktable-org/rawspeed/pull/755

What "algorithm" does it use? Also it can only convert from those formats, not to

Uh that's silly

I could be wrong, but seems to have slightly faster decoding. Lower bitdepths still load as 24bit, and the new transparency option makes my images brown if enabled :P

Hmm, yes, seems so. 300 ms for 80 MP jpg-in-jxl and 90 ms for 22 MP lossy jxl. Nice

Looking back on that, I wonder if it *was* a genuine mistake by an engineer who was thinking of JXR

Unsurprisingly, animated just does 1 frame https://bsky.app/profile/jonnyawsom3.bsky.social/post/3l75r6tsr4g2c

Not sure when this happened https://www.amazon.com/gp/help/customer/display.html?nodeId=GGU2SU8Y22DZYRMQ

What happened?

> Photos: JPEG, JPEG XL presumably

ooh nice

Noticed it while checking the wiki page for updates

Hmm Bluesky supports uploading JXL but the results are horrible

A larger image regardless Alpha channel is converted to a 2000 * 2000 pixels JPEG file

Even 8-bit PNG is converted

Me and Kampidh had a brief discussion about it in the comments of that https://bsky.app/profile/jonnyawsom3.bsky.social/post/3l776qx7gkf2f

any notable websites that serve jxl? other than jxl demo sites

lots of i2p hentai sites lol

Some websites that use Cloudinary have opted into it

Actually, <@794205442175402004> how are the JXL statistics at Cloudinary these days?

Let me get some up to date numbers. Two weeks ago we saw 27.24% of requests coming from a user agent that signals jxl support, and we delivered about 285 million jxl images per day.

oh, that's a large increase in images per day over last time you reported figures!

Are most Safari / WebKit based?

Also I’m guessing it prioritises JXL when available?

Yes, nearly all. Mostly iPhones. The market share of non-Safari browsers with jxl support is very tiny. I can see some Thorium, Waterfox, Pale Moon etc but the numbers are in the 0.00something percents.

I got my parents onto Thorium so add another 0.00001% 😄

Depends on customer settings. If jxl is enabled and they use f_auto, then yes it prioritizes jxl if available.

is there a way to get the original image?

In typical Cloudinary hosted urls, you can just remove the transformations from the url and that gives you a url for the original

so

``` https://res.cloudinary.com/cloudinary-marketing/images/f_auto/v1689095239/Web_Assets/blog/JPEG-XL_2/JPEG-XL_2-png?_i=AA ``` becomes ``` https://res.cloudinary.com/cloudinary-marketing/images/v1689095239/Web_Assets/blog/JPEG-XL_2/JPEG-XL_2-png?_i=AA ```

some interesting numbers!

can those stats be separated for certain countries (mainly us, uk, canada, japan, germany) ? mobile-only split too if possible (gives an idea how many passive receivers can be sent jxl overnight if cdns started served em at higher priority than other formats)

btw, for **tracked mobile users**, caniuse reports 40% mobile devices in active use in us and canada support jxl (uk and japan at 32%). whats huge is its literally fueled just by apple, chromium wouldve pushed it close to 90%

Like what I said Bluesky accepts JXL and converts to badly compressed JPEG

but that's not serving jxl

Two weeks ago we had this: (note our traffic is probably biased towards North America and Europe) - Desktop Chrome: 17.3% - Mobile Safari with jxl support: 14.5% - Mobile Chrome: 8.4% - iOS apps, i.e. Mobile Safari UI/WKWebView without signaling jxl support: 6.6% - "Mozilla": 4.4% (not sure which browsers this actually are, not Firefox) - Edge: 4.2% - Desktop Safari with jxl support: 3.3% - Android apps: 3.1% - Mobile Safari without jxl support: 2.2% - Firefox: 2.0% - Chrome on iOS, with jxl support: 1.8% - iOS apps that do signal jxl support: 1.7% - Desktop Safari without jxl support: 1.6% Also some specific mobile apps show up: - Google (I presume the app version of search): with jxl support: 1.4% | without: 0.2% - Facebook: with jxl support: 1.3% | without: 1.2% - Instagram: with jxl support: 1.3% | without: 0.5%

not sure how representative all of this is, in our data I also see apps of specific customers show up as user agents such as the Just Eat app and some Adidas app, and these do add up to a substantial percentage in our logs but of course that's just because we handle _all_ of the image traffic those apps generate

The daily number for this week (or rather, for Tuesday October 22nd) went up a bit, to 317 million jxl images.

\*sets up a botnet just to load JXL images from cloudinary\*

every (almost) cloudinary and lemmy instance for me [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)

interesting

"Not many people using JXL" — Google Chrome

All sites based on Shopify.

Don't suppose we have a member in here? https://pdfa.org/liaison-with-tc-42-brings-hdr-closer/

I tried looking into this and it seems like it might just be talking about gainmaps

TC 42 is doing gain maps, yes. We are adding a jhgm box to jxl for them.

Ahh right

Gainmaps which way round?

Also would this allow UltraHDR jpeg reconstruction?

Yeah, always surprised when I see a site that's a Shopify backend and get delivered at JPEG XL.

Nintendo

could you show me an instance?

> Cloudinary Programmable Media offers AI-powered APIs to automate image and video management, transformation and optimized delivery at scale What AI?

What/why is an AI being used?

Or is it just marketing

The Nintendo website was using it for their marketing images for the Nintendo switch for example, maybe they were using shopify...

I just returned to their website to check and for some reason they are using avif now

Nintendo uses cloudinary iirc

🤔

🧐

AVIFs strengths really represent Nintendo: low quality

AI based image repair for low quality jpegs, outcropping, ect

Huh, sounds interesting

Might have to look into that more

I will check if Nintendo still serves me JPEG 2000

No, the Nintendo website never used JXL. But Nintendo uses Cloudinary, which means that if you take an image link from Nintendo and change it from f_auto to f_jxl, you get a JXL.

Mostly HDR->SDR ones, that makes the most sense in codecs that can handle HDR.

I'm *pretty* sure they did, but maybe they disabled it again to save some CDN money

*can* you do it the other way round in the spec?

Why would it use avif if they use cloudinary?

because Cloudinary serves AVIF...?

Especially to user agents that don't support JXL.

Both directions are possible

Now the Nintendo website gives my Safari 18 only JPEG and PNG

I'm using Safari

It should give jxl

The Nintendo website has never served JXLs as far as anyone knows

I remember it used to

You probably remember that time when a lot of people were saying that it did, but at a closer look it was only because someone had changed a link to be f_jxl instead of f_auto

I think it was f_auto

even when implemented, issue is always priority. if your client/app supports jxl, it should be the top served format in increasing capacity - optional, low priority and jxl-demoting defaults a website never modifies do little good

Nintendo does have multiple subaccounts iirc, so could be they have jxl enabled in one but not another, I dunno

I tested on the U.S. site

Apparently Mandela punched us in the face

Any reason for that?

You'd have to ask someone who works at Cloudinary

Was primarily asking \_wb\_

by pinging me 🤔

Oops

libvips 8.16 is out now with support for JXL animation, and much better JXL metadata (icc profiles etc.) https://github.com/libvips/libvips/releases/tag/v8.16.0

Wow!

Hell yeah, vips #1

hehe still no HDR though 😦 next version maybe

I only just thought, bluesky is one of the few social apps with the entire app open source on Github. Wonder if JXL support could be added like it was for telegram desktop (yes uploads work on a supported browser, but that's just sending a blob to the CDN)

Is there already workflow to encode all images/pages of a cbr/cbz comic book archive into a single jxl with multiple frames? And a viewer to read them comfortably? This would require supporting different resolutions per image frame and layouts like side by side plus wide screen (double) pages etc

Also theoretically patches could be used there too, to compress the text glyphs like for scanned documents. And then combine multiple issues of a comic book into a volume and single jxl for better compression

I guess the question is if it's worth the hassle. Currently using NeeView to read cbz files with jxl inside

I doubt it would be

the theoretical patch advantage is the only one I see right now and it’s still quite theoretical indeed

I mean for scanned documents or books using patches to extract a rough "font" and compress the document would be worthwhile. So the code to use that for comics would already be there. But it's probably very marginal gains for comics / webtoons

This mentions "in browser translated webtoons" - how does that work? image based ocr extraction and translation all done in browser?

Not that I'd ever want to read an automatically translated comic 😄 Just curious. Automatic Japanese/Korean translation has to be pretty wacky

I don't know Russian so I can't say if they are automatically translated, or they are just a huge collection of translated comics

Those JXL thumbnails are barely readable however

Well I can't access the i2p domain, I guess you need to install i2p for that

I meant the quality of those is bad. Possibly worse than d3.0

Ah

Theoretically you could encode multiple languages into one jxl using different set of patches / glyphs

And reuse the same image background

Even a thumbnail is so small, the main page still loads dozens of MiBs

Basically have an image and multiple text layers

Would the html api for jxl images support multiple frames and layers that can be displayed side by side or overlayed using javascript code?

This should be answered by a JXL developer

This is probably more a question of web standard

From what I gather the javascript browser api doesn't support anything like this, so you'd need a separate "ImageElement" object for each layer or frame in a jpegXL file

I know SVG can do that

I mean there is likely to be redundancy between pages of a comic book

So much redundancy that a cb7 of jpeg often compresses better than converting the jpegs to jxl

So I don't think it's a theoretical advantage

Multi page jxl like tiff would be cool

Otherwise you need to wrap it in a tiff container

Which isn't that bad...

But it's definitely less efficient. No different than a cbz

Oh that's interesting. I tried this with precomp once but didn't realize it would utilize redundancy

Apparently JPEGs of comic books have a lot of redundancy in them in my experience

Or even a zip file of multiple variations of the same image

That last case would be extremely efficient using layers in jxl

Yeah if you had an image editing / painting program that saves as jxl and is designed specifically to make use of jxl compression features would be most efficient.

Huh, maybe generative AI could do this

I imagine in a few years comic books and webtoons will be illustrated mostly using generative AI, or a mix

imo some light filtering around both deep white/black could give stronger gains since noise would compress poorly in a multipage context anyway - assuming source is not an own creation but scanned/jpgs whose artifacts you couldnt initially prevent

Still hoping for a <#824000991891554375> based image software

Or maybe adapt a software that helps with translation of comic book archives / webtoons to use more efficient jxl features

And a webviewer

but can jxl take advantage of it?

that’s arguably what would make the advantage theoretical or not

I wonder what's being taken advantage of. If it's just metadata or headers or actual 8x8 patches of jpeg data

Presumably 8x8 blocks, since metadata and headers are negligible by comparison

I've also seen near linear compression when storing image alts in a 7z file

I guess that would depend on the art style and if it contains actual repeating elements.

But theoretically a specifically tuned multi page jxl compressor should be able to improve on that

In my case it was the same image each time with slight edits, but for the comic any white space would be compressed together for example

Ah now I get it... panels with slight alterations

Would multi page JXL use different frames for each page?

You mean different page sizes / resolution per frame? I would hope so... I kinda assumed jxl supports that?

No I mean like would each page be a frame or a layer?

Yeah

Wouldn’t trying to open the file in any other viewer then just show the last page (top layer) only? Maybe the top layer can say something like “Please use a JXL enabled comic reader” or something

Or maybe if you have 4 languages, you'd have 5 frames. 1 base layer + 1 text layer out of 4 that is selected by the web viewer

That would be clever

Well ideally I imagine some sort of standard. Like with PDF where the default would be to just show the multiple pages as one long scrollable page

I think jxl could be good for scanned documents or books with the right compressor, basically replace "raster PDF"

Does JXL support multiple pages?

I know it does different frames and different layers but can it specify the concept of a page?

frames would be the closest but not sure how the viewer could distinguish between an animation and a multi page JXL

Can the animation frame length be infinite or something?

Or maybe animation loops = -1 or something idk

Frames with no animation timing I think. But you'd definitely need to establish a "norm". Or even have specific metadata tags

If you use layers an unsupported viewer would just show the cover page

it's multipage image if animation TPS is `0xffff_ffff`

If zip can take advantage of the redundancy then why wouldn’t the superior entropy coding of jxl?

it's defined in that way

i was about to think of that myself lol

oh not tps, it's its inverse

animation duration

just checked the spec

Because JXL encodes per frame/layer/page, CBZ is all compressed together (I think)

so duration: ``` Duration = 0: non-top layer of a frame Duration = 0xffff_ffff: end of a page (next frame is new page) Else: Animation ```

That's why I think it would be cool if JXL supports some multi page stuff like with pdf right out of the box when it's finally added to firefox mainstream. To create a platform that people can use.

at least that's how i read the spec

i guess multipage can be interpreted as an animation where the user specifies when to go to the next frame, like the STEP button on a LaserDisc player that's what I'm assuming the rationale is

> If duration has the value 0xFFFFFFFF, the decoder presents the next frame as the next page in a multi-page image. Directly from the spec :P

Well my ideal would be if I open a multi page JXL file in firefox, it displays it like a pdf, as all pages vertically scrollable

Like foolproof

I mean, it should be supported by the API already, but we don't decide what the browsers do

i know thats what the spec says, im thinking about the rationale behind the way the spec was written

Yeah, I was copying it directly

pretty much every time i think "geez, it would be nice if jpeg xl supported feature X", feature X is actually supported and I just missed the place in the spec where it talk about it

Yeah, outside of bitching and moaning there is not much one can do 😄

Well a cool showcase might help

happened with: - named frame - page support - quantised (lossy) modular - reordered passes

Technically you should be able to make multi page JXLs using Kampidh's frame stitcher, would be curious if Irfanview noticed it and enabled the page buttons

can someone quickly generate one so i can test on macOS?

seems like jpeg xl can do everything

https://github.com/kampidh/JXL-Frame-Stitcher

apart from DCT on extra channels lol (it (mostly) makes sense though why not 🤷)

If CBZ is usual zip, then no, I believe, as zip is compressing file by file, not as one stream of data. So it can't take advantage of similarities between files inside it

That's why I said "All compressed together", I'm just making assumptions but it has to be as a blob otherwise there'd be no compression gains at all for just jpeg files

It would be very annoying to view such archives, as for accessing each page the whole archive has to be decompressed somewhere. So I believe it is usual zip with it's limitations

But how do you interpret the frame size or the canvas window size for a multi page jxl?

How do you determine the size of each page? Is it possible for different pages to be different sizes?

Does the spec define that? I think it was overlooked

Yeah different sizes and even "frame anchor" per page is supported. Just made a file with jxl frame sticher but not even gimp loads it properly

Maybe need newest version of gimp (nope, already got latest dev version)

Really?

That's great. I hope some good altruistic person can improve software support for multi page jxl then 😂

Cuz that would be awesome

The best would probably this web / wasm viewer to show a demo

What was the name again? I just saw that somewhere lol

<https://github.com/tirr-c/jxl-oxide-wasm-demo>

I could be wrong, but I think this was using WASM decoding of extra channels in JXL files https://reakt.io/temp/

So you *can* already do a lot in the browser

A page is just a frame with infinite duration, so it's still the same behaviour with dimensions in the header, cropped frames, ect

well jxl-oxide-wasm loads the 6mb multi frame jxl, but doesn't display it correctly

wasm-vips has animated JXL support too https://wasm-vips.kleisauke.nl/playground/

it's about 4.5mb of wasm that you can use in any web page, it's getting quite popular now I think

vipsdisp 3.1 is out! it has animated and multipage JXL support too https://github.com/jcupitt/vipsdisp/releases/tag/v3.1.0

you can load an animated webp or GIF image and save as JXL

multipage TIFFs can be saved as multipage JXL too

PDF too I think

there'#s no interface for modifying duration though 😦

that vipsdisp link has linux, win and macos binaries

This morning I spent an hour helping my technical artist friend try and find a format that supports 16bit layers, with the big blocker being Blender's importer. Strange that multipage/layer comes up here too haha

Are you sure it does multipage JXL? I can't see any mention of 0xFFFFFFFF or 4294967295 in libvips to detect a page

oh hmmm maybe not

if you load an animated jxl image with 0xffffffff fur the duration, you can flip though the pages with ctrl-< and >

so kind-of I guess? libvips doesn't really distinguish between animated and multipage

Does the hot key also change animation frame?

yes, if you do View / Display control bar you get a thing at the bottom

animated images normally autopageflip, but if you clock on the burger menu you can pick multipage instead and then flip between pages by hand

"toilet roll" mode shows an animation like a film strip

I guess libjxl would see the page, and just never advance since it's an infinite duration animation essentially. Although it should be a relatively simple addition at least, since TIFF is already supported and then you could save between the formats

yes, it should work I think, you just can't set the duration in vipsdisp

you can have multipage 16-bit TIFF with alpha and save as jxl too float TIFF too I think

the < and > in the titlebar step though images in the direcgtory you loaded the iamge from fwiw

Heh... Now if only Bsky used libvips for the app along with the CDN, then we could have comic uploads xD

to decode multipage / multilayer JXL (with libjxl), need to disable coalescing first, otherwise it got flattened https://libjxl.readthedocs.io/en/latest/api_decoder.html#_CPPv423JxlDecoderSetCoalescingP10JxlDecoder8JXL_BOOL

oh, interesting! could someone recommend a good multipage JXL image for testing?

So this file I saved with "jxl frame stitching" with "animated" disabled didn't show as multiple frames in vipsdisp.

hmm lemme whip that image real quick

Oh ok but as animated it works

Yeah, it's 'animated' but with maximum duration set

Well the maximum frame duration you can set with jxl sticher is 99. I mean why would you ever want to set it higher than that? 😄

Ah... A slight issue xD

Guess it would better be served as a checkbox anyway

here you go, it consists of 5 pages with similar dimensions

or that bouncy slime animation can be considered as a multipage as well haha

That plot also doesn't show multiple frames with vipsdisp

So that is presumably a limitation of vipsdisp so far

can try opening them in Krita as well, my frame stitcher contains a roughly similar codepath like what I did in Krita

Well I'm only playing around so far. For this to be really useful you'd need a viewer that is optimized for reading comic books and then only loads a few pages progressively

especially for mobile / web

And then would want a compressor that can take advantage while still allow progressive loading

I'm not big into comics or webtoons anyway, but it could be a good usecase

But it would be cool to add this to NeeView

yes, the bouncy slime works well in libvips and vipsdisp I was worried by what you said by coalescing

I used to think the slime JXL was a worst case scenario for a decoder, but what about animated, multilayer, multipage?

eeek, can you have a many-page animated image? I suppose 0xffffffff marks a page boundary

Multiple animated pages, plus multiple text layers in different languages 😄

oooof

yes that slime is a worst case scenario~ there are 3 layers per frame in that bouncy slime, 1 background (put as a reference frame), 1 for slime on the floor, 1 for the main slime and when it's decoded as coalescing (libjxl default), those layers will get flattened as a single frame per tick

yes, random access to pages is on the TODO list for the libvips jxl loader

thanks! I'll experiment with that

this is mostly why I deliberately coalesce / flatten the frames when import/exporting animated JXL in Krita, haha

Ahh, so it was an intentional decision rather than a limitation

this is settings overview of that bouncing slime, `0000` is the background image and saved to reference frame 1, while `000xa` are the floor slime frames and `000xb` are the main slime frames: https://raw.githubusercontent.com/kampidh/JXL-Frame-Stitcher/refs/heads/main/jxlframess-030.png

frame duration is only set on the top layer

There's also CBR, which is RAR. RAR supports solid archives.

Yes, I know, was speaking about CBZ only

ah the pages are in the layer dimension, I understand I don't think libvips will support this ... people should put pages into frames with duration 0xffffffff (I think!)

Yeah, (unsurprisingly) I think we got a bit confused between layers, frames, pages and animation

The rough order is Page > Animation > Layers You can have multiple layers per frame of animation, multiple frames of animation per page, and multiple pages per JXL

Ah yes that's a pretty solid idea as well

I think this makes JPEG XL the only format to have animated pages, no? Yet alone with layers too

yes, I think so

except for TIFF! you can do anything with TIFF, disturbingly

something like this? tried to set the frame duration to `0xffffffff`

hey, it works in vipsdisp kinda anyway, it detects duration as -21747483648 sigh

a simple fix

if you change vipsdisp to multipage view, you can flip between pages correctly

okay I'm gonna add that switch to frame stitcher as well

Encoder and decoder being improved in unison. Nothing more beautiful

But yeah, VIPS just needs to check if the duration is actually a page and then mark it as such

https://github.com/kampidh/JXL-Frame-Stitcher/releases/tag/v0.3.1

Thanks! So if I disable global "animated", are the frames automatically marked as "page end"?

nope, unfortunately global animated need to be enabled for multipage, otherwise it will saved as multilayered instead

Ah cheers

whoops careful when opening multipage image in krita, as it can trigger a deadlock ><

So libjxl already supports multiple frames, but cjxl.exe doesn't? Like a simple flag "--pages" where multiple input images with wild cards are just added as simple pages would be nice.