JPEG XL

Don’t LLMs (and I assume other large AIs) have weird issues where different hardware gives slightly different probabilities due to floating point weirdness?

6.9 bpp is not "half the rate" of 7.2 bpp

I should clarify, the latter 2 images are from the previous paper they reference. It was a show of their backlinking to JPEG XL results... Never actually saying how they were encoded and just citing the original paper

Compression ratio going from 2.93:1 to 6.32:1 is very suspicious. If it's true then that's a major, major breakthrough. But more likely they're just doing something lossy.

I will only believe this if someone shows me an encoder and a decoder I can play with to try it for myself. That kind of compression gains are just not plausible.

their middle-out compression game must be strong

In the previous paper they concluded with "it's 3% better than JPEG XL* *in near-lossless encoding" So I wouldn't trust a word of it. Too many missing variables, literally

Nature is supposed to be highly reputable though. How is such a paper getting past peer review?

DEI

Decryption and Encryption for Images?

Or just decoding and encoding for images

"DEI" is everywhere

JPEG XL - Industry Leader in DEI

Not DEI. Inclusion policies would imply actual skills 😂 This is just a bad paper.

Actually, something seems horribly wrong. x264 should not be getting worse lossless compression results than x265 here.

I mean, nothing makes ham sense here

Maybe the AI literally generated the results in the charts

Not sure how favoring researchers by demographic implies good science. The journal is definitely ideologically captured, to what measurable extent it affects publications I cannot say, but they were willing to participate in the #ShutDownStem initiative, which says a lot.

Anyway, someone should look at the code and figure out what's actually going on. I was able to run it locally, but it's rather opaque to me.

Yes, but diversity as a goal implies discrimination.

It can also imply that discrimination is the current reality and to obtain more diversity it is needed to reduce discrimination. I prefer to reduce it to zero but not to 'overcorrect' by applying positive discrimination measures.

But then diversity is not the actual goal... And even then, fighting discrimination (most of which would be long past) by discriminating against likely completely different individuals than those who benefitted from that past discrimination is a bit, eh, problematic.

<:YEP:808828808127971399> It's important to look at the effects of DEI initiatives and ask yourself what they are really trying to accomplish. DEI is designed to not decrease discrimination but increase it instead. It's the only reasonable explanation other then absolute incompetence when you look at the actual results of said practices. Particularly for workers in skilled jobs, when you have to wonder if a hire was really the best person for the job, or if their most meritorious factor was the color of their skin or gender it leads to, putting it nicely, negative feelings. When it starts happening constantly, it creates and reinforces patterns. And we all know what happens when patterns of negative feelings towards a specific group of people happen. Good old racism or sexism or whateverism. The only logical explanation is that DEI was specifically crafted to amplify discrimination, and it's an extremely effective tool at it. It is either the most incompetent or malicious forms of practices today.

and then ofc, you have the large negative feelings when you loose a competitive position to someone who is "included" in the DEI initiatives. It's literally resentment generation in the form of reinforcement training

I am in favor of initiatives that reduce discrimination like job application procedures where name/gender/photo/nationality are requested not to be mentioned so they cannot even be an unconscious factor in the decision process (at least the initial stages of it), or practice tests in the house rental market. I am not in favor of quota or other explicit positive discrimination measures since they have counterproductive effects — it only reinforces discrimination. I believe DEI can mean both things and simply opposing DEI is a step in the wrong direction. The question is not whether we need more equality and inclusion (we do) but how to achieve it. Abolishing DEI in general sends the message that you don't want more equality and inclusion and that discrimination is OK.

> I am in favor of initiatives that reduce discrimination like job application procedures where name/gender/photo/nationality are requested not to be mentioned so they cannot even be an unconscious factor in the decision process (at least the initial stages of it), or practice tests in the house rental market. I wouldn't consider these DEI, Taking it at face value, DEI, (at least here in Canada and US) means exactly as it is written, diversity, equity, and inclusion. Purely meritorious based hiring practices (to which I am all for) are naturally against Diversity and Equity as they go against people's natural choices.

I do agree that it's a good thing to remove as many discriminatory practices as possible. But I disagree that removing discrimination will naturally lead to diversity, at least in "all cases" or even the majority of cases which is what DEI initiatives strive to do.

DEI hmm yes, quite a codec. IDK why trump is against it though.

<:kekw:808717074305122316>

Switching to <#806898911091753051>

`cdei input.dat out.dei`

it seems like ezgif.com has now started exporting messed up GIFs for people where the last frame seems to be corrupted or something?

or maybe this was just something that happened yesterday and is fine now?

are you talking when posted to discord or in general

posted via Discord cause I haven't actually tested outputs from the website myself it's just that I noticed yesterday in 2 separate places that people tried posting GIFs and they where broken in the exact same way and had ezgif.com credited in the metadata

yeah there are some changes to lilliput about gifs

