JPEG XL

Ya know, to save on battery life and all that

maybe a bunch of e-cores could work on some types of server

Yeah, assuming it's all e-cores it doesn't sound like a bad idea

Since they're more power efficient

that's just called a pi cluster

True

No need to reinvent the wheel I guess

I think Intel has some CPU models with 8 P cores and 16 E cores

A key thing to remember is that the E cores don't have multithreading. So for the Silicon of the same chips, you could've had that many threads anyway

wrong

SMT actually kinda sucks these days

SMT is good at making use of unused parts of a CPU core, but since we're in an era of increasing transistor density *without* reducing the energy consumption of transistors, things being unused is literally necessary to not make the chip not overheat to hell and back.

is SMT like Hyper threading?

yes

simultaneous multi-threading, one core multiple threads

and in any case, Intel's E cores are SUPER TINY

you get way more than two of them for every P core you replace

The P cores would need to have like, 8x SMT to give you the same number of threads

we also don't want a repeat of bulldozer though

you would have to really fuck up to repeat that

so with SMT, you don't duplicate functional units, like ALUs and FPUs, since the point is to make use of unused units. But there are some things that you need to duplicate for each hyperthread. Most importantly, registers. In order to have two hyperthreads that run well, you need to double the size of your register file, and you need to double the complexity of your register rename engine. That's relatively cheap in terms of transistors, so back in the day, it made sense. But today, the biggest cost isn't transistors, it's power. And the register rename logic is the single most power hungry part of the CPU that needs to be turned on 100% of the time. So as soon as you add SMT, you double the minimum power draw of your CPU core, but you way less than double your potential performance.

> you don't duplicate functional units, like ALUs and FPUs that really just sounds like bulldozer or i guess its fine because they're not marketing SMT as different cores, just different logical threads

the problem with bulldozer was that it was garbage in general, not just that it shared FPUs between cores

I mean, it didn't share ALUs, but it still had shit integer performance

Apple shares their ARM SME unit between 4 cores and I've never seen anyone complain about it

bulldozer was chad

AMD got screwed because they didn't predict the future properly, and made a great workaround of a "just in case" strategy that panned out

Given modern compression formats like Brotli, does minifying JS still help significantly?

isn't part of the benefit of minifying related to decreasing the time/effort to parse the JS? if so then stuff like Brotli would have no benefits to that effect since the JS would be decompressed and then the unminifyed JS would be parsed

Oh yeah that’s a thing

parsing is usually the cheapest thing compared to all the other stuff a JS engine has to do

preset 1 (I don't think it makes sense since I'm using my fork) on other presets, the speed difference is the same

since SVT has a parameter that allows you to completely disable the native assembler optimizer, you can do this: The effect of processor instructions on the encoding speed of SVT-AV1 with identical PROCESSOR/consumption/power ``` mmx |sse 1x sse2 |sse3 1,32x ssse3 1.44x sse4_1|sse4_2|avx 5.3x avx2 |avx512 6.9x ```

yep

It makes logical sense that "more CPU area is occupied by work at a certain point.".. But it doesn't make sense if I just set the frequency boost to the temperature limits, without SMT. It comes out faster by ~5% when encoding. since the CPU usage density is less filled/clogged with queues and all sorts of garbage instructions that wander/walk back and forth

This is probably effective if something cannot fully load the processor, but since I use CPU only for compression and for the neural network. Situations where the processor cannot be loaded - doesn't happen

The "little" cores are really the funniest thing I've seen.

are so ____ that some are advised to turn them off so that more power goes to larger cores, as it will heat up less, giving more peak speed

skill (cooling) issue

yeah you get 4 for every P-core die area

I guess I will renew flif.info one more year, and then I think I will stop renewing it. The site is on https://github.com/FLIF-hub/FLIF-hub.github.io so it will still be available, just with an uglier url

Better to let someone take over the domain or it will become an online scam website

.info is one of the cheapest right?

And it's quite old

If someone wants to take it over, let me know. As long as you don't plan to make it an online scam website 🙂

The original domain of an old wiki software was transferred to a scam as its owner forgot renewing

Maybe make it a redirect to jpegxl.info

How many people are going to FLIF.info ?

From Wikipedia

I did a lot before the jpeg xl era 😅 I found the progressive loading demo (with the fish) so relaxing

Lol.

I'd be happy to take it over & redirect it to a page on the Codec Wiki covering FLIF

Someone should probably replace them with archived links

I would do it, but now that I've said this it would doxx me <:galaxybrain:821831336372338729>

Since JXL is partially based on FLIF it would maybe make sense to archive the original site on the info website for jxl and either refer to it if it is discussed on the main page or possibly create a subpage/section where the creation of JPEG XL is documented. There the FLIF stuff would be fitting

on FUIF to be precise, even if FUIF is a work based on FLIF

It's been frequently archived so it's not urgent to replace http://web.archive.org/web/20240922105531/https://flif.info/

Even if the link were dead, a bot would replace it automatically

