JPEG XL

no one complains about low frequency artifacts

that means they are pretty much *not hearable*

can you translate the graph?

I mean literally, I don't speak russian

I can't even type the characters to find out myself

distortions % frequencies hz

then it's what I thought. opus still has the least amount of distortion in the bass range, just like all the others, despite being the most prunned in that area.

what? how do you look at the graph? Lower - less distortion - better

you seem to be confused about how psychoacoustic models work

and what do you mean by that?

it is quite obvious that OPUS is better than all codecs, it is already clear, and the graphics can be seen more clearly

Because the distortion in the bass, after a certain point, gets masked by the distortions in the higher frequencies. Therefore, if you move those wasted bits out of the bass and into the higher frequencies you get a net improvement of quality at given bitrate.

I just show that due to the features of the codec itself, it is not so perfectly excellent in the low frequency region, and this can be seen on the graph

This is because the distortion is way higher in the higher frequencies, even in the opus model.

The only thing your graph shows is that opus in the only codec that isn't *wastefully overkill* in the bass allocation.

less bass distortion is only better when it's not already masked by the much higher distortions in the more hearable ranges, which is the case for all current codecs.

it is interesting that using such a large block at high frequencies does not improve the situation in the end, although it is only hundredths of a percent of quality another codecs

but I don't care about all this, I just shared an interesting observation of the tangent that all past codecs so accurately save low frequencies.

*at the expense of the higher frequencies

but yeah, I agree it's an interesting observation!

also please note that, IIRC, artifacts are not the only source of distortion. *any* deviation from the source, hearable or otherwise, is measured as distortion.

those blocks are only large in this linear scale, which is very poor at proportionally displaying human hearing.

Well the x axis is freq in hertz, that's easy to figure out. The y axis is a percent of some kind.

He's saying that, just like all the other codecs, opus has less distortion in the lower freq than the high freq.

Not that it has less distortion than other codecs.

But that it still distorts high freqs more than low

I don't think it's obvious opus is better at all bitrates for all types of music.

opus really, really has a problem with harpsichord music as of right now.

And that's my favorite instrument :(

what is the bitrate?

and yet, there are no other better codecs that can sound just as good at 128 kbit bitrate. and for large bitrates like 256+ there are always old codecs

that's understandable enough.

I tested as high as 128kbps I think.

<:Thonk:805904896879493180> u thnk

by default ffmpeg encode opus use 96 kbps

I used opus tools, not ffmpeg, and I made a point to increase the bitrate to a realistic level.

I don't think I tested above 128kbps

it was quite a while back since I did the abx tests but it was with the latest release.

at 320 KB/s, the residuals with opus are basically non existent within the practical ranges of human hearing

128 KB/s not so much, but by 192 KB/a it's already beyond my ability to tell a difference

Can you report it to encoder devs?

Is libopus actively developed still? it's been on 1.3 for a long time...

Also they were aware of the harpsichord problem and 1.1 was supposed to "fix" it according to them...

If I'm the only one who's bothered by it maybe it's not worth reporting...

Yes, there is a lot of activity in the repository of the codec

It doesn't need frequent releases when it is stable

FLAC had 4 updates in 8 years...

And this year alone 4 updates also 🙂

With some significant improvements (a bit better compression, other changes according to the newer stricter spec)

FLAC <:Stonks:806137886726553651>

other codecs work better at these bitrates? for example Vorbis

Perceptual improvements are a good cause for a new release.

FLAC does not have perceptual inprovements since it's lossless compression

Does opus have harpsichord problem even at higher bitrates? (>200K)

I don't think I tested that high but at that point it kinda defeats the purpose of using opus

So what codec would you use at such bitrates like 192 or 256k?

Probably lossywav?

🤔 Does it sound better than aac or vorbis at 256k?

Have not tested yet...

I could not reproduce this claim and I am not sure why it would be true

<:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180>

I recently learned that FLAC is limited to 8 channels per stream, which is kind of a shame

WavPack doesn’t have that limitation

it sounded more like a question, rather than a claim.

ah

Why would you need more?

It should be possible to put a few multiplexed FLAC streams into one Ogg contatiner if required, but 8 sounds like enough for all normal use cases

higher-order ambisonics would be one example

I wouldn't say it defeats the point of using Opus to at 160 kbps

since it's *still* going to outperform Vorbis and AAC at those bitrates

even if all three achieve transparency there's still no downside to using Opus

You could not reproduce the scratchy harpsichord?

I remember I used the same harpsichord sample on the opus 1.1 demo page

encoded with the latest version of opus and ABX tested with squishyball

I could not reproduce the claim that Vorbis did better than Opus at high bitrates