this was merged 13 hours ago https://github.com/discord/lilliput/pull/254

I thought downloading files/images from discord only resulted in stripped and not conversion?

unless lilliput is involved in that??

hmm, lillliput handles converting Animated WebP to AVIF but that's only the embed iirc, but it also resizes Animated WebP, and it might compress older formats like jpg, png, and gif

I'm getting someone who's file is affected by this to send it inside of a zip file

yeah the description mentions conversion

> Lilliput supports resizing JPEG, PNG, WebP (both static and animated), AVIF (both static and animated), and animated GIFs. It can also convert between these formats. Lilliput also has some support for getting the first frame from MOV and WEBM videos.

ok yeah this is a problem on Discord's end because I just got a person who's file is affected to send the original file and it's fine

Discord is stripping out a giant chunk/part of the end of the file‽‽

like the rest of the file is identical but there's just a giant amount of data the end of the file that is just missing

To be fair, when is it *not* Discord's fault when it comes to animated images?

ok just did some testing and this is no longr an issue.

I guess Discord's CDN was spitting out files with a bunch of end data removed or something yesterday

Anyone know any tools or software that can convert animated heic files like this to other animated formats like gifs and apngs? https://nokiatech.github.io/heif/content/image_sequences/starfield_animation.heic

You may want to try Fast Flix

what's that? Can you send me the link to that?

https://github.com/cdgriffith/FastFlix

(also includes images)

How would that work?

What other file managers have worked for you? I tried X-plore and EX but they didn't work

Try WinRAR's app I guess?? It functions as another file explorer. If that doesn't work, I can't help you I'm sorry.

Use mixplorer

I use material files or amaze, but most likely something is wrong with intents

<@184373105588699137> <@263309374775230465> <@207980494892040194> Neither of those, worked.

Samsung is anti-JXL I guess 😂

So don't get jxl viewer option to open jxl files?

I told them this several months ago, it didn't work for them apparently: https://discord.com/channels/794206087879852103/805176455658733570/1349842481096687637

I did get Jpeg XL Viewer, but whenever I tried to open a jxl file with it through a file manager, it was instantly crashes. But where can I find JPEG XL Imager Viewer at?

Did you give file access permissions to jxl viewer app

How do I do that?

Nvm. I just checked mine it doesn't have file access permissions but it still works

you using a Samsung phone?

No

Poco

did you try this? https://github.com/FossifyOrg/Gallery

Read this. https://github.com/FossifyOrg/Gallery/discussions/422

oh right, i ran into this myself <:facepalm:768798727292190722>

<@1259949633195737132> did image toolbox not play animated jxl for you?

When I zoomed in it didn't

ahhh, just tried it and you're right that's unfortunate

