JPEG XL

https://www.reddit.com/r/rust/comments/1q0maft/introduction_ffmpreg_a_complete_rewrite_of_ffmpeg/

this has to be a meme right?

no way

better start a new one with similar scope and none of the bagage or old cruft that doesnt suit modern paradigms

not an impossible challenge but itll be seen as an ffmpeg 'lite' playing catchup forever

its real lmao

This is 183B SVG: `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><path d="M1000 0v600H0V0z" fill="#000"/><path d="M1000 240v120H560v240H440V360H0V240h440V0h120v240z" fill="#fff"/></svg>`

168B here: https://discord.com/channels/794206087879852103/794206087879852106/1450657702698025122

I still need to continue the DCT tuning...

"rate_hz": 10500,   "original_length": 1580992,   "image_width": 1280,   "log_offset": 1e-06,   "log_min": -13.808087348937988,   "log_max": 2.441476821899414 —If you're bored, you can decode this dct

https://youtu.be/dTeSv0SKlGc we could take this instrument’s name as it is and it would be a compression project name

if you were to clone `github.com/google/çifteli.git`, what kind of project would you expect

maybe some kind of font shaping or related project I dunno

What I'm getting from this is that the instrument is edible

https://w3techs.com/technologies/details/im-xljpeg

https://w3techs.com/technologies/details/im-avif

https://w3techs.com/technologies/details/im-webp

Statistics of other formats: https://w3techs.com/technologies/details/im-gif https://w3techs.com/technologies/details/im-png https://w3techs.com/technologies/details/im-jpeg

they pushed it everywhere at gunpoint yet barely anything but some sites and cdns serve avif...

given almost all (at least 80%) of all webps and avif served online seem to be generated for preview-tier recompressed versions of originals (png and jpg), i suspect jxl support in browsers will rapidly shrink their numbersn especially if jxl is given higher priority over other formats when supported

> Random selection of sites using JPEG XL > Giannirosato.com > Traneptora.com Easy marketing if you get on the JXL bandwagon early

By that logic we should see WebP numbers decrease after AVIF became widely available in major browsers, but we didn't.

https://chromestatus.com/metrics/feature/timeline/popularity/3798 Also AVIF has a higher adoption rate if you look at popular sites.

different metrics

ohey that's me

SVG is so popular

Likely due to svg icon fonts, usage in certain major css frameworks, logos, certain icon formats etc. which is a really different category compared to the rest of those formats

svg for favicons specifically i hear is popular on account of it supports media queries

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1605902-jpeg-xl-image-support-returns-to-latest-chrome-chromium-code?p=1605993#post1605993 <@184373105588699137> here is the link: https://phabricator.services.mozilla.com/D119700#3977128

Firefox nightly still uses libjxl btw, vendoring jxl-rs is blocked by infra update, let alone the actual integration

I wish there was a competing format to SVG. Lottie isn't it.

.swf :p :p :p

That can be brought back as well imo

Isn't brotli pretty good at compressing SVG

But an image and animation format would suffice for a start. People aren't sending SVGs to each other and I think the only chat client I ever saw that supports SVG displaying to some degree is Element. (Besides that SVG animation requires either something on the website or embedded JS in the SVG – latter will be annoying the moment you don't have JS support) On Discord you can upload Stickers in Lottie format but good luck on being able to find software for viewing locally let alone editors.

> (Besides that SVG animation would require either a second file or embedded JS.) incorrect; SMIL

SMIL is not a second file?

SMIL is the same file

lookit my cool animated SVG

Is that even still alive anyways?

i don't know anyone else who does SMIL other than me but i don't know how "alive" it has been in the past

I will quickly test that on Element

I think I read SMIL was dead or something or w/e. Something held me back using it

i've been using the "nheko" matrix client which also displays SVGs inline

online search indicates chrome at one point claimed they would deprecate their SMIL support but then reversed their decision

But thing is also that a lot of sites don't allow SVG uploads cause "oh no scripts" when they could very well limit them to media display only.

that is annoying when i wanna share anything i draw in inkscape yes

Oh!

You know what I would kind of like

A working clock in a file format. So some way to get the time would be lit. But guess I will never get that.

ah yeah the letter of the SVG spec allows this but in practice no browser supports the `wallclock()` syntax in the animation begin attribute

https://www.w3.org/TR/SVG11/animate.html#WallclockSyncValueSyntax

Somebody should propose this at interop 🤔

and unchanged in the draft SVG 2 animation module (frankly they probably *should* specify the syntax better than "based on ISO 8601", like define a specific syntax or defer to RFC3339 or something)

when, where, and what is this interop

https://github.com/web-platform-tests/interop

oh wait right i forgot; it *is* defined in SMIL but SVG didn't bother copying that specific bit over (but SVG essentially goes "use SMIL (except for these changes); we've just copied bits of SMIL for your convenience") https://www.w3.org/TR/2001/REC-smil-animation-20010904/#Timing-WallclockSyncValueSyntax (and yeah pretty much just RFC3339 syntax)

For example the JXL proposal of last year: https://github.com/web-platform-tests/interop/issues/994 (interop results will then probably be out in February ig: <https://github.com/web-platform-tests/interop/tree/main/2026>)

i would love to see widespread wallclock support but i am not familiar with how to get this sort of thing started alas (is interop the best way? that i do not know)

Getting friends at Google Chromium team might be the best way

But at least some people look at the proposals at interop and I think I can get at least a few people I know to vote for one proposal for that. ~~in worst case I will mass-ping train lovers about how they could have accurate DB clocks on their websites /s~~

I forgot that the desktop client doesn't allow uploading SVGs. So it was either the web client or Schildichat that did. Or some other web client..

Very cool that Schildichat desktop client redirects me to a browser and then the browser asks me if I want to open Element (Fixed by using different home server)

The animation does work correctly in Element! (But in Schildichat – based on Element – the SVG is heavily blurred)