AV1 -- CDEF -- enable-restoration=1 increases the quality on super-super strong compression, but since it is a post-post-filter, it also takes away from 10% to 25% of the decoding speed In 99% of cases, it is better to turn it off, 100% it needs to be turned off if it is a recording of the gameplay of the game AV1 -- Temporal Filter -- enable-tf=1 by default, this is the most destructive thing in the codec, it kills smooth lines, low-gradient colors and details, and moves objects that should always be stationary. Must always be turned off for all parameters The hidden **Warped Motion** level destroys the decoding speed. Completely violates the standards of the AV1 levels. In order to comply with the level 3.1 standard at 1280x720, it must be completely disabled. Since super-complex vercors heavily load decoding -- Because on the best presets the number of real blocks is many times greater, due to the more complex division of large blocks into small ones. Combined with 10 bits of color, this greatly reduces the decoding speed. -- this WM parameters do give a *micro bit* of quality in the case when an object is overlapped by another object, but on presets like -1 0 1 it is fully compensated by complex block separation. -- on presets like 4+, the number of small blocks is small enough that the overlap takes a maximum of 10% of the decoding, so WM can be good on weak presets

The key frame original frame key frame with Temporal Filter key frame whitout

For a very long time, it seemed to me that my old amd processor had special instructions built in exclusively for encoding and decoding JPEG. It seemed logical. Although I don't have a graphics core either. Many years later, well, it turned out to be true. (at the expense of 3DNow instructions!) https://libjpeg-turbo.org/About/SIMDCoverage

<:SadOrange:806131742636507177>

some more commits for libwebp that relate to better lossless compression: https://github.com/webmproject/libwebp/commit/367ca938f11eda8d69c57530d0aa4e3df0bd0537 https://github.com/webmproject/libwebp/commit/7861947813b7ea02198f5d0b46afa5d987b797ae (EDIT heres a third one) https://github.com/webmproject/libwebp/commit/220ee52967c121adf3c690fbd0605a7de6371943 seems like lossless compression is going to use more memory/ram (not sure by how much exactly but seems like a relatively low'ish increase).

alright so a friend and I wanted to test the compression gains with all 5 of these commits and uhhh th first test image we tried compresses noticeably worse at max compression effort with the master branch of libwebp <:ReeCat:806087208678588437>

they made libwebp compress **WORSE** with all these commits designed to "**IMPROVE**" compression

we even triple checked with different compiles and binaries and the results still came out with the newer commits compressing worse

worse for smaller filesize? wouldnt be surprising a video codec prioritizes discarding even more detail for small wins in a an excel table (just dont show the low quality image)

this is lossless compression

I forgot to say this is for lossless

yeah

testing the main branch with all the mentioned commits against version 1.4.0 and the main branch comes out with larger files

does libwebp do *lossless* animations btw?

yeh though it's annoying to create them with the libwebp tools

Discord now supports animated WebP

https://discord.com/channels/794206087879852103/794206087879852106/1289443266475069523

😔

if only there was good tooling for animated WebPs

the libwebp tools suck and FFmpeg sucks

only converting GIFs to animated WebP is a seemless process

It looks like a static image for me 🤷‍♂️

Some softwares can directly export WebP animations

https://help.clip-studio.com/en-us/manual_en/600_animation/Export_animation.htm#1428921

as long as one skips the gif part, final webp/webm will be much higher quality and likely smaller too

Although CSP users are somehow the group that hates WebP the most

Maybe their use case doesn’t work well with WebP

Most of artists don't want to spend time on researching how to open and edit WebP

They're especially furious about Chrome converting all their artworks to WebP and their audiences unable to open

Gimp supports animated WebP but doesn't support animated PNG.

APNG is at least supported by ffmpeg.

CSP has been supporting APNG for long time

The most useful tool for APNG is TwekPNG by my experience.

that's because they kill quality when they export it lol

It's not that difficult to create good animated WebP, but convert it to something else is tricky.

if you have the original videos, you go back to those and dont bother with converting from webp

What about AVIF? I was trying to create AVIF animation with transparent background but couldn't find any way to do it. Is it even possible?

CSP didn't support WebP until this year

Yes, I can do it.

Everything I tried I got black background.

maybe it's a decoding issue

like, transparency for animated stuff is generally badly supported

I have never created animated transparent AVIF, but I would know how to do that.

As AVIF is based on video, it's expected to be a good format for animation. It can take advantage of all video encoding techniques.

yes

Already waiting for AVIF support everywhere so I can make my profile picture 8 MB Shrek playing in real-time.

GIF is the original sin. Things would be easier if still images and animation would not be as conceptually mixed.

size: 16x9... pixels

I don't understand what you are talking about. GIF is a video format.

ffmpeg is unable to create transparent avif, you can use avifenc for that. If the source is a video, you may be able to pipe it ti avifenc using ffmpeg's yuv4mpegpipe

before the PNG format became popular, GIFs were used way more for drawn/palletized stills

(I was joking obviously...)

ah gotcha 😄

There is an important distinction between video and animation, though: Video has audio, animation does not.

I mean, of course there can be standard video content without audio, but that's kinda rare...

Movies were silent for quite a while, historically 🙂

usually played back with music, though

Yes, must have been fun to be a pianist back then

if you had the skills, definitely

Shostakovich got a lot his inspiration from his work as a cinema pianist.

GIF was actually not meant for animation. GIF was an image format and could do slides. Looping is an unofficial extension from Netscape.

GIF was actually the only usable format for transparent images until the general adoption of Google Chrome because Internet Explorer didn't support transparency in PNG.

It would be much easier if avifenc could just read APNG directly.

Read APNG with ffmpeg and piping it somehow to avifenc is kinda cumbersome.

Well, the other option would be to extract all video frames and use avifenc directly on those frames, but that is even more cumbersome

What about the transparency?

In the latter case?

It would be retained, if you extract the frames as PNGs