install image viewer in termux time [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

Can you send me the link?

there is no link to be had

does libvips support HTJ2K decoding and encoding? only found J2K load and save functions in the foreign save section

what do you mean by that?

I mean there is no link to follow. even if you just installed termux, without knowledge its useless

I mean how do I install image viewer in termux time?

you will have to do some research on it

I tried opening those jxl files which you posted on reddit . They are not working on my phone too. Probably the file sizes are big.

So 7 series is also getting av1 decode

My phone has 8s gen 3 it includes av1 decode

<@1259949633195737132> it's better to use video formats like h264 or av1 for animated images of that size.

yup, finally

https://github.com/LMP88959/Digital-Subband-Video-2 DSV2.7 has been released!

ive been holding out for affordable qualcomm phones with av1 hwdec, glad we are finally going to see them that arent used market ones.

mali is horrid so I avoid that

video AVC HEVC VP8 VP9 AV1 audio WAV FLAC MP3 AAC VORBIS OPUS image JPEG/JPG/JFIF PNG (GIF APNG) WEBP ... any loseless LZMA2 (best) ZSTD (fast) Deflate (legacy) absolutely everything else is dead. because not used, has no base, no support, no effectiveness, no meaning. It makes no sense to discuss something else, because it has a ghostly existence. which contradicts the very essence of a computer: to solve problems.

tiff lol

JIFI, you mean JFIF? There is not really any distinction between JPEG, JPG and JFIF. It's all the same thing.

support for WavPack is not *that* bad

brotli is used quite a bit, too

I understand that there are smart people here, but just in case, I clarified this. Not everyone understands that it's the same thing

in http ok only (in jpeg xl ok) Not dead in real

is gzip not more prevalent in the web?

But you can't use Brotli because you've lost the meaning. It's just not good at anything.

The built-in dictionary is good, and compressing a small amount of data is good. but right now it's nothing but an http codec.

only if you live in 2010

https://almanac.httparchive.org/en/2020/compression

Majority seems to indeed still be gzip

The compression algorithm is selected upon request from the client. but firefox and chrome support both zstd and br. there is no need for gzip. zstd is better than it in any case and faster than gzip. br is better but slower for the server, more difficult. It's a matter of taste. but gzip just died. maybe if your site is 15 years old, then yes.

Of course things can change in 5 years

some people just don't want 10% better compression. They're fine as it is. The Internet is getting faster, and the difference is virtually invisible. but when you're the most popular service on the Internet, like reddit, or YouTube. Where there's only css and js size is megabytes, you're at the cutting edge of technology.

Somehow Brotli isn't here, being the second most-used compression algorithm for the web. (`gzip` and `deflate` are basically the same)

Both Zstd and Brotli are undeniably better than gzip. Zstd wins in real-time compression but loses to Brotli to compression ratio. Somehow Zstd 22 still isn't in the same ballpark as Brotli 11.

I wrote that, you didn't say anything new

because it's not something "you can use". you don't decide whether to use it or not. google decides, with its monopoly on the browser

that sounds like saying that zip is not something you can use, but that instead microsoft decides, with its monopoly on desktop OSes

brotli is supported by most browsers (https://caniuse.com/brotli), so I can decide whether to compress my websites’ files with it and let my web server serve those precompressed files (https://caddyserver.com/docs/caddyfile/directives/file_server#precompressed)

Hmm really? Brotli, among Zstd and gzip can be "used" just fine, be with `.tar` archives or as standalone compressed blobs. Maybe you just don't know how to use it, instead of it not being something "you can use".

Perhaps not explicitly. Brotli is still faster than gzip with better compression ratio at 4.

Funnily enough, I store almost all of my lossless archives with WavPack, since it offers better compression ratio than FLAC.

also supports more channels, which can come in handy

and 32-bit floats

Why FLAC doesn't support f32 is beyond me 🤷‍♂️

how often is lz4 used?

zstd has replaced lz4 in a lot of places

but lz4 is faster at compression than zstd can be, and needs less RAM afaik

To be fair, 24 bit int is already overkill for sound no?

for final delivery, yes

I suppose both for audio and images, integers with limited precision are fine for final delivery, but if you're still going to do editing which may involve multiplicative operations (i.e. bumping up volume or exposure), floating point is a better idea

Delivery yes, studio-use no.

Well floating point is useful to prevent clipping during processing but for interchange and transfer, 24-bit should be good right? I remember doing a round trip conversion of a 32f file to 24i and back to 32f again one time, and getting surprised that it was bit-perfect... but it's probably dependent on the input file being normalized within a certain range or maybe a mistake I made when measuring.

24i is considered studio-quality, but it's usually used in a 32f workflow and processing space

I guess the main problem is that extremely quiet samples have less precision.

32f has 24 fractional bits so in terms of precision it's not that different, except you also have 8 exponent bits to represent very small values and out of nominal range values

But that's easy to avoid. Just don't save any ludicrously -quiet samples to disk

Yeah that's probably why converting to 24i-32f and back was bit identical

It was probably normalized the entire sample to the same exponent bits

even for pretty heavy "normal" editing, 24-bit is perfectly fine

No one use linux bruh

the tar utils are included with windows since 10 released

I use zstd in 7zip addon. Real fast, real use

But brotli... For what? Just use LZMA2

For what? Flac created for the end user

brotli decompresses much faster

Mmhmm. Like PewDiePie, glad I'm not in the update hell of Windows 11 or in the prison of Apple.

I haven't even seen a 24-bit flac. Nobody needs this

qobuz sells them

Use win10 👍

Good luck on compression speeds then ;)

Which is getting EOL soon 👍

this is not relevant. lzma2 is parallelized to all threads, so it has no problems with unpacking speed

like one thread ppmd

Hauling carriages in parallel instead of driving cars, smooth moves \;)

Lzma2 is utterly outclassed these days by fse/ans based compression...

My workflows usually just use i24, which is good enough, unless I have to be concerned about clipping.

I do...

Also, you probably have forgot that nearly 100% of the server space use Linux, so your "no one" also includes virtually everyone who grants you service \;)

Ok... Uhh... No one normie <:SadCheems:890866831047417898>

Linux is kinda shit on desktop because kwin crashes all the time

It's that bad?

But yeah it's worth dealing with linux issues over windows and mac issues

X11 or Wayland?

X11

Wayland is a garbage heap too

I've been using Linux since 2016, and it's fucking crap 👍

Linux is absolute crap indeed. But somehow still better than most alternatives

Indeed XD

the only scenario where linux is running is a terminal without an environment. only then does everything work there

Wonder if that's a driver issue...

Most likely

I recently started using nvidia and boy it's the crap of crap

It's not worth putting up with the driver even if it was faster

Welcome to the world of NVIDIA, mate 😆

Where is that Linus gif when you need it

https://youtu.be/iYWzMvlj2RQ

A friend of mine says I'm cursed. any distibutive that I take, any environment. It's all wrong. One day at a time, and I'll find dozens of bugs. It's like no one uses Linux. It's like a browser is running in it and nothing else.