Lol. I just looked for DB clock online and found a non-working SVG on Wikipedia again: https://upload.wikimedia.org/wikipedia/commons/4/4c/Animierte_DB_Uhr.svg And yeah this uses this wallclock thing.

im glad to see gif winding down, id like it to be at 0

somewhat related, when you make an exception for headers, I wonder how many random bitstreams actually decode to an image

because iirc, JPEG XL was designed with very little redundancy in the name of compression. i.e. there aren't many bits wasted on invalid configurations

There is only one valid final ANS state so a random bitstream has a high chance of not being valid. This is useful for error detection.

we do it's called PDF

I meant mainly for (sharing) animation and images (in e. g. chats)... But well regarding PDF... is there a PDF standard that actually forces the user to know that the deprecated components of the PDF can't be loaded? Cause I found PDF files with SWF inside and they just don't display anymore. Imagine having such PDF files in critical environments and suddenly some important thing can't be loaded anymore after you do a system update at some point.

Ideally features inside such a format should just continue to work forever, but at the minimum I expect some kind of warning instead of just not displaying content...

pdf readers can support all pdf revisions, not just the latest as long as theyre conformant in each - its a developper's choice as to wether they do but theres overlap between revisions

Btw. tested with Adobe Reader and this tells a lot. There weren't many that supported Flash content anyways but this did (obviously).

The next interesting thing will be how will PDF/A files get displayed by most readers when JXL support is added to it

Or let's say you e. g. run a outdated Adobe Reader version

told to update it or use acrobat reader

later has like 2 billion installs, and the total pdf readers in circulations is at least triple that of browsers (each browser includes their own - pdf.js, pdfium and preinstalled edge ships' adobe's own)

pdf's upgrade treadmill works similar to flash player's. because something requires one or an update installed (youtube required flash player before so it had a near 100% install base), users receive the updated support passively

https://sh.itjust.works/pictrs/image/b79da149-8ab9-4478-8d87-8d9e2e7b6511.png?thumbnail=1500&format=webp

Looks like colors are off on Chrome canary

it should be fixed by https://chromium-review.googlesource.com/c/chromium/src/+/7459081

gif supreme sounds like a taco bell menu item

Or a character from Idiocracy

SWF++

> Starting with Firefox 148, HDR video on Windows is now supported in Nightly builds. This is considered experimental as we gather feedback before enabling it in regular releases. This feature works best when HDR mode is enabled in Display Settings (this may require a page refresh); otherwise, the display driver is likely to apply a tonemapping effect for non-HDR viewing. Some streaming sites may still not offer HDR video in Firefox. https://www.firefox.com/en-US/firefox/149.0a1/releasenotes/#:~:text=1978102-,Starting,Firefox,-%2E

doesn't work on my machine

the youtube player gets an hdr video but the output is very clearly sdr

is your GPU driver providing you with MPOs in Windows?

i think it should but i'm not sure how to check

well ``` MPO MaxPlanes: 1 MPO Caps: Not Supported MPO Stretch: Not Supported MPO Media Hints: Not Supported MPO Formats: Not Supported ```

Nvidia or AMD? resolution? and bitdepth?

I've had to deal with trying to get drivers to provide MPOs and all those factors make a difference

is the implication here that firefox will only support hdr video via MPO?

yeah that's likely how they are doing it

well that's not good

also oof you aren't getting MPOs because Nvidia cards only support them for 8bpc (AMD supports up to 16pbc) and also I think 4K is too high res as well but I haven't confirmed that fully

supposedly this configuration should work on w11 but i'm on 10

if you turn down the bitdepth and res you should get MPOs

also apparently: * if you have more than one monitor, the driver assigns all mpo planes to a single one * if you're using DSC (or potentially only when maxing out the bandwidth of a single display head, not sure), you don't get mpo at all

yeah there's a lot of random stuff that causes you to not have MPOs, it's annoying and so poorly documented

nothing on 1080p either

8 bit

darn either something else is causing them to get disabled OR it's possible that the res cap is based on the max supported res of the display or something like that

> On the technical side: we’re defining HDR video as video using the BT2020 colorspace with the Perceptual Quantizer (PQ) transfer function defined in BT2100. In our observations, all HDR video on the web uses this exact combination of colorspace and transfer function, so we assume all BT2020 video is PQ as a matter of convenience. how do we tell them...

