JPEG XL

2026-03-21 02:20:14	Most things can also handle tiff xD
2026-03-21 02:20:56	Exr just seems to be the odd man out
2026-03-21 02:21:51	noted
2026-03-21 02:22:58	Also some weirdness going on with video compair and jxl white point handling
2026-03-21 02:23:59	Specifically with this img
2026-03-21 02:26:36	Imma blame ffmpeg for that one
2026-03-21 02:30:02	Has the correct data and qview displays correctly
2026-03-21 02:30:14	Yea likely upstream bug

Quackdoc

2026-03-21 12:51:54	because a single exr image can contain many forms of data
2026-03-21 12:52:12	associated alpha, non clamped channels are the two massive ones
2026-03-21 12:52:23	per channel alpha is neat but rarely used
2026-03-21 12:54:09	The biggest benefit to associate alpha is that you're more accurately representing the real world. There are also real-world cases that you can represent using per-channel alpha, but it's fairly rare.
2026-03-21 12:58:25	By far, the most common issues you run into with rendering EXR are three issues specifically. 1) associated alpha. Alpha 0 images very rarely render properly unless you have an app that actually has proper alpha rendering. If you can disable the alpha channel in your app, you'll probably get a more accurate view. 2) non-clamped values being pixel values that are outside of the range of 0 to 1. Many apps will display that middle range, but you either need to be able to slide up and down or compress the entire image into that zero to one range. 3) EXR images by default are assumed to have an linear transfer value. This isn't always the case and this can really fuck up a lot of programs. A, programs that read in EXR and assume it's linear or B, programs that just don't support linear at all. Will both fail.
2026-03-21 12:59:51	The images with associated alpha don't really show your stuff until you put a background behind it, which is why when you load it into a properly composited either a video or image viewer, then that's when you'll see the benefits of it.
2026-03-21 01:01:13	to some degree
2026-03-21 01:42:38	using oculante as an example here but this is alpha enabled and disabled
2026-03-21 01:42:48	note oculante does not support linear transfers

o7William

2026-03-22 08:21:25

which exrviewer specifically?

Quackdoc

2026-03-22 08:26:06

the one I used to use was called openexr-viewer, but tev I thing can handle it good too

missaustraliana

2026-03-23 12:17:47

do you have high quality photos i can have? or does anyone? for codec testing

DZgas Ж

2026-03-24 02:12:17

webp is good

dogelition

2026-03-25 09:41:39	https://ipfray.com/dolby-sues-snapchat-over-av1-and-hevc-patent-infringement-in-u-s-and-brazil-access-advance-vdp-license-would-resolve-issue/
2026-03-25 09:41:41	damn
2026-03-25 09:42:24	so does that mean dolby can't use av1 anymore because of that patent clause? or does that not apply to this

_wb_