I don't think I tested higher than 128kbps

If I did it would not have been much higher

are there any high quality harpsichord samples in public domain?

or at least free to download

The 48khz sampled one on the opus 1.1 page works well for abx testing

oh I misread what you said earlier then

so is 12-bit jpeg really needed and used? <https://github.com/libjpeg-turbo/libjpeg-turbo/issues/199#issuecomment-1066163024> `12-bit support can be added to the TurboJPEG API as part of the TurboJPEG v3 overhaul, for which I'm currently trying to obtain funding. The new API structure will make it a lot easier to support 12-bit JPEGs, since it would only require a separate set of buffer set/get functions for 12-bit samples rather than a completely separate API`

Only if you can't have JPEG XL.

I just checked, YouTube really does send WebP images for its video thumbnails even if the user agent clearly indicates it does not support WebP (e.g. by requesting the url with `Accept: image/jpeg`).

That is quite nasty behavior imo, effectively forcing all browsers to support WebP since otherwise YouTube completely breaks.

this is what YouTube looks like when webp doesn't work

only the ad image works, it's a jpeg

the channel icons work too, they are jpegs too

to be fair there is no actual requirement about supported image formats, probably besides from PNG (even JPEG is not required AFAIK)

and yet everyone is using JPEG, resulting in a de facto standardization (people will serve JPEG even though you don't give `Accept: image/jpeg`, won't they)

WebP is now heading the same direction (like it or not) and I guess youtube's WebP only policy is actually quite late

https://www.w3.org/Graphics/ indeed says "There is no limit in the Web specifications to the graphical formats that can be used on the Web."

PNG is required by the canvas specification

(or more accurately, PNG *writing*, not sure about PNG reading)

isn't JPEG writing also required? I recall something like that

https://html.spec.whatwg.org/multipage/canvas.html#serialising-bitmaps-to-a-file "User agents must support PNG ("`image/png`"). User agents may support other types. If the user agent does not support the requested type, then it must create the file using the PNG format. [PNG]"

it does have an API support for lossy formats, but doesn't require any particular lossy format

right

so spec-wise, only png is OK. But all browsers do support jpeg too so I suppose that's de facto also required, likely some pages will break if that gets removed.

even writing image/webp is supported by all major browsers except safari, it looks like...

I didn't know chrome and firefox came with a webp encoder too, even on mobile. That must add some binary size and possibly security surface for quite questionable functionality, imo.

They heavily reference JPEG in the spec for <img>, even if they don't explicitly say it has to be supported.

https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element

I wonder when exactly they started doing that. But even today, still 2.7% of browsers in use don't support WebP according to https://caniuse.com/webp so I think it's still nasty to use WebP without fallback.

Does the rest of youtube work on those browsers?

in the past youtube used their power to discourage IE6 for users (https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6), and I guess they are trying to do that again

IE6 was kind of universally agreed to be horrible and I think they did the world a favor by helping to kill it. But the merits of (lossy) WebP were controversial, there was no consensus that it was actually a worthwhile permanent addition to the web platform, and Firefox/Safari resisted for as long as they could.

No idea, I just used Chrome devtools to show how it looks when 'Disable WebP image format' is checked. But I would expect the videos themselves to be available in h264, vp9 and av1 and use content negotiation to select a codec that works for the user agent.

The only reason to keep vp8 around in browsers is for webp now, I think. At least I don't think anyone is using it for video anymore, especially not without fallback.

I mean, they can convince themselves that they are doing the right thing, no matter it's true or not

I can say as a web developer that this is very common practice, since webp is supported by over 95% of browsers it can be argued that it's not worth the effort to support those very few users that can't use it

if this was done before firefox got webp support, yeah I could argue it could be seen as something malicious but if they did this after firefox got on board I don't think they did it on purpose

always having a jpeg fallback is of course nice but in youtube's case this could mean terabytes of extra data to store

when I want to use a new feature or API in a web project I usually look at caniuse and if it's supported by less than 90% of browsers I will use a polyfill or a fallback so it doesn't break on old browsers. if the support is over 90% I usually don't bother with any sort of fallback if: 1. there are only minor issues for browsers that don't support the feature 2. it's more effort than it's worth to implement a fallback

getting broken images is more than a minor issue imo

as to the storage: I cannot imagine that the storage for the thumbnails is in any way important compared to the storage for the videos themselves

I can't really speak for youtube's regarding their prioritisation but aiming for 100% compatibility is very difficult and often impossible. and we are talking about one of the world's most visited websites and not some hobby project

well actually, in a case of worlds most visited site, you could argue that compatibility is more important, but on the other hand you have to prioritize stuff like new features over perfect compatibility, since the new features and improvements bring in money and perfect compatibility uses a lot of development hours without bringing much immediate benefits