I know exactly what you mean. Linux is shit

I don't even have any distro recommendations because they are all shit

The least problematic one I used is arch

Ubuntu for compile ffmpeg for windows. Manjaro for games in compile portproton. Its over

But even arch is kinda shit

Just less shit

The only complaint I have with arch is that the packaging and build system is very stiff and rigid and amateurish

They are in the process of fixing it, thankfully

Build time customization is a hassle, every package is built for pre-haswell era

some of my friends are happy with NixOS

There is no alternative libc or init

But my gripes with arch are more minor gripes

You mean glibc and systemd?

Or architectural gripes

Yes

Well... musl and OpenRC comes to mind.

Don't like Linux? Just use GNU/Hurd!

let's just say Linux is a good thing. if you live in a country where Windows cannot be stolen. I have few arguments here. it's hard to argue when Windows is free and with updates disabled and another 100+ shit programs cut out.

<:SadCheems:890866831047417898>

GNU is what's wrong with Linux.

How so?

Very bad programmers and they all work for Red Hat

GNU is just the religious arm of Red Hat

Apart from Debian, GNU/Hurd is likely forgotten.

Ooooh, red hot take!

It is, but you can actually use it lol

I never tried it though

Yeah, that's my specialty

arch's benefit is that it is the "least shit" IMO but still shit, everything is shit

aeryn has actual promise. atomic updated without immutable

What's wrong with immutable fs?

To me it seems obvious there should be a separate place for configuration provided by the OS vendor and configuration provided by the user and site.

Vendor-supplied configuration directory, site-supplied config directory, and machine- or user-specific config should be separate filesystem trees

Not having such separation is annoying

Sitewide config can be supplied as an immutable image, while still allowing individual machine-specific customization. And the os vendor can distribute the OS image in a way that's trivially easy to install or upgrade

It's a great idea and I'm surprised it isn't more common

These are old and obvious ideas but people would rather do things the hard and annoying way

what is the problem with arch packages?

They are sloppy. The build system is terrible too.

Avahi package is required by many things but it installs a bunch of demo utilities bundled with the library instead of separating them into its own package, for example.

And the build system is extremely inflexible and stiff, it wasn't designed to allow you to write pkgbuilds with conditional routines and options like homebrew or gentoo for example

It's just very amateurish and sloppy

I see

CachyOS.

Cachy is just arch.

You can install arch and then add the cachyos packages if you like too. That's what I did.

its insanely annoying when you try to change stuff. DKMS is a good example of something that becomes a massive headache (though aerynOS has issues with dkms that need to be resolved)

cachyOS keeps making weird changes that either cause bad performance in many cases or outright bugs

for instance, I still can't boot any of the cachy kernels without having significant performance issues

what? You can do that easily?

really?

linux-cachyos-server is safest...

yes. I wound up making an issue ticket, and tried a bunch of things, but it got to the point where there were just too many intertwined patches they made and testing each patch was too much of a hassle

`linux-cachyos-bore-lto`and `linux-cachyos-bmq-lto` are the only ones I have installed. All the other schedulers have much worse real-time performance.

do you think it's a scheduler issue or something else?

gonna benchmark them at some point... have had some great raw performance results with bmq in the past...

no that it really matters for most architectures

but on my multi-CPU systems it can matter a lot

literally not a clue, I looked through their cachy.patch but it was just too much, but it's not just the kernel that has issues. Some of their package configs do to. CachyOS is nice when it works but is super unreliable, I know manwe has had loads of issues running cachy too, and I've helped more then a few people who have also had weird issues

Yeah homebrew does it best

You can do `brew install --with-libfoo bar` for example

Arch should throw pacman in the trash where it belongs and just use a real system like brew

arch pkgbuilds can easily do branches as well using env vars

That isn't easily or flexible since only very specific things lile CFLAGS can be passed and anything else requires editing the pkgbuild

It's a stiff and rigid piece of crap that should be discarded completely really

I don't really understand, how would --with-libfoo work if the packaging script doesn't understand arguments?

The packaging script does

You can't do that with a pkgbuild

I have use pkgbuilds that can read env vars all the time?

You mean like `foo=1 makepkg`

Because I thought that only works for the env vars in makepkg.conf

Or maybe the ones that aren’t in makepkg.conf

It's not really clear

Because it's shitty

no it works inside the pkgbuilds. its documented too. pkgbuilds are bash scripts.

did the msft extension not use dav1d???

You mean you have to edit the pkgbuild script. I have written many pkgbuilds as well as brew formulas before. The arch build system is very shitty. I usually put a small "preferences" section at the top of my pkgbuilds for changing the build process

Afaik you have to edit the pkgbuild instead of just setting options on the command line.

Why would I do that? I just read an envvar

YADDAOPT=true makepkg

