JPEG XL

i wish this were only academic but i want to write a vnc application based on jpeg xl heh so progressive steps really matter for that

cjxl --progressive should add passes for 1:4 and 1:2, but maybe something was lost in translation when cjxl started using the api

should jxlinfo know? if there's no way to know seems an obvious defect/patch opportunity

Well with the current api, it cannot really know unless it would try doing actual decode, which is not something you want in such a tool

(well, maybe, you could flag it under `-vv` if that's intrinsic and not just an api issue)

I think we should add an api to get the number of passes in a frame and the breakpoint offsets of where enough data is available for each pass

that'd be super helpful for my use case

The table of contents is part of the frameheader so this is possible bitstream-wise, just needs to be implemented

i was going to ask if there was a way to knnow the minimum data to show anything at all

i.e. to avoid needless returns of NEED_MORE_INPUT

Currently it will only show something when the full dc is available - in principle we could show the dc as it is loading but that's currently not implemented (I think the code is there to do it, but it needs to be wired up in the api)

so i have an old project called `flifvnc`. it worked by taking each window , doing a simple pixel diff on all changes, then sending the client a flif . i didn't get far enough with it to show you anything so that's more of a 'that's how i imagined it'd work'.

when wayland became v popular i gave up b/c all my code was xlib baesd lol.

despite the name it has nothign to do with the vnc protocol. you need a `flifvncviewer` and a `flifvncd`.

wayland's APIs are mature enough for this that `jxlvnc` is a possibility but the api's seem much less than the ones flif had for progressive decoding management

i used to live in philippines so this was something i actually really could've used, and know a lot of developers could use still. i even would still like to have it for some slow servers. existing way of doing vnc is very 80's – 90's

lots of raw bitmaps or terrible compression schemes perforamcne wise

i am imagining each window as an endless jxl animation now, with the server intelligently figuring out how many fps it can send the client based on its read speed. if the client is really slow, then the server won't invalidate / replace the frames as fast, but progressivism would make it much more tolerable to try to use

esp when scrolling documents

(and, of course, it can not send frames when there are no changes)

(or blended null frames)

you're probably better off using H.264 tbh

than something intra-only like JXL

progressive refresh low-latency H.264 could work

that said, Xpra already uses H.264

so this is a bit reinventing-the-wheeley

if you're unfamiliar with Xpra then I suggest you check it out

<@853026420792360980> no and I'll tell you exactly why unless I'm wrong about it. I can't just stop sending frames for hours on H264.

In the global south data costs a lot. It's unethical to send even 1fps of useless frame.

Furthermore the case it's optimized for is not screen sharing.

i guess it depends what kind of screen sharing — playing a fps game is very different from showing slides or some other mostly static stuff

Absolutely. I'm assuming mostly developers and office workers will use it.

It's not at all optimal for a video game, very true. But I can rapidly vary the frame rate, even to zero for hours , with my method , based on demand and capabilities of the connection at any given time.

Also , Xpra only communicates over TCP. I'd use UDP to overcome unethical practices of some ISPs in the global south.

Thing is that inter coding is uber efficient vs even the best all intra JXL coding has to offer.

Quality/rate is what matters, and for video, dedicated video codecs excel for that.

Xpra supports SSH tunnelling

and TLS

sorry <@853026420792360980> i don't know what that has to do w/what i statead 🙂

you can overcome unethical practices of ISPs using encrypted connections like TLS

you don't have to use UDP

<@321486891079696385> it's (imo) a false assumption that screensharing is similar to video just because we most often map video codecs onto it to represent it digitally. i would say that screensharing is far more bursty, far easier to optimize through tiling, etc.

<@853026420792360980> that implies there is one type of unethical practice.

well I don't see how UDP will solve your problem

i am not saying it won't work at all. i'm saying it will be slow. of course Xpra will work. but it's going to be throttled. in my actual experience, they had far fewer traffic shaping policies and controls on UDP connections.

that's why i used mosh os often when i lived there. mosh uses ssh to establish the original connection then drops to UDP.

i also used this a lot: https://uftp-multicast.sourceforge.net/

it was far more reliable. now, i don't know exactly why. i think it was probably traffic shaping/port sniffing on their end. but i am not a network expert. it could just be that as not many applications use UDP, i was using a less stressed circuit.

From a practical standpoint, it would be nice if there was a convenient way to compress all of my existing image files, particularly JPEG and lossless files, into smaller JXL files, on Windows.

On Linux I would write a shell script but on Windows I need to learn PowerHell

Also the vast majority of people who will benefit from JXL are stupid normies that exclusively use Windows.

you don't need to condescend people who use windows

Well, no, that's not what I'm doing at all actually. The vast majority of people are stupid normies, in general, regardless of what they use.

You misunderstand me.

I wouldn't call someone technically unsavvy "stupid" just because they're not a power user

Think of how dumb the average person is, and now realize that half of mankind is even dumber than that.

the average person is of average intelligence

But we still want to help these hopelessly dumb idiots.

Everyone should benefit from JXL compression, regardless of how hopeless they are

I think you're being unnecessarily condescending to people with lower levels of technical expertise than you

And currently it seems like more trouble than it's worth, to conveniently take advantage of JXL compression on Windows. I'm using Windows right now unfortunately.

Well, I am being a little facetious yes, And I do not think technical expertise is a good measure of intelligence, really.

There are lots of extremely intelligent people with little or no technical expertise... But really, the vast majority of people on this planet contain barely an inkling of sentience in the first place

idk, "how do we get all these dumb idiots to benefit from JXL" isn't the kind of mindset that really helps its adoption since by and large, most people will *not* notice any benefit the people who will benefit the most are people who create content and deliver it

Without taking technical expertise into account

on average people are of average intelligence

you don't have to be elitist

That's just how I was made 😎

good, maybe it's not too late

So, I'm on Windows atm, explorer.exe doesn't seem to know what these JXL files are, I tried installing the winthumb dll but that only seems to work for the outdated and crappy Windows Photo Viewer and not the newer Photos app, and it doesn't even work at all half the time, there are still no thumbnails in explorer either even though it's literally called winthumb, and aside from using the command line, which kinda sucks on Windows, the only other way I know to losslessly compress images with JXL is XNconvert. And I don't know what version of libjxl they are using.

If you really want you can export with GIMP

but not with lossless JPEG transcoding

but it does work for PNGs

I feel like if the experience on Windows was better, that would accelerate adoption since the vast majority of average normies that we love so dearly, are probably going to be on Windows

just need someone to write software to do that

Yeah, maybe a plugin on the Windows App Store similar to the webp plugin https://www.microsoft.com/store/productId/9PG2DK419DRG

Hmm, that reminds me, Edge has JXL support I hear.

It's probably just as good as Chromium's support

it's the same as chromium's support it's litteraly the same code

That means Windows already ships with a JXL codec built in...

no?

well i mean sorta but it's just the edge browser

and they are likely to not keep it once chrome removes it

It's just not used by anything except edge when that parameter is passed to it

But since it already exists somewhere for Edge to use it, I wonder if there's a way to get Explorer and the rest of the OS to use it...

instead of installing a 2nd copy of libjxl

no there isn't

the jxl support in edge is not anywhere in windows

it's compiled into edge

Statically compiled?

yeah

I guess

edge's jxl support is just directly chromium's support

That's kinda unexpected especially considering how compartmentalized and sandboxed modern web browsers are getting

it's likely that microsoft might not even know that edge supports jxl

Would expect codecs and all other processes that take arbitrary input from the internet to be all separate as possible from each other.

So if some input causes a crash in the decoder, the decoder is it's own separate process that crashes without affecting any other part of the browser

Separate process doesn't mean separate code wise

Chromium does do this kind of separation of processes, worst thing that an image codec can do is crash a tab, but not the whole browser

Thank you Hayasaka. I will look into it.

I think encouraging Windows users to compress their images with JXL to save space, will go a long way towards acceptance and adoption of this new format and demonstrating how useful and practical it is.

But at the moment it's basically a pain in the ass on Windows.

Would be nice if there was a tool simple enough for anyone to use to reversibly/losslessly compress old JPEG and PNG to and from JXL, for starters.

Perhaps also with an optional checkbox to enable lossy/irreversible compression (maybe with a warning or explanation about it being irreversible)

yes https://github.com/Huluti/Curtail something like this with jxl support on windows. I'm trying to create a python + qt app for this purpose.

does anybody else have trouble with imagemagick-based things (e.g. ImageGlass, `magick` command) and recompressed JPEG files with rotation metadata? as far as i can tell imagemagick just passes on the EXIF data to a PNG when decoding, which doesn't rotate the resulting image in many viewers, while if you convert a JPG to PNG with magick, it rotates the image for you djxl also rotates the png for you i don't know the mechanism ImageGlass uses to display images. but it's getting annoying trying to view an album of JPG portrait photos recompressed to JXL when everything is sideways

I suppose double orientation can happen since the libjxl decoder will do the orientation for you by default, but then if the viewer also looks at Exif and applies the orientation there, it will have been oriented twice

Viewers need to be updated to ignore Exif orientation when showing JXL (like they typically do with PNGs)

if they get the Exif info via libjxl, we could cheat and reset the orientation field at decode time (or rather, set it equal to what still needs to be done to the decoded pixels, which is nothing by default)

but likely they get the Exif via exiv2 or exiftool or something, which will just pass the Exif as it is

Another option could be to cheat and reset the Exif orientation field at encode time (so always set it to the noop identity orientation, and only store the real orientation in the jxl codestream header) — this would then require changing the jpeg bitstream reconstruction procedure to fix up the Exif orientation field when reconstructing a jpeg

I think what current viewers typically do is apply Exif orientation for JPEG and not for PNG.

What they should do for JPEG XL is ignore Exif orientation if they use the decoder in the default way, since the decoder will already return correctly oriented images.

I am sure lots of people would love to reduce the size of their photo collections with JXL

I think plenty of people probably have a big library of JPEGs on their PCs that could benefit from the reversible lossless compression

PNG too

People are generally willing to use new format when all apps they use support it. And the app makers sometimes say they will add support after people use it widely. That's the chicken&egg problem. And there is a group of people who doesn't care about new formats, because they have very few photos or they rather buy new harddrive instead of using more efficient compression.

The first one is exactly what we're running into with Chrome/Chromium, which makes it all the more infuriating \:))

Should we be having a situation when the default behaviour is to have metadata conflicting with the image (rotated image data **and** unmodified orientation metadata)? This sounds like asking for trouble. I think everything that applies orientation metadata should also remove the metadata it already acted upon?

The thing is: the libjxl decoder tries to make the life of applications easy by orienting the image correctly by default — if you don't want it to take orientation into account and give you the image as it is encoded (so still needs to be rotated/flipped), you have to explicitly ask for that.

But if appplications then also go look at Exif and apply orientation again, that's not correct.

Either they should use default libjxl behavior and not do any orientation themselves, or they should set the option in libjxl to not orient, and then look at the orientation field they get from libjxl to do the correct orientation. They shouldn't look at Exif because if Exif orientation is different from codestream orientation, codestream is what counts (and this is what they'd get by looking at the libjxl orientation field).

