JPEG XL

i can reexport to 16 bit if you want but it will need to be tiff

Most things can also handle tiff xD

Exr just seems to be the odd man out

*noted*

Also some weirdness going on with video compair and jxl white point handling

Specifically with this img

Imma blame ffmpeg for that one

Has the correct data and qview displays correctly

Yea likely upstream bug

because a single exr image can contain many forms of data

associated alpha, non clamped channels are the two massive ones

per channel alpha is neat but rarely used

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.

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.

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.

to some degree

using oculante as an example here but this is alpha enabled and disabled

note oculante does not support linear transfers

which exrviewer specifically?

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

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

webp is good

https://ipfray.com/dolby-sues-snapchat-over-av1-and-hevc-patent-infringement-in-u-s-and-brazil-access-advance-vdp-license-would-resolve-issue/

damn

so does that mean dolby can't use av1 anymore because of that patent clause? or does that not apply to this

I would imagine that this does trigger the defensive termination (clause 1.3 in https://aomedia.org/license/patent-license/)

it will be interesting to see how AOM responds to this

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

they do support dolby vision with av1 but afaik every streaming service still uses h.265 for that

https://professional.dolby.com/legal/AOM-statement/

hm

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

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

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

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

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

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

So maybe something like "you may not license any patents from an entity that sued" or something

basically forcing everyone to either choose AOM or Dolby in this case, which would hopefully be the death of people licensing from Dolby

idk the answer but since av2 is upcoming it would be interesting to see if they do anything different now

though the spec draft is already out so i guess that couldn't apply retroactively to that...

https://storage.courtlistener.com/recap/gov.uscourts.ded.92505/gov.uscourts.ded.92505.1.0.pdf

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

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

ah, they only support h.264 and h.265 in the transcoder. makes sense

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.

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?

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

for me it's fine to discuss

generally all patents are intentionally formulated in a very generic, vague and confusing way, I suppose because patent lawyers like it like that

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

Without patents people would be more shy about publishing the inner workings of their inventions maybe

So that's one possible silver lining

Intellectual property is an infringement on real property.

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

The terminology they use is designed to hypnotize and brainwash

Stallman says this a lot too

And I don't agree with Stallman half the time but he is right the other half

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.

>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.

...or skip writing the paper altogether and directly implement the idea in code

I bet someone at Dolby is also looking hard at IAMF

https://patents.google.com/patent/US10404272B2/en - I read this as just having multiple distributions and having something to chose between them

unless I'm reading it wrong, I think it would apply to JXL?

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.

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

it was filed in 2012 in a bunch of countries, 2016 in the US

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?)

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

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?

https://discord.com/channels/794206087879852103/805176455658733570/1486318627715285092

the main focus is definitely h.265

for future stuff: https://www.courtlistener.com/docket/72582162/dolby-video-compression-llc-v-snap-inc/

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

ok comeback to vp9

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

I thought Theora had lots of potential...

With the right encoder.

One of the x264 devs even mentioned a long time ago, the possibility of modifying x264 to output a theora-compliant steam.

x264 is still very good

x264 yes.

For "gifs" forever

So apparently there's an AVIF 1.2 now

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.

It will be harder to convince people to use JXL when it produces blurrier smeared results compared to AVIF

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.

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

need more study about lossy modular

JXL is not interesting if most CDN use VarDCT

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>

Maybe work and experimentation on new psychovisual optimizations can be forked from the libjxl-tiny encoder.

Since it's a simpler and smaller project to fork from.

Might be easier to start from there.

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

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.

And I'm not an avif fan. I want avif to be the next webp, and jxl to be the next jpeg

But I know that isn't going to happen if avif is noticeably several generations ahead in terms of quality.

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

But the same or similar tuning and RDO could be applied to a theoretical jxl encoder

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.

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.

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

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

ehhhh 😄

working on it I guess

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)

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

~~usable jxl on amiga when~~

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

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.

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

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

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