I wasn't aware that makepkg passes env vars to the build environment. Which is also a very shitty way to do things, compared to a predictable and controlled build environment like in homebrew

There is a chroot build script but it's not commonly used and a lot of packages on the aur have missing build dependencies that fail when built in a chroot

"makepkg" can work on one system but not on another system

It's just very shitty...

Also pacman installs vendor-supplied settings in /etc/pacman.conf instead of /usr/lib

So every time arch updates the vendor supplied settings they go in /etc/pacman.conf.pacnew

Which is stupid

I have my own pacman.conf include pacman.conf.pacnew as a source so that my own pacman.conf only includes settings I want to change from the defaults. But this should not be necessary. Vendor supplied settings do not belong in /etc

every package on the aur is supposed to be chroot tested, and if its not its a bug that needs to be reported. env vars are great since they can be set in whatever env you want and forgotten about, and they work across any aur helper. pacnew is also preferred for most users as they generally don't want their updates overwritten. /etc is the proper place for it

if makepkg does work for whatever reason, that's a bug

In practice about half the aur packages I try to install are missing build dependencies and not chroot tested. "/etc is the proper place" This is flat out wrong. Vendor supplied settings go in /usr/lib

/etc is for your custom settings, not vendor supplied defaults

If you want to build in a chroot, you have to jump through a lot of steps because it's not the default and it's not even in the instructions on the archwiki without serious and tedious digging.

No instructions here: https://wiki.archlinux.org/title/Makepkg

Nor here: https://wiki.archlinux.org/title/Arch_build_system

Nor here: https://wiki.archlinux.org/title/Arch_User_Repository

Here it is, and it's not convenient at all. And barely used and tested on the AUR. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

This is something that really ought to be the default. Homebrew always uses a controlled build environment when compiling, by comparison.

You can also install the latest developer version of a package by doing `brew install --HEAD foo` for example.

I can confirm that for a time, I used to have a chroot for building binary packages (after finding out that if I didn’t do it in a chroot, the built packages contained a full list of my installed packages and that was considered a feature) and it was a bit of a pain

Yeah, arch honestly blows. It's awful, but somehow all the other distros are somehow even worse. Linux is a dumpster fire

I'm thinking of just using a Steam Deck as my only PC

/usr/lib is literally for libraries and objects according to FHS, which is about the strongest authority there is

most apps install defaults to /etc

its tolerable to install configs to /share or /usr/etc /usr/share in the case of a hermetic usr system. but installing to a lib folder is wrong on so many levels

I just use an AUR helper to manage it since its a minor setup, and one flag

This is wrong behavior though.

If you really believe in the FHS then vendor-supplied default config files should go in /usr/share

/etc is for host-specific configuration, not vendor-supplied config.

systemd for example uses /usr/lib as the directory for all of its default config files

And any machine-specific customizations always go in /etc

where does it say literally any of this?

who says files should go in /usr/lib, and where does the FHS say defaults have to go in /usr/share?

fhs says static data goes in /usr/share. Vendor defaults are static data.

it also says static data goes in etc... > 3.7. /etc : Host-specific system configuration > 3.7.1. Purpose > > The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary.

systemd uses /usr/lib for all of its default config. Even though lib is usually for architecture specific object files

/usr/share is intended for data that *should not* be modified, which is NOT default config files, default config files are intended to be modified by system administrators to apply globally

With which os?

They are using static in a different sense there. Static usually means unchanging but obviously config in /etc is meant to change and be machine-specific

SteamOS

Arch then?

pacman.conf and makepkg.conf for instance is an example of a file which is intended to be modified, admins should control the config and tune it per use. This is why default configs go in /etc/ and example configs in /usr/share

I am talking about vendor supplied templates and default configs that can be sourced or overridden from a user-supplied config file

sure, that could also be in /usr/share, but thats fundementally not how arch users typically want pacman or makepkg to operate

updates should not change your configs on you, that's just bad behavior, this is why .pacnew exists instead of just updating the config one way or another.

Ideally my pacman.conf should look like ``` Include = /usr/share/pacman/defaults.conf Include = /usr/share/pacman/multilib.repo [options] Color ```

If it didn't suck so much

Currently it looks like ``` Include = /etc/pacman.conf.pacnew [options] Color [multilib] Include = /etc/pacman.d/mirrorlist ```

That's stupid

no, thats called preference lmao

What? It's the same thing, just stupider

not really, I prefer the latter

Since there's no separation of vendor-supplied data vs my own custom settings

You prefer having it in .pacnew?

That makes no sense

pacnew files aren't supposed to live as a separate file, pacnews are supposed to be taken care of by the system administrator

Generally speaking

It should not encourage me to edit a config file that the package owns and wants to overwrite. That's just bad package/filesystem management

It should install the default config to a separate directory

So that it doesn't create pacnew files every update

It's stupid