Is VP8 part of the webRTC spec, or is that not an issue with openh264?

<@886264098298413078> so now there will be dav1d in tdesktop for windows (after merging), but it's not used for av1 video decoding yet? <https://github.com/telegramdesktop/tdesktop/pull/25572>

https://artifacts.videolan.org/x264/release-win64/

Not yet, but it should be easy to do it later.

Well, if Google does this for WebP, I believe we could do this for JPEG-XL on Chrome browsers. Note that word *could*. Since we are above Chrome/AOM devs, we won't be doing this.

I was wrong: YouTube actually does work on browsers that don't support webp

it just does it in a weird way — when trying "disable webp support" in chrome devtools, it does break

but e.g. using an old firefox version from before firefox supported webp, it does work

I guess there is some user agent stuff then. Probably because it polyfills some JS for older browsers or similar.

https://www.mpeg.org/standards/Explorations/41/

It seems that the most reliable way to view animated AVIF is to play the file in VLC.

> Looking at the latest incarnation of HDR in Adobe camera raw I am mildly disappointed > > A number of considerations > > 1. The choice of AVIF and Jpeg XL is not particularly exciting. Of course those are license free and google is backing AVIF however from compression point of view they lag quite a bit from other formats within HEIF containers. Not necessarily HEIC there are others

