JPEG XL

this produces this

which uses cICP

my viewer doesn't support cICP so it's rendering it as-is as sRGB

if you use a PQ ICC Profile instead

I tried with `--color_space=RGB_D65_SRG_Per_SRG`, it created something that looks correct.

Yup, the issue here with the washed out is that it's interpreting a 16-bit PQ image as sRGB

which is incorrect

this is what happens if you use an ICC profile, which Eye of MATE supports

In other words, with the above image:

If you see this, it means no peak detection was run. It is not mathematically incorrect, but it is undesirable:

If you see this, it means that libjxl is outputting PQ/BT.2020 data, but the rendering engine thinks it's sRGB, and is rendering the pixels as sRGB. This is incorrect.

If you see this, or something similar, then something most likely correct is happening.

Thanks for the detailed info. 🙂

Again, there's no unique correct way to do it, but there are incorrect ways.

np :)

ah tonemapping what a mess

tfw You grade for SRGB, but you have no idea if SRGB actually means SRGB or a pure gamma 2.2 transfer.

https://tenor.com/view/luck-zoro-one-piece-anime-cartoon-gif-8600231

I wonder if we will ever be able to leave all relative luminance transfers

doesn't help with things like the IM bug that treated `sRGB` chunks as though they were gamma45 and not actually sRGB

gamma45 being `0.45455` aka `1/2.2` (that's how it's tagged in the PNG)

I always knew srgb transfer shenangians was an issue, but I never knew just how rampant of an issue it was until I watched this video https://youtu.be/NzhUzeNUBuM?si=krF_m0fYdN8MalBO

basically, whether or not something uses a real srgb transfer or not is around 50:50

so like, at this point I dont even care anymore

<@208917283693789185> made a windows build of vipsdisp https://github.com/jcupitt/vipsdisp/releases/tag/v2.6.1

it includes jxl support, so you can load and save JXL images

I have never worked with images at the byte level yet. how were you able to derive this stuff?

I did it by reading the spec. Part 1 is for the codestream itself. You can find a copy here: https://discord.com/channels/794206087879852103/1021189485960114198/1169087534060556339

i dont understand this 😭

Its a little unintuitive. You can skip the first few section, as they are mostly just definitions, and go down to Annex D, which is the definition of the Image header.

Some of the fields described in the table there have their own tables elsewhere in the specification.

Just in case, the files in the specification channel are HTML, so they should be downloaded from discord and opened in a broswer to view.

Anyone else suddenly having trouble with ffmpeg jxl encoding?

I keep getting "[libjxl] Failed to add Image Frame" w the latest build, was fine a few days ago

nothing changed in FFmpeg's jxl code, what are you trying to do?

like, what's the command and version of FFmpeg and libjxl?

what version worked "a few days ago"

I'm using the daily windows builds from a community github action minimal command is simply `.\ffmpeg.exe -i in.pfm out.jxl` latest daily build that worked: <https://github.com/zhongfly/mpv-winbuild/actions/runs/6956960419> first daily build that didnt: <https://github.com/zhongfly/mpv-winbuild/actions/runs/6969372061> latest commits of all packages used are listed in the summary if you scroll down a bit. i'm using the ffmpeg-x86_64_v3-git-[hash] artifacts

nothing relating to libjxl was changed here https://github.com/FFmpeg/FFmpeg/commits/master

it may be a regression in libjxl itself

if I had to guess, this commit may be the culprit

https://github.com/libjxl/libjxl/commit/b59e312125138bbc9623fcd9749ba02567d6c9f2

anyway, full command output?

<https://pastebin.com/aU0azXxU>

you would need to use a debug build of libjxl for more info

can you provide the sample?

<@178524721023811584> the problem is on line 2270 of lib/jxl/encode.cc

https://github.com/libjxl/libjxl/commit/6bd63f5880a36bc94172ff285064ebb1743b1964

https://github.com/libjxl/libjxl/blob/main/lib/jxl/encode.cc#L2270

the size of `color_data` should not `bytes_per_pixel * xsize * ysize` but rather should take into account `jxl_format.align`

the problem is FFmpeg is passing a buffer with a linesize of 576

which used to work, before this commit