I agree that it's better to keep the Exif not conflicting with codestream (this also keeps jpeg reconstruction simple).

But we should check that none of the viewers are doing accidental double orientation.

Defaulting to orienting the image is better, it prevents the issues I've seen in the past where applications or even OSes forget to check and orient the image leading to sideways or upside-down images.

^ it's more common to ignore orientation than to overcompensate and orient again

That's why we made libjxl do it itself by default

I'm currently working on Exif support in FFmpeg's libjxl wrapper, and my plan is to have libjxl handle that

and zero out the exif orientation field

Should we make the libjxl api to get the exif zero out the field if the pixel decoding has done or will do the orientation already?

Better to leave it as it is. Application may read Exif via other library and not via libjxl API, so it would not help them. However I manually set orientation to Normal in GIMP and set dimensions in metadata to match decoded image. It is easy, just few lines of code. If you want to do it in libjxl side, I do not mind...

does libjxl currently have code to parse Exif? if not then it probably doesn't sound worth it

since zeroing out orientation in FFmpeg is as simple as doing `frame->exif->orientation = 0;`

It does, as it needs it encode side to set it correctly when recompressing jpeg

ah

but if it's not in libjxl-dec then I'd probably not do it

But I am sure there's also a class of people, including myself among them, that have a bunch of images and photos on their computer that could be losslessly compressed with jxl and save a bunch of space. Regardless of what other people support or whatever.