(https://www.dpreview.com/forums/thread/4688341?page=2#forum-post-66723006)

<:Thonk:805904896879493180>

This is stupid lmao.

Also, Google is backing JXL, but Chrome/AOM are backing AV1 as well.

Besides, HEVC (HEIC), the other payloads you can currently have in HEIF are: - AVC (h264) - JPEG - AV1 - JPEG XR - JPEG 2000 - JPEG XS

At one of the previous JPEG meetings they asked us if we wanted to define jxl as a possible payload for heif — we said "no thanks" since unlike for those other payloads, there's basically nothing the heif container can offer jxl that it doesn't already have, it would just be an unnecessary duplication of functionality.

HEIF is designed to be a wrapper for 'dumb' payloads that just compress numbers without semantics, which is how things were done in the past: the codec doesn't know what the numbers mean, it just compresses them, and meaning is left as a metadata/file format/application responsibility.

So heif has metadata for colorspace (enum or icc) and orientation, and it does tiling, cropping, layering, extra channels like alpha etc at the file format level.

That's great for payload codecs that don't support those things yet, but it's not the optimal way to do things.

In jxl, all render-impacting info goes into the codestream (payload), and the jxl file format is a very shallow thing that just stores some optional metadata that doesn't influence how to display the image.

Main advantage of the jxl approach: the encoder always knows what it is doing, since it has all the information. It knows the colorspace, it knows which pixels are visible or not because of alpha.

Since it can internally work in an absolute colorspace (XYB), the encoder configuration of quality can use a scale that is the same regardless of the image colorspace.

Yes! This is actually a massive issue with classical video encoders: there has to be specific optimizations for specific color spaces.

I asked the person in the thread but the response I got was not very informative

https://www.dpreview.com/forums/post/66723770

Maybe they are confused about jxl vs JPEG?

Or maybe it's one of those persons who don't realize lossy compression can reach various trade-offs between quality and size? Maybe comparing default settings of every format and getting the smallest files with heic?

Usually Google look at those images and wants good compression

Don't care about the quality

hello, is possible to convert a jpg xl sequence to prores?

you could probably just use ffmpeg

telegram desktop (windows) now supports AV1

svt-av1 does not have the ability to limit the block size.

<@886264098298413078> is it hard to also add this for windows? it feels like the telegram devs don't have windows <:SadCat:805389277247701002> https://github.com/telegramdesktop/tdesktop/pull/25623

It would work only in Qt6 builds as they made special patches to force using lcms in Qt 6.3 and Qt 6.4

and didn't attach any commands. I'm using spline interpolation. and besides, why doesn't anyone tell people about the existence of 540p

for the last 4 days I have been researching the best AV1 encoding option for the Telegram, and it turned out that it can be even faster than AVC veryslow with extremely good output quality

In fact, it's even strange that I spent so many days doing this, considering how much "no one" wants people to change coding parameters

in fact, I have never encountered such a problem that the codec is doing its job much better, while use the same amount of time. But at the same time, it's impossible to show it visually, people just don't see it. for example, where is AV1 and where is AVC? And be sure that if you don't know exactly how each of these codecs works, you won't be able to understand it.

SVT-AV1 slightly disappoints with its quality. Well, of course it's fast and generally what need. But his algorithms for smoothing noise and block jitter just don't seem to work, or work very poorly. At AOMENC, even at speed 8 (the fastest), all algorithms work that destroy any noise and shaking of blocks.... but unfortunately it is 6 times longer than SVT-AV1 speed 10

SVT-AV1 speed 9-10 same AVC veryslow-placebo || I can't give an exact answer because of the different encoding time depending on the complexity of the film scene ||

let's play a game I like to call Guess the MP3 <:kekw:808717074305122316>

what are the best (and free) lossy encoders out there right now?

I'm trying to compare AC4-IMS (new Dolby format for binaural audio) to other lossy codecs like opus and ofc mp3

libopus should be the best free lossy audio encoder

that's the official one right? I used opusenc.exe from opus-tools-0.2-opus-1.3

opusenc is the frontend to libopus, yes

any runner-ups?

i'm gonna try vorbis next just for shits and gigles

and I can't find an MQA encoder, guess it's proprietary?

libvorbis outperforms LAME by a good deal, the FFmpeg built-in AAC encoder is something solid to try. I'm assuming by free you mean FOSS and not just free to download

if you want something just free to download then quicktime's AAC encoder is gratis

nah I meant free as in free download, not necessarily FOSS cuz I just don't wanna have to pay for a quick experiment lol

and is ffmpeg's AAC the best encoder for that format (as in highest quality within the 72kbps constraint)? or is there a better reference encoder?

72 kbps is 36 kbps/channel which is well within HE-AAC range, and FFmpeg's encoder is only LC-AAC

I'd use quicktime's AAC encoder if you're trying to test "AAC" itself not a specific encoder's implementation of it

I don't know how to obtain it but I do know it's free

it's at least one of the best if not the best AAC encoder that's freely available

👌

how about Fraunhofer FDK AAC? i don't know which among the two is better

although, fdk-aac is harder to find an easy-to-use binary for

fdk-aac for a while was source-only

unsure how it compares to qaac nowadays anyway

<@557099078337560596> <@853026420792360980> is there a tool to measure quality loss by comparing these lossy conversions to the original lossless WAV file?

I was just searching for something like that a few days ago

I think the closest thing I found was either just inverting the audio and checking how much it differed (not very smart or perceptual) Or Visqol by Google (https://github.com/google/visqol) "Perceptual Quality Estimator for speech and audio"

yeah I usually invert the 2nd track in audacity to hear the difference but I was hoping there would be something more mathematical that checks how much the bits/samples have changed compared to the raw source. is that what visqol does?

I guess so? I haven't tried it yet.

https://youtu.be/3zaq56QsX28

couldn't figure out how to build/use visqol but found a tool that does exactly what I was looking for I packaged it with scripts that make it even easier to use here <https://github.com/ThreeDeeJay/eaqual/releases/latest>

here's a test I made comparing quality and filesizes: <https://airtable.com/shrA5PHQEomEZXKZb> > An ODG of -4 means a very annoying disturbance, while an ODG of 0 means that there is no perceptible difference.

ugh, no wonder stuff like qaac AAC-HE got a worse ODG than MP3 it seems that for some dumb reason, they desync (leading silence added?) during conversion

what bitrate are these targeting? also, thank you so much for the comparison!

perhaps my tool https://github.com/sboukortt/intersect-lv2 could be of help? It’s not made specifically for this purpose, but by using it with the original as the “left” channel and the lossily-compressed version as the “right” channel, the output would have most of the audio in the center output channel, what the lossy codec removed in the left output channel, and what it added in the right output channel

since by just computing the difference, you can’t know whether it was added or removed

(well, in some cases, you _can_ know, but not generally)

72kbps, which I think is the target used by AC4-IMS (a new format by Dolby for binaural stereo), so I just wanted to check if this new format was actually more efficient than the other good lossy standards which actually reached a somewhat decent support. tho I also wanted to check if there was anything better than opus right now

so like inverting channels in audacity? I already tried that and noticed the difference, but I was just looking for a way to quantify how *much* difference there is between 2 (lossless and lossy) stereo tracks. Thanks for sharing tho 👍

note quite like inverting it, because if you invert in Audacity and notice a difference, it could be either something that was present in the original signal and lost by the lossy codec, or some noise/distortion that was _added_ by the lossy codec

my tool lets you know which of the two it is

ahhh I see. I'll check it out then 👌

Lately I was testing jpeg-quantsmooth filter. It does pretty good job cleaning up drawings that were "accidentally" saved in jpeg.

> As part of a larger story about Apple's plans to allow third-party app stores on the iPhone and iPad in EU countries, Bloomberg's Mark Gurman claimed that Apple is also considering removing its requirement for iPhone and iPad web browsers to use WebKit, the open source browser engine that powers Safari.

That would be amazing. Unlikely, but amazing.

lol. We will consider it, mortal peon.

You're lucky we allow you to pay us 1000 dollars to use our phone at all. Don't go thinking that it's your phone just because you bought it.

<:FeelsReadingMan:808827102278451241> https://github.com/nigeltao/boring-libjpeg-turbo

Wait, libjpeg-turbo allows for arithmetic-coded JPEG?

That's cool.

It does, and there are also variants that support 12-bit and alpha, but the problem is that using such features will create big interoperability issues since we cannot upgrade all jpeg decoders...

I’ve used a program called “cupscale” along with a machine learning model called “1x_JPEG” to remove JPEG artifacts very successfully

The convenience of jpeg-quantsmooth filter is that it's available in IrfanView. It's not perfect and it needs the actual JPEG data to undo the artifacts. It worked pretty well on some pictures before downscaling them. The downscaled pictures are pretty much spotless. I'm still keeping the original JPEG data, losslessly transcoded to JXL.

Firefox not support animated AVIF lol

The funny thing about animated AVIF is, if the program doesn't support animation, it can't decode the file at all.

that's because AVIF is not forward compatible like PNG

mpc-hc 1.9 supported animated avif

VLC can play avif animation as well. It's acting as a video file. Why not just use mp4 or webm/mkv?

How does this fast "block shrinking" (shrink-on-load) work for JPEG? Is it a libvips thing or is there something inherent to JPEG that allows for quarter size or half size decodes, like I know CineForm can do?

perhaps something along the lines of bypassing the inverse DCT since you would be throwing away the spatial information anyway?

I guess shrinking happens during zigzag decoding, so that you drop high-frequency components?

AFAIU they do a slightly modified 4x4 DCT on the top 4x4 DCT coefficients

or 2x2

We could in principle do the same in jxl, just we have more block types to do it for (but codewise, I think you could basically just treat e.g. a dct32x16 as a dct16x8 on the top coeffs to get the 1:2 pixels, so only for stuff like AFV it gets tricky)

It is correct to assume that JPEG XL is de-facto the last *real *image codec in the coming decades

(Okay, there will still be an ultra-heavy AVIF2 in about 5 years)

I doubt it, because lossless is always going to be a usecase.

it just doesn't seem to me that anyone will take on such a large and all-encompassing project like Jpeg xl ever again.

it will be much more profitable in the future to invest in improving the Encoder, making it better and better every year

True, there is a lot of space for improved encoders using the JXL bitstream.

avif is ALREADY a valid mp4 container file

I low-key *prefer* this behavior

well I prefer it actually supporting animation, but I kind of agree that 'graceful degradation' to just showing the first frame is rather confusing, since people will just think it's a still image that happens to be a big file for some reason.

pretty much. I have said before that an animated sequence 99% of the time requires itself to be opened fully to convey it's message unambiguously. showing just the first frame of an animated sequence and calling that graceful degradation is not much unlike sharing a video and only being able to play the first GOP

yeah, generally speaking graceful degradation for these kind of things just doesn't work because people will just assume the degraded experience is all there is — better to fail clearly and get application developers to do things properly

it's the same with transparency: if you're going to just ignore the alpha channel or blend poorly (say reducing things to 1-bit alpha instead of doing proper blending), you can better not show anything

I think this was the main problem with JPEG XT: sure it is nice that you can add extensions to JPEG that add alpha, HDR, lossless etc, but if most applications are just going to show you the 'fallback' lossy SDR image with alpha ignored, people will think that's all there is, with near-zero pressure on implementors to add any support for those extensions.

It seems I was wrong, some programs will show the first frame (Firefox, Xnview MP, Windows Photos), other programs (IrfanView, Gimp, krita) report unknown file format.

Another story is AVIF with transparency. Only IrfanView and Windows Photos loaded the picture with black background (both using WIC), all other programs, including Firefox, refused to open the file.

What's a good codec like PNG for lossless compression but faster decoding? I know QOI is a thing, but are there any decompression speed comparison graphs? I know there are ones for encode (fjxl vs fpnge vs QOI for example)

http://www.radgametools.com/oodlelimage.htm ?

of course, non-free (though I think there is a source code available because of the integration to UE)

Hi <@794205442175402004>, I hope this @ isn't an annoyance. I just read this: https://twitter.com/eddychik/status/1614642129397231616 And was wondering if you knew much about their comments regarding HEIF testing.

I don't know much about the experiment, but there are many axes for codec comparison; in which axis is HEIF 10% better than JPEG XL?

I asked him a similar question in a reply.

The answer is in the twitter thread already. We did test heic (libheif with x265), and at the settings we used, it was somewhat better than jxl (and avif) at the low to medium qualities, but then got worse than jxl as quality goes up. This was with an encode speed that was 3x slower for heic than for jxl iirc, and libjxl 0.6 iirc.

We haven't tested Apple's hardware encoder of heic, which is maybe more relevant in practice since this is how most heic files are currently created in the wild. I would assume it's significantly worse in quality/byte than x265, though of course much faster.

Yeah, they ended up linking the source, so sorry for the ping. I didn't know about the encode speed stuff, though. Thank you!

https://www.cast-inc.com/blog/800-mpixelss-260-luts-implementation-qoi-lossless-image-compression-algorithm-and-its

discussion on implementing qoi encoder/decorder on fpga

w-why

oh this was from last year. I was wondering why anyone is still talking about qoi in current year

Actually, what *are* the benefits of animated JXL versus animated AVIF (i.e. AV1 video)?

coming from a convo over on the AV1 discord, it is a good question

are there any? 😛

a video codec will do better at video

if you have animated pixel art, then maybe jxl will be better

(if using lossless)

or in general animated-whatever where you want to do lossless

otherwise, nah

so it's mostly there as a feature because... completeness sake?

that, and they needed to give me an internship project 😛

well, tbf

this is on the delivery side

for the content production pipeline usecase, you probably don't want inter prediction anyway, i.e. a video there is just a sequence of (high-quality) images

and there you do get benefits from jxl, I think

(I did not test this, or even verify my assumptions)

so something like a replacement for jpeg2000 intermediates?

... maybe?

aight aight thanks for the insights

avif is better for lossy animation/short videos, jxl is better for true lossless images, for example I need to merge several lossless images into a single animated one and since jxl is better for lossless, it will be better for that also for higher bpc

Mostly better intra lossless. Otherwise, just go with AV1 for anything even closely related to video.

I would say for animation JXL would be better but for video you would want to use AV1

and by animation I say something like a loading indicator in the UI. something you would traditionally use a GIF

there is all-intra for avif

Yeah, I know, but I'd argue that animated JXL is probably better than all intra avif

When things are basically a slideshow of unrelated pictures, so inter doesn't help much at all, jxl should be better.

Also when quality is very high (lossless or close to it), jxl should be better.

If it's a synthetic animation (something like screen content with sprites moving around as perfect translations with integer pixel offsets), in principle jxl could be better (patches could be used to encode sprites only once, though we currently only look for that within a frame, not across frames)

This guy is extremely verbose...

but FJXL killed QOI

They don't compete unless someone start implementing FJXL on FPGA

QOI will probably live on as long as people prefer a shorter code

the problem is that, of course, if you are willing to only look at a short code and modest performance there will be a better format than QOI 😉

yeah just use png

import zlib

done

if i'd have anything on hardware i'd like zstd

well one can argue that zlib (or to the point, even miniz) is longer than qoi

a modest proposal: make a new image format which i) can be encoded & decoded in ~500 lines of C and ii) roughly as speedy as libpng (TYPO) but iii) results in a smaller size.