Right, that's why the pacnew file exists – it does not overwrite the old file because you are supposed to migrate your config changes to the new file and remove the old one

well, it depends, pacnew is the fresh file, so importing it really isn't that bad

But that should not even be a problem

Sure, but again, the system administrator should, if proper care is taken, deal with that file

I should not be editing a config file that is owned by a package unless there's some sort of exceptional situation like a major system upgrade

or just ignore it <:YEP:808828808127971399>

That's also a choice

an important one

At some point you will likely have to take action though. But can be years before it becomes necessary

the only change I have personally needed to do was the repo change, but well, thats what arch news readers are for

Exactly

It would not be difficult to just install vendor-supplied defaults to a separate place. Even /etc/pacman.d/defaults.conf

I do see your point, but it is a minor gripe at the end of the day

personally, pacnew works great for me, so this is absolutely my preference

Then you could either copy that file to /etc/pacman.conf during system installation or create an empty file and source defaults.conf

nah thats dumb

Without getting a .pacnew file because that's just stupid and shitty

pacnews are great, because they just overwrote the old files in the past, including the user's changes

so this is the better option

I don't want to get all these false-positive warnings about .pacnew files just because I want color output. That's stupid and shitty and no amount of "oh it's just my preference" will change how shitty it is

"issue only user has apparently effects every other user and they totally hate it without hating it"

Like I said I currently just source the .pacnew file but that's not what pacnew files are supposed to be for.

It would make more sense if there wasn't a pacnew file at all and it just installed a defaults.conf somewhere else like every other software project that isn't stupid already does

Like this

nah I don't like that myself, if I want to have the defaults, sure, leave it default and it can be upgraded, but if I modify it, system should not modify it at all

you also want a seperate dedicated "new file" so the "new file" can be located by the system admin

Agreed

It is also viable to just diff the pacnew file and copy the changes to the old conf, then deleting the pacnew one

There is also a dedicated command for dealing with pacnew files: `pacdiff`

thats what I occasionally do, is just diff them

If you want that behavior there's no one forcing you to `Include = defaults.conf` instead of just specifying your settings...

Your objection makes no sense and has no merit

I just want something cleaner with more separation and less mess

I want a separation between vendor supplied settings and user supplied settings, like every other competent tool on the system

sure you could have a defaults.conf.new or some shit with just the diff but that's not very ergonomic. Meanwhile arch's solution has proper tooling around it, is not hard to use at all, the biggest detriment is the extra file

If you actually like having pacnew files for whatever reason then you can even modify defaults.conf directly so you get a .pacnew file still like you want so badly

It would not be taking anything away from you

arch's design is to be ergonomic as possible for power users, and the pacnew system is really good for that

even when not using the pacdiff tool

But most likely you would just make a copy of the defaults.conf and make your modifications, or source it and make your modifications after that

Sorry but there's nothing ergonomic about getting false positive warnings about pacnew files because I changed a config file so I can get color output for pacman

What do you mean by "false positive warnings"?

It's very ergonomic to simply copy or source a template file

I mean every time a package upgrade creates/overwrites a pacnew file it generates warnings

in the log

which is very nice because now I can grep for those

.pacnew files are supposed to be an exception, an error when installing an upgrade

absolutely fucking not

god no

Calling it anything but information is over the top tbh

thats actually horrid

They should not be spurious because they waste everyone's time manually checking each one

just don't do it then?

You are saying wasting my time is a virtue

just dont waste your time? you only need to do it when you want

I literally have pacnews from 2022 that I havent touched and my system is perfectly fine

can I touch them if I want? sure. but I don't want

It just means that a file owned by a package was not upgraded because it was modified after installation. That is an exception, and a possible problem that needs to be manually examined. Spurious exceptions like this are a waste of everyone's time.

Wasting time is not a virtue, it's a sin

This amount of necessary tinkering is to be expected with arch, it is not a "just use and go" kind of distro in these aspects

not only is it expected *it's wanted by the majority of it's users*

Those are problems that can and should be addressed too

I don't want updates to fuck with my configs

no

im fine thanks anyways

passwd does not need to be owned by a package

You're getting those warnings because packages own those files when they should not

This is normal in pretty much all linux distros, no?

Config in /etc should not be owned by a package in a well-designed system

yeah in most systems

Pretty much all linux distros are also shit, though

for their own separate reasons

If you want a good OS why not use TempleOS /s

But there's even talk about Linux being able to support having an empty /etc directory soon

this is normal behavior that is well normal. Doing it in other ways is just weird. hermetic/immutable systems do weird hacks to emulate this behavior because it's normal behavior that the user expects

it already does

I don't expect my package manager to own my custom config files.

I expect the package manager to own vendor-supplied immutable system data

if you say so

If I'm supposed to modify it then it makes no sense for it to attempt to own and update what I'm expected to customize

Really it's just laziness