According to `ffmpeg -h encoder=av1` av1_nvenc supports alpha with bgra and rgba, but requires an Nvidia GPU. Try that if you have one

I guess GTX 1050ti won't do.

I would still try it, this is the only way to get an alpha AVIF with ffmpeg directly

No way, it can barely do HEVC

Anyway, extracting to individual PNGs the frame timigs wouldn't be preserved, so piping RGB+alpha it is.

In case you don't know how: `ffmpeg -i INPUT -f yuv4mpegpipe -strict -1 -pix_fmt yuva444p - | avifenc --stdin OUT.avif`

Couldn't I pipe RGB for lossless?

No, neither ffmpeg nor avifenc allow that

You'll have to settle for yuva444p

Why would you use lossless for avif?

Simple, in animation, AVIF can take advantage of AV1 interframes so in this particular case it might be better than other lossless formats.

That's unfortunate. I guess this is just limitation of the current implementation. Is it at least full range YUV?

AVIF lossless is often/sometimes trading blows with lossless WebP, so I would recommend you compare it with a few of the files you want to convert

Yes, yuva444p is full 4:4:4

together with alpha that is

FFmpeg supports alpha with WebP directly

I mean, if it's PC range or TV range.

`for y4m or stdin, range is retained`

it will be the same as input

PC range pixel formats usually have "j" in the name.

Since your source files are APNG I can pretty much guarantuee that they are full range which will be retained with the command I sent, outputting full range AVIFs at the end

No, I was wrong, it actually does output a TV range avif

iirc, the “j” pix_fmts are deprecated; it’s a separate -color_range flag now

in fact, I see discussions about their removal https://patchwork.ffmpeg.org/project/ffmpeg/cover/20240112082950.41637-1-ffmpeg@haasn.xyz/

https://www.reddit.com/r/ffmpeg/comments/1c6nnsq/yuv_and_yuvj/l04i38c/

Alright, the importing thing is if the flag makes it all through the entire process.

maybe it makes a difference to specify it explicitly?

<@688076786525143117> What sources do your APNGs have? Would you be able to share one of the APNGs here?

I did some testing with this test animation, RGBA lossless avif doesn't even beat animated png 🥲. YUVA avif landed in between apng and webp.

Moral of the story, lossless avif sucks, always use lossy

Here are the sizes: ``` rgb lossless avif --------- 1.07 MB apng ---------------------- 934 KB yuva "lossless" avif ------ 908 KB webp ---------------------- 631 KB jxl ----------------------- 521 KB ```

Are WebP and JXL lossless too?

AVIF cannot exploit any correlation between alpha and color, since those are in separate codestreams.

all comparisons are lossless of course

Is lossless in quotes because it’s the annoying yuv rounding error thing?

Converting RGB to YUV is an inherently lossy process

https://github.com/AOMediaCodec/libavif/wiki/Drift

I was questioning if lossless and/or transparent animated AVIF is possible at all. Apparently there are some ways to do it but it's not worth the trouble.

WebP is apparently better for lossless.

AV1 doesn't even beat PNG most of the time, so naturally WebP and then JXL will beat it

Not always, but as I said yesterday AVIF and WebP are ofen/sometimes trading blows, WebP is often better, but not always

Also, I think lossy WebP is perfectly fine for lossy animation, even with the 4:2:0 TV range. Most people don't seem to care about color fidelity in animation anyway, if they're using GIF.

I fthey cared, they would use at least APNG.

Most animations are better stored lossless, with either limited color palette and sharp angles or smooth gradients in shading. Videos turned into GIFs on the other hand...

At the end, it depends on the application which format can be used. There are still websites that don't allow uploads in WebP.

I was trying to optimize some GIFs by converting them to APNG. And it was both success and failure. Success if the GIF was using only global palette, failure if the GIF was using local palettes. In that case, APNG got bigger.

There's no intraframe coding utilized for animations if I read the source correctly.

But that doesn't help lossless AVIF much.

WebP can still do simple difference frames like GIF does.

For natural video, av1 will be much better than anything intra-only (or only simple inter like gif/apng/webp/jxl)

At least for delivery quality. For authoring workflows and high-end applications like digital cinema, intra-only is the way to go.

I wish there was an alternate AVIF decoder library for C that didn't rely on libyuv.

And still maintained.

Well, the current intra-only approach used in digital cinema delivers significantly degraded quality, much worse than what you get on UHD Blu-ray, 4K DCP is severely bit-starved on usual movie content. That's because each JPEG2000 frame can only be ~1.24 MB MiB in size max in a standard 24 fps digital cinema package, no matter if 4K or 2K, due to a hard bitrate limit of 250 Mbit/s.

Even worse, every 4K DCP JPEG2000 frame needs to contain a 2K JPEG2000 frame for backwards compatibility reasons with older projectors, using the scalability feature of JPEG2000. Really wouldn't be surprised if 2K cinema often looked significantly better than 4K, if supplied with a 2K-only DCP.

3D and HFR have a 500 Mbit/s limit. At least those don't need to have the fallback 2K images. Still, with ~0.5 MiB per frame for 120fps content this probably means almost garbage tier quality at 4K... pointless to even support 120 fps with these restrictions...

I didn't realize the bitrate limit was that low, and not different for 4K than for 2K

The only JPEG2000 hardware decoder on the market back then (some FPGA by Xilinx) couldn't do more than that. Only reason why.

And for 2K, it was ok.

Strange they didn't just bump up the limits