and it'd be named MOI (More than OK Image format)

There's actually a deflate encode/decode library in < 1000 line of C afaik raylib uses them as part of the game framework https://github.com/vurtun/lib

https://youtu.be/WeM2D1-yTzo

Anyone else having trouble decoding this file? libwebp says it's a lossy animated webp with no errors but ffmpeg is unable to decode it.

> [webp @ 0x559661416700] skipping unsupported chunk: ANIM > [webp @ 0x559661416700] skipping unsupported chunk: ANMF

looks like it's not supported

Well that's pretty weird...

ffmpeg does not support animated webp eh?

on decode, that's correct

it does on encode (via libwebp)

Yeah... That seems really weird...

Ah well

DjVu can have a DPI of at least up to 6000 according to this encoder I'm testing.

The default DPI is 300 but you can set it to anything between 72 and 6000 just by passing the --dpi option to the encoder

SQOA is an image format derived from QOI. Like the original, it is a single header (two if you enable ANS compression). https://github.com/jido/seqoia

There was an annoying bug in the rANS code which is why I never advertised it, but I finally fixed it so it should be usable now.

https://habr.com/en/post/456476/ - about improved Bluetooth SBC support in Android

https://issuetracker.google.com/issues/136342164 - pity that Google don't want to implement this little but really useful change