And I think one thing that is needlessly preventing most people from using this codec for their own personal use today is, well, how much trouble and hassle it is on Windows to use this format. Winthumb seems to hardly work properly at all.

The Photos app at least doesn't use WIC codecs, it needs special support from stuff like the WebP/HEIF plugin to work there

And if I want to convert files I am very comfortable with the command line and POSIX shell, but I do not feel the same way about PowerShell. And besides I would not expect the average normie on Windows to even know what the command line is, so I can't expect most people to adopt the codec even for their own personal use.

Maybe we are putting the cart before the horse here worrying about whether browsers will adopt it when we can't even expect the average Windows user to adopt it for their private photo collection.

(That's not to say that I'm not still baffled by the Chromium decision.)

It's honestly something that should be done via whatever app people use to manage their photos

Like a default on "Use more efficient JPEG XL format to save space" checkbox in the settings

And then when they save/share a photo it automatically converts to JPEG/PNG if needed

I use whatever the default file manager and photo viewer is on whatever platform I'm on.

The filesystem is my photo manager

I would never use a "photo manager" app

Unless I'm literally forced to, as these things often are forced on us

I think the only way to avoid the chicken-and-egg problem is to try to get things done on as many fronts as possible at the same time, and avoid having self-imposed circular dependencies.

https://sourceforge.net/p/opencamera/tickets/1019/ I opened a ticket here

Google Photos is organizationally quite close to the Chrome team so I don't think they'll help push it

Drive probably just does whatever works in Chrome

Camera might be an option, but it might be easier to get third party camera apps like Open Camera to be the first

I suppose we could/should try to get Android to add system support for jxl, does anyone know how to make feature requests there?

https://partnerissuetracker.corp.google.com/u/2/issues/259900694

created an issue

Feel free to star and +1 it

oh really, oops

https://issuetracker.google.com/u/0/issues/259900694

I can also see it from my personal account, but the url is indeed different then

I have only 24283 .jxl files so far.

Only?

I have some million, I had to format one of my disks on Windows in ReFS in order to operate with such quantities, and I have to use 7ZIP gui for file move instead of the default Explorer

It's funny that the old and hideous 7z ui is STILL better than explorer.exe

as well .7z itself turned out to be the best for packing millions of files

in COPY mode

I don't know much about the 7z archive format.

as I know 7zip cli is built into the new ubuntu 22 and is called "7za" (same p7zip)

Yes, I bevieve the gui is simply called 7z

and also I often use 7zip together with Zstandard, for windows there is GUI called 7zip-zstd

It's too bad Igor doesn't seem to embrace it

don't care

7zFM

interestingly, it works better in windows recovery mode than explorer.exe

if you need a GUI to do recovery work and you can't launch explorer cause it's missing some userland dlls, 7zFM.exe actually works

well I don't see any metadata in that png file

``` Chunk: Data Length 13 (max 2147483647), Type 1380206665 [IHDR] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 8192 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 3373 (max 2147483647), Type 1413563465 [IDAT] Chunk: Data Length 0 (max 2147483647), Type 1145980233 [IEND] ```

but when i look at it eg in my file explorer, there is the original modified date, which vanishes

there's literally only image data in that png

that's probably just info stored in your filesystem, not in the file itself

i.e. it's info that also disappears by uploading the file to discord

okay, different test subjects:

i used cjxl -d 0 -e 7 infile.jpg outfile.jxl

Brotli-compressed Exif metadata: 8409 compressed bytes

so this is what requires an updated exiv2 that can handle brotli-compressed metadata boxes

in the meantime, you can use `cjxl --compress_boxes=0` to disable compressing metadata boxes

it throws out an unknown argument error (still on 0.7.0 not on the git version)

so a newby question, when cjxl runs, it uses exiv2 to passthrough the metadata? and if thats the case, the new update to exiv will hopefully fix it?

then why is the exif data lost in conversion?

so it's just waiting for the exiv2 update then

in that case i can close the github issue, right?

IMG_20171028_130209.jxl in GIMP 2.99.14 (Windows build)

<@794205442175402004> <@532010383041363969> GPU accelerated Brotli now exists apparently: https://github.com/GPUOpen-LibrariesAndSDKs/brotli_g_sdk

It is mostly decoding.

looks interesting -- it will be good to learn more about the performance characteristics

https://gpuopen.com/brotli-g-sdk-announce/