They didn't want to complicate distribution. Thus backwards-compatible 4K DCPs seemed like a great idea. To the marketing people anyway. And 4K digital cinema still is little more than a marketing gimmick, due to the old inherited constraints.

its just mp4 demux + av1 decode + yuv->rgb, wiring these together probably isn't too painful

It requires libyuv to scale the tiles.

interesting, I bet libyuv could be replaced in crabbyavif without too much issues hmmmm

`jpegtran` has an oversight that it adds JFIF marker even if EXIF marker already exists in the JPEG file, resulting in non-compliant EXIF file. EXIF is supposed to be the first marker in JPEG file, so is JFIF, that means if EXIF exists, there's simply nowhere to put JFIF.

Seems the latest OpenEXR version breaks my jpegli `dyld[15035]: Library not loaded: /usr/local/opt/openexr/lib/libOpenEXR-3_2.31.dylib Referenced from: <1CFE580E-5732-368B-B23D-9B98B64AEBDC> /Users/meow/Tools/jpegli/build/tools/cjpegli Reason: tried: '/usr/local/opt/openexr/lib/libOpenEXR-3_2.31.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/openexr/lib/libOpenEXR-3_2.31.dylib' (no such file), '/usr/local/opt/openexr/lib/libOpenEXR-3_2.31.dylib' (no such file), '/usr/local/Cellar/openexr/3.3.0/lib/libOpenEXR-3_2.31.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/Cellar/openexr/3.3.0/lib/libOpenEXR-3_2.31.dylib' (no such file), '/usr/local/Cellar/openexr/3.3.0/lib/libOpenEXR-3_2.31.dylib' (no such file)`

oh, yeah, there are sometimes annoying problems like that

in first intention, I usually open `CMakeCache.txt`, remove all `*_OpenEXR_*` variables to force CMake to find it again, and then rerun it

if that fails, I set `JPEGXL_ENABLE_OPENEXR` to false

(ah, wait, jpegli)

ah, the variable still has that name there

I’m not sure OpenEXR input makes much sense for jpegli anyway, so maybe it’s best to just disable it

Should I do anything else after editing CMakeCache.txt?

rebuilding should be enough: it will detect that CMakeCache.txt has changed and will rerun cmake automatically

you can rerun cmake by hand if you prefer

Seems rerunning cmake or rebuilding the entire library of jpegli or libjxl now results in the same error: `CMake Error at cmake/FindAtomics.cmake:55 (message): Neither lock free instructions nor -latomic found. Call Stack (most recent call first): CMakeLists.txt:212 (find_package)`

And developers for Telegram already faced it last year for libjxl https://github.com/TelegramMessenger/Telegram-iOS/issues/1235

WTF the build problem is caused Xcode

Reinstalling Xcode Command Line Tool can solve all problems above

How Apple f ed its users

Curious if anyone has seen or tried compiling this before https://vivivi.leprd.space/software/gifthermal/

Can AVIF be a interframe predictive or is it intra only?

for animated ones? you can just shove a AV1 stream into a AVIF so I guess the answer is yes it can be interframe predictive

I always thought that AVIF limits this

Originally it did, but they changed the spec and now AVIF can contain arbitrary AV1 payloads

So it's basically just a video container that promises not to have audio (or subtitles, or whatever else goes into video containers besides the video itself)

Oh, clear

Does it support alpha channel in this mode? 🤔

I remember alpha channel in AVIF is stored in a different codestream unrelated to color channels

so I guess there are essentially two encoded images when there's alpha

does it support exif/jumbf/xmp metadata?

that is correct, this is also just in general a common old way of encoding alpha

\*cough cough\* JNG

Yes, and I guess for animated avif with alpha you basically have a color av1 for the RGB plus a grayscale av1 for the alpha

Exif and xmp yes, JUMBF I dunno

Yes, it's just a separate grayscale av1 stream that functions as the mask.

does anyone know any JPEG decoders that take advantage of restart markers for multithreading?

I think there are some proprietary ones that even add an app marker with the offsets so if encoded that way the decoder doesn't need to parse the bitstream to look for restart markers, but can just seek. The same thing exists for PNG too. It only gives you parallel decode with stripes though, not tiles (so only of limited use for region of interest decoding).

Even mozjpeg jpegtran is adding APP0 JFIF when APP1 EXIF already exists. Seems nobody bothered fixing this bug.

it's funny that I remembered that old conversation. I wanted to add that the interlaced PAL scan looked better than the half-frame scan of SECAM and was less annoying. After the collapse of the USSR, television operated in two SECAM+PAL systems from region to region. But in general, there was rapid digitalization, and at the moment there are only a few analog television outlets in Russia, whose owners decided to pay extra for the rent of analog frequencies. 1-2 channels on country. Another funny fact is that, since Russia is a country that is well with space. We never got Netflix or anything like that. About wires. Everything works by satellites. Because of this, multi-storey buildings are literally hung with 10-20 satellite dishes on the side of the multi-storey building

This is more of a joke, of course. But still the photos are real. https://discord.com/channels/794206087879852103/803950138795622455/1292859688932741170

While in neighboring Poland, television has long been HEVC 1080p. In Russia, it was decided that rebuilding the networks of the whole of Russia is so expensive that it is better not to change anything and stay on 960x540 AVC as it is now. Anyway, television is dying, switching to satellite and the Internet. It's a pity that my satellite set-top box does not display any information about the codec that is received from the satellite. Perhaps HVEC use been there for a long time, even on low-quality transmission... but at least for 4k channels, it is definitely yes. <:H265_HEVC:805856045347242016>