2026-03-25 09:50:25	I would imagine that this does trigger the defensive termination (clause 1.3 in https://aomedia.org/license/patent-license/)
2026-03-25 09:55:50	it will be interesting to see how AOM responds to this

dogelition

2026-03-25 09:56:30	doesn't make sense to me unless they really think h.266 will be the next big codec instead of av2, as i assume this would also lock them out of av2
2026-03-25 09:56:57	they do support dolby vision with av1 but afaik every streaming service still uses h.265 for that
2026-03-25 10:00:46	https://professional.dolby.com/legal/AOM-statement/
2026-03-25 10:00:47	hm

_wb_

2026-03-25 10:02:54

Right. So they basically say: we don't use AV1 and we don't need a license for it.

Fahim

2026-03-25 10:07:57

>"For more details, click here" >here links to Sisvel Not surprised

dogelition

2026-03-25 10:11:55

so even if that turns out not to be true, they already gave up the rights to those patents now so they have nothing to lose anymore by suing companies over these patents? that seems bad

_wb_

2026-03-25 10:15:32

yeah, looks like they became a patent troll like nokia, no longer actually doing anything useful so they don't need patent rights from anyone and have their hands free to sue all over the place

Exorcist

2026-03-25 10:29:44

AV1 users also don't want Dolby, so this is two-way rejection

ignaloidas

2026-03-25 10:32:09	I wonder could a stronger defensive termination clause could work? Because for patent trolls, there is no real cost from the defensive termination, since they don't do anything themselves
2026-03-25 10:33:48	So maybe something like "you may not license any patents from an entity that sued" or something
2026-03-25 10:34:58	basically forcing everyone to either choose AOM or Dolby in this case, which would hopefully be the death of people licensing from Dolby

dogelition

2026-03-25 10:55:59	idk the answer but since av2 is upcoming it would be interesting to see if they do anything different now
2026-03-25 10:57:27	though the spec draft is already out so i guess that couldn't apply retroactively to that...
2026-03-25 10:59:35	https://storage.courtlistener.com/recap/gov.uscourts.ded.92505/gov.uscourts.ded.92505.1.0.pdf

_wb_

2026-03-25 11:16:48

IANAL but it feels like this is probably complicated to pull off legally

dogelition

2026-03-25 12:04:22	i don't understand how dolby can claim not to be bound by the aom patent license when they seemingly use av1 commercially just like they are accusing snap of doing: https://go.dolby.io/hubfs/Streaming%20One%20sheeter%2020250328.pdf
2026-03-25 12:10:50	ah, they only support h.264 and h.265 in the transcoder. makes sense

_wb_

2026-03-25 12:36:16

What would be interesting is if AOM would show that they did their homework when claiming AV1 is royalty-free. It's quite possibly that those claims by Dolby are all bogus, either because the patent itself should be invalidated (because of prior art or obvious) or because the patent does not actually apply. After all, during AV1 design there was the explicit goal of avoiding any patent encumbered technology. I think it's time that patent trolls are getting discouraged, which requires fighting back rather than making it cost-free to troll.

ignaloidas

2026-03-25 12:57:59	I briefly looked at the one listed in that ipfray article that's mentioned to be AV1 specific and while it's vague, I think it would apply to JXL as well?
2026-03-25 12:58:25	idk if it's fine to discuss the specifics of what it says tho, there's some ideas of "if I don't know about the patent, it's better for some reason" that I've heard but idk whether those apply

_wb_

2026-03-25 02:16:09	for me it's fine to discuss
2026-03-25 02:17:30	generally all patents are intentionally formulated in a very generic, vague and confusing way, I suppose because patent lawyers like it like that

Demiurge

2026-03-25 02:29:33	The more vague and all-encompassing you make it the more you can accuse people of violating it in a sort of vile rent-seeking incentive
2026-03-25 02:30:34	Without patents people would be more shy about publishing the inner workings of their inventions maybe
2026-03-25 02:31:07	So that's one possible silver lining
2026-03-25 02:31:59	Intellectual property is an infringement on real property.
2026-03-25 02:33:19	Even the term "intellectual property" is a made up marketing/PR term that the industry lobbyists invented in order to gaslight people into thinking stealing an idea is the same thing as stealing a purse
2026-03-25 02:33:52	The terminology they use is designed to hypnotize and brainwash
2026-03-25 02:34:10	Stallman says this a lot too
2026-03-25 02:34:37	And I don't agree with Stallman half the time but he is right the other half

JaitinPrakash

2026-03-25 03:40:45

I wish that at the very least we go from permission required to attribution required, as even if knowledge should be shared freely people still want their names on the ideas.

_wb_

2026-03-25 04:03:59

>95% of current patents are "novel ideas" that are just straightforward combinations of existing ideas, things that people working in the field would likely come up with independently many times. Generally when someone has a great idea, they don't patent it but they write a paper about it and/or create an open source project implementing the idea.

juliobbv

2026-03-25 04:16:40	...or skip writing the paper altogether and directly implement the idea in code
2026-03-25 04:17:56	I bet someone at Dolby is also looking hard at IAMF

ignaloidas

2026-03-25 05:10:36	https://patents.google.com/patent/US10404272B2/en - I read this as just having multiple distributions and having something to chose between them
2026-03-25 05:19:57	unless I'm reading it wrong, I think it would apply to JXL?

_wb_

2026-03-25 05:37:52	if it's that generic (just context modeling) then obviously it was not novel when it was filed in 2018. E.g. CABAC (context-adaptive binary arithmetic coding) was presented already in a paper in 1999, so almost two decades earlier.
2026-03-25 05:39:44	so if the patent is valid, it must be something more specific than just "having multiple distributions and having something to chose between them", since that's something that basically any codec or compression scheme has been doing since h264

ignaloidas

2026-03-25 05:52:56	it was filed in 2012 in a bunch of countries, 2016 in the US
2026-03-25 05:54:23	I think it might be the fact that you mix prefix and arithmetic coding in the same bitstream? (which I guess doesn't apply for JXL then?)
2026-03-25 05:55:37	but patents are often written in such a weird way because the fact that you can't understand what it does or does not cover is useful for the holder/troller

_wb_

2026-03-25 07:47:16

It would be interesting to see what exact thing in the AV1 spec or in an AV1 implementation they claim to be covered by what exact patent claim. Just saying "this vague thing here is essential for AV1" should not be sufficient. The burden is on them to show exactly how it applies. Are the proceedings of this case publicly available?

dogelition

2026-03-25 07:58:22	https://discord.com/channels/794206087879852103/805176455658733570/1486318627715285092
2026-03-25 07:58:56	the main focus is definitely h.265
2026-03-25 07:59:38	for future stuff: https://www.courtlistener.com/docket/72582162/dolby-video-compression-llc-v-snap-inc/
2026-03-25 08:00:52	the way US courts handle these documents is strange, they are public domain but access to them costs money. so people then mirror them on this site

Reddit • YAGPDB

2026-03-27 10:52:57

DZgas Ж

2026-03-28 01:11:10	ok comeback to vp9
2026-03-28 01:15:15	It's been 8 years since AV1 came out, and this isn't the first time something like this has happened. Well, well, it's the same thing every time

Demiurge

2026-03-28 05:27:11	I thought Theora had lots of potential...
2026-03-28 05:27:31	With the right encoder.
2026-03-28 05:28:18	One of the x264 devs even mentioned a long time ago, the possibility of modifying x264 to output a theora-compliant steam.
2026-03-28 05:29:06	x264 is still very good

DZgas Ж

2026-03-28 08:40:19	x264 yes.
2026-03-28 08:43:43	For "gifs" forever

Demiurge

2026-03-29 01:19:40	So apparently there's an AVIF 1.2 now
2026-03-29 01:22:50	And I worry that while AVIF blazes ahead in terms of lossy compression quality and efficiency, especially with all of the recent psychovisual RDO tuning it has been receiving, that jxl encoders will fall noticeably behind in terms of image fidelity.
2026-03-29 01:25:51	It will be harder to convince people to use JXL when it produces blurrier smeared results compared to AVIF

A homosapien

2026-03-29 01:38:31

It's been happening for the past 3 years, (lossy) jxl has been stagnant while avif has been improving leaps and bounds. So yeah, jxl has already fallen behind. It's not a race to be the best, but it hurts to see jxl severely underperform (regressions or otherwise). Especially since the potential is there.

jonnyawsom3

2026-03-29 01:49:03

Quite a few of the 'AVIF is better' cases have been resolved with certain parameters or using lossy modular instead of VarDCT. It shows even with the current (regressed) encoder, with some more heuristics we could still win out. With the regressions fixed and quality improved more, there's leaps and bounds to gain

Exorcist

2026-03-29 02:09:16	need more study about lossy modular
2026-03-29 02:10:19	JXL is not interesting if most CDN use VarDCT

DZgas Ж

2026-03-29 03:17:31

Minor update, the script selects the first track for movies, stereo mixing, smart resolution depending on the aspect ratio, etc. And just to remind that i have something called my personal preset-standard EASYHEVC for x265 for hevc, the essence of which is to achieve the fastest decoding possible while using all HEVC technologies for quality. To play 1280x720 60fps on any crappy 100$ smartphone <:AV1:805851461774475316>

Demiurge

2026-03-29 06:07:56	Maybe work and experimentation on new psychovisual optimizations can be forked from the libjxl-tiny encoder.
2026-03-29 06:08:28	Since it's a simpler and smaller project to fork from.
2026-03-29 06:10:06	Might be easier to start from there.
2026-03-29 06:12:09	Plus it's meant as a guide for hardware implementers, so improving libjxl-tiny could potentially improve future hardware implementations using it as a guide
2026-03-29 06:17:18	AVIF has significantly improved since JXL was introduced. Meanwhile the reference JXL encoder has not made any similar improvements in lossy fidelity. It has improved in other ways, like no longer calling abort() anymore, but it never should have done that to begin with if it's meant to be a library.
2026-03-29 06:18:20	And I'm not an avif fan. I want avif to be the next webp, and jxl to be the next jpeg
2026-03-29 06:19:34	But I know that isn't going to happen if avif is noticeably several generations ahead in terms of quality.
2026-03-29 06:20:59	And libaom has significantly benefited from recent RDO patches that fixed a lot of its old shortcomings that JXL used to have an advantage in
2026-03-29 06:21:57	But the same or similar tuning and RDO could be applied to a theoretical jxl encoder
2026-03-29 06:59:20	Hmm, looking at the libjxl-tiny repo, it's kinda sad that a lot of cool stuff and placeholders were removed, and that it hasn't been touched in over 3 years. There used to be a stub/placeholder for a future spline detection subroutine. Also removed were seemingly important things like jpeg transcoding support.

_wb_

2026-03-30 08:58:51

It's normal that once an image format is semi-universally supported, like AVIF, effort starts focusing on improving the encoder. For JXL, currently the priority is still to get support in Chrome and Firefox, and then it will become a more attractive target to spend effort on encoder improvements.

jonnyawsom3

2026-03-30 09:32:05

If you checked libjxl at all the past month, you'd see a major increase in bugfix PRs since the Chrome support got re-added

Quackdoc

2026-03-30 01:28:21

personally I care far more about decoder improvements, I want jxl to be usable on even the most potato of hardware

veluca

2026-03-30 01:30:41	ehhhh 😄
2026-03-30 01:30:44	working on it I guess

jonnyawsom3

2026-03-30 01:31:04	The main weakpoint of the decoder currently is Modular, and IIRC specifically MA trees. There's ideas to speed it up, but they're either very complex or considered unsafe from a security perspective (JIT compiled MA trees to native code)
2026-03-30 01:32:23	On a side note, one day I hope we can add a debug option to zero out residuals. It'd be cool to see the image the raw tree produces, and how the accuracy changes with different parameters

Quackdoc

2026-03-30 01:33:05

~~usable jxl on amiga when~~

jonnyawsom3

2026-03-30 01:33:56

We already had it on an iPaq didn't we? Someone could probably get it running

_wb_

2026-03-30 02:16:21

zeroing out residuals will quickly introduce cumulative artifacts, since an error in one pixel can cause the next pixel to end up in a different MA branch, which will make it wrong too even if it still has the correct residual. It will be cool glitch art though.

jonnyawsom3

2026-03-30 02:16:55

Right, the predictors run on the final pixels, not exclusively the predicted values

Reddit • YAGPDB

2026-04-01 04:31:20

okydooky_original

2026-04-01 07:07:51

If Rasky gets the motivation, we'll probably see it on the N64 next.

dogelition

2026-04-02 06:30:38

https://x.com/i/status/2039482543112860062

Info

JPEG XL

General chat

Voice Channels

Archived

other-codecs