Alright, viewing PNGs and JPGs in DOS is easy. Now I've tried something more modern. I've managed to install Windows 98 on 486DX2 66MHz with 16MB of RAM, it took only two hours. I've found out that IrfanView 4.44 should work on Win98 and it has WebP plugin. IrfanView successfully loaded PNG, so far so good, but WebP causes IrfanView to crash immediately. I didn't expect miracles, loading PNGs is slow on this poor little CPU, but it's not even trying. I'm disappointed.

has anyone looked into the difference in compression efficiency between limited (16-235) and full (0-255) range with x264/x265?

maybe with a 10-bit source to isolate the effect of converting 8-bit content from one to the other

I suppose it's similar to using a wide gamut colorspace to encode sRGB images in 8-bit. Smaller range of values means smaller files (all else like the quantizer setting being the same). But it also means more banding and lower precision in general...

Does the 486dx have SSE?

That might be an issue.

I suppose if it was working somehow, it would be very slow. I was just curious how slow it would be.

I cannot find any information about the alleged patent issues there supposedly were at the beginning of DjVu.

All I can see is that it was a free format that is older than PDF and available for free earlier than PDF.

And it has a GPL reference implementation called DjVuLibre

The reasons for its failure can be attributed to the lack of decent freely available encoding tools.

The encoding tools available in DjVuLibre do not take advantage of any of DjVu's main advantages.