continuing from https://discord.com/channels/794206087879852103/803663417881395200/1292810554091507752: https://github.com/Yellow-Dog-Man/FreeImage/pull/17#issuecomment-2397145502 <@238552565619359744> rather then going lower for lossless effort why not get it closer to what the FreeImage and or libwebp defaults are? I don't know how and where Resonite exactly uses WebP/Image encoding however speed complaints seem to have only came after the lossless cruncher was enabled so surely something closer to default rather then lower is fine right?

Going for a setting that's both faster and smaller seems like a more appealing change for Frooxius to accept than doubling the encode time for the same relative gains

I brought it up in the past to him and he said he doesn't care if the files are 50% larger so long as they're fast

hm. also what where you comparing method 1 quality 20 to? was it method 3 and quality 30 or method 0 and quality 100

Also hence why I even mentioned setting both to 0, since as a live game most people just care that it shows up fast rather than how long until their storage quota is full

Method 0 Quality 100, which is what the game currently uses (Confirmed via a SHA256 match)

Jeez, might as well be using PNG at that point if you want speed that bad

It was worse than an optimized PNG

Naturally JXL was faster and denser

What kind of media are we talking about?

Non-photographic?

In-game photos/screenshots

oh also I probably should have mentioned that I left a comment (the link I posted) on the github pull request before posting in here

the majority of the comment is based around the idea that your results where against method 3 and quality 30

I know, I'm writing a reply

I just wish I hadn't gone to bed early for once last night so I could've explained it to you better

at the moment I'm leaning towards leaving it at `-z 4` (method 3 and quality 30) rather then lowering or raising it

it's like 2.5 presets lower then the default FreeImage settings

I'm assuming encode speed changes based on image content, because I can't replicate the timings on the original issue in the Resonite github

Today, one person tried to compress a png smaller than 83 bytes, today is the first time I needed this site

discord can not play vlc can not mpc-hc can mpv can

3kbps lmao

<:This:805404376658739230> vorbis best codec for this

wat about opus

Opus at 3.2 kbps (only goes by 0.4) sounds really weird

for music compression at 10 kbps, it is worse than mp3

You have to force the encoder to go below 6kbps

https://github.com/facebookresearch/encodec If you want to .... then use this. at 12 kbps, it sounds quite good on opus 64 kbps + stereo. I'm telling you why my vorbis file doesn't play everywhere

What if I told you could get a pretty long song at full 44100 or perhaps beyond under a MB

This is 730KB <:t_:1240995769952112692> (spectral is from 40MB FLAC conversion)

bruh. my link above

What if I told you this technology was older than me

🥱

<:t_:1240995769952112692>

Basically this is what you would call a tracker, which basically is a collection of uncompressed WAV sounds with instructions on where they go Basically the computer follows these instructions to play the song Therefore you can have basically an infinitely long song in a small file

doesn 't impress

ok

aka a MIDI file

or at least very similar lmao

I guess you could call it a midi with a bundled soundfont

no wonder, it's purely optimized for voice down there

I think fdk-aac is probably better.

8 kbps cbr minimum

oh right...

this is really dumb anyway

the two are very different

MP3 (liblame) < Vorbis (libvorbis) ~ AAC-LC (libfdk_aac) < AAC-LC (iTunes) < Opus (libopus)

this was for ~4 kbps

darn I have no idea on extremely low bitrates

A strong similarity does exist, no? A tracker file and a MIDI file are interpreted by the software playing the file. Of course the tracker file has, at least according to above comment, I have never had tracker files or software installed, soundfiles which are then played according to the instructions, similar to a MIDI file. Right?

fdk-aac -m [3-5] beats anything qaac has to offer, and even Opus on very variable content at high quality

just by having superior consistency

Tracker files are monophonic on each channel with voice control events. MIDI files are polyphonic, can contain arbitrary metadata and can include effect settings, device configurations and more.

They may look similar on the surface because both have audio synthesized in real-time, but when you really dig into the rabbit hole...

Trackers actually came up the other day https://discord.com/channels/794206087879852103/806898911091753051/1290666110798270476

Well, at least -m 4 and -m 5 can definitely beat Opus on diverse content, like movie audio.

So in other words, trackers were designed for creating music and midi files were designed for controlling hardware?

To compress the 3 ep of TADC, I had to write my own algorithm, an analog of AQ mode 3 in x264 and x265, to dynamically determine the brightness in the frame, to increase the bitrate I split the episode into keyframes for 10 seconds and compress each one with its own CRF step Because AV1 all dev apparently decided to give a f... about it all👍

<https://github.com/gianni-rosato/svt-av1-psy>

full of code

```python def adjust_qindex(qindex, avg_luma, frame_luma_bias, temporal_layer_index): return qindex + round(-((255 - avg_luma) / (1024.0 / (temporal_layer_index * 4 * (0.01 * frame_luma_bias)))) ** 0.5 * (qindex / 8.0)) if frame_luma_bias != 0 else qindex initial_qindex = 62 avg_luma = 32 frame_luma_bias = 100 temporal_layer_index = 2 adjusted_qindex = adjust_qindex(initial_qindex, avg_luma, frame_luma_bias, temporal_layer_index) print(f"out q: {adjusted_qindex}") ``` to check what quality will be given at what brightness, I wrote this function in python like this

in fact, I'm not very happy with the flexibility of this func.

I use much hard values... to implement using the psy method, will most likely have to change the entire logic of the psy function