🎮 ```As a general data compression format, Brotli may also be applied to other software ecosystems such as gaming and cloud gaming. Video games are asset-dense software applications, and many already employ some type of compression to reduce file size. The gaming experience may be improved by improving the compression and decompression performance of compressed assets.```

but this is sad, and it is unclear if a normal brotli can decode brotli-gpu ```One thing for developers to note is that assets that have already been compressed with Brotli cannot be decompressed with Brotli-G decompressor implementations. To take advantage of Brotli-G, assets must be recompressed using a Brotli-G compatible compressor (also supplied in the SDK).```

and there are no benchmarks as well

wait, those names look familiar <:kek:857018203640561677>

Yeah, there's a reason I pinged Jyrki specifically 🙂

Still so nice to see familiar names.

from reading that paragraph, it actually seems like brotli-gpu decoders cannot decode normal brotli, not the other way around

as in brotli-gpu is a subset of brotli?

looks like it

I guess it is like fjxl in that respect, where the fast decode only works for a subset of features.

Extremely fast JXL is a nice idea

But I like extremely fast everything

<@794205442175402004> I've got an excellent question to ask you: isssimulacra2 differentiable? If it is not in its entirety, which parts of it differentiable?

I think it should be.

https://github.com/mirillis/jpegxl-wic

Is this thing any good?

Anyone tested it?

jxl-winthumb barely works so I'm looking for alternatives.

Preferably something that works in the new Photos app

that WIC codec is based on a pretty old version of libjxl and also I' pretty sure it has the same or more limitations as jxl-winthumb

jxl winthumb doesn't even work most of the time even with the old "Photo Gallery"

I don't think photo gallery accepts third party WIC codecs

But it does work sometimes

I can open JXL photos sometimes, in that ancient and crappy image viewer

Not in the new "photos" app however.

1. photo gallery and photo viewer are different programs 2. photo viewer accepts third party WIC codecs 3. I personally think that photo viewer is amazing and that the UWP photos app sucks

for simple picture viewing photo viewer is great and does what I want and is fast

I have had so many issues with the UWP photos app in the past and hate it

I am not a Windows user. I am not familiar with the nuanced differences between Photo Viewer and Photo Gallery. But I would wager they both suck. I'm referring to this program: https://en.wikipedia.org/wiki/Windows_Photo_Viewer

And it's fugly and slow and just awful. Look at all of that useless blank wasted space.

the Photos app that comes with windows 11 seem decent. The entire window is taken up by the image you want to view. Which is what image viewers should do.

The UI is clean and feels smooth and gets out of the way of the image you're trying to view.

yeah the wasted space is a big issue however it's not slow it's quite the opposite from my and a friend's experience

But that's just my impression from my casual/professional use of Windows

For JXL it's slow as hell at least :)

oh yeah the wic jxl codec is pretty slow. i've had the window thumbnailing system lock up or break from it trying to load jxl files

it also uses a lot of cpu usage

i like the old windows photo viewer, hate the win 10 photos, win 11 photos is okay, and like the win 11 22 photos

from what I recall, it’s not even color-managed

it converts from the image’s colorspace to sRGB, and then sends the sRGB values to the display as-is

could be worse...

I’m guessing that if you have “Photo Viewer” with JXL extension and “Photos” without JXL support, Windows is smart enough to open the “Photo Viewer” when you click a JXL file?

you could tell it to do that and then it will do it automatically

depends on if Photo Viewer registered JXL as supported or not

if so, then yes

i can also vouch that windows photo viewer is nice

very late response though lol

the windows vista photo viewer was even better, and didn't mess up colors in webps and jxls

my primary image viewer is qimgv though lol

<@532010383041363969> I found these optimizations for the original butteraugli in a fork: https://github.com/gralic/butteraugli/commit/b4a44b2bc496dc60f4ad9aeae9630f92ea4c3f57 https://github.com/gralic/butteraugli/commit/ce0a303f3302455d960189c2ebc2daa3b88100eb

I thought we brought them into libjxl butteraugli

That is possible.

https://github.com/ImageMagick/ImageMagick/blob/1c7af5461d4defbcfcac2a8db3e4fb1a81324861/coders/jxl.c#L873-L875 does this mean the only way to make a modular JXL in imagemagick is to set quality 100? and every quality 99 or under is vardct?

I'm gonna assume imagemagick doesn't do jpeg recompression in "lossless" mode because it's working with the raw image data and not the source file

yeah, most libraries don't really have a concept of bitstream recompression, they have a pipeline that always goes decode - pixels - processing - encode.

it's not impossible to add such a thing though — but it's trickier than just defining a new encoder/decoder

did some testing by encoding a simple graphic as JXL at imagemagick quality 99 and 100 and the Q99 file is significantly larger so I'm gonna assume it's vardct while the Q100 is modular, I wrote my test results here https://github.com/ImageMagick/ImageMagick/discussions/5437

jxlinfo doesn't report if the file is modular or vardct, only if it's "(possibly) lossless" or "lossy"

well if it's "(possibly) lossless" it can only be modular since only that mode supports lossless lossy could mean either modular or vardct, i'm not sure why jxlinfo can't report which one

can you not figure out if any certain lossy jxl was encoded with vardct or modular?

well, they could always add a "define" like they do for jxl encoder effort:

https://imagemagick.org/script/defines.php

at least, i think

or that may be most applicable for switching between vardct and modular

jpeg recompression is not just an encode setting when you already have pixels, it's something that can only be done starting from a jpeg bitstream (and no image processing can happen)

selecting modular or vardct to do lossy encoding is indeed something that can be done, question is if it's worth exposing since it's not really a good idea to do lossy modular