Even to this very day, if you want to create an acceptable DjVu file, you have to pay money, or use image editing software to manually divide an image into layers yourself and use the command line tools and inferior, less-optimized GPL encoding tools to combine the layers into a single file.

And you have to do that for every page.

There is a `pdf2djvu` tool and a `djvudigital` tool for converting PDF to DjVu but `djvudigital` is illegal to distribute in binary form because that would violate Ghostscript's copyright license. Both tools produce slightly different output and neither of them produce ideal output. One produces output that mangles page metadata such as bookmarks/ToC and the other produces output that mangles page margins and often a larger filesize than the input PDF. Both tools apply lossy compression to the image data in the PDF files. Neither tools produce acceptable output in my opinion.

With such a poor tooling situation, it's impossible to expect DjVu to gain widespread use and success if it's such a pain in the ass to create a DjVu file.

No matter how innovative and awesome and capable the format is in theory, if no one can use it and take advantage of that innovation, it might as well not exist at all.

To clarify, it's actually the Ghostscript *driver* by AT&T `GSDjVu` that has a license (CPLv1) incompatible with the GPL. That's why they cannot distribute binaries.

`djvudigital` is not functional without that ghostscript driver, and distributing the driver in binary form theoretically violates ghostscript's copyright license. And since neither copyright holder has publicly clarified or granted a license exception, computer-illiterates (and time-constrained people, and people working in artificially-constrained software environments, etc) who rely on precompiled binary distribution of software, and are incapable or unwilling to compile source, can't even use djvudigital regardless of whether it even has good performance in the first place.

In my experience `djvudigital` is fast but is constrained to single-threaded operation.

It also uses the djvulibre encoders, which have not received the same amount of tuning as the commercial encoders.

It's extremely fast despite being single threaded. It's also mangling the chapter titles in the table of contents.

Overall I would say it produces unacceptable output.

If only because of that.

<@310374889540550660> <@208917283693789185> what about considering adding fpnge to libvips for fast modes? <https://github.com/veluca93/fpnge> https://discord.com/channels/794206087879852103/803645746661425173/1069395996473311242 I didn't do a very accurate comparisons, but it was about at least twice as fast as `vips compression=1` with much better compression for non-palette images and not just for screenshots however, i don't know how hard it would be or how much effort it would take to fully implement, but in my opinion that speed and compression is worth it

a small test on spng images <https://github.com/libspng/benchmark_images/> ``` 884777 large_palette.png 2877559 large_palette.png.fpnge.png 13730755 large_palette.png.vips0.png 2493372 large_palette.png.vips1.png 1259778 large_palette.png.vips6.png 1218769 large_palette.png.vips9.png 13107563 large_rgb8.png 13806093 large_rgb8.png.fpnge.png 25932709 large_rgb8.png.vips0.png 21406843 large_rgb8.png.vips1.png 15309969 large_rgb8.png.vips6.png 15205517 large_rgb8.png.vips9.png 14874463 large_rgba8.png 15895344 large_rgba8.png.fpnge.png 34575485 large_rgba8.png.vips0.png 25566328 large_rgba8.png.vips1.png 15940463 large_rgba8.png.vips6.png 15879244 large_rgba8.png.vips9.png 2285461 medium_rgb8.png 2347682 medium_rgb8.png.fpnge.png 3950106 medium_rgb8.png.vips0.png 3663753 medium_rgb8.png.vips1.png 2838908 medium_rgb8.png.vips6.png 2827241 medium_rgb8.png.vips9.png 2934436 medium_rgba8.png 3093087 medium_rgba8.png.fpnge.png 6034599 medium_rgba8.png.vips0.png 4816040 medium_rgba8.png.vips1.png 3250939 medium_rgba8.png.vips6.png 3240970 medium_rgba8.png.vips9.png 216531 small_rgb8.png 221353 small_rgb8.png.fpnge.png 375198 small_rgb8.png.vips0.png 359452 small_rgb8.png.vips1.png 289068 small_rgb8.png.vips6.png 288357 small_rgb8.png.vips9.png 248924 small_rgba8.png 257845 small_rgba8.png.fpnge.png 500157 small_rgba8.png.vips0.png 411361 small_rgba8.png.vips1.png 291282 small_rgba8.png.vips6.png 290519 small_rgba8.png.vips9.png ```