Although... in general, the code is written right inside the source code, so I can insert it into my fork with default parameters. The problem is that the psy function changes the QP (frame-luma-bias 100) 10 times lower than I need. because I'm doing a very strong compression. So this feature will only help me a little by default.

```c qindex += (int32_t)rint(-pow((255 - pcs->ppcs->avg_luma) / (1024.0 / (pcs->temporal_layer_index * 4)), 0.5) * (qindex / 8.0)); ```

remove temporal_layer_index `qindex += (int32_t)rint(-pow((255 - pcs->ppcs->avg_luma) / (256), 0.5) * (qindex / 8.0));`

a very interesting thing that I did not want to add in any way is an increase in QP with strong brightness. I definitely didn't want that.

The formula turned out to be not so simple

since QP is an integer, it little jumps

It turned out to be a very difficult job on the eye. In addition, for some reason in function removes the effect for keyframes, which can cause a sharp jump in quality from the keyframe to the regular frame

```C qindex += (int32_t)rint(-pow((255 - pcs->ppcs->avg_luma) / (256.0), 12.0) * qindex); ``` As a result, after half a day of testing, I took the function in this form, on any default encoding

an interesting bug mozjpeg-v4.1.1 DCT block in the 1280x7000 image is incorrectly rotated encoded

mozjpeg-v4.1.1-win-x64\shared\Release\cjpeg.exe -baseline -notrellis -sample 2x2 -quality 50 -tune-psnr -quant-table 1 VK.png > VK.jpg

Woops how does that happen? Overflow in their deringing trick?

If anything looks more like it was inverted

Have you opened an issue for it? It should get fixed

well first the latest version should probably be tested https://github.com/garyzyg/mozjpeg-windows/releases/latest

the official mozjpeg repo can't do release tags anymore because they all lost permissions to do so

what

This looks like the first AC coefficient got a sign flip, which you can totally get if you exaggerate coefficients and rely on decoder clamping to get sharp black/white edges without ringing, so you end up with an int16 overflow

At least that is where I would look first to find this bug

https://github.com/mozilla/mozjpeg/issues/424#issuecomment-1249902681

I don't know, maybe I'm cursed. everything I touch is broken, codecs, browsers, operating systems. sometimes it seems to me that I am the only one who Uses. The only one who compresses, who plays games. the only user of manjaro. It's all such a disappointment. I don't mind reporting it here, because there are people sitting here who care, but, I don't care, I showed a bug, you can repeat the bug and report it yourself

for example, there is a bug in aac fdk, because of which my 2013 TV loses sound every 1-2 hours during playback, somewhere the legacy is broken, in some one byte. but no one knows about it

Samsung J4 2018 does not support 10 bit AVC hardware decoder. but all AVC videos are decoded through a hardware decoder. Breaking 10 bits and YUV444 videos

There were usually so many mistakes with manjaro that I'm surprised they haven't closed yet, they're so broken, part of life has become -- The only post on the entire Internet about error... without a solution

Okay. here's a fun introduction to the ubuntu installer

I know someone like that too lmao

I am sure that I would write about errors in Jpeg XL every day. But so far I don't use Jpeg XL as I would like, only in Modular mode to archive photos once every half years

https://github.com/mozilla/mozjpeg/issues/444

👍

I'm surprised that didn't stop you

I didn't realize it had become that inactive. In any case a bug like that should be an easy fix, maybe I will look at it myself if it remains open for too long

famously

Can the issue be replicated by using libjpeg-turbo? or does it only affect mozjpeg?

the file is here, you can test it yourself https://discord.com/channels/794206087879852103/805176455658733570/1293674664798978150

Likely only mozjpeg, disabling the overshoot thing (which is a mozjpeg addition) solves the issue.

Maybe use plain arch instead of manjaro 👀

the inability to install without an internet connection is the funniest thing I've seen. the instructions for moving the offline filesystem from a USB flash drive to a disk are more long than a bible

Use archinstall or EndeavourOS or one of the other Arch derivatives

Why would you do that? You will have to download updates anyways. If you bootstrap arch with the latest online packages then you don't need to waste time downloading updates

i use manjaro ok just sudo systemctl disable --now lightdm.service --force and kill every bad things

The USB is meant as a bootable recovery and rescue disk, not as a template for your system

> You will have to download updates anyways no

It has recovery and backup and partclone tools installed for system rescue

It's a rescue disk, you're not meant to just copy it onto your hard drive...

You don't understand what I'm talking about. Arch cannot install itself. A bootable image to disk. can't. it does not have the ability to perform the installation. nothing at all. You need an internet connection

Do you not have an internet connection?

Why do I have to have it? it is not written on the ARCH website that this image is ONLINE-ONLY

This is rather one of the funny problems. One of the hundreds I come across all the time

Yes, it's true. It's not designed to copy itself onto the drive. It's designed to be a rescue disk you can use for backup and repair purposes, and it's designed to retrieve packages from online

you don't need it to "copy itself onto the drive" to have a linux image that can do an installation without an internet connection

It's designed that way because it saves time and disk space as long as you have an internet connection

The problem was funnier when I found out that DEBIAN does not have a built-in SSH server in the CD image version. And I just couldn't connect the system local without an internet connection without install openssh server.

For example, Alpine Linux images simply have a large collection of package archives in a directory on the install image, which of course the package manager can install from just as well as from the Internet.

That's why I call it more directly and offensively - not independent OS

The arch iso has custom config designed to be a bootable rescue disk, you need different settings if it's only meant to stay on a single computer.