this info is in the frame header, but it is not currently made available to applications in libjxl, so e.g. jxlinfo doesn't know

i'm not sure if there is any good thing an application could actually do if it would know that information

that is a good point...

I would use that information for debugging purposes 😅

it shouldn't be too hard to hack libjxl, J40 or jxlatte into being a more verbose jxlinfo that spits out all kinds of image and frame header fields

that's because modular and VarDCT are on a per-frame basis and jxlinfo doesn't report Frame info

jxlatte *does* however

but it requires a full decode

jxlinfo does report some frame info, like frame names and dimensions, iirc. But only what is exposed in libjxl, which are only things we considered part of the decoded image data, not things we considered part of the encoder choices, so to speak.

Anyone having an up to date Windows binary of fjxl lying around?

you can just use cjxl?

This is the first time I've heard about FJXL, what is it? killer QOI?

fjxl and fpnge are highly based in qoi's methods yes

no, they aren't 😉

lol, I urgently need to laugh at my familiar QOI fan

I had a pdf laying around I'll try to find it, I could be recalling wrong.

are you talking about https://www.lucaversari.it/FJXL_and_FPNGE.pdf ?

once I go back to my pc

unless someone else wrote something, I don't think other PDFs on FJXL exist 🙂

probably, yeah

the very second slide makes it sounds like both were based on QOI's ideas

At least that's what it appears to me

ideas, maybe, as the fastest encoder, but not methods and now cjxl -e 1 are equal to fjxl, and became even faster

in the limited sense that I saw that ppl were interested in QOI and I thought I could do better within existing formats 😛

that's what I'm now noticing

(new PR coming soon)

wow wait, is FJXL already part of the CJXL ?

qoir is based on qoi, but faster and with better compression, but no longer as simple though these benchmarks are somewhat wrong, at least for fpnge and jxl (most likely the compiler is the cause) https://github.com/nigeltao/qoir

In git, yes

yeah, -e 1 = fjxl

😱

isn't this value occupied? I thought it would be -e 0

yeah, i wanted it to be -e 0 too, but i guess that would require api changes

eh, -e 1 was meant to be the ~same as fjxl anyway

I also accidentally found when more than 16 bit is required, I use various video comparison tools and for hdr (I guess) there uses formats that support 32 bit, so it is only something like bmp and tiff without compression (not sure why j2k is not used, maybe because it was slow back then and later not that popular) and fast encoding is also important because it could be like thousands of saved frames in one burst I wonder -e 1 just uses other libjxl paths if it will be a 32 bit image?

I think because the formats have been around for a very long time, someone will be able to do it even faster in 5 years~

The API allows to make values like -e 1.5 ?

it does

nope

<:PepeSad:815718285877444619>

1.5 would be very confusing for many people, but 0 as a speed/preset/effort used in most encoders (as the fastest or slowest mode)

https://github.com/libjxl/libjxl/pull/2009 shouldn't change much for avx2, except I suspect it will work better with GCC

what is input step?

the part where RGB(A) 8/16 bit input is converted to YCoCg 16/32bit

so I tried the per-channel prefix code thing, it improves a bit but I had hoped for better xD: https://github.com/libjxl/libjxl/pull/2011

well, at least it doesn't make things slower, so there's that

<:megapog:816773962884972565> not that much, but still maybe different group sizes could also have an effect? or if sometimes more threads in use are needed

increasing the group size would definitely not hurt

IDK how much it would *help*, but at least a bit

but also no idea what it'd do to speed

at least having a selectable group size would be useful

what for?

for some experiments or if more threads per image need to be used, so that the encoding will be even faster

ah, I think even for 1mp images with the default group size you'll be memory bandwidth limited anyway

I doubt you'll be getting much out of more threads unless you have very small images

maybe, but if it is not so difficult to implement, why not, some images may have more compression, some more speed, also for example I have some server processors with lots of cores, but low frequency

honestly even on my 64-core desktop CPU I don't think it will help 😛

and it is somewhat painful to implement

understood, I thought it wasn't that hard to add (then maybe it's better to use a larger size) also, besides ans, is there anything else that can be used for fjxl and that can then also be used for other modes in libjxl or is it hard to combine?

I do have *some* ideas

there's certainly room for improvement in libjxl too

Likely avoiding groups in a 300x300 image is a good idea

it seems to be a ~2% improvement on the QOI test set, not too bad

``` 1063912 fjxl-adapthuff 1143404 fjxl-base 1017684 fjxl-beforechhuff 998504 fjxl-chhuff 1114508 fjxl-newhuff 1057364 fjxl-tweak ``` I also had a bunch of qoi set encodes with older fjxls which show some nice progression 😄

numreps 0 for fjxl produces empty files (I think some checks are needed) maybe bump the lodepng build as well (always using master would be risky)?

waiting new feature build in https://artifacts.lucaversari.it/libjxl/libjxl/

tbh not a lot of reason to use fjxl directly at this point, cjxl has all the features and more 🙂

need for speed

yeah, but still, it's faster for compiling at least

fair

but I think I'll leave that to later, I have some ideas for compression gains 😛

After zero encode repetitions you get nothing, what's the bug? 😅

but this is not zero encodings, and repetition assumes that something finished needs to be repeated <:KekDog:805390049033191445>

~1.7% improvement on some of my sets

pretty good 😄

new year's present: more RLE https://github.com/libjxl/libjxl/pull/2013

fun fact: at this point, things are so fast it is probably worth it to spend time optimizing prefix code construction (~9%!!) and final assembly of the groups (~5.6%!!) -- and all of those on a single thread!

now it's faster (~9% -> ~4%) [just by using uint32_t instead of uint64_t when I can...] and pretty much at the same speed of before 🙂

another ~0.6% improvement on top