wait i should try fullscreen, not sure if i did earlier (no that doesn't work either)

😬 where is that from

https://mozillagfx.wordpress.com/2026/01/16/experimental-high-dynamic-range-video-playback-on-windows-in-firefox-nightly-148/

so first Mozilla/Firefox supports MKV incorrectly now HDR?

what a shame

luckily no other standard beside PQ is used on the web ever

oh wait

Firefox sometimes really doesn't make it easy to remain a user

I’m sure there is some HLG, but what’s a concrete example we could give them?

there are hlg hdr videos on youtube

yep

e.g. https://www.youtube.com/watch?v=3ypGuk6JC6M

Also some productions, like from the BBC, are available on streaming services that may be consumed on the web. Although that portion of users will be niche I assume

since default phone camera apps exclusively (?) record in HLG, there's also a ton of random videos with HLG that are just direct uploads from a phone

True, but the same goes for photos too

HLG HDR is more common with high end cameras

But well, supporting HDR photos on firefox will take even longer than HDR video

someone else who has MPO working tested it and it doesn't work for them either so idk what configuration is even supposed to work

IMO arbitrarily not supporting aspects/components of something based on assumed usage is an awful idea and just makes it so people are forced to limit how they are using/making something. This kinda feels similar to how we are stuck with a limited version of the JPEG 1 spec because people decided they didn't need or care about the full thing

what does the `about:support` page say next to where it says "OverlaySupport"?

mine: `NV12=Direct YUV2=Direct BGRA8=Software RGB10A2=None RGBA16F=None VpSR=Supported VpAutoHDR=Supported HDR=Not Supported` theirs:

also found this: > IsHDRTransferFunction() was added to check if a gfx::TransferFunction is > one of the HDR ones (PQ or HLG), but currently TextureHost does not have > any easy way to get the gfx::TransferFunction to DCLayerTree to make a > decision to display it as HDR, so DCLayerTree code is assuming that any > video with BT2020 colorspace is HDR (this is the same assumption we made > on macOS, it has proven surprisingly robust) - it would be good to clean > that up by properly plumbing TransferFunction through TextureHost, which > could be useful for future code paths like HDR canvas and images.

example for that https://www.youtube.com/watch?v=WI_s2cPfzlg

oh for fucks sake

I really hate lazy ass devs

BBC iPlayer my beloved (I don't have HDR though)

anyone know a way you can redirect image urls on chrome? on firefox you can just use the redirector extension but it doesnt seem to work on chrome

finally got fed up and made a jxr to jxl converter, but the libjxl rust bindings are kinda rough to say the least

So JXL in HEIF is called HXL https://github.com/webmproject/CrabbyAvif/pull/738

could you compare it to passing a JXR as EXR via magick to libjxl?

suuuuure, gimme a few minutes but heres the code https://codeberg.org/Quackdoc/jxr_to_jxl right now it only really works with scrgb since I cant figure out how to attach a color profile in jpegxl-rs that isnt srgb or "srgb linear"

I want to bypass image-rs but it seems like it doesn't kill out of exposure data at least for now

huh, libjxl on arch doesn't compile with exr support?????

``` cjxl -d 0 -e 7 test-magick.exr test-magick.exr.jxl JPEG XL encoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Getting pixel data failed. ```

you mean from the repos or if you compile yourself?

repos

You have to compile yourself

sadly

damn it

whats the cmake arg to add exr support?

ah nvm

if you compile yourself it just compiles with EXR support, at least for me

if you have the libs for exr of course

when JXR support in libjxl? <:galaxybrain:821831336372338729>

at least in tev, the jxl file matches the exr file, when you encode tiff using the program, it looks the same as jxrdec

jxrdec doesn't assign metadata so it just defaults to g2.2

which is obviously wrong for a lot of reasons

try to compare the image hashes instead. You'll have to decode the JXL to EXR for the comparison because converting an EXR to JXL has mismatching checksums if directly compared

but at least that behavior matches [omegalul~1](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&name=omegalul%7E1&lossless=true)

I just opened both the exr from magick and the jxl I encoded in tev and looked at them and matched some pixels, oh, also my program doesnt save alpha, jpegxl-rs seems to break with alpha for some reason and most people probably don't even want the alpha from jxr anyways

Most JXRs are generated by Windows, does it even generate JXRs with alpha?

At least mine don't have an alpha channel

it probably could but I doubt any apps would use it but something like MPV might

it depends on the format

PQ will never have alpha, some scrgb ones will

MPV cannot even open JXRs for me

not a surprise, since jxrlib is in like, nothing

Yeah, I don't think libjxr was ever(?) included with FFmpeg

I only used rust since jpegxr-rs vendors it and makes it easy to compile even on windows

also jpegxl-rs does the same, so it's literally just a cargo build with no dep management needed

nice

I just need a tool that can modify a jxl file in place and assign an ICC to it

that or for jpegxl-rs to support it lol

Can you assign an ICC with exiftool?

also should work in place if it does

I dont think exiftool works with jxl like that sadly

at the very least it cant read one ``` exiftool -icc_profile -b -w icc ./test.jxl 0 output files created ```

I gotta say, jxr saving in 128bpp is kinda wild

wait lmao

it creates no output file, but if i do -v3 it does

[woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=woag&lossless=true)

i just wanted verbose output

and all i got was an ICC

oh weird, it writes the verbose output to the file

lol

I can see whats happen, because -icc_profile writes to stdout, I guess -w just redirects stdout to a file

oh well

hm, maybe PNG as a mezzanine format to extract the icc from is necessary

prolly, but if it cant read it I certainly have no hopes of writing it lol

another mezzanine PNG to write the ICC to <:galaxybrain:821831336372338729>

the RGB planes of a cjxl .jxr.exr.jxl and my jxr.jxl match so thats nice

Couldn't you just use cjxl to attach the colorspace?

that would be interesting, but realistically no, that is too much headache since I want this to be able to be used without the userland tools installled

(audio) new fast implementation of the same old metric as the late “TT Dynamic Range Meter”: https://github.com/sboukortt/speedr

on theguardian, it seems jxls not loading might not be jxl-rs or chrome specific (no load on ff stable with jxlextension or chrome canary, but does on cromite 128 with the old libjxl integration and other supporting browsers). seems it tries loading the avif versions of images and either succeeds despite jxl support or fails and displays empty placeholders

I got served JXLs with .jpg extensions, which the browser extensions wouldn't pick up

some browsers with jxl support correctly receive jxl, others dont

Canary not decoding is a jxl-rs bug though, I can repoduce it with my own files and a build of the jxl-rs binary

Probably because some aren't doing MIME sniffing and rely exclusively on extension

Extension is not a good indicator, nearly all jxl served by cloudinary is with a url like .../f_auto/.../foobar.jpg

That's due to https://github.com/libjxl/jxl-rs/issues/609

looks promising

Oooh

(http://uwspace.uwaterloo.ca/bitstream/10012/3867/1/thesis.pdf)

Not bad

A shame it was never cited for further development, the only ones are for blue-noise dithering during raytracing

Because it is useless for compression, add noise = add entropy also useless for display, screen is not sigma-delta DAC

My friend sent me this as a suggestion to get JXL support into Blender https://cdn.discordapp.com/attachments/530853682678595594/1462578778071892051/stelkai_-20260118-0002.mp4?ex=696eb422&is=696d62a2&hm=b5b1c978f7189d19904af7adc67f8a979c34b335a10c3ebcf4298224d19eb1d4&

https://copyparty.adrian.place/PublicUnlisted/hubblepicture.jxl (~25 mb, lossy e7 d10 fast decoding 2) from https://science.nasa.gov/mission/hubble/science/explore-the-night-sky/hubble-messier-catalog/messier-31/ 42,208 x 9,870 203 mb jpeg uses like 9gb ram on my computer, but encoding time is fairly reasonable. interestingly effort 8 uses like 22 gb of ram before erroring out from not enough memory. windows photo viewer is pretty responsive with the jpeg xl (and the jpeg, I think it decodes the whole thing and then generates mipmaps or something). imageglass is basically unusable with the jpeg xl though, taking way longer than 0.12 djxl to decode and then doing the same thing again whenever you move the viewport. chrome doesn't even try to open it

Chromium limits max pixel count to 2^28, so yeah this is not supported

Why is that? Chrome can open the jpeg perfectly, at least on my phone

Interestingly Firefox is a lot more responsive on my phone because Chrome freezes while it's decoding the jpg

Is the limit just a general jxl-rs thing?

it's a level 5 conformance thing

jxl spec defines level 5 and 10, level 5 is more restrictive but allows related decode assurances/assumptions

JPEG calculates the required memory and sets the limit based on that, I suggested it for jxl-rs but a megapixel limit was already put in place to match level 5

Also because currently jxl-rs uses 2-5x more memory than libjxl

The JPEG/PNG limit has bit depth taken into account (i.e. 2^29 for 8-bit and 2^28 for 16-bit), while AVIF/JXL use global 2^28 limit

Also, distance 10 does resampling 2, so it's actually half the res internally. Effort 8 disables chunked encoding, so it tries to run patches

That's interesting, I tried to force resampling 1 but the output seemed very similar and almost exactly the same file size. Maybe I did something wrong, i'll try that again.

Depends on encoder version too, it's 0.12 only

yes, i'm using from https://artifacts.lucaversari.it/libjxl/libjxl/latest/

Here's the link to that discussion too https://discord.com/channels/794206087879852103/803574970180829194/1451557167353172039

It may not have much effect, I did set 10 as the threshold since it didn't look much different, and targeted the same filesize

might be it then, it was significantly <1% different iirc so i was suspicious

oh also the encoding speed was very similar

ok idk if it's because of faster decoding or me doing something wrong before but it was around 3 MP/s now, and I remember ~5 MP/s before with resampling and ~6 MP/s before without might be just because my RAM is more full, it did go up to about 20 gb and start going into swap this time

significant filesize difference now however, the resampling 1 version is 23.0 MB vs 25.3 without the flag

Huh... Interesting... I know (Theoretically) the resampling should be a flat 2x decode speed boost for libjxl and jxl-rs, but again only in 0.12 so not much shipped with it

<@623776984987729940> in a future Chrome commit, what if we made the limit based on memory too? There's even already a variable for the other formats we could use <https://chromium.googlesource.com/chromium/src/+/1ade7e92edd967c0d54c64f262f9c149b48d0a96/third_party/blink/renderer/platform/image-decoders/image_decoder.cc#79> ```size_t CalculateMaxDecodedBytes( ImageDecoder::HighBitDepthDecodingOption high_bit_depth_decoding_option, const SkISize& desired_size) { const size_t max_decoded_bytes = Platform::Current() ? Platform::Current()->MaxDecodedImageBytes() : ImageDecoder::kNoDecodedImageByteLimit; if (desired_size.isEmpty()) return max_decoded_bytes; const size_t num_pixels = desired_size.width() * desired_size.height(); if (high_bit_depth_decoding_option == ImageDecoder::kDefaultBitDepth) return std::min(4 * num_pixels, max_decoded_bytes); // ImageDecoder::kHighBitDepthToHalfFloat return std::min(8 * num_pixels, max_decoded_bytes); }```

yes can confirm with current flags 3.0 w/o resampling and 6.2 with it's not resampling per axis? I would have expected 4x speed...

i think i uploaded an earlier one on accident though, this is the actual without resampling flag https://copyparty.adrian.place/PublicUnlisted/hubblepicturefast4_new.jxl and this is with resampling 1 https://copyparty.adrian.place/PublicUnlisted/hubblepicturefast4noresample.jxl

It still has to do non-seperable-upsampling too, so that could be taking up some time, but good point

So I need to buy a new monitor and I was wondering... HDR standards, is it all just a scam? It honestly seems like a bunch of marketing buzzwords designed to make a bunch of FOMO money. I want higher bit depth, I want wider color gamuts with deeper primaries, but I don't know what "HDR" has to offer on top of that.

i'd reccomend looking at reviews, they usually show actual minimum and maximum brightness, contrast ratios, white box test for the dimming zone monitors, etc

verify before you buy. wouldnt look outside what RTings recommends

hdr would give you consistency in image reproduction accuracy for your entire workflow if it supports it

after using a 144hz 1080p monitor for a while I would honestly much prefer a 144hz lcd over a 60hz very accurate oled even if i'm not doing any gaming

the illumination approach makes a massive difference. everything cheap fakes hdr

dimming zone monitors are worth considering IMO, a 4k monitor with like ~45x25 dimming zones costs about the same as a 1440p oled although iirc some suffer a whole lot with accuracy in hdr content, but in sdr and wide gamut the newer ones are very accurate. in hdr of course they also can't do high contrast over a short distance on screen, but I've heard they've gotten pretty good at hiding that limitation.

Consistency why, because they are more likely to have a properly calibrated factory color profile? I don't see what the difference is between "HDR" (sounds like a vague marketing term like saying "the cloud") and a monitor that simply has wider color primaries and a higher internal bit depth.

You can always turn HDR off, but you can't make an SDR monitor display HDR

anything with a non-dimmable backlight will never be remotely accurate in darker colors

But if it's bright enough and the internal bit depth is high, then... what exactly am I missing out on? The marketing buzzwords?

hdr is generally a buzzword for high contrast ratio

which is what really matters

but it's not a term people know as well

Are all OLEDs HDR then automatically by that logic?

Or I guess only if they can get bright enough

Most apps won't output a high bitdepth *unless* HDR is enabled, it's only Unreal Engine we discovered recently outputs 10-bit SDR

if they have enough bit depth that they can look decent when a part is really bright while the white point is darker

then all they need for hdr is software support

imo

Hmm

(oled) hdr400 is better than regular hdr400 but thats the lowest end hdr thatll be certified

edge lit dimming makes movies look as dull as on old lcds

iirc some monitors say 'hdr' without really supporting a high contrast ratio, but I think if you look at the hdr spec you can know if it's actually high contrast ratio or not

Okay I think I sorta maybe understand now lol

Wait

i recommend sticking to specific models and evaluate how itd work with your own system. some OSes, cables and other devices might accept the signal but not interpret it as you hope

I guess I would say hdr is a combination of having a decent bit depth in darker areas and having a good contrast ratio

afaik apple's ecosystem is consistent, windows and linux diy messy

I don't understand 10 bit SDR mode exactly

yeah hdr in software is a whole other mess

I think it's just 10 bit ints everywhere but I don't really know

temporally dithered 8 bit looks the same

will take a look, that might also be the root case for this 99frame 4k image

Every monitor has a different contrast ratio and a different peak brightness so I don't understand what is so special about this special hdr/sdr designation when at the end of the day, the content is always tone-mapped to fit the range the monitor can support

if a monitor has good enough bit depth and a good enough contrast ratio then it's just software

Either by the hardware itself or by the OS

It seems weird that a bunch of sleazy fomo salesmen have this weird line in the sand separating SDR from HDR when every monitor is different

monitor branding is just generally terrible

Like they want you to buy a monitor based on the marketing buzzwords on the box rather than the quality

like in monitors with dimming zones you always have to dig around to find how many dimming zones there actually are, no company ever puts that in the name of the listing

would be so much better if they actually just told you the specs..

And an inferior monitor can claim to have support for some new buzzword and you might forsake a technically superior monitor that doesn't have the latest buzzwords on it

that's just how buzzwords work in general really

"AI"

anything that you can bend the meaning of

"Metaverse"

Well even if you know the dimming zones, you don't know the behavior until you do a bunch of local dimming tests and see how it looks... and it's nice to be able to disable it entirely since it can mess with how colors look

Yeah it also annoys me that people don't use the right words

There's a difference between "AI" and neural nets / machine learning

Really AI is something completely different

yeah some of the local dimming zone monitors i've looked at seem like they just don't care about color accuracy at all when the local dimming zones are enabled, which is kind of terrible IMO because either way you're missing out on one of the 2 major monitor features

Yeah, local dimming can be really terrible... especially when the entire screen suddenly flickers to a different brightness level, but then they shouldn't call it "local" anymore...

yeah i've seen that in macs, it's weird

ok i'd say i prefer the no resampling version but it's really a tradeoff between sharpness and artifacting

... probably should have done this in benchmarks but whatever distance 3 effort 7 is 2.8 MP/s, 74 MB, similar ram usage to d10 resampling 1 transcode didn't print the speed but e7 was a few seconds and e10 a few minutes, with 162.2 MB for e7 and 161.6 for e10. e1 is about the same speed as e7 but 174.2 MB. (all coming down from 202 MB)

cjxl is reporting size in decimal, explorer is reporting it in binary, but also reporting decimal multiples of binary kilobytes not confusing in the slightest so i may have messed up some numbers slightly earlier but idk

<https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md> > Chunked encoding is also disabled under these circumstances: > VarDCT at distances ≥10. > Effort 7 VarDCT at distances ≥3.0. > Efforts 8 & 9 VarDCT at distances >0.5.

PQ and HLG are designed _so that_ 10-bit is more likely to be enough to not have banding when used over such brightness ranges (plus they’re a way to “address” the right brightness without the OS having to know how bright the display gets)

if a 1000-nit monitor simply displayed the same thing as a 100-nit monitor, but scaled to 10× the luminance, it wouldn’t look right

the "HDR is just marketing" doesn't make sense to me. I'm sure it's marketed to hell, but that doesn't take away from that there's a set of valuable standards that make it work

That sorta makes sense, but that sort of simple and naive scaling works pretty well until pushed to the extremes.

seems like with a good enough spatiotemporal dither at a normal distance from my monitor (1080p, 144hz, 23 in maybe?) it stops being objectionable to me somewhere between 3 and 4 bits (quantization in srgb) but not 100% sure because the spatiotemporal blue noise approximation that i found on shadertoy doesn't work for this purpose because it's not always evenly distributed for one pixel over time

You're testing temporal dither with blue noise? Sounds cool. Where’s the code?

using https://www.shadertoy.com/view/wfjcz3

you can even see that it's not evenly distributed here

because it only averages out over time in linear space and not srgb

or i guess the other way around

idk, i mean you take the output and blend it in code you get 0.5 always, vs if you take the output, give it to a monitor, the average real-world brightness of the pixel won't always be 0.5

The framerate is definately doing a lot, at 60fps similar distance it's very obvious

no that's effectively 1 bit

https://www.shadertoy.com/view/33tcDs here's the code i'm using

the other was the noise function i was using for my code

just look for the flicker though, the persistent noise and light to dark banding i think wouldn't be an issue if an actually correct noise function was used

Ah right

Hmm

oh whoops should be fixed

https://www.shadertoy.com/view/t3sBWs here's with temporal ign from https://blog.demofox.org/2022/01/01/interleaved-gradient-noise-a-different-kind-of-low-discrepancy-sequence/ which has its own issues, a little bit of smoothed banding and some correlations over time causing a creeping effect

both of those are ~3.5 bit, 11 colors

256/24, so change the 24 to something else to change the number of bits

not really

also, a MacBook Pro’s display can go up to 1600 nits peak, or 1000 nits sustained

nothing in fact, afaik all panels use 2.2 gamma and native primaries as the wire format so really any consumer display, or the device driving it, is doing a conversion from "hdr" to "sdr" (very loosely defined) in its pipeline and you can take any (good) sdr display and convert an hdr signal to be displayed on it the same way yourself. i think madvr and/or mpv can be configured to do that

so an external "hdr" monitor is really just one that can convert a bt.2100 pq signal to panel native 2.2 internally (depending on the display technology this might also involve switching the panel into an "hdr" mode, that e.g. lets it go brighter at the cost of introducing dimming in large bright scenes)

https://www.shadertoy.com/view/wXdyWl this one should be perfectly smooth on an ideal monitor, just using white noise though because i think the ign i'm using is introducing its own bias

correcting the proportion of time the pixel is turned on for based on what would actually match srgb when averaged over time

here's a completely unlabeled desmos graph that shows the problem https://www.desmos.com/calculator/jk7t7kbtb5 but honestly the code is more readable

spatiotemporal blue vs white noise really makes a huge difference

The summary is that dithering is linear so you need to calculate what proportion to dither in a linear color space regardless of what space anything else is in Which is still applicable with just spatial and not temporal dithering

In the context of a dithered image this probably doesn't matter as much because image viewers usually do their own blending in nonlinear color spaces for some reason

Yes, dithering should be done in linear color in principle, but that will make way more difference when doing something like using dither to make an image with a small number of colors (like a 16-color palette or something) than when using dither to reduce banding in an 8-bit RGB buffer (24-bit per pixel).

when the difference between two neighboring values is just 1/255, the error from doing dithering in gamma-compressed space vs linear space is not that important, compared to when you're dithering with colors that are way further apart.

As the length of a segment of the gamma curve decreases that segment approaches a line so the error from interpolating linearly is smaller Idk how that principle is usually described

But it makes sense that the error should be much smaller in higher bit depths

BTW, yesterday I am thinking > We know uniform quantization need adding noise before noise shaping (error diffusion), but how about vector quantization (palette color)?

for what it’s worth, here is how it looks with naïve, non-linear TPDF dither: https://www.shadertoy.com/view/tXdyDl

messing around with the ign function in python and it seems like it's fine, i think the rest of the banding just comes from my monitor not being ideal

at a slightly further than average distance from my desk i probably wouldn't even notice the 3 bit temporal ign

yeah in some images i notice a tiny bit of flicker if i look for it but it's mostly fine reached a shader limit apparently so here's the code

some nice textures

from this source, I thought this would be a hard scenario for vardct but it handles it pretty well. helps though that it's impossible to tell how correct any output is without flipping back and forth

hdr images in chrome on android cause same insane jank

also note how much random noise there is in the tab preview, that's not a recording artifact

bonus: if you zoom in just right you get grid lines

yes, a 1000 nit monitor has something like 35 % more dynamic range than a 100 nit monitor, psychovisually

hey <@184373105588699137>, i was trying to ask you on that Phoronix thread which web gallery tools you can recommend that support JXL and/or progressive rendering not sure if I offended you somewhere and you're not replying on principle or just missed it, so I'll ping you again once just in case — apologies if it's the former 🙃

ah no, I just fucking lost it lmao way too many comments on that thread, rn I am only using web based tools, I don't actually use much native tools any more simply due to lack of time, but tools that I used in the past was a fork of calibre that had some support for progressive loading. but most web based gallery apps will support progressive loading like pleorama and what not, as for native apps that support progressive loading there were some old chan clients that supported it, but it's been ages since I used them.

yeah I was asking about web tools, not native what's pleorama? doesn't turn up in my google

we should be seeing more support for progressive loading soon as iirc flutter devs were working on actually supporting it

sorry, meant pixelfed, pleorama is a twitter like alternative, pixelfed is a snapchat like alternative, I believe immich should support progressive images too for self hosting

ahh, you mean pleroma

oh did I misspell it? my bad im terrible at typing

so yeah, I know about the activitypub social-media-adjacent stuff, but was mostly wondering about pure "self hosted gallery" stuff, like sigal or copyparty (it has a slideshow mode)

I'm using copyparty now but it's obnoxious because it resets itself out of the proper file name sorting mode every now and then

and it doesn't do jxl for thumbnails, or I couldn't make it work nor does it keep track of your current position

so I was mostly checking if you know anything better for that usecase

the usecase is essentially a web viewer frontend for a folder with 1000 images in it, not anything social-media-adjacent or photo-organizer like immich

hmmm, maybe nextcloud memory is more your style? its more of an organizer but it's first onboarding is much like google photos

I think that has a webui

something more simple like https://github.com/hsa00000/urocissa but I dont think it supports jxl... yet

doesn't seem to support external folders at all

I'll try the nextcloud thing

oh wait urocissa is entirely wasm anyways

oh wait, try https://github.com/gbbirkisson/spis

it used to be bog simple to do, might work by pointing it at a folder

oh, this looks promising

seems to have some sort of a folder picker in the UI

alright, thanks!

Jxl isn't supposed in the slideshow thingy yet but for thumbnails it works for me, it should just work if you have ffmpeg or pyvips installed (I have copyparty, pyvips, and ffmpeg all installed with the package manager on Arch) See https://github.com/9001/copyparty/issues/724

original image, jpegmini converted, jpgxl from jpegmini converted 10mb, 7mb, 6mb can you see the difference?

10 MB to 7 MB isn't much for a JPEG conversion from an original, I assume it's camera JPEG, to jpegmini, to JXL transcode?

i'm using an iphone 17 pro

yes

let me try og -> xl

still 20%

By default it will always be 20% and lossless, you need to disable JPEG transcoding to get smaller lossy results (if you're using cjxl, its `-j 0 -d 1`)

> The scope of JPEG DNA standard (ISO/IEC 25508) is to define a syntax and accompanying decoding process capable of representing media assets, notably digital images, in a quaternary representation suitable for synthesis into nucleotide sequences to be used for storage on DNA support. this sounds like a science fiction :p

anyway, unfortunately it seems that only the JPEG XL page on https://jpeg.org/ has the image as a JXL

they should all be JXL, really

and there are also some PNGs (like the graphic on <https://jpeg.org/aic/aic3.html>) which I feel should be lossless JXLs!

don't you know about the MPEG group for genome compression? https://mpeg-g.org/

JPEG DNA is fun, when they talk about encapsulation they mean actual physical capsules to contain the DNA.

found some site offering jxls that display fine in a webpage and desktop viewer when DLed but gargbled text when opened in a new tab in canary. possibly malformed, issue in jxl-rs or server misconfiguration?

(site is skifworld . com)

maybe there was no content-type header and browser had to guess?

reopening the downloaded jxl in canary displays fine, so server blip?

The image is served as gzip-ed text, it works inside the page because it has `<source type="image/jxl">`

Seems it's due to Cloudflare doesn't support JXL and didn't set the content-type header

+ it set x-content-type-options: nosniff

anyone else going to [RustWeek 2026](https://2026.rustweek.org/) in the Netherlands?

I'm still annoyed I missed the VLC conference, but I would've had to leave at 6am with no guarantee of entry after finding out about it at 2am 😅

oof yeah, that's a tight schedule XD

There's a reason conferences/conventions usually have hotels on site haha

Rustweek sounds like a chill holiday

I'd go if it didn't collide with EGOI (https://egoi2026.it)

ah that's unfortunate

https://issues.chromium.org/issues/475475547 did that issue get lost in the void? the regression is in the beta now and it'll be in stable soon :/

ugh, I forgot about that - writing someone and seeing if they can figure this out...

adb shell dumpsys surfaceflinger can tell if someone wants to set up automated testing

nomacs

Windows Photos

xnviewMP is really good

Chris figured it out (even in time for fixing it :D)

so 145 stable should have jxl and working hdr on android, right?

yup

Is Special K Image Viewer any good? For those poor souls on Windows.

i couldn't get it to open jxl images when i tried it recently, no idea why

it complained about the decoder missing even when i put the files there manually

SKIV is designed for viewing HDR screenshots so it might be the perfect thing to recommend but I haven't been on windows in a long time to test it

Oh yeah I forgot this is an option now

Just use that

Windows has a JXL codec just like they have a h.265 codec and you get it the same way

(minus the part where you're supposed to pay money)

there's a official free version of the h256 codec on the Microsoft store but it requires a GPU with support and also they try to hide and prevent you from installing it despite it working fine

afaik that's intended for things like laptops where the manufacturer paid for it, and you can't download it directly from the ms store like that anymore

(you can just get the file elsewhere though, that's what i did)

Nothing faster than qview

If ya want more features this forks the way to go https://github.com/jdpurcell/qView

Also a good cross-platform **QOI** viewer

can confirm this is fixed on latest canary, and the merge on 145 stable is in progress

If you want to track progress <https://issues.chromium.org/issues/479223728>

can confirm that everything on https://jpegxl.info/resources/hdr-test-page.html works properly on android canary now

yeah, one of the early user of jxl-oxide

seems chrome 146 might have jxl decodable out of the box? tried latest canary, didnt need to enable the about:flag toggle

It might have imported setting from the old installation, or synced it from the cloud

full default, changed flag a few time. just wondering if theyre trying to speedup solving kinks with a much larger feedback pool

seems you mightve been right, default sometimes replicates the previous state of the toggle. false alarm i guess

<@&807636211489177661> <:BanHammer:805396864639565834>

<@794205442175402004> do you have a line to the people at Cloudinary that help with the maintenance of the JPEG website? I think it deserves that all images hosted on it are primarily a lossy/lossless JXL, replacing many PNG and JPEG files

It's not Cloudinary maintaining that website, Cloudinary just helps to cover the operational costs of the website and committee in general.

But I do know the maintainers well, I will bring it up when I get the chance.

perhaps old sites could benefit from using hj's polyfill since it gracefully uses a browser's native decode if it supports jxl - like sneyers.info/browsertest and jxl art pages

I imagine they'll use the ⁨`<picture>`⁩ element to fall back to older formats, like they do on the only page that serves a JXL: https://jpeg.org/jpegxl/index.html

I wonder if anyone recognizes what this is

Individual XYB channels of a browser screenshot?

apparently this is what Firefox's texture caches look like

or at least, the debug visualization of them

possible inspiration for JXL's improved patches encoding ?

I suppose if you're using Firefox's screenshot tool it could directly hook into it to replace manual patch detection, though this texture cache can contain anything from any tab, so to avoid leaking information you'd have to cut out everything that's not from the captured rectangle

I've talked about how Firefox could put photographic images into their own VarDCT frame, so that the text and other elements can be losslessly compressed while not wasting so many bits on photographic features -- using the texture cache to give Patches a hand could be interesting for sure

the guy who created jpegultrascan (and reported the APP14 issue) is actively working on a better/faster version of it > I have a working version of this that actually improves on the Perl result a little. However, I discovered that unlike libjpeg, scan encoding in jpegli is NOT invariant and instead depends on preceding scans, so the core assumption of this program is violated. > It's not feasible to test every possible combination due to combinatorial explosion, so I am still working out the best way to proceed. https://encode.su/threads/2489-jpegultrascan-an-exhaustive-JPEG-scan-optimizer?p=87018&viewfull=1#post87018 Can someone explain what it means by "*scan encoding in jpegli is NOT invariant*" and why it would be different than libjpeg ?

One day the PRs will get merged....

I was looking at the image in the old issue you made and wondering why it had so many red edges https://github.com/MegaByte/jpegultrascan/issues/7

Then I remembered, I think one of my PRs was to fix subsampled XYB, as it was subsampling X and Y instead of X and B

I wish I had an OLED HDR screen <:PepeHands:808829977608323112> but on my LCD, I have huge difficulties to see stuff like that (and banding too)

Huh, really? They seemed pretty obvious to me on a standard LCD too

`gfx.webrender.debug.texture-cache` on https://jpegxl.info/

well it's already red in the source look at the left-most edge, it's green ask if you want the 13MB PNG

Oh, interesting. Can definately see the luma is subsampled though

MPV is not happy with that XYB jpeg `[vo/gpu-next/libplacebo] ICC profile too wide to handle, colors may be clipped!`

interesting

I wonder if that's why Irfanview has a blue tint to XYB images, going slightly out of range of it's color management

I thought XYB profiles are PCS LAB multidimensional transforms, so video software wouldn't bother handling that kind of thing?

it's specifically libplacebo here if you look

not "video software" in general

though... I think you're right

well I get the same results with other `--vo`

I still don't know what he meant by "*I discovered that unlike libjpeg, scan encoding in jpegli is NOT invariant and instead depends on preceding scans*"

depends on the software

https://www.flatpanelshd.com/news.php?id=1770375204&subaction=showfull

patents suck

lmao

Hell yeah

Oh wait this is bad news

lol

Who needed HDR and 3D anyway

I thought initially from the title that it meant patents held by disney were ruled invalid but it actually says patents held by interdigital patent troll llc are being used to shut down technology

HDR is pretty much not needed for many Disney releases. At least the ones I have checked rarely exceed 200-300 nits

tron ares hovers around 300 - 400 nits maxcll but looks absolutely stunning

any update about interop? right now support powered by jxl-rs is trickling down behind a flag to browsers (now in brave beta 1.88, firefox nightly 149).

its not just chrome planning to have it on by default, with it being done on chromium eventually the derivatives surely will, including webviews (preinstalled and autoupdated) and chromeos (v145 is in early stable rollout)

Results should be out Feb the 12th I think

hear me out... cropped ENcoding

being able to load a massive image and zoom in on certain areas, while changing encoder settings on the fly. it could only encode the sections in view <:Stonks:806137886726553651>

the theoretical JPEG XL Studio program that I've been dreaming about would have this

I have no idea what the use case would be but maybe look at Hydrium

I was goofing off in Squoosh with the massive mandelbox render, which has a lot of interesting features and different parts of the image test different strengths of a coding system. but it's massive, so any settings change makes it take a while to encode again. since groups are individually encodable, a tool could just encode the groups that are in view, if you know the group size and viewport location/dimensions ahead of time

though, now that I think mow about it, the decoder is expecting groups in a set order, so I doubt you can modify the JXL in-place as if "streaming" it by adding more groups... rather you might be better off compressing and caching groups individually, and then reconstructing a new JXL with the groups that you need after the viewport has moved, on the fly

Yeah but... Why? Are you trying to preview lossy compression in an area? Because you could just crop the image and encode that instead without writing to a file constantly

> Because you could just crop the image and encode that instead without writing to a file constantly it'd be an in-memory file, but yeah, that would work. a naive approach like that would mean that already encoded groups can't be re-used if you're just panning and haven't changed encoder settings, but that may be a fair compromise. (and you'd have to make sure you're still encoding units of groups even when you crop, as you wouldn't want to change pixel alignment)

> already encoded groups can't be re-used if you're just panning and haven't changed encoder settings Again... What is this for? Encoding random blotches of an image only where you've dragged and zoomed doesn't feel very useful

maybe some complex system with a giant super mega large single image encoded at a low effort that then re-encodes areas people view the most at higher efforts?

it's for encoder quality testing on massive images. you can change encoder settings without having to re-encoder the *entire* thing, rather just the part you're looking at

we have the wedges coding tool at home. with multiple frames, patches and blend modes

Previously the No Man's Sky website had some sins like non-lazy-loading 8K PNG images, so I thought I'd check their most recent update page... Seems they've moved to using 8-bit PNG, which is... Something I guess https://www.nomanssky.com/media/f5lbgarf/remnant-book-cover-optimised.png

lol

https://www.youtube.com/watch?v=Ol7uc9OqEf8

anyone have an idea what all those weird video artifacts are? did bad cameras just output files that look like that or is there some weird youtube processing going on

stuff like these patterns that seem to come and go, and the halos/artifacting around anything that's moving

and that also turns into weird colors for a bit

re-encoding a video several times compounds the artifacts

yeah. im fairly certain this is mpeg-4/h.263

https://en.wikipedia.org/wiki/Nokia_6630

this would be a phone released around that time and that video certainly fits the bill for 176x144 h.263

> It's a format built for the demands of today's digital world, aiming for longevity – hence the 'XL' for 'Extra Long' or 'XL' for 40 (XL in Roman numerals), signifying its ambition to be a long-lasting standard. [source](https://www.oreateai.com/blog/jpeg-xl-the-next-generation-of-image-compression-you-might-not-know-you-need-yet/0c5ab57f95f11d008b7928126f197f26)

how do we convert from tif to jxl

I used XL Converter, vips & magick, its in same file size & larger file size with lossless method

JXL should be smaller than a TIFF on average, what are you compressing?

some album scans from slsk. I often get smaller size when tif is uncompressed, but if it is compressed with jpeg, it will increase about 3-5% of its size I think

can you share a sample file for testing?

this two is compressed with JPEG according to exiftool