It has lots of drivers for every type of system you could plug it into, but you only need the drivers for the system its being installed on

What's wrong with installing it by downloading the latest packages online?

Isn't that more logical?

Personally I think Arch is not that great but it's probably the simplest Linux

Debian is so bad it's tragic

as the person who knows more than me told me when I wrote to him, "what the fuck did I install Alpine on your advice and it can't run programs for me": --- Uh. glibc... localhost:~# ldd mysql libs (x86_64)1.2.4_git20230717 Oh, yes, that's what I was talking about... use manjaro... or something else)))

Symbol not found just means you're trying to run a dynamic linked binary that has missing library dependencies.

You are trying to run a binary that was compiled for glibc

musl moment

You should try running a non-glibc version

Or compiling it

I believe that everything I can use should work offline too☄️

Or sometimes installing gcompat helps

Luckily there are lots of installers providing an offline installer

I.e. EndeavourOS, to just name one of them

I mean it could work offline but the arch iso was just designed that way to save space on the ISO

yep like this arch offline installer: manjaro

Just a suggestion. It might be simpler for you to just use arch

And install it online

https://www.linux.org.ru/forum/linux-hardware/16090572 manjaro bug from 2021 (still work) --- The WI-FI device is turned off by the system. after opening the laptop lid. I checked it a week ago

I don't think it meets my requirement to be offline. It's strange that you ignore it, giving an example of some advantages that I don't need at all.

A system that I really just didn't get to, having found something sufficient

No, the operating system is designed to run programs, the only task, not the other way around. Not in our time.

ask him to become a speedrunner of games

You can't run precompiled binaries that depend on things you don't have. A lot of games on steam no longer work on modern linux because they depend on old version of glibc

You can't expect to be able to run some random dynamic linked binary file on any system

Just use a different, compatible binary or make one

And avoid glibc because it's a compatibility mess

i change os

OS with new glibc can’t even run binaries compiled with old glibc

glibc is one of the biggest problems with Linux as a whole

Alpine also has a package called gcompat which allows some glibc programs to run

Made by adelie linux developer

this is the problem of the old one. it is not considered in my case. I'm not interested in that. the new software does not run on the new Linux. alpine moment

Because it was compiled for a different system. You can't run Darwin binaries on Linux either

linux and linux

Symbol not found errors are easy to fix

Probably just install gcompat

But you really ought to use a version that isn't compiled for glibc because that's inefficient

It has a lot of extra symbols that don't need to be there and can be removed if you compile with musl

I don't agree with you. That's how I see it: I have a program. I can run it on manjaro, I can run it on ubuntu, on mint. But I can't run it on alpine. This means that apline is a broken OS. And I won't use it anymore. Do you understand?

Even more specifically: the program itself is much more important than the OS that runs it.

Not including glibc was an intentional tactical decision by the alpine devs

I wouldn't consider it broken just because the default install doesn't have glibc. It's still linux and you can still run glibc on it if you wanted to, or use gcompat to replace glibc

That it's his right. > if you compile with m... But I'm not going to do anything at all.

There's even a whole page about this https://wiki.alpinelinux.org/wiki/Running_glibc_programs

Use flatpak, or just type "apk add gcompat" if that isn't too hard to do ;)

Or, you know, avoid using binary files that weren't compiled for alpine

the Linux application does not run on Linux, because this Linux is not the Linux that it should be to run the application. This is one of the reasons why Windows is popular, why x86 is popular. That's why. It just works

Even on Ubuntu you don't usually use binaries, you usually run software compiled for ubuntu

Using build tools designed and optimized for ubuntu, the platform it will run on. Same applies to all distros like Alpine. It's always most optimal that way

That's a legitimate problem with glibc and with Linux project refusing to include libc as part of Linux

Linux is intentionally incomplete and some people think it's a virtue but I agree with you that it's not

"But they call all this one common Linux." Although as I see it, you don't mind diversity to the extent that some programs don't run on different Linux distributions.

Linux is successful in spite of its lack of included libc, not because of it

Linux is successful in spite of gpl, not because

A lot of things people consider strengths of Linux are not really helping it succeed

No, I think it's a problem, but it's not the fault of Alpine

It's a fault of the crappy state of Linux ecosystem

the way

And the arbitrary refusal of Linux to provide the bare minimum OS userspace library and tools

Oh wonderful world

If Linux was more like BSD it would be more likely to succeed without sabotaging itself. People wrongly attribute Linux success to its flaws

And yet, a linux binary file remains the most stable way for a program at the moment, it is always there as a file, and it will always run as a program. I have an OS and I have a program. And I'm pretty sure that it will start at any moment. On any computer, in any environment.

I have never seen a living person who would work on BSD. Really.

<:Linux_Tux:806135372739510282>

It succeeded by being in the right place at the right time in spite of its major flaws. if it adopted good ideas from BSD it would be in a lot more powerful position but instead Linux is very stagnant

And this compatibility mess is a direct result of Linux refusing to evolve

Because it doesn't provide a bare minimum baseline that can be expected on every system.

Instead glibc does, and a terrible job too, since it's the main source of cross distro compat errors

Even before musl was created to be a simpler alternative

If you need compatibility with glibc there are plenty of different ways to do that on alpine

dietlibc, uClibc, Newlib, musl, Klibc

very open very source

I still live in a world where I can use neither arch nor alpine. and downloading and installing any linux is 5+5 minutes