nice! about what I expected 🙂

not sure if it's really worth it, but how hard would it be to add fast 32-bit encoding for fjxl or it wouldn't be significantly faster? because, as I said, some tools need 32-bit image formats, plus it would be a really unique fast encoder (because 16-bit qoi, png and other variations exist, but I haven't heard of 32-bit ones) but it's probably not worth it if it needs a lot of work, and anyway, it is possible to use other fast modes from libjxl (they are not hyper-fast, but still fast)

32 bit would be a fair bit of work

<=30 bit would be significantly less, but still not nothing

and jxl -e 2 is ~6-7% better (so still useful)

yeah, makes sense

that one has an actual context model 😛

interestingly, doing something like -e 2 in AVX512 ought to be possible, but I don't think it'd be that useful

yeah, sadly the AVX512 is not really mainstream yet, except maybe more for server use

but, anyway, faster decoding would be much more useful for the investment, as would improving the slower modes or maybe at least 24-bit (but to my knowledge it's less often used even than 32-bit) and still, 8-bit is by far the most used

Yeah... I mean, zen4 has all the subsets (or close to it), so hopefully in 4 years or so it will be really usable

For now I'm just experimenting with it for fun 🤣

(OTOH, it is way more pleasant to work with than avx2)

too bad that avx512 is disabled on Intel cpus with hybrid cores, even though performance cores have it

32-bit float in 0..1 range is effectively 30-bit, right?

It is not really complicated if you cut out Skylake. There is a reason why all devs nowadays use ICL AVX512 as a minimum base.

Yeah

But then again, for 32-bit floats I am not sure you gain anything from trying to compress them 🤣

<:JXL:805850130203934781> where the new build https://artifacts.lucaversari.it/libjxl/libjxl/

at the moment, is fjxl still an external tool or is it part of libjxl?

I have the same question

both

<:Thonk:805904896879493180> how

how do you use fjxl as part of libjxl?

-e 1

`-e 1` lossless only, right?

maybe -e 1 -q 100

or does it work with lossy modular as well?

(I know vardct -e 1 is the same thing as -e 3)

yeah, lossless, not sure about lossy modular

lossy modular uses completely different algorithms for image compression

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

yea, it squeezes and lossless doesn't

waiting

no lossy

I think there will be one after https://github.com/libjxl/libjxl/pull/2013 goes in, but it needs a review first

I lied, there was one more bug

I had some more fun with AVX512 but I think I'll stop here for now 🙂 https://github.com/libjxl/libjxl/pull/2015

Does avx512 increase encoding speed in vardct?

probably, but I doubt the same amount

nerd sniping... fell for it... I believe range [0.5 .. 1.0] is likely 24 bit precision with 32 bit floating point, then one bit more for every halfing of the range until you have 30 bits of precision. e = 1. / (2 ** 53) # double floating point mantissa is 52 bits + 1 implicit 1-value (53 bits altogether) print(e + 0.75, e + 1.5) 0.7500000000000001 1.5 32 bit floats have 23 bits of mantissa (+ the implicit 1), i.e., 24 bits

the range of [-1 .. 1] gives one bit more relative worst-case precision than the range of [0 .. 1] (or any [0 .. 2**N] range)

The first bit (the msb when seen as big-endian uint32) is the sign bit, which is zero for positive floats. The second bit is zero for numbers in the interval (-2,2).

we generate noise in libjxl by generating the mantissa randomly and set the exponent to 1, which generates something in the range of `[1, 2)`

and then subtract 1

that being said, as far as I'm aware the higher precision in the smaller floats is actually desirable so it's not such a big deal

since darker values have more visible quantization errors

<:Poggers:805392625934663710> does this enable using the current jpegli for benchmark_xl? https://github.com/libjxl/libjxl/pull/2043

<:Thonk:805904896879493180> is not xyb by default? d1

mozjpeg

ssimulacra2 79.26883614 vs 82.51984706 (mozjpeg)

mozjpeg version seems to have more texture

Also it's slightly smaller size too

I tried the squoosh.app tool and didn´t get the results expected. On other sites I´ve seen benchmarks where JPEG XL does better than both AVIF and WebP. However, on Squoosh, not only are WebP and AVIF very similar but I am unable to get JPEG XL to be even remotely close. Does anyone have a possible explanation for this? Am I using the tool wrong? Is the tool outdated? Have other formats improved? Can the other benchmarks be inaccurate?

squoosh and jpegxl.io are kinda weird

It's a very different experience vs native (non-web) at least in my experience...

Are you looking at photographic images, or non-photo?

<:Poggers:805392625934663710> oh, now it's a jpegli and also a decoder https://github.com/libjxl/libjxl/pull/2048

jpeg:q90 is libjpeg? dec-jpegli:bd16 is not slower for decoding, what are the differences, memory consumption or incompatible api?

Does cjxl not accept JXL files as input?

It would be useful to re-encode pre-existing JXL files, either for lossy or for further compression with lossless.

The encoder just stops at "Getting pixel data failed."

I agree we should add that. Especially for recompressing lossless jxl to higher-effort lossless or to lossy jxl. But even for lossy recompression, it would be better for generation loss to avoid converting first to 8-bit png, since the actual jxl data has higher precision than that.

Yeah, I mentioned this before. I thought it is kind of unexpected and hilarious that cjxl can't read a JXL file.

People asked me "why would you want to do that? You shouldn't compress an already-compressed file" as if they forgot that JXL does lossless

various pieces of “generally good advice” become rigid pieces of dogma in the hands of certain people

looks like quality selection via q for jxl in benchmark_xl doesn't work? q96=q86 ```Encoding kPixels Bytes BPP Max norm SSIMULACRA2 pnorm BPP*pnorm ---------------------------------------------------------------------------------------------- jxl:q96:3 2856 626501 1.7545362 1.68004227 84.13495464 0.75717498 1.328490875633 jxl:q96:4 2856 631840 1.7694882 1.67337632 84.59683311 0.75597263 1.337684654329 jxl:q96:5 2856 605221 1.6949408 1.73409772 83.88214428 0.73421736 1.244454988832 jxl:q96:6 2856 609243 1.7062046 1.67085242 84.58881865 0.71247660 1.215630829387 jxl:q86:3 2856 626501 1.7545362 1.68004227 84.13495464 0.75717498 1.328490875633 jxl:q86:4 2856 631840 1.7694882 1.67337632 84.59683311 0.75597263 1.337684654329 jxl:q86:5 2856 605221 1.6949408 1.73409772 83.88214428 0.73421736 1.244454988832 jxl:q86:6 2856 609243 1.7062046 1.67085242 84.58881865 0.71247660 1.215630829387```

We should find some way to make benchmark_xl use the library api too and maybe share some code with cjxl so encode parameters can be set in the same

Anyone know why image magick acts weird when comparing a jxl image to the original png? It repeats the image a bunch and claims it has a giant pixel difference

My thought is that it has something to do with progressive decoding, but I'm not sure

Does it do that with graphicsmagick as well?

Theoretically PNG and lossless JXL should both decode to identical image data since that's what lossless is all about.

If we were talking about a lossy format like JPEG there are different decoders with different valid ways of getting different image data so comparing a JPEG with a losslessly-recompressed JXL can result in different image data if you use a different decoder to decode each file.

Could be it's comparing images that are in different colorspaces? It's rather dumb about that, and just compares pixel values without taking colorspace into account...

Both the png and jxl should be 16-bit grayscale images

Anyway, I worked around it by converting the jxl back in png, and then comparing the pngs

I wonder if graphicsmagick has the same problem

I mean one could be linear and the other using the sRGB transfer curve, or something like that

https://www.reddit.com/r/jpegxl/comments/10ehwhk/comment/j4uyuli/ Does anyone feel like adding a heuristic like that to cjxl?

Unfortunately it is something we can only do in cjxl, not in libjxl, because the api doesn't work that way...

I think anyone who wants this should just do lossless jpeg transcoding too and compare result

it's kinda silly request

and such heuristic can go wrong

especially with more varied `-d` values

I mean as long as the heuristic only tries lossless too and only keeps that if it's smaller than lossy, it can't really go wrong besides wasting time. The same could btw be done for encoding from pixels (say png): sometimes lossless is smaller than lossy. Finding a good balance between not wasting time and catching most of the cases where lossless compresses better than lossy is maybe a bit tricky though.

I don’t think you can reliably estimate JPEG quality from a JPEG file if you don’t have the original source image

But I do think it could be preferable to get a smaller losslessly transcoded JPEG than a bigger JXL with two sets of compression artifacts

you know the quant weights though

so you can determine which quality setting was used to encode those quant weights for some well-known jpeg encoders

like turbo-jpeg

GIMP somehow manages to detect what "percentage quality" was used in the original JPEG image if you open a JPEG with gimp, although I don't quite know the mechanics behind it. maybe it just reads metadata

At least from my testing, photoshop, imagemagick and MozJPEG give completely different values

That wouldn't surprise me. Imagemagick uses /usr/lib/libjpeg.so by default iirc

which on most systems is TurboJPEG

on windows builds, I have no idea what it uses internally

https://github.com/ImageMagick/ImageMagick/blob/9ab84aaa5dec73bef9682def5ce94034e65a4b8d/coders/jpeg.c#L778 here’s how imagemagick does it

Some encoders might write the quality value in the metadata also

ah, thanks

so I was right that it bases it on quant weights

but I agree that unless it's written in the metadata this isn't sufficient unless you know which encoder encoded it

I'd say it shouldn't be a default but an extra option to guesstimate this and attempt wasting a bit of extra time

https://github.com/libjxl/libjxl/pull/1362 is this forgotten >_<

Jpeg quant tables basically give you an upper bound on what the quality can be

There are ways to make low quality jpegs with quant tables that are all 1s

But there is no way to make a high quality jpeg with quant tables that are all >100

Basically they define the "bit depth" of the image in the dct domain

Just like you can have a nominally 16-bit image that is in reality just an 8-bit image stored in 16-bit, it only gives you an upper bound on the actual quality.

But an upper bound is good enough for a heuristic like this, since the heuristic is only for speed: it cannot really make a worse decision compared to what we do now because lossless is by definition better than the distance target that was given, so if it's also smaller, it's just better.

(only if we would start not doing both but only lossless recompression in some cases, then it could lead to bigger files, so that should only be done if it can be done in a way where the likelihood that the not-tried alternative would be smaller is very low)

There are two ways this could be solved in libjxl. The "guessing" or inquiry function to heuristically guess whether the image is more suited for lossless mode, could be added as a public function to the API so that cjxl is not the only program able to do that...

But that's not the best solution.

The other, better solution would be... to make lossy mode more clever, so that it doesn't lose to lossless mode. But that would be a lot harder. UNLESS you took a shortcut...

You could make lossy mode check the heuristic, and switch to lossless mode instead when lossless mode would likely result in a smaller file. :)

I am sure no one would complain about overshooting the distance target. After all distance is supposed to specify a maximum limit of distortion/ugliness

It's supposed to be a "fire and forget" encoder where you say you don't want psychovisual distortion to look any worse than X

Otherwise, like I said, lossy mode could be a lot more clever and use different lossy techniques on non-photographic regions.

Techniques that preserve clear lines and borders but reduce entropy and make the image more compressible by subtly altering noisy parts of the image in hard to notice ways. Like what pngquant or some GIF tools do

what would be the additional performance loss for large images i wonder

i forgot whether jpeg recompression is image dimensions sensitive

if it's pretty low compared to vardct and/or fixed then it could be legit usable

also agree that it's fine to overshoot

but it's just that one can end up with image having some additional properties compared to what would end up with vardct which could trigger some tools down the line

probably not serious enough of an issue

It shouldn't trigger any tools. If it does, that tool has a problem.

Also lossless crushing of JPEG is pretty speedy at least in my experience. Although lossy re-compression tends to be pretty transparent and give way better space savings considering.

I mean the api for doing lossless jpeg recompression works with jpeg bitstreams and the api for doing lossy works with pixel buffers, so the lossy encode does not have access to the input jpeg file...

I don't think anyone was suggesting otherwise...

<@794205442175402004> maybe `ad` would be better than `D`, so that there would be less confusion or mistakes with `d`? and if there are some changes for benchmark_xl, it would be nice to readjust the Aggregate calculations for SSIMULACRA2 with negative values (and maybe correlation to bpp) https://github.com/libjxl/libjxl/pull/2117

is there native mozjpeg support for benchmark_xl? it would be very useful for comparisons as it is the most common of the highest quality jpeg encoders and if I am not mistaken is not fully compatible with libjpeg

You can just install mozjpeg as your libjpeg, the annoying thing is it's a bit tricky to benchmark libjpeg-turbo and mozjpeg at the same time...

for some reason benchmark_xl --codec=jpeg:q90 (compiled with mozjpeg) and cjpeg (from same mozjpeg version) -quality 90 are not the same

same chroma subsampling?

iirc, we hardcode a default (maybe 4:4:4?), whereas mozjpeg switches between 4:2:0 and 4:4:4 somewhere around q90

hmm, maybe

how different are they?

(and how are they different?)

Maybe cjpeg defaults are not quite the same as what benchmark_xl ends up doing

yeah, looks like below q90 quality for mozjpeg it's 4:2:2/4:2:0, but for benchmark_xl it's always 4:4:4 q89 `jpeg:sampling-factor: 1x1,1x1,1x1` benchmark_xl `jpeg:sampling-factor: 2x1,1x1,1x1` mozjpeg (4:2:2) q79 `jpeg:sampling-factor: 2x2,1x1,1x1` mozjpeg (4:2:0)

maybe it's worth it at lower quality for jpegli too (and bench-mozjpeg), because mozjpeg usually looks better at lower qualities

`jpeg:sampling-factor: 1x1,1x1,1x1` jpegli q77

are there any image viewers that support jxl that have progressive decoding? or do offline image viewers just generally not have progressive decoding for any image format?

good question — for offline viewing, progressive rendering is generally not worth it, except for two things: 1. dealing with partial/corrupted images: a viewer might want to show what it can (which means decoding it progressively) as opposed to just refusing to show it 2. very big images: if the image is much larger than the screen, and fit-to-window zooming is done, it's overkill to decode the full image (then again, it's not exactly progressive decode you want here, but decode-at-lower-resolution, which is similar but not quite the same thing)