and libjxl is rejecting the buffer as "too small" (it's not) because the buffer it's rejecting is actually this one allocated here called color_data

<@178524721023811584> https://github.com/libjxl/libjxl/issues/2971

ah, thanks for figuring that out!

Nice. It's great you reported the problem.

can you test latest git main? may have been fixed

Interesting, the gdk pixbuf loader appears to be having issues with orange2.jxl

libjxl handles it fine

as does ffmpeg, djxl, etc.

and GIMP

but running eye of mate on it crashes, wonder if the gdk pixbufloader is just out of date?

seems fixed! thanks

now i just need to figure out why vf_libplacebo chokes on grayf32 but not on gbrpf32 input and most of my ffmpeg woes will be gone

(I already opened an issue for that in the libplacebo repo since I think the problem's somewhere in there, but it's been languishing for the past month sadly)

I can investigate if you link

<https://github.com/haasn/libplacebo/issues/214>

https://code.videolan.org/videolan/libplacebo/

open it here

yes but consider: issues & prs in the gh mirror do get addressed and i did not want to make an account on the videolan github

ah apparently they just have long standing issues with floating point yuv

and now finally found a bug thats definitely in ffmpeg itself lol

```bash # Create grayf32 input image magick magick:rose -colorspace LinearGray -depth 32 rose.pfm # gbrp, gbrp9/10/12/14/16 work fine: ffmpeg -color_range full -color_trc linear -i rose.pfm -vf "format=gbrp, format=rgb48" rose.png # gbrpf32 creates unholy green abomination: ffmpeg -color_range full -color_trc linear -i rose.pfm -vf "format=gbrpf32, format=rgb48" rose.png ```

https://trac.ffmpeg.org/ticket/10716

thank you <3

<@179701849576833024> for fpnge do you lock to paeth or west

I don't remember what the default does, probably paeth

There's also something that will select the best predictor per row which is not much slower

https://github.com/veluca93/fpnge/pull/19

<@184373105588699137> how'd you hack JPEG XL into NUT btw?

using this patch with ffmpeg. ```patch diff --git a/libavformat/riff.c b/libavformat/riff.c index df7e9df31b..16e37fb557 100644 --- a/libavformat/riff.c +++ b/libavformat/riff.c @@ -34,6 +34,7 @@ * files use it as well. */ const AVCodecTag ff_codec_bmp_tags[] = { + { AV_CODEC_ID_JPEGXL, MKTAG('J', 'X', 'L', ' ') }, { AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') }, { AV_CODEC_ID_H264, MKTAG('h', '2', '6', '4') }, { AV_CODEC_ID_H264, MKTAG('X', '2', '6', '4') }, ```

after this ffmpeg will recognize it and mux/demux into most containers

ah, okay

how does it packetize the encoded stream?

the encoder emits one AVPacket per image

but idk how that happens

I can't remeber quite how it does it since I've been using the riff hack for years, it works with pretty much any image sequence, I've used it for qoi image sequences in the past

iirc you were having issues with jxl inside nut tho, idr what they were tbh

yeah, right now decoding jxl from a video container, nut or mkv doesn't matter, something during decoding is messing with how ffplay or mpv determine the timestamps, here for instance is how mpv is reporting the video stats

looks like an issue with pts

may be a bug in the decoder

its not something i've taken the time to look into.

test this for me

```patch diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c index 002740d9c1..831b7a40f3 100644 --- a/libavcodec/libjxldec.c +++ b/libavcodec/libjxldec.c @@ -431,10 +431,8 @@ static int libjxl_receive_frame(AVCodecContext *avctx, AVFrame *frame) if (ctx->basic_info.have_animation) ctx->timebase = av_make_q(ctx->basic_info.animation.tps_denominator, ctx->basic_info.animation.tps_numerator); - else if (avctx->pkt_timebase.num) - ctx->timebase = avctx->pkt_timebase; else - ctx->timebase = AV_TIME_BASE_Q; + ctx->timebase = av_make_q(1, 1); continue; case JXL_DEC_COLOR_ENCODING: av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n"); ```

it doesn't have seemed to change much? ill try setting that to 25fps and test a 25fps video

yeah it seems like setting the fps manually using `ctx->timebase = av_make_q(1, 25);` mpv will play it back perfectly fine. seeking is broken however for some reason

removing the line out right seems to allow for seeking, ofc now with pts issues

I think I figured it out

basically: if the container has PTS info (which it always will), use it

if not, use 1fps

as a fallback

i'll give this a try when I can, had to reboot to windows for a bit so cant test atm

speaking of time stuff, i'm trying to use mergeplanes to bypass the grayf->gbrpf bug but it seems to nuke all the frame metadata. colour info etc i can easily restore with vf_setparams, but the duration of input images also gets set to 0 which means they dont get output... any idea on how to override that?

what if you use `-vf zscale=min=709,format=gbrpf32le`

oo so then zscale reads the desired output format and does the conversion instead of swscale? good idea, ill try it right now

tried it, same issue. but I did successfully try `ffmpeg -i rose.pfm -vf libplacebo=format=gbrpf32le rose2.pfm`

``` ffmpeg -color_primaries bt709 -color_trc linear -colorspace bt709 -i rose.pfm -vf libplacebo=format=gbrpf32le:color_trc=13 rose2.pfm ```

this also works

what libplacebo version?

this produces a pure black image for me

my builds a few days old though ill grab latest and retest

I just rebuilt libplacebo today

omg it works now

looks like the commit yesterday finally fixed it

https://code.videolan.org/videolan/libplacebo/-/commit/52314e0e435fbcb731e326815d4091ed0ba27475 this one, yea

ngl I prefer `UINT64_C(1)` over `1llu` but this does the job ig

reading the discussion it looks like theyre still slightly shifting float values when they're not supposed to, but good enough for my purposes as its still better than the additional roundings etc from using 16 bit int in my pipeline

my old solution was to just store the greyscale images as rgb float but that uh isnt possible anymore with how large my new dataset is haha

now i can also encode the entire dataset as lossless jxl rather than pfm (since ffmpg jxl doesnt do float rgb, only do float grey), the savings \o/

pretty fast to do too since e1 seems to produce the smallest filesize in this case when using faster decoding

interesting, it seems like ffplay will work fine, but mpv isn't playing nicely unless I use `--no-correct-pts` using `--container-fps-override=` doesnt make a difference, not sure if this is an issue with the patch or with mpv.

at the time I wrote the plugin, rgbf32le and rgbaf32le didn't exist

I should probably add those now

with matroska or nut? I had mpv and ffplay both work okay but I tested nut, not mkv

ah yeah, I was testing MKV, nut works fine.

mpv has its own matroska demuxer

interesting, I knew it had it's own demuxer for mkv but I didn't think that would case an issue, but indeed using demuxer=lavf worked fine

That's... Interesting... Lossless e1 uses a separate codepath, so I'd double check it's still actually lossless with faster decode just in case it's doing something weird

I mean, faster-decoding is completely ignored by lossless-e1

Apparently not if they're right

I certainly never wrote any logic to handle that flag xD

Hmm, no difference for me, although I didn't use a greyscale image

r> jpegli rotation

r> jpegli arw input

libjxl still no tiff...

trying to encode photos from camera and i'm having to jump through a billion hoops

It's already hard enough just trying to get uncompressed images out a camera, aside from the RAW itself which then needs pre-processing before JXL

I plug it in > open up sony image viewer > export tif

or plug it in > drag arw

If the shot is fine, the raw doesn't need any preprocessing

magick convert -depth 16 input.tiff output.png

alternatively, ffmpeg

Yeah that's what I did and it takes like 3 minutes per image

Didn't need -depth 16 it seems to already do it

I meant debayering and such

ye RAW itself still needs processing cause the actual data isn't pixel data

you need some sort of camera-raw like adobe camera raw or ufraw or something

there’s a libraw developer who gets a bit annoyed by such statements

since, after all, it’s also true of JPEG files that the actual data isn’t pixel data

conversely, raw files contain not just the data from each sensel, but some metadata as well

to the point that at least Canon’s and Nikon’s raw development software produces images that look exactly like the in-camera JPEGs (but in potentially higher quality)

I just treat "RAW" as a marketing term

so many formats and companies take extreme liberties with the word

incidentally, that libraw developer also gets annoyed by the use of “RAW” in uppercase

(“we don’t call the opposite COOKED” – paraphrased)

yeah, but there's no standard to do that, right? So it's still a bit different from JPEG where you can just use libjpeg and get a nice picture out.

what troy sobotka told us on the olive forums before he left was a pretty good take IMO ". This is in terms of things like blackmagic raw, prores raw, alexa raw > Because raw isn’t a thing. So it’s fair to call it raw. Unmassaged RGB primaries are most certainly “raw” Hence Yet Another Meaningless Garbage term.

basically raw without any qualifier to define it is a meaningless term

I guess it depends on what you call “standard”; one could argue that whatever Canon produces from their own raw files should be the standard for those files

but yeah, no public spec for that

I honestly thought of raw as what cameras simply output what those saw according to their own interpretation/language without any processing whatsoever.

"raw" is whatever the implementer wants it to be, it sounds great at least xD

yea, but RAW files don't have a spec that tells you how to convert it to pixel data, right?

like camera raw data is not a specified codec

I'm aware that JPEG decoding isn't fully specified either but that's more of a quirk of the spec itself than a conceptual difference between JPEG and other image codecs

Canon probably has something like that for their .CR2 and .CR3 (at the very least, “whatever DPP outputs”), Nikon for their .NEFs, etc. just as PNG has its spec and JPEG has its own

but yeah, nothing public, AFAIK

yea, in particular, .cr2 files are not designed a way to store pixel data

they're designed as a way to store sensor data

likewise, JPEGs are by design a way to store pixel data efficiently

I thought RAW is an actual format

https://tenor.com/view/blunder-princess-bride-you-fool-gullible-gotcha-gif-14120688

it's like BMP is to bitmap

I'm otherwise stuck using Sony image edit then unless I want to pay for lightroom

so that's why I at least ask for tif

2gb tif files...

```$ convert DSC00892_PSMS16.TIF DSC00892_PSMS16.TIF.png convert-im6.q16: Unknown field with tag 50341 (0xc4a5) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/985. convert-im6.q16: width or height exceeds limit `DSC00892_PSMS16.TIF' @ error/cache.c/OpenPixelCache/3909. convert-im6.q16: no images defined `DSC00892_PSMS16.TIF.png' @ error/convert.c/ConvertImageCommand/3229.```

i'm owned

what about `ffmpeg -i input.tif output.png`

it works

unfortunately all metadata is lost

and when i try to ffmpeg rgb48 `fish: Job 1, 'ffmpeg -i DSC00892_PSMS16\ \(1\…' terminated by signal SIGKILL (Forced quit)` 😭

OOM killer?

does libvips work any better?

what tool uses libvips

libvips has a CLI of its own, you can use `vips copy original.tif output.png` or `vips pngsave original.tif output.png` to see the options for each command just do `vips [command]` where [command] is the command, without any arguments

you can also try `vips jxlsave`

unfortunately it also kills the metadata

but doing copy jpg took like a few seconds while jxlsave took a minute and died after using more than 8gb

on stable vips, unfortunately yea, but on vips git master (and hopefully a future release), metadata is preserved pretty well

the jxl encoder could use some work, it's still a memory hog just like cjxl

i built git master

v8.4.2-4006-gd80ccd205

would also like mozjpeg or jpegli...

you can also use `exiftool` to move metadata to image encoded with any method. It doesn't support icc profiles for jxl tho

it needs `-m` option for raw jxl codestream

<https://github.com/exiftool/exiftool/issues/230>

<:AngryCry:805396146322145301>

that's the one thing I wanted to avoid

oh, then i dunno, metadata saving is fine for me

```cjxl -d 0 -e 1 death-and-life-gustav-klimt.ppm death-and-life-gustav-klimt.jxl JPEG XL encoder v0.10.0 26d32cab [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 1869826.2 kB (9.269 bpp). 42458 x 38011, 763.424 MP/s [763.42, 763.42], 1 reps, 20 threads.``` ```cjxl --streaming_input --streaming_output -d 0 -e 1 death-and-life-gustav-klimt.ppm death-and-life-gustav-klimt.jxl JPEG XL encoder v0.10.0 26d32cab [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 1] Fatal glibc error: malloc.c:4369 (_int_malloc): assertion failed: (unsigned long) (size) >= (unsigned long) (nb) Aborted (core dumped)```

$20 to whoever can get me jpegli 240MP 16bit tif input with <2gb ram <10s on 4 cores

240mp? Bruh

just use hydrium lol

only takes png input tho

unless you link to za library

would it be able to write exif too tho?

you can losslessly add EXIF to an existing JPEG

would be one way to do it

that was one thing w wanted to avoid, so that's why I'm asking

oh

why, though

if it’s the UI, is exiv2 less painful?

no, it writes raw codestreams

Not sure, probably as-simple-as-possilble pipeline is needed. I think exiv2 supports only reading for all BMFF-based containers, so `exiftool` may be currently the only widespread option for repacking exiv in jxl, without re-encoding the image. Maybe a simple tool in libjxl that can add exif/xmp metadata (eg. having metadata extracted with exiv2 to a file), without transcoding would be useful.

<:linusretire:707375442226708542>

does cjxl/libjxl even copy metadata?

I see `Brotli-compressed xml metadata: 494 compressed bytes` but have no idea how to read it

nothing shows up in exiftool

and there's nothing in the cjpegli output aswell

oh looks like libjpeg-turbo/mozjpeg/cjpeg doesnt do it either

I guess what I really need is jpegli as a library which I can build magick against

you can do that, i don't even rebuild magick, i just do LD_PRELOAD like ```bash LD_PRELOAD=/home/username/dev/libjxl/build/lib/jpegli/libjpeg.so.8 magick original.tif -quality 90 test.jpg ```

does `magick identify -verbose` work?

has stuff but not the original metadata

sweet that works, also the resolution complaint went away after building im7

i just overwrote the installed libjpeg with the jpegli ones

looks like imagemagick doesnt copy all the tags either... but at least I can tif to jpegli with it

I just realized that this applies to Floorp too... it's really annoying when I just want to "Open image in new tab" and it suddenly downloads the JXL file

I had to fix that with an extension in waterfox

What extension?

https://github.com/Rob--W/open-in-browser

Imo it's just bad UX that browsers do file type sniffing for jpeg/png/webp/avif but not for jxl because apparently just after it was added for avif, people decided that no more file type sniffing should be added to browsers because of security reasons.

I think the issue is entirely server side (atleast for firefox it is), I have checked the source code for Firefox/Gecko and I could not find any instances of it auto correcting mime types at all for any image format and it seems like the annoying auto download behavior happens because most servers hosting JXL files don't send them as "image/jxl" but instead as "application/octet-stream", take for example this http://demos.webmproject.org/webp/cmp/2022_10_04/comparisonfiles/subset1/small/JXL/08-2011._Panthera_tigris_tigris_-_Texas_Park_-_Lanzarote_-TP04.jxl url which works just fine in chromium and firefox/gecko because it actually sends the file over properly as "image/jxl".

it seems like it's just an issue of a lot of web servers not understanding what .jxl fikes should be sent over as

https://jpegxl.info/ has this problem as well

Shopify's CDN servers seem to have the correct behavior. (these get served as a JXL in browsers that support it) https://magicholz.de/cdn/shop/files/rokr-The-Luminous-Globe-ST003-v2_400x.png?v=1699359962 https://kojimaproductions-store.com/cdn/shop/products/KJDST11710M240000_1_large.png?v=1695319286

I opened the link in thorium. I get png.

they end up as jxl for me in both browsers, it's just there is no direct url for the jxl version because all formats are served from the same url

May be some problem with thorium Android or something

https://addons.mozilla.org/firefox/addon/content-type-fixer/ this extension works as well though annoyingly you can't set an override directly and can only do it after it's appeared in the log

Of course it's the server's fault for not putting image/jxl in the response header when serving a jxl, but it's the browser's fault that it's not trying to open it anyway (like it does when a server sends any other image format without the correct response header).

I noticed when helping change a friend's NGINX config file. Their mine.types file is years out of date and heavily cherry picked. The octet stream would display for me, but image specific additions in the network inspector (such as previewing the file) wouldn't until I replaced the outdated mime.types file

This is super useful too, thanks for sharing!

I discovered this issue when configuring my webserver. nginx doesn't include image/jxl in its default mimetype file

I wonder if they would accept a contribution/patch to add jxl to the default mime.types list? https://nginx.org/en/docs/contributing_changes.html There's a chance they could decline since image/jxl is still sitting on the IANA provisional media list, although the nginx folks might not care too much and accept it either way https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

also I have no clue how IANA operates or what the process for getting media types registered with it/them is like but why is image/jxl still not accepted/registered? is there some timespan that needs to pass or something?

(relevant discussion from a few years ago): https://discord.com/channels/794206087879852103/794206170445119489/845019584230064168

I'm too wondering how long the whole process takes. And how long it's been since IANA got full registration form (to be put in provisional list doesn't need full registration request, so the moment `image/jxl` appeared in provisional list may be some time before they got full registration request)

> Accordingly, a provisional registration process is provided to support early assignment of media type names in the standards tree. A provisional registration MAY be submitted to IANA for standards-tree types. The only required fields in such registrations are the media type name and contact information (including the standards-related organization name).

it seems that the formal registration *is* required, though that's about the only requirement

errr I’m not fully sure we sent it 👀

<@794205442175402004>, did we? I think it was the object of one of the ISO meetings, wasn’t it?

If we did, I wasn't in cc. Can someone do it? 18181-2 ED2 should be approved soon so it should be ok now.

I discovered a little inconsistency. cjxl assumes sRGB in untagged input files, however, the rendering intent depends on the file format. PNG and JPEG (lossless transcode) results in sRGB, Relative. GIF, Netpbm, JPEG (decoded to pixels) results in sRGB, Perceptual. I'm not sure if it actually makes any difference in sRGB. AFAIK rendering intent tells how to remap colors that are outside the target color space, but sRGB is the smallest color space in use.

In any case, think the color space assumption should be consistent for all input formats.

that's true - rendering intent is a hint to the CMS engine on how to map the gamut

so if the colors are sRGB then it is unlikely that gamut mapping has to happen

but I agree it should be the same

I might post an issue about this.

When printing an sRGB image, there are typically out of gamut colors since CMYK based printers do not cover all of sRGB. So it does matter in theory. I dunno if printing applications actually look at rendering intent, they might just ignore it and do something based on printer settings, but in principle they should be looking at this field.

displays with a gamut smaller than sRGB aren't exactly uncommon either, but such systems would not commonly have correct color calibration data to tell you that anyway.

regardless, I do think it should be set to Relative for all of them, or Perceptual for all of them

rather than one for some and one for the other

I forgot about printing, but that's an entirely different problem. Pictures must be created with printing in mind, otherwise the colors will be incorrect.

Yes, these are just using sRGB and hoping for the best.

Alright, I will create an issue about this, so the default intent should be the same for all untagged input files. Anyway, it seems that the rendering intent is not encoded as a single byte value in the jxl file. The same pixel data in different file formats resulted in jxl files of different size. That's how I discovered the discrepancy in the first place.

I was wondering if it would be possible to change the rendering intent tag without reencoding the entire jxl file but it seems it won't be that easy.

looks like sRGB with kRelative is an all-default ColourEncoding so that will take only 1 bit while anything else requires at least one or two bytes

perceptual requires a table that is tailored for the source gamut and often ends up being equivalent to relative anyway

relative as default is probably good

I will open the issue tomorrow so we can keep track about it.

Does anyone know how to configure nginx to check the accept header and send a different image depending on what is present?

I did it once

I don't really remember how, let me see if I still have it somewhere

nope 😦

dont you use location directive for that?

I remember it's not exactly hard

but I don't remember how it's done at all

and nginx config files are always a bit of a mystery

location directive lets you make rules based on the URL of the request

not based on the accept headers

I thought it could do both hmmm

probably map then

ye, looks like it's a map directive

```nginx map $http_accept $image_suffix { ~.*image/jxl.* .jxl; default ""; } ```

and then ```nginx location /images { try_files $uri$image_suffix $uri; } ```

or something of this form

you will need a content negotiation, but nginx proper doesn't have a direct support for that (hence that hack)

highly unlikely, but that mapping will be incorrect for `image/*,image/jxl;q=0` for example

yea, looks like it doensn't actually support content negotation at all

you just have to regex match the accept header

what would be an actual regex that would support weird cases like this

Supposing you only serve jxl and have a jpeg fallback

not a whole myriad

also how does content negotiation work with cloudflare caches and the like

I dunno about others, but in Cloudinary we only use the Accept header to figure out what the UA can decode, not to return the format they prefer.

I think my best strategy atm for my own site is to not deal with content negotiation and instead use `<picture>` tags

since currently I use nginx for static delivery, not apache

yeah, I find it an overall more satisfactory option

it also alleviates the issue of “when I save, it saves as webp”

since the browser can in principle let the user choose which format to save (and from what I understand, there are extensions for that)

it requires me to control the HTML though, which I do in this casae

For that it doesn't matter whether you use picture srcset or content negotiation: when you do "save as" it will request the image again without the usual accept headers, so you'll get a fallback jpeg if the server supports multiple formats.

not necessarily

oh, does it?

some browsers if you do "save image as" may save directly from the browser cache

(but what if you _do_ want to save as webp, then?)

Or at least at some point it worked like that in Chrome, not sure if it still does that

something I do sometimes is rclick copy image link followed by opening a terminal and then "curl -O link"

but at least on firefox iirc it just saves whatever the browser put in its cache

to prevent a second request

Yeah it's annoying, this is how I discovered that, I wanted to save the webp but got a jpeg

for example, consider the following page: https://traneptora.com/404

```html <!DOCTYPE html> <html> <head><title>404 Not Found</title></head> <body style="text-align: center;"> <h1>404 Not Found</h1> <h3>I can’t find them. There’s only soup.</h3> <picture> <source type="image/jxl" srcset="/images/soup.jxl"/> <source type="image/jpg" srcset="/images/soup.jpg"/> <img src="/images/soup.jpg"/> </picture> </body> </html> ```

in my browser, which is a firefox fork that supports jxl, right click -> save image, will save soup.jxl

Also it depends on how the server is doing its selection of formats: e.g. YouTube does something funky to detect your browser and then just assumes stuff about it, but it will e.g. keep sending webp to Chrome even if you manually disable it in Chrome devtools

this is without HTTP content negotiation btw

If the various sources are in the html like that, a browser could show a "save as" dialog that lets you pick which one you want to get. If it's via http content neg, it cannot know what's available but it could still offer a choice between "the image I already downloaded" and "refetch with Accept header set to pretend I don't support jxl/avif/webp"

in theory it could, but it also doesn't

at least my browser does not

with <picture> and <source>, in principle, this sort of extension should be possible: https://chromewebstore.google.com/detail/save-image-as-type/gabfmnliflodkdafenbcpjdlppllnemd

oh, wait, it says it’s open source, so it should be possible to check whether that’s how it currently does it

https://github.com/image4tools/Save-Image-as-Type there it is

seems to use a regexp to replace the extension in the url

ah, no, it also has a conversion utility

`canvas.toDataURL(`

surprised it's not using `toBlobURL` or something

`toDataURL` is wildly inefficient

er wait

`URL.createObjectURL(object)`

`canvas.toBlob()` works

Does anyone know an alternative File Explorer on Windows that can display JXL thumbnails? jxl-winthumb is a little slow (and the new jxl-oxide releases have wrong colors, see [#29](https://github.com/saschanaz/jxl-winthumb/issues/29))

older, non-jxl-oxide version should be faster, unfortunately the updates changed to not yet so optimized jxl-oxide (and not fully feature rich) it's good that there are alternative decoders, but as for typical usage it's a downgrade because even libjxl is not always fast enough for large or lossless images

the last part rings quite true, i usually use jxl for lossless recompression of large tiffs

for that use case, it is really quite slow

i'd probably use lossy jxl more once adoption gets better

jxl-oxide has gotten a number of fairly good perf improvements recently

yeah, but i mean if even the much highly optimized libjxl is slow for large images, using something even slower to decode it is a noticeable downgrade for typical usage

i understand that jxl-oxide is easier to maintain for a rust-based decoder, but from the user side it's not an improvement

any recommendations for an image viewer that can do multi-threaded decode of jxl files? imageglass, gwenview, etc. all seem way slower than djxl, but if i disable multi-threading on djxl it seems to be on par

not sure if it's faster, but multithreading is supported https://github.com/nomacs/nomacs

thanks! definitely *feels* faster

~~mpv~~

Not sure if this is the right channel, but does anyone know why 70 % JPEG quality (3.14 MB) corresponds to roughly 36 % JPEG XL quality (3.16 MB) in Lightroom? I kinda expected 70 % JPEG XL quality to give me the same file size for more quality than 70 % JPEG quality, but the scale seems way off.

Quality is not a percentage.

Are you comparing the lightroom jpeg scale to the lightroom jxl scale? If so, then it's indeed a bit strange that they don't match very well...

Yep. Since JPEG 60 % was good enough for me, I tried to export JPEG XL with 60 % as well, expecting a similar if not better perceived image quality at less storage space. Lightroom instead exported JPEG XL with a file size that far exceeds what JPEG does. The image quality was obviously there, but not at the file size I expected. So I tried different JPEG XL quality settings until the file sizes roughly match, and am a bit confused why the JPEG quality doesn't align with the JPEG XL quality setting at all.

I wonder what kind of scale they use

Not answering your question, but want to mention the thing that was kind of suprise for me - 16 bpp jxls are (can be) smaller than 8 bpp at the same quality level set

Huh? Okay...

For lossy, bpp is just metadata, doesn't make a difference in the actual data. But giving the encoder 16-bit data can be good, then it's not wasting bits on trying to keep the slight quantization errors of 8-bit encoding...

yep, same with AAC (at least with fdk-aac) and 16- vs. 24-bit input in my experience

higher precision input data allows the predictors to be more accurate

for real world content

but yeah, all in all, there is no reason to expect quality scales to match

~~just have no quality option~~

JPEG quality scales are arbitrary to begin with, as evidenced by the fact that various encoders have different scales

if JXL tried to match either of them, it would not match the others

(and actual lossless encoding would be outside of the scale)

Anime piracy often uses 10-bit HEVC for content that was originally 8 bit. Supposedly the quality ends up better vs file size.

oh, yeah, I’ve heard about that too

reportedly, that was also true with H.264, but 10-bit decoding was less widespread for H.264

Don't forget that 10-bit YCbCr is basically 9-bit RGB, even a little less if they use "tv range" YCbCr...

H.264 at 10-bit can compress more efficiently than 8bit even for 8bit src because it gives the encoder more fudge room

1 lower order bit becomes 3

Mm

it also relied on an encoder which had a good psychovisual model

which x264 does

and x265 doesn't

I find minimal reason to use x265 over x264 in practice

A good encoder for an old format is often better than a mediocre encoder for a newer format. See e.g. JXR.

how mediocre is x265 still, by now?

did they just drop x264’s psychovisual model for no good reason or was there one why they couldn’t practically keep it?

I wanna know why video people seem to love objective metrics so much. x264 got so good, in no small part from one dude just eyeballing it. Meanwhile both MPEG and AOM got people still using PSNR and SSIM.

my guess would be because it’s easier to run various calculations and pretend that it makes the results “objective” than it is to critically assess a bunch of material

it’s objective in the sense that no one would agree, therefore it doesn’t favour any one person’s opinion

XYB was largely jyrki eyeballing iirc

it’s a “fine, then no one will be happy” solution to the problem of slight interpersonal disagreements

never forget the best x265 codeblock

```cpp if (p->bLossless) { p->rc.rateControlMode = X265_RC_CQP; p->rc.qp = 4; // An oddity, QP=4 is more lossless than QP=0 and gives better lambdas p->bEnableSsim = 0; p->bEnablePsnr = 0; } ```

<:kek:857018203640561677>

… what

is that true in general?

as of 2024?

IIRC, adobe lossy jxl exports are not in XYB except for the hdr ones https://discord.com/channels/794206087879852103/803574970180829194/1107970567241486398 which may explain bigger filesize

yup 😄

that was a while ago, I think we later had an exchange about what `uses_original_profile` means (unless I’m misremembering?)

it’s likely they’ve since fixed it

oh they fixed it?

https://bitbucket.org/multicoreware/x265_git/src/74abf80c70a3969fca2e112691cecfb50c0c2259/source/encoder/encoder.cpp#lines-3711

I meant more like “is the comment true”

It's very perplexing

considering "more lossless" isn't a thing

for AVIF, this is the same - 8-bit AVIFs are usually worse than 10-bit AVIFs in fidelity per bit

this is in part because precision is a fundemental part of the spec

for lossless jxl modular, it just encodes integers as-is

since the residuals are just fed to an entropy coder it doesn't really have a size cap beyond the 32-bit integer cap of the entropy coder

whether they started as 12 or 8bit doesn't make much difference

for lossy it's all floats internally anyway so bit depth is just metadata

So what's the best way to encode a jxl image currently? Lightroom can't export to OpenEXR, so that leaves me with png and tiff. cjxl doesn't support tiff, so png it is?

I compared x264 to x265 few times, and every time it appeared that 264 compression tradeoffs are more pleasant for me than 265, as 265 tends to blur low contrast details\textures, while 264 tries to more or less save it

https://x.com/dm4uz3/status/1754643509879943448?s=20 Does Safari really have a minimum size to decode images?

specifically this reply

yeah it's true

same thing happens to tiny WebPs as well

is that the issue? can someone file a bug report? seems like something that should be trivial to fix

It was mentioned here long ago when it was discovered, but I don't think anything ever came of it

probably because I assume no one reported it to the proper place(s). Although I do wonder why this is even a problem in the first place? could have been something done on purpose back before formats that could naturally make files this small came to be added

I think it was a sanity check to prevent random 404 responses from being sent to the decoder

but that is just a guess

It would be funny if they assumed that no real image would be smaller than 48 bytes. In PNG/JPEG that is true.

but the smallest gifs have been used quite extensively

Safari doesn't choke on 1-pixel GIFs, I assume? Maybe it's something specific with how they feed modern bitstreams to their decoders...

So far I've managed to make jxl_from_tree produce invalid jxl files 😄

guess I'm violating some invariant when setting a frame to be reference only...

streaming encode is currently only for pnm, right? so i guess i have to wait for libvips to support it or something

ppm is for the streaming input, the encode itself should still be streaming but obviously has less of an effect on memory

streaming input is not _super_ important — the main issue with lossless memory consumption was that it was using something like 100 bytes per pixel before — which is a lot if the image is large. With streaming encode it only uses something more or less proportional to the number of threads (and nb of channels, I guess).

There is adobe jpeg quality and libjpeg jpeg quality. Adobe's 'save for web' quality 60 is about libjpeg quality 86. Also somewhat similar to quality 8 when save without 'save for web'. JPEG XL uses libjpeg quality when used with the lossy quality number that goes up to 99 in JPEG XL.

Might be a stretch to call this a *tool*, but I guess this would be the place to share this nonsense that I slapped together... https://github.com/yaywalter/Random-Image-Rumble

It doesn't go up to fractional values like 99.99?

Guetzli goes to 110

That feels weird to me. 100 should be mathematically lossless.

That's normal Jpeg though, so there is no lossless

Technically the 1992 jpeg spec does have lossless modes too, but yeah.

Yeah

and 12-bit and arithmetic coding, but…

I still feel bad for the one guy who converted all his photos into arithmetic jpegs and now can't JXL them

jpegtran can probably undo that

yes

(just tried)

not passing `-arithmetic` reverts to huffman

Yes. There is no jpeg bitstream reconstruction but jxl can still represent the image data of arithmetically coded jpegs perfectly. Probably the same is true for 12-bit ones, but that will be trickier to actually pull off.

Classic https://youtu.be/4xgx4k83zzc 😆

wait why does the arithmetic jpeg smaller jxl

``` arithmetics: 118kb huffman. : 146kb jpeg xl. : 131kb ```

Reconstruction metadata probably

Is there a way to tell cjxl not to add that?

I think so, with --jpeg_store_metadata 0

<#803663417881395200>

This is <#803663417881395200> though

which encoder do you use to make arithmetic jpeg ?

Jpegtran can convert between AC and Huffman

Jpegtran

Thanks everyone

I've noticed cjxl now accepts jxl input which is appreciated. However, the bitdepth information is not carried from the source jyl file to the target jxl file. In fact, all input jxl files are converted to 32bit float, including the lossless ones.

I think that's because libjxl decodes jxl files just the same as any other like png, ppm, etc. into pixel data. So the encoder knows nothing about bit depth, pallette, or whatever, it only has the raw pixel data, which I believe is 32bit float internally. The encoder decides how to optimize from there.

AFAIK only JPEG files are treated specially since they can be losslessly recompressed.

This is not true, the bit depth, either 8 bit or 16 bit, is carried from PNG or PPM to target JXL.

It was attempted to be fixed before https://github.com/libjxl/libjxl/pull/2591

As far I can tell, the fix doesn't work in the current build.

Ah, good to know, thanks!

Is there any way to disable streaming output when using a speed that enables it by default in cjxl?

https://github.com/libjxl/libjxl/issues/3291

`unrelated to 1.0` <:FeelsSadMan:808221433243107338>

streaming output is not enabled by default

what is enabled by default is tiling the image in 2k x 2k buffers

ok you know what the more I learn about the new streaming stuff and defaults the more confused I get lol

so it's streaming input is enabled by default and output should be enabled separately, then what does streaming output gives if enabled, memory saving?

Actually you're still wrong xD

Streaming Encoding: Enabled by default, 2048x2048 buffers Streaming Input: Loads the buffers from the image as required instead of loading the entire image at once Streaming Output: Writes the JXL file as groups finish encoding instead of soring it in memory and writing when finished

hmm, I thought if it's a supported format like ppm, then streaming input is also enabled by default

nope

so that's even more variations for testing <:FeelsReadingMan:808827102278451241>

and the buffer size is configurable, because I saw some options for benchmark_xl?

it's configurable but configuring it will do nothing for now 😛

vipsdisp 3 is out now, includes libjxl 0.10.1 https://github.com/jcupitt/vipsdisp/releases

video demo here https://youtu.be/KSoBkO2_HtE it's almost a useful tool now heh

Hmm, I think `--output_extra_channels` on djxl is broken, either that or I'm not using it correctly

```djxl suz-multichannel-800px.jxl --output_extra_channels multichannel.png JPEG XL decoder v0.10.2 e148959 [AVX2,SSE2] Decoded to pixels. 800 x 450, 11.979 MP/s [11.98, 11.98], , 1 reps, 16 threads.``` Only gives 1 PNG file

are you sure the jxl file _has_ extra channels?

I don’t know if `jxlinfo` is supposed to say anything about them, but it doesn’t

?

it’s not what I get with the one from discord

oops, one second

right, if I run jxlinfo on the wrong jxl file, it’s not going to work

sorry about that

it seems that somehow, `djxl` is not seeing them

```patch diff --git a/tools/djxl_main.cc b/tools/djxl_main.cc index b739fa2de..909209f3b 100644 --- a/tools/djxl_main.cc +++ b/tools/djxl_main.cc @@ -600,9 +600,11 @@ int main(int argc, const char* argv[]) { fprintf(stderr, "Encode failed\n"); return EXIT_FAILURE; } + fprintf(stderr, "num_extra_channels = %zu\n", encoded_image.extra_channel_bitstreams.size()); size_t nlayers = args.output_extra_channels ? 1 + encoded_image.extra_channel_bitstreams.size() : 1; + fprintf(stderr, "nlayers = %zu\n", nlayers); size_t nframes = args.output_frames ? encoded_image.bitstreams.size() : 1; for (size_t i = 0; i < nlayers; ++i) { for (size_t j = 0; j < nframes; ++j) { @@ -611,6 +613,7 @@ int main(int argc, const char* argv[]) { : encoded_image.extra_channel_bitstreams[i - 1][j]); std::string fn = Filename(filename_out, extension, i, j, nlayers, nframes); + fprintf(stderr, "Filename(\"%s\", \"%s\", /*layer_index=*/%zu, /*frame_index=*/%zu, /*nlayers=*/%zu, /*nframes=*/%zu) = \"%s\"\n", filename_out.c_str(), extension.c_str(), i, j, nlayers, nframes, fn.c_str()); if (!jpegxl::tools::WriteFile(fn, bitstream)) { return EXIT_FAILURE; } ```

```console $ tools/djxl .../suz-multichannel-800px.jxl --output_extra_channels multichannel.png JPEG XL decoder v0.10.2 05afcb368 [AVX2,SSE4,SSE2] Decoded to pixels. num_extra_channels = 0 nlayers = 1 Filename("multichannel.png", ".png", /*layer_index=*/0, /*frame_index=*/0, /*nlayers=*/1, /*nframes=*/1) = "multichannel.png" 800 x 450, 12.933 MP/s [12.93, 12.93], , 1 reps, 32 threads. ```

Weird...

I suspect there’s a good chance that this is a regression, maybe we can find a revision where it worked and bisect from there

potentially a good starting point could be when that code was introduced

I'll write up an issue quickly

https://github.com/libjxl/libjxl/issues/3407

… I’m actually unable to find a revision where it worked

not sure if I’m missing something obvious too

(I’ve only tried revisions that encompass `djxl_ng`, not the legacy `djxl` from before mid-2022 which used the internal API)

I made that image with libjxl 0.7.0 during testing in krita. In the end we decided not to add multi channel capabilities though, and focused on multi layer capabilities instead. https://invent.kde.org/graphics/krita/-/merge_requests/1795

soo, can't confirm it opened normally on latest 0.10+

Well if jxlinfo sees it but djxl doesn't, then I guess the bug is not in libjxl itself but in `extras/dec/jxl.cc` somehow not properly putting the extra channels in the ppf