It's a pity that the old microsoft chose The bad way for jpegXR

Hi <@1034873369314730065> , we've just switched to spng as our default PNG library https://libspng.org

oic, fpng is an AVX encoder, interesting ... I'll ask the spng author

thanks for pointing this out!

yeah i know, i meant fpnge just for faster speeds and spng for the rest (and for decoding) and pnge also supports sse4.1 after some updates, not as fast as with avx2 but still the fastest encoder at this compression https://github.com/veluca93/fpnge/pull/3

```i7-12700K AVX2 244.678 MP/s 10.787 bits/pixel i7-12700K SSE4 171.628 MP/s 10.770 bits/pixel Ryzen 3900X (VM) AVX2 156.358 MP/s 10.787 bits/pixel Ryzen 3900X (VM) SSE4 92.838 MP/s 10.770 bits/pixel Atom C2350 SSE4 10.159 MP/s 10.770 bits/pixel```

any idea which one of these 2 would have (at least in theory) higher quality? 🤔

hmm if I download the (youtube) video (in JDownloader), I can select an opus track with higher bitrate, but still not sure which one would be better

I don't recall yt having AAC 192

for normal videos -f 251 is always the best (opus 160)

192 for youtube music

ahh, that's right. guess it used some inaccurate estimation of the bitrate, maybe because it uses VBR

ok so I'm trying to compare the audio quality when uploading lossless WAV vs NVIDIA Shadowplay, which according to this uses Windows' built-in AAC encoder > *** As of version 2.4.1.21 the bitrate is now 192 Kbps by default *** > The information below applies to ver. 2.2.2.0 and older. > Background information : Shadowplay uses the AAC Encoder included with windows for audio encoding and by default it uses 96 Kbps as the bitrate. More information is available on the MSDN page. > <https://msdn.microsoft.com/en-us/library/windows/desktop/dd742785(v=vs.85).aspx> > The bitrate is variable, but may not be sufficient for every user at 96 Kbps. Fortunately we don’t have to stay at that setting ! With a simple hex edit you can change that value to one of the 4 available : 96, 128, 160, 192 <https://linustechtips.com/topic/331710-guide-shadowplay-mods/>

so the question is: is there a way to use this encoder (or replicate settings using ffmpeg/reference encoder) to convert a reference test WAV file so I can upload it and compare it to uploading the WAV directly?

like, I wanna download the (Opus 251/160kbps) audio track and check just how much quality is lost between the WAV and the AAC 192kbps upload

found this but getting an error when converting <:NotLikeThis:805132742819053610> <https://github.com/SvenGroot/MFEncode>

figured it out, it requires 48khz 16-bit exclusively

https://phoboslab.org/log/2023/02/qoa-time-domain-audio-compression oh well

knee-jerk reaction: whyyyy

while I has been a bit harsh for QOI, I do think he has a knack for picking some scheme that somehow appeals to the average programmers for the simplicity

> with a constant bitrate of 277 kbits/s for Stereo 44100hz.

;p

> It does not cut off higher frequencies, like many transform codecs do

;p

someone doesn't realize that low-pass at 20 kHz is a good thing

the concept itself does make some amount of sense though, it's basically like a gpu texture format but for audio

had opus not already existed and had a permissive open-source library that works well

then it would make more sense

does opus decode fast enough to do it on the fly for playing game sound effects?

yea especially cause it's super low delay

opus decodes at like hundreds times realtime

at least FFmpeg decodes it at 417x realtime, on a quick test sample

I get about 300x realtime with that one instead

certainly there's a lot of variables that can be controlled here but this should give you a rough estimate

for something like game sounds you need not only super low delay but also low enough complexity to play many samples at the same time without hogging the cpu

this. if you only have a handful number of samples played at any time opus will be fine. if you have 100s of them you really want to decode it and preload buffers.