[X] My Assistant

As for why they swung hard for it as opposed to JXL? I'll admit I have no idea. Haven't read up enough on it to formulate a schizo theory. :^)

I admittedly had never heard of JXL until people started mentioning it in this topic, which means most of my info is just going to come from stuff like the JPEG XL Wikipedia article:

"The Chrome team cited a lack of interest from the ecosystem, insufficient improvements, and a wish to focus on improving existing formats as reasons for removing JPEG XL support."

Which, I mean... Yeah, if nobody adds support for it, the ecosystem won't really be that interested. Catch-22. Part of the reason getting buy-in from big players to start with is so important. Either way, the reasons given are at least somewhat reasonable - and not mutually exclusive with the various conspiracy theory stuff either, so not much to glean. It could really be anything, so whatever someone's personal theory is could be right.

I actually find this more interesting, honestly:

"Mozilla expressed security concerns, as they feel that the rather bulky reference decoder would add a substantial amount of attack surface to Firefox. They expressed willingness to ship a decoder that meets their criteria if someone provides and integrates a suitable implementation. The JPEG XL team offered to write one for them in the memory-safe Rust language."

That's a rather... realistic concern. One entirely unrelated to the feature set of the format itself (ie if it's N% faster, N% smaller, lossless, etc). And if the (relatively speaking) brand new JXL decoding code were found to have an exploitable bug in it, that would be kinda a big deal.

Sure, that's Mozilla, not Google. But I guess my point is, the reasoning and discussion behind these kinds of decisions can be a whole lot more nuanced. (And why I find the immediate jump to schizo theories so amusing.)

In their defense, 100,000 lines of C++ really is a massive attack surface that would almost certainly hide multiple exploitable RCEs that would show up to bite them in the ass for years to come. So I can't blame either party for refusing to include that.

Was it the Photos app or the legacy Windows 7 photo viewer? You should report to Microsoft so they can fix it if it's the former, but I don't think the latter is still supported.

Edit: Found [www.winhelponline.com] this.
It seems the Microsoft WebP Extension may cause images to be darker in the legacy photo viewer, the solution is to uninstall that and install Google's WebP Codec (instructions in that post).

Actually, I can confirm that the issue still persists in Windows 11 23H2, and replacing the Microsoft WebP Extension with the Google one did fix it.
I mean, I kinda get that the legacy photo viewer is discontinued, but shame on you, Microsoft.

In their defense, 100,000 lines of C++ really is a massive attack surface that would almost certainly hide multiple exploitable RCEs that would show up to bite them in the ass for years to come. So I can't blame either party for refusing to include that.

Its still a hugely complicated library, but 100k loc is a bs argument by Mozilla. It includes the encoder, jpegli, and everything else unrelated to the decoder itself in the reference library.
The google research team is working on a rust implementation now, which should make the people at Mozilla happy at least.

This post has been edited by -terry-: Nov 20 2024, 10:27

Its still a hugely complicated library, but 100k loc is a bs argument by Mozilla. It includes the encoder, jpegli, and everything else unrelated to the decoder itself in the reference library.
The google research team is working on a rust implementation now, which should make the people at Mozilla happy at least.

I mean, I didn't exactly download it and count lines. But that's literally what they said, [github.com] on the relevant Mozilla page - they said the "decoder" was "more than 100,000 lines". With the amount of numbers and formal dialog there, I would have to assume that if the figure was significantly wrong, someone would have corrected it.

Also another interesting thing (from [github.com] an earlier discussion in the same area):

"The difference is that the support cost (maintenance, attack surface, code size) for a video-derived codec is much lower, because browsers ship the associated codec already for video decoding. AVIF support in Firefox weighs in at about 1k lines of straightforward glue code. JPEG-XL is roughly 100k lines of multi-threaded C++."

So part of the reason the JXL decoder is so "heavy" is because it can't reuse someone else's homework like AVIF can.

Was about to reply https://forums.e-hentai.org/index.php?showtopic=281301 but that one got closed, so I guess I just put it here:

For MangaMeeya, there's a third-party plugin that adds WebP support: [toroidj.github.io] WebP Susie Plug-in
Or you can use the WIC plugin if you've already installed the [storage.googleapis.com] WebP Codec: [toroidj.github.io] WIC Susie Plug-in

Usage: Extract iftwebp.spi/iftwic.spi to MangaMeeya's SusiePlugin folder

Webp performs poorly with images of real people, especially widescreen images.

Webp performs poorly with images of real people, especially widescreen images.

Good job this is a hentai manga site then, huh.

It's not performing poorly, they really are 3DPD.

Webp performs poorly with images of real people, especially widescreen images.

You just need to use sharp yuv while encoding. It increases encode time (negligible on modern computers) and file sizes by like 2-5%, but there's a very noticeable quality increase. Especial the more you lower the quality.

here's a random blog post on the topic:
[www.ctrl.blog] Enable the sharp YUV option for better WebP images

Webp performs poorly

You just need to use sharp yuv while encoding. It increases encode time (negligible on modern computers) and file sizes by like 2-5%, but there's a very noticeable quality increase. Especial the more you lower the quality.

here's a random blog post on the topic:
[www.ctrl.blog] Enable the sharp YUV option for better WebP images

webp always uses yuv420, which means that the color loss will be much higher.
If this option can reduce the color loss, it will definitely be worth it!

If we intended/prefer to read the 1280x resampled pic, that means we actually not really fussy about the quality. So why make this change compulsory and permanent?
Exaggeratedly, I smell technological autocracy lol

This post has been edited by youaregreat: Dec 10 2024, 12:19

That isn't the case for guests/users without necessary perks

"Not being fussy" doesn't mean that's it's not a consideration at all. It's not binary, where you're either perfect lossless or you're everything else with all forms of lossy having equal merit. It's a sliding scale.

The goal obviously isn't "absolute best quality at 1280", otherwise we'd be using lossless. So it's a tradeoff between filesize and image quality. And according to the numbers given (whether this thread or others), the switch to WEBP was made because it simply provides a better tradeoff - higher quality at the same filesize, or lower filesize at equivalent quality.

A discussion can be had about support, with old browsers or unmaintained readers. A discussion can also be had on alternative similar formats, like JXL. Whether people will agree with you on those is another question, and Tenboro has seemingly made his stance pretty clear at this point, but at least it's a discussion to be had.

But comparing JPG on filesize/quality metrics to WEBP isn't really even a discussion. It's just a straight upgrade.

Jumping on the "I don't want new default image formats forced on me" bandwagon.

At least make an option to convert files in both original and resampled archives to any of the supported formats that includes jpg and png, before downloading. That way no one's getting mad over this tiny issue in the first place.
But if the guys in charge of e-hentai want to persist on their webp updates despite the valid criticism, then all you've been doing pushing this webp as the end-all-be-all format is gonna blow up in your faces sooner or later.

Don't say I didn't warn you.
(IMG:[invalid] style_emoticons/default/lurk.gif)

I think we've heard enough about this. Final answers have been made.

/thread