sure - just use only the 1:8 image for thumbnails... the only thing in the current libjxl api is that it will upscale the 1:8 since progressive previews are all at the image dimensions — which makes sense for a browser but not for thumbnails

so we'd need to add an option to get decoded image at other scales than 1:1, since it's of course silly to upsample 1:8 to 1:1 and then have to downscale it to 1:20 or whatever is needed for the thumbnail

https://squoosh.app/ Just wanna say, playing around with the test images in this app, AVIF seems to be overall substantially ahead of JXL in terms of subjective quality. In particular, in the screenshot of the phone, note how AVIF quality 40 preserves the color of the yellow glasses better than JXL quality 75. Also note how, in the hand "squoosh" image, JXL does not do any better than AVIF at preserving the faint grey lines, has a lot stronger ringing artifacts, and annoying artifacts show up at a higher bitrate than AVIF.

I am beginning to believe that lossy AVIF is comfortably ahead of JXL in terms of quality. That being said I still think JXL has more potential and less hard limitations than AVIF in the long run. I just think that the current state of lossy JXL encoding has a lot of room for tuning and improvement.

Someone could (hopefully) write a JXL encoder in the future that looks better than what the current lossy AVIF encoders can produce

As it stands right now, someone probably could comfortably cut bandwidth in half by using AVIF instead of JXL. But of course they would miss out on all of the features that AVIF lacks.

Food for thought.

Also, Waterfox JXL support is awesome, and JXL decode speed is actually faster than JPEG, for images that used to be JPEG

And since a lot of images will probably start off as JPEG before being turned into JXL, that's pretty significant.

https://sneyers.info/browserspeedtest/index2.html

Also I noticed that fd3 is slower than .jpg.jxl for some reason. And I also noticed that JPEG decode is significantly faster in the other speed test: https://sneyers.info/browserspeedtest/index.html

Also it would be nice if the test results appeared closer to the top instead of at the very bottom of the page

3 out of 4 of those test images are non-photographic. For non-photo, indeed avif performs better. That's also what we saw in subjective experiments: https://sneyers.info/CID22/

The question is if dct-based lossy compression for non-photo images is even a good idea to begin with. I think it's better to either use SVG if possible, or lossless/near-lossless techniques rather than DCT for such images.

Squoosh is not a very convenient way to compare codecs, since you manually have to find settings with comparable file sizes and the encoding takes time

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#cecret-lake-panorama-albion-basin-alta-utah-july-2009*1:1&AVIF-AOM=m&JXL=m&subset1