And it's a horrible and unreliable way of doing things. Like for example instead of owning things like passwd it could use a post-upgrade script instead to create the file if it does not exist or check the file if it does, rather than create a useless .pacnew in that situation. That would just be objectively better in every way and not clutter your filesystem with duplicate files

The only reason those files are owned by packages is because the arch devs are too lazy to write that script

If things can be improved without any downsides you should not reflexively defend the status quo of mediocrity

<@245794734788837387> FTL multiverse went from 672 MB to 617 MB with an oxipng pass :P

with zopfli (`-Z` in oxipng)? the recent speed improvements to it and also since all the art would be low res I'd say it's worth doing `-Z` with oxipng

No, and not all of it is low res, some took quite a while

oh f i forgot backgrounds existed

TBS 3 install size shrinks by 646 MB, nearly 10% with dedup and PNG compression.

For those who might be interested: I've been working on improving libaom's tune iq efficiency at the highest speeds: 8 and 9. I can happily say I've successfully addressed a ton of ringing, blocking, and mosquito noise artifacts with minimal compute impact!

this is how SSIMU2 scores compare on Daala's subset1 before and after my changes for the speed 9 (lowest effort)

every improvement (except for a pending speed 9 one) has already been merged to libaom

"superold" in the filename for the first image, is the sample image you posted using an older build than the one compared in the ssimu2 scores?

"superold" uses the same settings as the "novb" curve in the graph

i.e. a libaom build from a week ago, before all the improvements

alright, I was just thrown off by that name lol

you can tell many improvements happened in rapid fire <:kekw:808717074305122316>

same settings, but is it the same build as novb?

different builds novb: https://aomedia.googlesource.com/aom/+/2cca4aba034f99842c2e6cdc173f83801d289764 newer: https://aomedia.googlesource.com/aom/+/1c53a4ce4127ebc43f8630978afe8210a6cd7b6a both used same settings: `avifenc -a color:tune=iq -s 9 <input> <output>` (equivalent aomenc command: `aomenc --allintra --tune=iq --cpu-used 9 <input> <output>`)

btw, I still recommend to use at least `-s 6` if possible -- higher speeds are meant for super high-throughput scenarios (like CDNs)

i'm just trying to confirm whether the picture you posted is something represented by novb on that graph

correct, the picture on the left represents novb

I see, that's a lot of difference behind 2 points of ssimu2

but i guess targeted fixes for the most noticeable artifacts would do that

yeah, ringing/mosquito noise only happens in like, 10% of the image on average, but it's *very* noticeable when it's there

libjxl needs people like you...

Butter and ssimu2 are supposed to represent the "worst-case" not the average.

The real reason is that "psychovisual" metrics do not do their supposed job very well and the scores are meaningless.

I'd sometimes love to split into two (fork myself?) so I could work on JXL and AV1 at the same time 😅

but I'll always support pushing the efficiency of modern codecs forward

it's time to move on from what's effectively the image version of MPEG1/2, it's 2025

hmm, ssimu2 roughly represents "2/3rds of the case", while butter can represent that and the worst case

correct me if I'm wrong <@794205442175402004>

<:JXL:805850130203934781> is the more modern and future-proof codec... with the spaghetti-code reference library.

ssimu2 uses a weighted sum of L1 and L4 norms over the various error maps. L1 is just the average, L2 is root mean square, etc. Higher norms means closer to basing the score just on the worst-case.

Butteraugli maxnorm is doing that: the worst artifact determines the whole score. Butteraugli p-norm does a weighted sum of L3, L6 and L12, as far as I understand.

The usual implementations of ssim/ms-ssim only do an L1 aggregation over the error map. The problem with that is that 'easier' images (e.g. with large solid or blurry backgrounds) will get higher scores even if the quality of the region of interest is actually low.

I've examined the SSIM, file size, and 'quality value' for the Lena image using a new JPEG encoder. Do you think the quality is good?

SSIM is not a great metric. For example, it is color blind: you can literally make the image black&white without affecting the score.

This also has nothing to compare against. I think it's good? But I don't have my JPEG encoder benchmark results learnt off by heart, yet

I was make new graph. To compare with mozjpeg

Testing just on the Lena image is not a particularly great way of testing things. In particular because that image is an old scan of an old printed magazine picture, so it is not very representative of modern digital images.

What is this new encoder? jpegli or something else entirely?

I developed my own new JPEG encoder.

Mozjpeg is tuned for PSNR-HVS by default iirc, not for SSIM. Which particular implementation of SSIM are you using here? (there are large differences between different SSIM implementations, e.g. the Matlab version vs the libvmaf one are very different)

I used ffmpeg

For SSIM measurements

Currently as far as I know, the best metrics (for SDR images) are CVVDP, IW-SSIM, SSIMULACRA 2 and Butteraugli pnorm.

Interesting! Is it a fork of one of the existing encoders or something new from scratch?

How does it compare to jpegli