Completely abandoning glibc would be a step in the right direction. It's very telling that software compiled with musl can run on any system but software compiled with glibc can only run on certain versions of glibc.

musl actually makes it possible to just have a "linux binary" that works everywhere, not a "glibc 2.19 linux binary"

If you want Linux to evolve and become more universally compatible like that then you should support what the musl people are trying to accomplish for Linux... because Linus refuses to do it ;(

It's really the fault and responsibility of Linus that we have this problem since he intentionally only wants to provide an incomplete and half baked system

Some people actually argue that it would be a bad thing if Linux was less incomplete and try to justify the lack of effort

It's good that I'm not a Linux developer

and you too

Considering how glacially slow the kernel gets improved it would be pretty frustrating I imagine

It's basically just a collection of drivers with ancient glue code in between

Ancient stagnant code that never gets refactored or replaced with more fault tolerant and cellular code

Andy Tenenbaum's old criticism of Linux is still relevant today. Linus read his book but learned no lessons from it he said... the most basic and uninspired kernel with no separation and compartmentalization of code or fault-tolerant design paradigms

Just a big monolithic kernel

Only successful because there were no other alternatives at the time it was released

As a result of another day of tests, the dark areas became too demanding, so I had to change the function a little more ||Plot3D[-((255 - x) / 256)^8.0 * (y/4), {x, 0, 255}, {y, 1, 64}]|| `qindex += (int32_t)rint(-pow((255 - pcs->ppcs->avg_luma) / (256.0), 8.0) * (qindex/4.0));`

When I use --xyb for option 420 or 422 in jpegli, the image is very blurry compared to the image without using --xyb.

With high quality settings.

I don't think XYB is optimised for 4:2:2

that artifacts don't look like XYB at all for me, they are rather RGB artifacts. I guess something's going wrong

chroma subsampling selection in jpegli is messed up in multiple ways. for example there are two different 4:2:0 (or was it 4:2:2 or both?) modes but good luck trying to intentionally switch between them

also non-xyb defaults to 4:4:4

iirc using XYB with no forced chroma subsampling results in a different 4:2:0 then if you force 4:2:0

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

wait here this comment explains what is actually happening with what I am remembering https://github.com/libjxl/libjxl/issues/3605#issuecomment-2132425056

I think the blue channel subsampling was disabled to make it compatible with JXL transcoding

https://gitlab.com/wg1/jpegxe/ctc_tools/ https://jpeg.org/jpegxe/documentation.html Does anyone feel like making a submission to the JPEG XE call for proposals?

The "uncompressed" format here is a sequence of 'events', where each event can be of different types and consists of bit-packed fields with an interpretation that depends on the event type.

what is JPEG XE?

something that doesn't exist yet, it's in exploration stage. It's for event-based vision. This document describes what they want to do: https://ds.jpeg.org/documents/jpegxe/wg1n100887-104-REQ-Use_Cases_and_Requirements_for_JPEG_XE_v2_0.pdf

At this point we have too many JPEG X<alphabet> formats and more creative names would be preferred....

I ain't interested in this. Not sure this will be useful as camera sensor standard...

XI = 11 XV = 15 XL = 40 XC = 90

“JPEG XV” would sound quite intriguing, I must admit

extra value?

JPEG Extra Virgin

like olive oil, right?

maybe JPEG 15

ah I was late

"Exclusivity deal signed with MindGeek"

Next format should be called JPEG XXL

or JPEG XML

JpegRTC

How does this have anything to do with encoding and compression of images though

This just looks like generalised MIDI

It is image data, just sparse, not with full frames of rectangular pixel grids

So just JPEG XL patches and frames?

This feels like something that could extend jpeg xl

More like single pixels. But compression should be much simpler than jxl, it's more like XS, low-complexity

Is it for real time or meant to be highly compressed

Most use cases real time, though I guess sometimes they also need archival and then you can do something more

You could just do brotli

Is there a spec?

Probably you can do better than generic byte compression by exploiting the field structure

The uncompressed format is described here: https://ds.jpeg.org/documents/jpegxe/wg1n100891-104-CPM-Common_Test_Conditions_for_JPEG_XE_v2_0.pdf

So that is what has to be made as small as possible?

Yes, there are also some example data files in that format available

I assume e.g. typically the x,y coordinates will be correlated so probably some kind of delta coding will be useful

We need another x to show how powerful it is 😉

what is the most indestructible image format? So that I can shooting it, delete bytes, replace bytes, add bytes and trim data. It is quite possible to do this for MP3 because it is the most indestructible format created specifically for CD. But it's a sound. What about the pictures?

Even though Jpeg XL is divided in blocks of 256x256. Changing 1 byte anywhere will completely break it for decoding

Maybe something like JPEG XS?

That JPEG XE proposal probably would have high resilience to corruptions as well

The thing is unlike video or sound there is usually no reason to steam an image

You usually either want the whole image or you don’t want it all, and you can usually load the whole image in one go

So there isn’t really any image formats with internal packet loss / corruption compensation like video or audio

Something like PPM since it is uncompressed would naturally be relatively endurant

Jia Tan XD

🤔

need to invent

that's probably just the current decoder implementation choosing to bail if something is wrong

CD audio doesn't have anything to do with MP3 though

I didn't even talk about CD audio. I was talking about CDs

the disc

as in just putting files on a CD?

<:PepeGlasses:878298516965982308> mp3 on CD

i'm confused

what

How could MP3 become a super successful format, without the internet, or anything else. in 1993