JPEG XL

well that is how Safari does it technically though

it calls Core Image / Core Media at the OS level

Adobe still doesn’t provide its own WebP encoder (let alone deeper integration, eg. in Export for screens), only recently Google started providing a plugin for Photoshop (https://developers.google.com/speed/webp/docs/webpshop). AVIF has a feature request status only (https://feedback.photoshop.com/conversations/photoshop/photoshop-please-add-avif-file-support/5f5f46314b561a3d4278baf4). Historically, they are extremely conservative (for, some!, good reasons). Reading HEIC on Windows requires OS-llevel apps (one paid for).

Core Image has proprietary stuff like the Kakadu JPEG 2000 and HEIC in it, which is probably why they insist on keeping things at the OS level and not doing them in WebKit

Adobe is indeed slow to adopt stuff, yes.

I suppose imagemagick and libheif could decode HEIC on Windows

Gimp on windows doesn't open heif?

not sure about gimp

ImageMagick, Magick.NET as well as my own little image procesing app all support HEIF decoding, and also encoding iirc

actually i think i used libheif for encoding, but decoding is native in magick

Reading in Adobe, I meant (https://helpx.adobe.com/photoshop/kb/ps-heic-codec.html)

Can you use "patch-ception", which is: make a reference-only frame 1 (e.g. just the letters), create reference-only frame 2 with patches from 1 (e.g. longer words and sentences) and then encode visible frame 3 with patches from frame 1 and 2?

yes, but at any time during decode there are only 4 slots of reference frames available

so you can't do this with frame 6 that uses patches from frames 1,2,3,4,5

you can however use patches from frame 1,2,3 to make frame 4, then use patches from frames 2 and 4 to make frame 5, then use patches from frame 2 and 5 to make frame 6, or stuff like that

How it was decided that 4 slots should be the maximum?

originally we had just the single reference for patches, and then we said "maybe that's a limitation because it could be useful to have both modular and vardct references", which would mean 2 slots would be better, and then we changed the frame blending mechanism to get rid of the complicated dispose modes, instead using a generic "reference slot" mechanism to let frames refer to the base frame they want to be blended against, which would mean 3 slots would be needed, and at that point we decided to round it to 4 because it would be a 2-bit value anyway. IIRC. <@!179701849576833024> do you remember?

More slots would be somewhat more expressive but also potentially force decoders to use more memory (reference frames need to be kept in memory) and require more bits to signal which reference frame to take a patch from. Limiting it to 4 seems a good balance between expressivity and those considerations.

Can you do after july faster decoding mode for modular lossless

Sounds about right

Yes, I think that would be useful. A setting for fast lossless encode and decode is useful in authoring workflows, where you want just some weak compression (because uncompressed gets huge quickly but while editing you don't really need / want to wait for strong compression).

I think because you want to compete with wp2

Also the invisible pixels

I do wonder how much we can speed up the tree on the decoder side...

Speeding up generic trees you already did some nice stuff to avoid branching on every individual decision node

yeah, but I do still think we can do a lot better than that... I'm hesitant to go full-blown JIT on it, but...

Probably things could be sped up a lot of you would allow JIT compilation type things, though security-wise that gets tricky

Speeding up fixed trees like we have in -s 3 is easier (but we cannot keep adding hundreds of special cases, of course)

A simple fixed tree for something that doesn't use the Weighted predictor (but Gradient or something) should still give somewhat useful compression, and could make a `-s 2` for lossless...

Yes But good encoding and faster decoding can it coexist?

to some extent fast encode and fast decode go somewhat hand in hand, but you could have slow encode that still targets fast decode

<@!239702523559018497> How is Firefox currently handling/requesting JXLs? Does it use 16-bit floats and convert them like Chrome or is it relying on the bad 8-bit output of djxl?

What? The text would still be a part of the picture though?

Yes, it's an internal codec thing, nothing the application can see.

Is there some optical character recognition that saves coordinates, font used and style, then saves as letters instead of pixels that make up the letters?

<@720988177648713819> c Patches are a feature of JXL that lets you do things like that (e.g. it can signal "here is a frame to decode, but not show" and "on top of this frame, copy-paste this range of x/y coordinates from this previous frame"). So it could be used for things like repeating letters. No idea to which extent the current encoder can make use of that.

Current encoder has a heuristic that basically searches for 4x4 regions of constant color, then tries to find repeated patterns around them. Right, <@179701849576833024> ?

It works quite a lot better than what I would have thought was possible in a sane amount of time

yeah, looks for regions of constant color to detect "background of text"-like places, then finds connected components of not-constant color, then tries to find how many of those occurred multiple times

although that last part should probably be changed to also encode those things that only occur once but that would improve "flatness" by removing them, I think

also constructing the patch frame is not quite done optimally - some characters are repeated multiple times because they have some slight differences that make them not fully overlap, but they could share most of their pixels

Maybe some things could be effectively converted to splines too, if they're large and curvy enough to make that better than modular encoding them as pixels

I'd imagine saving a letter and font info would take significantly less space than the same text in 13x20 pixel boxes.

is the font i use for notepad too complex to encode for jpeg xl?

yeah but then a JPEG XL decoder would have to implement font rendering, and *that* is a can of worms I don't want to touch anytime soon 😛

https://discord.com/channels/794206087879852103/840831132009365514/841373683499139093

what you think veluca

is this font resistant to generation loss

Rasterized fonts with good lossless compression are probably not really more expensive than vector fonts, if you don't use multiple font sizes

or have propierties that indicate resistency

it seems like semi sans serif

It would take quite a lot I imagine to optically detect the font, settings such as bold or italics and do it at any size or color and then replicate it flawlessly while decoding.

is this otf

https://github.com/fabiorug/Suduwe-font

actually i use ttf version

You would have to encode the font itself too to make it self-contained

I wouldn't use a non-monospace font for notepad...

so are you saying that is not very resistant to generation loss?

Cannot expect an image decoder to download a font to decode an image 😅

it would artifact a lot

in vardct

are semi sans serif good to encode for DCTs?

I'd imagine manga archivers could be interested and only CC's Wild Words Roman would be needed because that's the font that's used in mangas.

Well, outside of certain special cases.

DCT is not good in general for text, regardless of font

but like the font i created and forked

does it makes it worse

because is semi serif

or something

difficult

Doesn't matter much I think

The bolder and bigger, the smaller the relative cost for DCT

This tool seem to compress tiff with jxl? <:BlobYay:806132268186861619> (i know that tiff format is limited but there are many extensions)

But patching is where we should put our money for efficient photos of text?

Efficient text rendering with inbuilt freetype :p

idk if anyone here is into xmpp but https://dev.gajim.org/gajim/gajim-plugins/-/merge_requests/211

For now it depends on 8bit output, but can be enhanced later 😉

Patches aside, here we could actually try encoding with lossy Modular instead of VarDCT...

It would be good to get JXL support in the next version of the PDF format. It has support for JPEG2000, iirc.

Leonard Rosenthol, in a pm to me: "For PDF, we are working on some Proof of Concepts to show off to the ISO committee that does PDF. Their next meeting is October, and I expect that we’ll kick off the actual standardization work coming out of that meeting. I already have the committee approval for that direction - now just need to do the hard parts 😉."

imagine a pdf compressor using jxl

we could actually get better lossless compression of PDFs than we've ever been able to get before

around 20% for something like a pdf of scanned jpg pages

maybe more for a pdf with png images too and gif images

Has anyone tryed getting FFMPEG to support JXL?

Not afaik

<@710762823986446367> do you have thoughts on https://github.com/annevk/orb/issues/3 ?

I'll take a closer look tomorrow, but almost all image requests are credentialed

Because nobody does <img crossorigin=anonymous> ?

Only reason to do that is if you want to draw it to a canvas

Or, if you want access to SharedArrayBuffer, then all external assets need to be CORS or CORP

I mean they should have implemented multi threading in the first place lol

But probably yeah

Regardless by the time it even gets standardized either jxl decoder will be fast enough for single threaded or CPUs will be fast enough for single threaded

It's the PDF standard, getting it in is going to take ages

yes but actually no

There's an AVIF polyfill that converts it to BMP and can be used in img or canvas. Could do the same with JXL. Re-encoding to JPEG might cause some visual loss. PNG should be fine but might be a bit slow using a JS conversion.

Polyfill and WASM are two completely different concepts. Polyfill just means software that brings support for features that are not yet natively supported. WASM is WebAssembly, a lower level language meant for speeding up code such as games within browsers. WASM, coded correctly, is faster than using pure JS but not as fast as a compiled program or library... so having the format supported natively by the browser would be faster but WASM would still be faster than implementing the decoder/encoder in JavaScript.

Only other way I can think of is through a browser extension that hooks into the encoder/decoder API... but that would bring a whole lot of security concerns.

I don't think polyfill is a very useful strategy for new image formats. For lossy webp, in theory a polyfill was possible (I think) that would just repackage the payload as a webm and use the native decoder on that, but that hasn't happened. I think the performance benefits of a new codec are largely negated by missing out on the image prefetching - remember that browsers request images long before they're even starting to parse javascript let alone execute it.

Yes, the performance is reduced.... but it's either that or have a slowly reducing percent of people that either see nothing or fallback to an older image format, but destroys the reduced storage & bandwidth of the new format. There are tradeoffs. Personally, I prefer using a polyfill rather than taking up more storage space and bandwidth using other formats and waiting for everyone to update their browser which could take years.

Yes, if storage is the main cost, that is true

For most of the use cases I see, bandwidth is the main cost

But end-user image loading speed is also very important - in e-commerce use cases they notice the effect on conversion of 0.1s loading time improvements.

you're likely better off converting on the fly on the server, latency-wise, if you want to save storage

The increase in file size could potentially add 0.1s or more too it, depending on the format and features. The decoder is not affected nearly as much on performance compared to the encoder. Unless they are running really old hardware, it would probably be largely unnoticeable unless the entire page is covered with images.

True, but not everyone will have access to a server or CDN with image conversion capability.

it's not too hard to make a nginx plugin for that I think

it should certainly be relatively easy to make one that does jpeg -> jxl on the fly

I tend to come up with solutions that work for as many people as possible (from large organizations to people making blogs). A lot of people run Apache and may not be able to do that even with Nginx. The CDN is the best option as many free CDNs also have image conversion, but may not have CMS support in some cases... though there are no current CDNs and little software with JXL support currently. The software & browser level would provide the largest range of support. I would rank them in this order of preference: 1. OTF image conversion via server/CDN (though may not be supported by some) 2. Browser polyfill (will be slightly slower to decode for older browsers & hardware) 3. Produce & store other image formats (increase storage & bandwidth and may be slower depending on format/features) 4. Custom server software (not a viable option for many)

I think in many conditions 3 >> 2, the wasm-based decoder is *significantly* slower (especially on ARM IIRC)

just store jxl

How much slower? I've not really tried on my phone but even 10+ year old computers seem to run squoosh very quickly.

I think WebCodecs will make polyfills more feasible, but then we'll need a polyfill for WebCodecs itself 😁

https://c.tenor.com/8PFwkSkhIxUAAAAM/shades-inception.gif

If Safari/WebKit would adopt reasonably quickly, we might not need fallback options for that long - between chromium/edge, firefox and safari/webkit, arguably a large enough fraction of web users are covered...

https://c.tenor.com/FHQWr-zMA-oAAAAM/im-just-like-day-dreaming-sumit-anand.gif

I'm confused, even with that API wouldn't the actual codec still need to be in JS or WASM? It largely just seems to handle capturing the image and setting up a thread / WebWorker to move the encoding off the main thread. Other than that it looks like the implementation still needs to be in JS or WASM.

WASM is getting closer to native speeds. I think the main advantage of webcodecs would be to hook into the img tag directly, instead of having to do stuff with a canvas etc (missing out on prefetching etc). If I understand correctly.

I'm reading the spec and readme again, and actually it seems not about polyfills but only about the browser internal codecs 😬

I think it could be used to create a polyfill, but I don't think it's for actually implementing new codec the browser does not support on it's own.

> Non-goals > Writing codecs in JavaScript or WebAssembly https://github.com/w3c/webcodecs/blob/main/explainer.md 😭

But it looks like you can tap into the stream data for things like images so at least it should remove having to write the portion of a polyfill where you have to check for file extensions in images (yuck!). It should eliminate a few steps to creating a polyfill.

Actually, I've got a great idea.

If the device doesn't support JXL, disable website access <:kekw:808717074305122316>

I haven't really measured, it was more of a "gut feeling" thing - but I wouldn't be surprised if it ended up being 5x slower

That was done a while ago already: https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

They recently drafted an IETF doc that mentions it, I suppose they did that to have a reference to point to for an IANA registration

Even Google cannot just invent by itself new media types besides a `vnd.` one (something that comes from a specific vendor, like image/vnd.adobe.photoshop). It has to come from an international standardization org, like IETF, W3C, ISO, ITU, ...

something that came up after a discussion of integrating ffmpeg into the kernel (shudder): if/when ffmpeg supports jxl, how will it support lossless jpeg→jxl transcoding? as far as i know, ffmpeg always decodes input files before passing the data to encoders, so it wouldn't know not to decode the jpeg.

we could add a flag or something to not decode the input, but that feels like a pretty huge architectural change on ffmpeg's end.

but i think it could maybe work as a bitstream filter, as those do get to process compressed input data.

I suppose ImageMagick and libvips have the same problem, right <@693227044061839360> and <@310374889540550660> ?

At a high level, the internal objects are uncompressed pixel buffers, and the pipeline is basically decode to pixels, manipulate pixels, encode from pixels.

While jpeg to jxl and back skip the pixels (in libjxl internally, we still have an internal object for the image data as DCT coefficients)

For ffmpeg, I suppose it does know the concept of handling bitstreams without decoding (remuxing only), so I suppose it could be something like that, conceptually

oh that could work, like `ffmpeg -i foo.jpg -c copy foo.jxl`?

Yes, something like that

i guess the issue is it really is transcoding, while usually `-c copy` guarantees it's not transcoding. an ffmpeg user with no jxl knowledge would probably think that command should be near instantaneous/not do any processing.

In ImageMagick, there is a concept of input annotation where you can do a downscale-on-decode or selecting only a specific page/frame from a tiff/gif. Maybe that mechanism could be extended to do "don't decode, just make a dummy image with the whole input bitstream as 'metadata' blob"

if ffmpeg encoders always process raw data, `-c copy` must be a special case right?

i think maybe you could make `ffmpeg -c jxljlt -i foo.jpg -c jxljlt foo.jxl` work

or whatever you want to call it

the jxljlt *de*coder takes a jpeg of N bytes and produces an Nx1 8-bit monochrome image representing all the bytes, which the jxljlt *en*coder can process <:kekw:808717074305122316>

i hate this already

It would be nice if `ffmpeg -i foo.jpg foo.jxl` would do the lossless recompression by default

ffmpeg has some... interesting defaults ||aomenc `--cpu-used=1`||

but maybe we could get that to happen

how many mime databases are there?!? I already sent a patch to include jxl to the debian and fedora mime info repos, and I found out yesterday that nginx has its own, and now I find this one too?

Probably there are a couple more - I assume MacOS and Windows also have their own thing too

How do we get image/jxl from the provisional list to the actual list, btw? Do we just have to wait for IANA to review the application? They do seem to take a long time for that...

I assume(d) they are waiting for IS

That makes sense, though don't we need an amendment then (probably to part 2?) that mentions the media type?

no clue

mhh, I'm not sure what's the difference between shared-mime-info and https://salsa.debian.org/debian/media-types

if someone can open an issue, I think it would be better than just me sending a MR

freedesktop

Yes, libvips will always decompress the input image. As you say, you could potentially optionally attach the DCT coefficients as metadata I suppose, but that sounds pretty ugly. Yes, libvips lets you pass parameters to loaders, eg. "vips copy x.jxl[page=4] y.ppm" to copy the third page of an animation, so you could have a arg for "attach-compressed-data-as-image-metadata" libvips decompresses on demand, so something downstream could opt not to fetch pixels and it wouldn't trigger the decompress, it could just use the coeffs on the metadata

Would make sense then to do something like that in both libvips and imagemagick, and basically decode to pixels only when needed, which would not be triggered by a jxl encoder at the output end if it has a lossless setting and sees jpeg-bitstream-as-metadata in its input object

Not super elegant, but the jpeg bitstream is smaller than the image buffer, and when you have to decode it then you won't need it anymore, so it's not that bad

https://chromestatus.com/features#Jpeg%20xl <@532010383041363969> <@795684063032901642> <@768090355546587137> why does the chromestatus thing say "no active development"? Shouldn't that be "in development" or "proposed"?

see also: https://twitter.com/watIsAgoodUsern/status/1393397141414977543?s=19

mhhh

good question

https://www.yacreader.com/ Сan read JXL in CBZ/CBR using the Qt plugin from novomesk (have to put it in the imageformats folder)

Yep, but some people use Win 😄

was just updated

<@!795684063032901642> How do animations and multi-pages look/work in Chromium? What do I have to consider as web dev?

Animation is being worked on.

Multi-page we don't really have in jxl (at least not as something that is different from an animation), and images on a web page are not supposed to have any controls so I don't think it makes much sense to have page flipping (frame seeking) controls for jxl in a browser

TIFF being able to be like PDF sounds like antifeature to me to be honest

TIFF is adobe featurecreep

TIFF can do anything, it is the hairiest thing in the world

https://c.tenor.com/H627PKHZHP4AAAAM/walking-into-my-wax-appoinment-hairy.gif

better lets make TIFF do jxl coding internally :--DDDD

Adobe also puts basically entire PSD files in a TIFF as 'metadata'.

Why not put in javascript and make it turing-complete while we're at it like svg

Vector formats have a thing for being turing complete

The old PostScript could also make your printer go into an infinite loop

As in: crashing and not doing anything, or as in printing an infinite amount of stuff, both could be done at some point

so I do have a working patch, but it doesn't really seem to work properly xD

like, it blocks the rendering thread

Of course they are supposed to have controls! In case you have multiple to slide through. It would be useful for something like that: https://www.reddit.com/r/comics/comments/neecej/bobbi_and_the_spaceman_12_rain_oc/ Reddit could simply use a single, more handy and much smaller JXL instead if the browser would allow access to all JXL frames.

I see how that would be useful, but then you'll need to fight w3c and co to redefine what <img> can do

Is there no other way around?

Well you could do things in javascript or whatever, but if you want the img tag to do new things, that means changing the html spec

<video controls><source src="fancy.jxl"></video>

<img> should be for static images only

Tell that to whoever made animated gif work in an img tag

That ship has sailed

I will continue to disable them then

But it would make sense to allow any codec (image or video) in img tags, and maybe also to have a new tag for multipage stuff

Like PDF, which is something browsers often can display but it's not really well integrated in the web platform

No, I don't want animations running that don't have a way to pause them

Then I guess `prefers-reduced-motion` is something for you?

Or maybe just a browser UI way to pause animations (besides img there can also be css animations, or js doing stuff on a canvas; those might be a bit trickier to put pause buttons on)

Even just something in the context menu to pause a specific animation would be ok, but just running constantly with no way to pause is not acceptable

I wonder why that doesn't exist yet. Seems reasonable enough.

Fortunately people are moving to <video> (using video codecs, not image codecs), and <video> looping can be turned off in the menu; I just hope jxl doesn't cause a resurgence of <img> animations.

It shouldn't, video codecs are better for video than image codecs

Just would make sense to also have a pause option for img with animation

And allow any video in img

Currently Safari allows h264 (in mp4) in img, and Chrome allows av1 (in avif)

A pause for img would be great, but videos in img without controls sounds horrible.

That would motivate me to build a browser extension.

Well it is not meant for whole videos of course, more to replace gif for 5-second looping stuff

Those who will abuse it don't care what you think it is for.

Maybe browsers should always show controls if you ask for them

Serve the user instead of advertisers? That would be nice!

Any idea why? Does that always happen or only for large animations?

fixed 🙂

Was it something silly, something funny, or something interesting?

we didn't have a way to quickly count frames

The bitstream doesn't have a way to do that, you can skip over all frames and count if you have the whole file but that's it, right?

Do you mean doing the whole image decoding through JS or do you think it is possible to tell the browser via JS which JXL frame to decode?

I was thinking more like do it as a large single frame image and use js or css to show parts of it, or something

But it would be nice to have a single JXL that works locally as well as online.

well we couldn't even do that xD

Ah

So chrome was like, "how many frames does this animation have?" and libjxl was like, "I dunno let me decode the whole thing for you and I will tell you"

Tell me cloudinary, when will .../pg_x/ be supported for JXL files? 😄

We don't even support jxl animation yet atm, it's one of the things I have to work on this week

The cloudinary notion of pg_x is like the imagemagick one, it's a page of a pdf, a layer of a psd, a frame of a gif

Question for jxl will be whether to count in layers or in coalesced frames

(also layers can have names in jxl, like in psd, which can be convenient to not have to worry about the "how is this counted?" problem)

Layers you can count from bottom to top, from top to bottom, starting with 0, 1 or 2, and afaik all of those conventions are used by something or someone

yeeees... that wouldn't have been *that* bad except for the fact that then chrome would create two different decoders for counting frames and actual display in some cases

Animated jxl art will be fun

How hard would it be to make jxl_from_tree support a mode where it has multiple frames, but they're all just slices out of a single hidden one?

And e.g. transparently have it translate checks on group and frame number into a unified group number (where every frame is a range of groups).

Not hard, probably, just annoying plumbing

Easier thing is to just do frames with a new tree per frame

(and maybe write a bash script that generates a set of trees)

Just need to add a way to indicate duration and blend mode, and then what does overlays now can be used to make animations

<@794205442175402004> Yeah, but a new tree per frame means you can't share (parts of) the tree.

Yes, for minimum size it may not be optimal (though signaling patches is also not free so I guess it depends on how much of the tree can be shared)

I could imagine things like having the first out-of-view line be different for each frame, but then the derivation of how that first line generates the next (visible) ones be the same.

Could let you do automate that vary over time.

Yes, if the patch signaling plus selection on frame/group in the tree is less costly than duplicating the automaton description itself.

The language doesn't even need to be different if it's sufficiently high level. jxl_from_tree could just try both strategies and see which one is smaller

i guess that'd earn it the label "compressor"

makes sense

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c29 is this kinda progressive decoding or not quite yet?

good question, <@!768090355546587137> do you know what exactly this does?

no, it's not

it's just the same as partial decoding of sequential JPEG1

(but one rect instead of one line at a time)

does it render fully decoded groups at a time?

more or less

horizontal line of groups?

nah, every group, but not exactly a group

minus filter padding?

Before the chromium change, it first got all bytes, then started decoding

After the change, it will already start decoding while receiving bytes, and place pixels in Chrome's image buffer This behavior is more like the other image decoders work too

It will work group per group, or scanline per scanline, depending on the image

Over a slow network connection, it should be possible to see the groups appear

Nice

Next step: showing upsampled DC too?

I suppose we first want the DC upsampling properly simdified

yeah

that's done btw 😛

Can you _show_ an example of upsampling? (image preview vs image)

https://chromium-review.googlesource.com/c/chromium/src/+/2903086 now get to work! 😛

second image from the left here https://www.youtube.com/watch?v=uzYHXqjGgL4 works as an example (it has more steps than usual though)

<:Hypers:808826266060193874>

So Chrome will be feature-complete before Cloudinary? ... <:PepeOK:805388754545934396>

Chrome Canary maybe. Chrome stable, nah 😅

Btw, can we additionally have `video/jxl` as media type? This would not only allow people to stop animations if the website uses JXL inside a video tag but also support seeking for multi-page-like JXLs.

mime type isn't relevant to that, html element type is

not to mention that jxl would make poor video type

Well, it's a small portion of content where JXL animations shine but having the option doesn't harm.

video/jxl would be weird, jxl is definitely not a video codec

having options is what makes current web browsers as big as they are. it absolutely does harm

especially not well though out options

but it has animations and many people would like to stop/control them.

i personally wouldn't

usually animated images are too small for controls to be placed

and no right clicking every thing is not good UX

video/jxl mime type also might make people think serving longer/high-res videos as jxl is okay which it probably (if you care about bandwidth) isn't

<@!260412131034267649> I don't want to replace image/jxl, just have another option.

How browsers do their UI is somewhat orthogonal to media types or the html spec

also extension vs mime type confusion (servers usually divine mime types from extensions, so would need one more)

it's also not really OK from a browser implementation point of view...

which part? <:ugly:805106754668068868>

If a browser wants to show controls on animations, I think they can, regardless of if it's an img tag or a video tag or what the media type is

they would break layouts if they aren't overlaid on images themselves

They can also not show any images and show just the alt text

Or read out the html aloud, for that matter

i dont recall any browser putting out raw html tags in place of images tbh

I mean how blind people browse the web

pretty sure their readers don't annotate specific tags, though they may do annotate some semantics/properties

The alt description is supposed to be used for img tags

idk I'm not blind so I don't really know but I would find it weird if it was like reading html source

It's the only obligatory part of an img tag besides the src

I'd probably like big global switch "stop all animations in the page"

because usually if site does one gif it can do several more

killing them one by one would be bad UX

Maybe could be a good idea for a browser extension (or feature request)

Big pause button, sets `prefers-reduced-motion` and pauses all animations and videos.

What about: `<img src="pic.jxl" alt="animated JXL" controls=""/>` (Controls being totally optional!) <@!179701849576833024> Can you add support for that? 😁

well, I guess one would have to add support of that for avif, apng and gif too

can be done, but I'm not the right person 😛

Can you at least tell your Chrome friends about this feature wish? ^^

it's not really chrome, more w3c I guess

That's better discussed at the html/w3c level than trying to add it as a chrome only thing

I am in favor of basically making img and video the same tag, just with different defaults regarding controls, looping, autoplay and mute.

But that's a big html spec change

We can't let w3c control everything. A browser should add optional features to make w3c add them officially.

That's what lead to the IE feature bloat

inventing tags just for fun

marquee tag anyone?

I remember those days

We don't need button, only pause when click on animate image. For me a browser can add this feature very easily without changing html.

There was a time I thought IE was kinda cool for that.

Not really. Images can be links, there can be js watching click events. You cannot just redefine left click on image to mean something else.

Ok, browser could pause image with exception if it's a link image. Gif with link is very rare on internet.

<@456226577798135808> did you end up doing this? 🙂

thanks! 🙂

sounds about right I'd say

``` <comment>JPEG XL image</comment> <comment xml:lang="fr">image JPEG XL</comment> <comment xml:lang="nl">JPEG XL afbeelding</comment> ``` haha 😄 maybe I should add Italian too, to make the set of languages even weirder

`<comment xml:lang="pl">obraz JPEG XL</comment>`

thanks a lot!

hope so too 😛

I also hope that it will make things "just work" for a few cases

who is Ai Hayasaka

I saw that here Luca didn't use capital letters and I just followed suit

and what have to do with the standardaziation

I just copied it from our source code 😛

I guess one can just replace "JPEG" with "JPEG XL" in the description for image/jpeg...

<https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c30> animation landed

you people are very reactive xD

just in time for Chrome 92

so Chrome 92 will have a full jxl decoder (behind a flag), right?

now only need to make it progressive too, and get it enabled by default in Chrome 93 😅

should be

but wait this makes it progressive already right? https://chromium-review.googlesource.com/c/chromium/src/+/2900235

this got merged 2 days ago

that makes it incremental/sequential

GOOGLE PHOTOS PLZ

I can even pay a bit and sign an NDA to test JPEG XL in Google Photos, lots of photos are already uploaded and just waiting for being `-d 1` or `-d 2` converted on Google's side...

mark the date: Jul 20

Great news.

Openmandriva will get full JPEG-XL support in its next stable release 👍

Yes, out of the box 😄

Everything, even the gimp plugin.

However, there's something dubious <:Thonk:805904896879493180> ```Upgrading: jpeg-xl znver1 0.4.0-0.20210521.1 cooker-znver1 7.1 k jpeg-xl-gdk-pixbuf znver1 0.4.0-0.20210521.1 cooker-znver1 344 k jpeg-xl-gimp znver1 0.4.0-0.20210521.1 cooker-znver1 814 k lib64jxl0 znver1 0.4.0-0.20210521.1 cooker-znver1 817 k lib64jxl_threads0 znver1 0.4.0-0.20210521.1 cooker-znver1 13 k lib64xml2_2 znver1 2.9.12-1 cooker-znver1 632 k python-libxml2 znver1 2.9.12-1 cooker-znver1 243 k ```

I didn't know JXL 0.4.0 was already out <:Thonk:805904896879493180>

0.4.0-0.20210521.1 probably means "git checkout of the branch that will become 0.4, on 2021-05-21"

Which is extra suspicious, because in my timezone it's still may 20th!

Yeah, it's very odd.

They are in Europe, so that's fine, but how did they manage to get 0.4.0 in the 1st place?

I wonder if they did that just to be able to differentiate it more easily <:kekw:808717074305122316>

good riddance

It still existed?

No seriously, it still existed?

It is still the official browser of Win8 and is included in Win10 for people that need to check compatibility

I don't like that Win10 has 3 browsers installed by defualt

IE, old edge, and new edge

I guess I wasn't *really* serious about the question, the fact that The Verge wrote an article about it must mean it did. Still, I had no idea!

Just for me to install Firefox and ignore those 3

"Microsoft Internet Explorer: a pre-installed tool to download browsers"

Also new edge has outpaced firefox <:FeelsSadMan:808221433243107338>

(a joke I heard several years ago)

Microsoft lost the phone operating system war, so now they try to profit off of android's/IOS's success

This was microsoft's actual pre-installed tool to download browsers https://upload.wikimedia.org/wikipedia/en/e/e2/BrowserChoice.gif

Although it was a page displayed in IE......

yeah the eu forced them to display that i believe

iirc the order was randomized, but they kinda goofed the randomization so certain browsers were more likely to show up in certain positions. i forget if that was in a way that benefited microsoft, but cue conspiracy theories galore

I rarely use Win 10, but was surprised find IE was the default program for opening some file types ... maybe xhtml, I don't recall exactly.

XML

I'd expect it was just a programming mistake... this just by knowing a lot about typical programming mistakes 😛

I guess it's just the 0.4.x branch and they're expecting we'll make a 0.4.0 soon 😄

I've just found out that FF Nightly on **Android** supports jxl too! 👍 It's not stated at https://caniuse.com/jpegxl and I didn't find it here at Discord either so it could be a new piece of info for some of you.

o damn

hell ye enabled

it totally wasn't there for quite a while, i tried looking for it numerous times

and it works. but alpha stuff still aint implemented rip

They mostly have interests in lossless like FFV1?

no idea, they list all kinds of formats

I think because there are other things when the format/standard can be considered stable

https://github.com/mozilla/standards-positions/issues/522

I'm waiting the next chrome canary update to test animate jxl ! <:Hypers:808826266060193874>

it might use a bit too much ram for now

Yeah, they live a bit in the future 😛

animated jxl on chromium snapshot

well!

that I didn't expect

does that one work?

it's counting without crashing

ok, amazing

I'll have to fix this I guess

can you perhaps share the gif?

ok xD thanks!

``` #4 0x559ceb5cad10 jxl::PerformBlending() #5 0x559ceb62c0ef jxl::PatchDictionary::AddTo() #6 0x559ceb635c0c jxl::FinalizeImageRect() ``` well, it's a JXL bug...

pretty random one too i guess as ive converted another gif and that isn't crashing stuff

wait uhh.. did upper patch stuff limit get fixed in latest sync

because ive just pulled new git stuff.. and if it uses patches.. and chromium uses old one.. could it be related?

haha this one doesn't crash stuff

nope, not related 🙂

so in patches but not related to limit

the more I look at the code, the more I realize I must have done something extremely stupid xD

that's what "canary" and "behind-a-flag" are for, right? and also an amazing community that starts to try stuff and finds stuff that breaks nearly immediately 🙂

well, now I fixed the crash, but the image looks weird

progress?

can you perhaps share the original gif?

^

thanks! I found the bug in the meantime...

by the way, there was *also* an *encoder* bug

wow

kinda curious what exactly these bugs were

patches weren't cleared between frames

and on the encoder side, patch *frames* weren't cleared between frames

basically the combination of patches and animation was kind of completely broken

so the first patch frame would be encoded for *every* animation frame

the second patch frame for every animation frame *except the first*

etc...

luckily <@!179701849576833024> found and fixed the bug already

also explains why encoding a bunch of PNGs as frames would give worse results than encoding them one by one xD

(I still want to have an heuristic that can find patches common to multiple frames... not hard, in theory, but requires quite a bit of plumbing)

I suppose this fix should get cherry-picked into public repo and chrome quickly, no?

yeah

I expect it will be in 0.4.0 (probably on Tuesday)

and in chrome by the next beta build, which is I think on Thursday? For sure in a canary somewhere around Wednesday though 🙂

As of today, latest Graphic Converter’s beta version supports JPEG XL importing and exporting: https://www.lemkesoft.org/beta.html

Nice

wha

what is this symbol?

chinese

what it means

the above (google translate)

I think mean 'have more content'

Nice! Let us know if you need help to get color profiles and metadata working.

Just to specify I’m not involved with the development, just had contact with the developer asking about JXL implementation. Really excited about this though, I use this software a lot!

And thanks for the https://jpegxl.info/ website <@!794205442175402004>, very useful and condensed informations. Those comparison websites between formats with a slider are great!

Thanks to <@493871605408071681> and the WebP2 folks for those comparisons, and also <@710762823986446367> and <@228116142185512960> for Squoosh!

https://github.com/gabriel-vasile/mimetype/commit/e9147bdbbbf03bb48e09c00d8b1b1f3db92ac62f

yay

One mime db a day keeps the doctor away

Is anyone familiar with the relationship between Chromium and Electron feature support? Could you ship an Electron app with JXL support right now?

no idea... but if Electron uses blink, probably yes

right, it does use blink

which is not a surprise I guess 😄

I would assume it could be enabled in a nightly build but since it's not in stable yet I would not release a stable app with it, but you could obviously start updating/testing an app to use it when JXL reaches stable in Chromium & Electron.

I still wonder why doesn't Discord support AVIF...

feature-gating: not all supported frontends support it so it would result in sub-optimal experience for ones where it's not supported

does discord embed webms (with vp8 or vp9) on ios?

i wonder...

Not supported by Firefox, Edge, or Safari yet. Also they may not support it for a while. A number of CDNs are passing on it for now due to slow encode speed. Going into the next year I feel a lot are going to put serious thought into the performance impact of AVIF in whether they will support it now or later. Even if they do support it I'm sure they will take time (maybe months) to test and generate AVIF versions of all the images. I think it took over a year after WebP got wide browser support that Discord added support.

also another reason why discord doesn't support AVIF is because their electron client is still using electron version 9 which is based on chromium 83 which is before chromium 85 and chromium 85 is the version that added AVIF support.

Why don't they update their Electron version?

they run a patched version of electron so maybe they don't want to rebase

They patched it?

i'm pretty sure they have some native code for voice stuff

They should cherry-pick commits responsible for AVIF and other nice functions, they shouldn't interfere with their voice stuff

It would still not work in the web version until browsers support it.

Just checked Chromium 93.0.4523.0. It supports jxl animation.

and the next canary / beta should even have it work! xD

(with patches)

Yes! animate works great with --patches=1 --dots=1 --noise=1 --progressive_dc=0 <:Hypers:808826266060193874>

good!

Next step is to work on chrome on android? 😇

there's not a lot to *work* on there

just getting the flag enabled

So who have the power to enable jxl flags? 😄 i don't see any flags on chrome canary android.

I'm not actually sure...

Looks like libjxl was approved by Fedora last weekend: https://bugzilla.redhat.com/show_bug.cgi?id=1922638#c17.

wonder why they built it with sjpeg...

oh well

nice! now we just need to get debian to include the package we gave them 😛

what bundled libraries anyway?

Probably because `JPEGXL_ENABLE_SJPEG` is enabled by default, but I'm not sure.

I guess

According to that spec file, they included the bundled sjpeg because there is no official release.

But there's no need, really

I mean, for sure there's no need for the library, but even for the tools

Ah, you're right. libjpeg(-turbo) can also be used for encoding (which is already included within the spec file), so sjpeg is not necessary. In that issue, should I ask why they included sjpeg?

Perhaps they could also swap the bundled skcms with lcms2, since lcms2 does get packaged by Fedora. Or is there any downside to using that?

https://discord.com/channels/794206087879852103/794206170445119489/821664205672677417

it's not a big downside imo

Curious, I couldn't reproduce that with libvips on Windows (which uses lcms2), I'll have a look. ``` vips.exe icc_transform 50551002028_1738fd834f_o.jpg x.jpg srgb --vips-progress vips temp-3: 4922 x 3017 pixels, 6 threads, 4922 x 16 tiles, 128 lines in buffer vips temp-3: done in 0,17s ```

🤔 Maybe cjxl does it in a different way

we transform to floating point, not to int, and not to sRGB

so likely some optimizations in lcms2 that are specific for transforming to 8-bit sRGB don't apply

skcms is slower

possibly a lot slower

but also a bit more precise and works in more cases

skcms is IIRC a single file, so not too bad

sjpeg on the other hand... I'd prefer if it was disabled I think

So flac and probably a few other music formats support embedded album art. I wonder if this is an area where JXL could shine

mh, I don't know - I don't think more than on other cases, at least

Never understood that. Why would you wanna do that? Let's say a typical album contains 10 songs, then why save the cover 10 times for each FLAC? Of course, you can use one FLAC per album instead of per song but then you probably have an additional .cue anyway and another .jxl won't harm.

Yeah that's a good point

I'm more excited for when JXL is supported enough that I can convert my comic collection to JXL