Feels like an odd decision when JPEG XL has already been available for quite a while, unless wavelets specifically help EXR for some reason https://github.com/AcademySoftwareFoundation/openexr/pull/1883

Actually, aren't they in this server? I won't disturb them but it feels like shooting yourself in the foot to start adopting the previous (Equally if not more obscure) format when the new one is already out

Read the evaluation, and every benefit of J2K is covered by JXL. Wonder if it also matches the performance

Thinking about it... Why wedge another image format inside of EXR at all? Seems like they're ending up with a new TIFF

I know that J2K is used in some specific medical fields

so maybe he's trying to address adding support from that angle?

JPEG XL is also in DICOM medical specification though

And I can't see what kind of market they're aiming for that would add J2K support but not JXL

Maybe simply because wavelets are cool

it's recommended to use something like [SSIMULACRA 2](https://github.com/cloudinary/ssimulacra2) instead of SSIM for measurements/comparisons

Thank you. I'll try

when will they make a jpeg encoder that is better than webp? <:Stonks:806137886726553651>

They already did, it's called JPEGLI

no

For artwork WebP does better, but for photos I perfer using Jpegli

interesting opinion... because I don't choose what to use, all the photos that I would save, and all the art, they are already compressed, and drop somewhere on the Internet, there is no choice here

I don't understand at all what you can choose here. Only if you make your personal archives of your photos - but why in that case not save the originals source

Lossless is my usual choice for storage, but I do compress things when I post online.

My personal experience shows that Jpegli is on par or better than WebP for lossy non-Alpha images

This doesn't count Jpegli embedded with XYB

yeah I've seen jpegli be subjectively better than webp above medium fidelity on photographic images

it is reproducible in some metrics; I think on Daala subset1, they are matched up to SSIMU2 <50 where WebP takes over

My usages are mainly for converting lossless ||NSFW|| artworks to lossy

||Noodles, Sandwiches, Falafels, Wontons|| photos? You're like a food photographer?

Yeah I took a lot

sounds very *tasty*

@mod

<@794205442175402004> malicious ad

oh my bad, someone already pinged admins in another channel

No worries

well.. um... no... jpegli sucks. completely. What kind of nonsense are? it has the same problems with color faden as jpeg xl and AVIF. Regular mozjpeg not only gives a sharper picture with the same file size, but also save colors...

this is all some kind of nonsense

What I mean is that webp is not only more sharper, but also has zero problem with colors

Ah yes, quite a normal photographic image. Pure yellow noise. Anyways, the desaturation of yellows is an issue with XYB, not jpegli. Using regular YUV results in proper yellow preservation.

(except for the complete absence of yuv444 of course)

Compressed at distance 3

the yellow is preserved

yes, I also noticed that apparently, as far as I can judge, the biggest problem with Jpeg XL as a codec is the use of XYB -- is that what you mean?

distance 3 ? how much is this in quality? now i use the encoder which is in XnView and i see fading both on q50 and q80

Is it the biggest problem in JXL? I don't think so, it's fixable. I would say google chrome not adopting it is the biggest problem in my opinion. Can't fix office politics. <:kekw:808717074305122316> 😅 Distance 3 = quality 68

Also just use the CLI tools, I don't trust other programs to properly encode my images.

Well, I agree with you on this one

I wonder how much does converting an image to XYB affect a jpegli image? is it even necessary? is it an option? I didn't get that point

ok i downloaded the latest jpeg xl from cjpegli and in yuv444 rgb mode there are no big problems with colors, but the original problem remains -- this picture is worse in quality than what i get in mozjpeg in terms of actual amount of details

although of course on gradients everything looks great. but somehow it is not serious, there is no superiority

More efficient compression ideally, since it's closer to human perception. Images with XYB usually score higher on metrics and look better on photographs. But there is an issue with XYB desaturating strong vibrant yellows. Which is obviously apparent if your entire image is yellow. I made a Github issue here: https://github.com/libjxl/libjxl/issues/3616

I want to note that when I use, for example, **guetzli**, I really see that same superiority that I am talking about, that the result is really at the theoretical limit, and jpegli is something that I am kind of disappointed with

The adaptive quantizaion in jpegli tends to blur the image, which I really don't like so I turn it off using `--noadaptive_quantizaion`. I have visual results here https://discord.com/channels/794206087879852103/1301682361502531594

hmm, it's even funny that I've been talking about this problem here for 3 years already

and yet nobody made an issue until I came along 😅

this is indeed a solution and it helps. But unfortunately it is not enough. Although they are ""equal"" in quality, for some reason I can still see a better image here

Also, can you send me more images like this? Jonnyawsom3 and I are going to talk to the JXL devs to try to address this color problem. I might even post some examples on the Github to get the ball rolling.

No, I notice jpegli has the same desaturation issue as libjxl, and I don't remember for sure if the issue also applies even without the xyb mode