There is a hotfix to mitigate a security problem with WebP in Fireox and
Thunderbird. Also see:

<https://www.bleepingcomputer.com/news/security/mozilla-patches-firefox-thunderbird-against-zero-day-exploited-in-attacks/>

--
Arno Welzel
https://arnowelzel.de

Arno Welzel <usenet@arnowelzel.de> wrote:

> There is a hotfix to mitigate a security problem with WebP in Fireox
> and Thunderbird. Also see:
>
> <https://www.bleepingcomputer.com/news/security/mozilla-patches-firefox-thunderbird-against-zero-day-exploited-in-attacks/>

Google code: https://chromium.googlesource.com/webm/libwebp
Mirrored at: https://github.com/webmproject/libwebp

Didn't find a ticket for the defect at:

https://bugs.chromium.org/p/webp/issues/list

but I didn't look very hard. It's Google codec. It's Google's fault.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4863
https://digital.nhs.uk/cyber-alerts/2023/cc-4376

While the Bleeping article makes it look like Mozilla's fault, their
"patch" would be to deploy the updated libwebp codec from Google.
Google fixed their libwebp codec, and Mozilla incorporated it in an
update.

The vulnerability affects ALL software that uses Google's libwebp, not
just web browsers.

On 9/13/23 13:41, this is what VanguardLH wrote:
> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> There is a hotfix to mitigate a security problem with WebP in Fireox
>> and Thunderbird. Also see:
>>
>> <https://www.bleepingcomputer.com/news/security/mozilla-patches-firefox-thunderbird-against-zero-day-exploited-in-attacks/>
>
>
> Google code: https://chromium.googlesource.com/webm/libwebp
> Mirrored at: https://github.com/webmproject/libwebp
>
> Didn't find a ticket for the defect at:
>
> https://bugs.chromium.org/p/webp/issues/list
>
> but I didn't look very hard. It's Google codec. It's Google's fault.
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4863
> https://digital.nhs.uk/cyber-alerts/2023/cc-4376
>
> While the Bleeping article makes it look like Mozilla's fault, their
> "patch" would be to deploy the updated libwebp codec from Google.
> Google fixed their libwebp codec, and Mozilla incorporated it in an
> update.
>
> The vulnerability affects ALL software that uses Google's libwebp, not
> just web browsers.
And I got an update to Google Chrome this AM and Ant just posted release notes for Thunderbird. I'm guessing Firefox
will be hot on it's heels.
--
Linux Mint 21.2 Cinnamon
Al

Big Al wrote:
>> The vulnerability affects ALL software that uses Google's libwebp, not
>> just web browsers.

> And I got an update to Google Chrome this AM and Ant just posted release
> notes for Thunderbird.  I'm guessing Firefox will be hot on it's heels.

Both Firefox and Thunderbird released fixes yesterday.

As I'm doing run-downs of updates, I see new versions of Chrome, Edge
and Opera all released also.

Smith

On Wed, 13 Sep 2023 12:41:57 -0500, VanguardLH wrote:

> Didn't find a ticket for the defect at:
>
> https://bugs.chromium.org/p/webp/issues/list
>
> but I didn't look very hard.

Chromium bug reported to be at <https://crbug.com/1479274>
or <https://bugs.chromium.org/p/chromium/issues/detail?id=1479274>
(bug only visible to those with permission).

> It's Google codec. It's Google's fault.

--
Kind regards
Ralph Fox

‪“𐌀𐌖𐌕 𐌖𐌉𐌀𐌌 𐌉𐌍𐌖𐌄𐌍𐌉𐌀𐌌 𐌀𐌖𐌕 𐌅𐌀𐌂𐌉𐌀𐌌.” -- 𐤇𐤍𐤁𐤏𐤋 𐤁𐤓𐤒

VanguardLH, 2023-09-13 19:41:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> There is a hotfix to mitigate a security problem with WebP in Fireox
>> and Thunderbird. Also see:
>>
>> <https://www.bleepingcomputer.com/news/security/mozilla-patches-firefox-thunderbird-against-zero-day-exploited-in-attacks/>

[...]

> While the Bleeping article makes it look like Mozilla's fault, their
> "patch" would be to deploy the updated libwebp codec from Google.

The article refers to
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4863> which is
*not* Mozilla.

> The vulnerability affects ALL software that uses Google's libwebp, not
> just web browsers.

Correct.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel <usenet@arnowelzel.de> wrote:

> VanguardLH, 2023-09-13 19:41:
>
>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>
>>> There is a hotfix to mitigate a security problem with WebP in Fireox
>>> and Thunderbird. Also see:
>>>
>>> <https://www.bleepingcomputer.com/news/security/mozilla-patches-firefox-thunderbird-against-zero-day-exploited-in-attacks/>
>>
>> While the Bleeping article makes it look like Mozilla's fault, their
>> "patch" would be to deploy the updated libwebp codec from Google.
>
> The article refers to
> <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4863>
> which is *not* Mozilla.

It was the title of the article that was misleading by mentioning only
Mozilla products. ANYTHING using Google's libwebp codec was vulnerable.
That means Google's Chrome, probably Chromium, Firefox, probably every
web browser variant, any local image rendering clients, and anything
else using Google's libwebp codec. They all have to incorporate the
patched version of the codec. Those that implement their own WebP code
are unknown for vulnerability.

>> The vulnerability affects ALL software that uses Google's libwebp, not
>> just web browsers.
>
> Correct.

https://en.wikipedia.org/wiki/WebP

Is another image format really needed? Seems Google just wants to push
something they created, like when Microsoft tried to push XPS to replace
PDF. Even if the compressed version of WebP makes for a smaller file to
speed transfer from server to client, how many folks are still back on
9.6 kbps, or less, dial-up?

On Thu, 14 Sep 2023 16:36:32 -0500, VanguardLH wrote:
> Even if the compressed version of WebP makes for a smaller file
>

And that's a big *if*. It's not unusual to find, when I
open a downloaded .webp in Irfanview and then save it
as .jpg, that the saved file is smaller.

--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...

VanguardLH, 2023-09-14 23:36:

[...]
> https://en.wikipedia.org/wiki/WebP
>
> Is another image format really needed? Seems Google just wants to push
> something they created, like when Microsoft tried to push XPS to replace
> PDF. Even if the compressed version of WebP makes for a smaller file to
> speed transfer from server to client, how many folks are still back on
> 9.6 kbps, or less, dial-up?

Well - when you serve millions of users saving 20-50% of data *is* a big
thing. And this is the expected saving when using WebP instead of JPEG.

--
Arno Welzel
https://arnowelzel.de

Stan Brown, 2023-09-16 08:53:

> On Thu, 14 Sep 2023 16:36:32 -0500, VanguardLH wrote:
>> Even if the compressed version of WebP makes for a smaller file
>>
>
> And that's a big *if*. It's not unusual to find, when I
> open a downloaded .webp in Irfanview and then save it
> as .jpg, that the saved file is smaller.

Then you use a very low quality setting for the JPEG. Usually WebP can
be up to 50% smaller at the *same* quality. Of course reducing JPEG to
30-50% quality level instead of 70-90% will make it smaller, but
depending on the content will also see this with more visual artifacts.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel <usenet@arnowelzel.de> wrote:

> VanguardLH, 2023-09-14 23:36:
>
>> Is another image format really needed? Seems Google just wants to
>> push something they created, like when Microsoft tried to push XPS
>> to replace PDF. Even if the compressed version of WebP makes for a
>> smaller file to speed transfer from server to client, how many folks
>> are still back on 9.6 kbps, or less, dial-up?
>
> Well - when you serve millions of users saving 20-50% of data *is* a
> big thing. And this is the expected saving when using WebP instead of
> JPEG.

You mentioned setting the resolution for the saved .webp image file. I
never see an option to set the WebP resolution. You sure WebP isn't
fixed (in that the user has no choice) on resolution? Then the
comparison becomes how much compression you configure during a JPEG save
to equate to the file size of a WebP image file to know just how much
loss you incur continuing to use JPEG.

WebP is described as adaptive, so the compression level is unknown to
the user viewing the image files to know how to compare against JPEG
compression levels. The image author using WebP decides whether to use
lossy or lossless compression. Lossy compression is based on VP8 key
frame encoding. Lossless compression is proprietary, and why you need
Google's codec to decode.

Google's claim is "WebP images are about 30% smaller in size compared to
PNG and JPEG images at equivalent visual quality." Has anyone tested
their claim on a worldwide impact status to verify your claim that WebP
is saving a huge amount of disk space on the file servers?

Then you inflict the requirement that all viewers of WebP image/video
files must also have a copy of Google's codec. Another codec to manage,
and to update, and another exploit vector for vulnerability.

If WebP is so great for the Internet to conserve disk space and
bandwidth, why aren't online file storage providers (e.g., imgur.com,
flickr.com) converting all uploaded images to WebP format? Why aren't
smartphones saving to WebP?

VanguardLH <V@nguard.LH> wrote:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> VanguardLH, 2023-09-14 23:36:
>>
>>> Is another image format really needed? Seems Google just wants to
>>> push something they created, like when Microsoft tried to push XPS
>>> to replace PDF. Even if the compressed version of WebP makes for a
>>> smaller file to speed transfer from server to client, how many folks
>>> are still back on 9.6 kbps, or less, dial-up?
>>
>> Well - when you serve millions of users saving 20-50% of data *is* a
>> big thing. And this is the expected saving when using WebP instead of
>> JPEG.
>
> You mentioned setting the resolution for the saved .webp image file. I
> never see an option to set the WebP resolution. You sure WebP isn't
> fixed (in that the user has no choice) on resolution? Then the
> comparison becomes how much compression you configure during a JPEG save
> to equate to the file size of a WebP image file to know just how much
> loss you incur continuing to use JPEG.
>
> WebP is described as adaptive, so the compression level is unknown to
> the user viewing the image files to know how to compare against JPEG
> compression levels. The image author using WebP decides whether to use
> lossy or lossless compression. Lossy compression is based on VP8 key
> frame encoding. Lossless compression is proprietary, and why you need
> Google's codec to decode.
>
> Google's claim is "WebP images are about 30% smaller in size compared to
> PNG and JPEG images at equivalent visual quality." Has anyone tested
> their claim on a worldwide impact status to verify your claim that WebP
> is saving a huge amount of disk space on the file servers?
>
> Then you inflict the requirement that all viewers of WebP image/video
> files must also have a copy of Google's codec. Another codec to manage,
> and to update, and another exploit vector for vulnerability.
>
> If WebP is so great for the Internet to conserve disk space and
> bandwidth, why aren't online file storage providers (e.g., imgur.com,
> flickr.com) converting all uploaded images to WebP format? Why aren't
> smartphones saving to WebP?

When you start to hunt around to learn more about WebP, it isn't all
good news. For starters, online images are rarely high-quality images.
Also, do WebP images gradually paint during rendering as do PNG? With
PNG, the viewer sees there is an image although it may not yet be
completely painted, but they know it's there, and can decide to wait, or
they're not interested in the huge image and instead move on.

https://www.smashingmagazine.com/2015/10/webp-images-and-performance/
(dated 2015, so comments about web browser support are inaccurate)

Besides the pros and cons mentioned, they also mention that comparing
compression levels between JPG and WebP is misleading. You can only
compare low compression levels (as in 70%, and above) between JPG and
WebP. Below that and WebP degrades pretty fast.

Compression settings don’t match up one-to-one with JPEG. Don’t expect
a 50%-quality JPEG to match a 50%-quality WebP. Quality drops pretty
sharply on the WebP scale, so start at a high quality and work your
way down.

Seems the real winner advantage of WebP is when compared to PNG which is
used a lot at web sites due to the gradual rendering to show an image
rather than dumping a placeholder for the image until whenever the image
file shows up.

WebP supports animation. When compared to GIF, lossy WebP takes 2.2
times longer to decode as GIF while lossless WebP takes 1.5 times longer
than GIF. The flip side is, yes, animated WebP is smaller than animated
GIF: animated lossy Webp is 64% smaller, and animated lossless WebP is
19% smaller. (https://developers.google.com/speed/webp/faq)

Then there's compatibility with web browsers. WebP was not ubiquitous,
and still isn't. Plus, some users stick with older versions of web
browsers, because they don't care for design changes made by the web
client authors, especially regarding features those users still want.

https://blog.tinify.com/pros-and-cons-webp-images/

That has a chart of when WebP support was added to various web browsers.
Not all variants of each web engine is presented, so you'd have to check
if WebP is supported, and to which level (lossy vs lossless, animated)
in your particular choice of web browser. Some folks are left out.

And, of course, we now have to deal with upgrading any software using
the WebP codec to eliminate the new vulnerability. Wonder how fast all
the software using libwepb will get updated.

On 9/17/2023 1:27 PM, VanguardLH wrote:
> VanguardLH <V@nguard.LH> wrote:
>
>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>
>>> VanguardLH, 2023-09-14 23:36:
>>>
>>>> Is another image format really needed?

You can tell this is a disease...

https://en.wikipedia.org/wiki/WebP

when you look at "how many new formats are trying
to ride off the coattails of movie formats". And
as one critic put it there

arguing instead that "good psycho-visual optimizations
are more important than anything else for compression"

some of these concepts have "weird looking pictures"
when you examine them.

JPEG is partially based on "what info can you throw away
that preserves the information a human could use". It was
a purpose built effort, not a bodge.

Paul

On Sun, 17 Sep 2023 15:40:06 +0200, Arno Welzel wrote:
> Stan Brown, 2023-09-16 08:53:
>
> > [quoted text muted]
> >
> > And that's a big *if*. It's not unusual to find, when I
> > open a downloaded .webp in Irfanview and then save it
> > as .jpg, that the saved file is smaller.
>
> Then you use a very low quality setting for the JPEG.

Nope. 85%

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown, 2023-09-18 05:54:

> On Sun, 17 Sep 2023 15:40:06 +0200, Arno Welzel wrote:
>> Stan Brown, 2023-09-16 08:53:
>>
>>> [quoted text muted]
>>>
>>> And that's a big *if*. It's not unusual to find, when I
>>> open a downloaded .webp in Irfanview and then save it
>>> as .jpg, that the saved file is smaller.
>>
>> Then you use a very low quality setting for the JPEG.
>
> Nope. 85%

At 85% jpeg is usually bigger then WebP with the same quality.

--
Arno Welzel
https://arnowelzel.de

VanguardLH, 2023-09-17 18:59:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> VanguardLH, 2023-09-14 23:36:
>>
>>> Is another image format really needed? Seems Google just wants to
>>> push something they created, like when Microsoft tried to push XPS
>>> to replace PDF. Even if the compressed version of WebP makes for a
>>> smaller file to speed transfer from server to client, how many folks
>>> are still back on 9.6 kbps, or less, dial-up?
>>
>> Well - when you serve millions of users saving 20-50% of data *is* a
>> big thing. And this is the expected saving when using WebP instead of
>> JPEG.
>
> You mentioned setting the resolution for the saved .webp image file. I

No - where did I do this? I just mentioned, that WebP files with be
smaller when providing the same visual quality compared to JPEG.

Also see:

<https://developers.google.com/speed/webp/docs/c_study?hl=en

> never see an option to set the WebP resolution. You sure WebP isn't
> fixed (in that the user has no choice) on resolution? Then the

No. WebP images can have any resolution up to 16383x16383:

Also see
<https://developers.google.com/speed/webp/faq?hl=en#what_is_the_maximum_size_a_webp_image_can_be>

[...]
> Google's claim is "WebP images are about 30% smaller in size compared to
> PNG and JPEG images at equivalent visual quality." Has anyone tested
> their claim on a worldwide impact status to verify your claim that WebP
> is saving a huge amount of disk space on the file servers?

Yes.

> Then you inflict the requirement that all viewers of WebP image/video
> files must also have a copy of Google's codec. Another codec to manage,
> and to update, and another exploit vector for vulnerability.

Well - I don't know of any browser which does *not* support WebP (except
IE which is dead anyway). So there is no option to avoid that codec anyway.

Also see:

<https://caniuse.com/?search=webp>

> If WebP is so great for the Internet to conserve disk space and
> bandwidth, why aren't online file storage providers (e.g., imgur.com,
> flickr.com) converting all uploaded images to WebP format? Why aren't
> smartphones saving to WebP?

I don't know. But in fact for WordPress there are plugins which do
exactly that, like this one:

<https://wordpress.org/plugins/webp-express/>

And using a converter server side which creates WebP for those browser
which support that, is a real method for optimizing stuff.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel <usenet@arnowelzel.de> wrote:

> VanguardLH:
>
>> Has anyone tested [Google's] claim on a worldwide impact status to
>> verify your claim that WebP is saving a huge amount of disk space on
>> the file servers?
>
> Yes.

Okay, I'll qualify. Has anyone other than Google verified Google's
claims? If you know, please provide URLs as I'd like to read those
independent studies. I'm not averse to learning more.

On 10/16/23 10:01, VanguardLH wrote:
> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> VanguardLH:
>>
>>> Has anyone tested [Google's] claim on a worldwide impact status to
>>> verify your claim that WebP is saving a huge amount of disk space on
>>> the file servers?
>>
>> Yes.
>
> Okay, I'll qualify. Has anyone other than Google verified Google's
> claims? If you know, please provide URLs as I'd like to read those
> independent studies. I'm not averse to learning more.

Here's my survey of 1:

3.7M Nov 12 2021 20211111_184609.jpg
2.9M Oct 16 10:05 20211111_184609.webp

100% lossless selected (default was 90) using GIMP

So the potential to save space is there.

Rinaldi

VanguardLH, 2023-10-16 17:01:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> VanguardLH:
>>
>>> Has anyone tested [Google's] claim on a worldwide impact status to
>>> verify your claim that WebP is saving a huge amount of disk space on
>>> the file servers?
>>
>> Yes.
>
> Okay, I'll qualify. Has anyone other than Google verified Google's
> claims? If you know, please provide URLs as I'd like to read those
> independent studies. I'm not averse to learning more.

Then look for yourself:

<https://www.google.com/search?q=webp+jpeg+comparison>

--
Arno Welzel
https://arnowelzel.de

Arno Welzel <usenet@arnowelzel.de> wrote:

> VanguardLH, 2023-10-16 17:01:
>
>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>
>>> VanguardLH:
>>>
>>>> Has anyone tested [Google's] claim on a worldwide impact status to
>>>> verify your claim that WebP is saving a huge amount of disk space on
>>>> the file servers?
>>>
>>> Yes.
>>
>> Okay, I'll qualify. Has anyone other than Google verified Google's
>> claims? If you know, please provide URLs as I'd like to read those
>> independent studies. I'm not averse to learning more.
>
> Then look for yourself:
>
> <https://www.google.com/search?q=webp+jpeg+comparison>

I already found those articles describing what is Webp, and extoling the
size reduction. I was looking for a more thorough, in-depth, and
technical analysis of quality and compression based on file size,
content, compression levels, where quality falls off for Webp at which
compression levels (I mentioned one article), along with the typical
sizes of images used in web pages. And something indendepent of
articles regurgitating Google's claims.

Remember yenc for binary Usenet posts. Its author discarded that scheme
as unreliable. Someone else stole, er, grabbed the code, because it
shaved some size off the binaries in Usenet. It was a crappy encoding,
but it /mostly/ worked. Just because it reduced attachment size (which
gets bloated due to conversion from binary to long text strings) wasn't
sufficient reason it should become a standard compression method. Base
64 was the standard. yEnc was a ... <censored>. That yEnc enjoyed
popularity didn't mandate it was a good compression scheme.

Also remember that Webp is not just employed in web servers and rendered
by web browsers. For anyone saving images from the web, their photo
store probably has lots of .webp image files. Users may not want to get
stuck having to rely on a web browser as the image handler for .webp
files. While Webp seems [now] ubiquitous across web browsers, image
viewing is not solely the domain of web browsers.

VanguardLH, 2023-10-17 22:19:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> VanguardLH, 2023-10-16 17:01:
>>
>>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>>
>>>> VanguardLH:
>>>>
>>>>> Has anyone tested [Google's] claim on a worldwide impact status to
>>>>> verify your claim that WebP is saving a huge amount of disk space on
>>>>> the file servers?
>>>>
>>>> Yes.
>>>
>>> Okay, I'll qualify. Has anyone other than Google verified Google's
>>> claims? If you know, please provide URLs as I'd like to read those
>>> independent studies. I'm not averse to learning more.
>>
>> Then look for yourself:
>>
>> <https://www.google.com/search?q=webp+jpeg+comparison>
>
> I already found those articles describing what is Webp, and extoling the
> size reduction. I was looking for a more thorough, in-depth, and
> technical analysis of quality and compression based on file size,
> content, compression levels, where quality falls off for Webp at which
> compression levels (I mentioned one article), along with the typical
> sizes of images used in web pages. And something indendepent of
> articles regurgitating Google's claims.

Well - you could have found that:

<https://siipo.la/blog/is-webp-really-better-than-jpeg>

No, WebP is *not* *always* better. But that depends on what kind of JPEG
encoder is being used. And in my personal experience, WebP file size is
often 50% smaller without any visual quality degradation for images up
to 1920*1080. Yes, JPEG imges can also be optimized by recompressing
them using another encoder or trying a higher compression ratio. But
this often does not yield much more than 20-30% in file size and when i
have to deal with 100 images or more (which is case for a film festival
website I maintain) this becomes a lengthy and unpractical process
compared to letting the server just convert all images to WebP
automatically. Those images are not there to download but to *view*. And
since all browser support WebP, there is no issue with that.

> Remember yenc for binary Usenet posts. Its author discarded that scheme
[...]

No.

> Also remember that Webp is not just employed in web servers and rendered
> by web browsers. For anyone saving images from the web, their photo
> store probably has lots of .webp image files. Users may not want to get
> stuck having to rely on a web browser as the image handler for .webp
> files. While Webp seems [now] ubiquitous across web browsers, image
> viewing is not solely the domain of web browsers.

Please name a major image editor/view which has no support for WebP.
Even Gimp supports it:

<https://www.widsmob.com/articles/gimp-webp.html>

And if it is not clear yet: WebP is open source and everyone can just
implement it:

<https://chromium.googlesource.com/webm/libwebp>
<https://github.com/webmproject/libwebp>

--
Arno Welzel
https://arnowelzel.de

In article <kphd79FbnpqU1@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:

> Please name a major image editor/view which has no support for WebP.
> Even Gimp supports it:

> <https://www.widsmob.com/articles/gimp-webp.html>

> And if it is not clear yet: WebP is open source and everyone can just
> implement it:

> <https://chromium.googlesource.com/webm/libwebp>
> <https://github.com/webmproject/libwebp>

I use PaintShop Pro 2022 and while it will Load and Save WebP files, the
User has no available Save options to set things like Lossy or lossless
saves.

Infact, in the save dialogue for WebP files, Options is Greyed out.

D.

Dave, 2023-10-21 12:52:

> In article <kphd79FbnpqU1@mid.individual.net>,
> Arno Welzel <usenet@arnowelzel.de> wrote:
>
>> Please name a major image editor/view which has no support for WebP.
>> Even Gimp supports it:
>
>> <https://www.widsmob.com/articles/gimp-webp.html>
>
>> And if it is not clear yet: WebP is open source and everyone can just
>> implement it:
>
>> <https://chromium.googlesource.com/webm/libwebp>
>> <https://github.com/webmproject/libwebp>
>
> I use PaintShop Pro 2022 and while it will Load and Save WebP files, the
> User has no available Save options to set things like Lossy or lossless
> saves.

Then try Paint.NET - this will allow to set losless yes/no and also
quality presets like "Picture", "Photo", "Text" etc..

Paint.NET can be used for free: <https://www.getpaint.net>

--
Arno Welzel
https://arnowelzel.de

In article <kpi945Fh4jjU1@mid.individual.net>,
Arno Welzel <usenet@arnowelzel.de> wrote:
> Dave, 2023-10-21 12:52:

[Snip]

> >
> > I use PaintShop Pro 2022 and while it will Load and Save WebP files,
> > the User has no available Save options to set things like Lossy or
> > lossless saves.

> Then try Paint.NET - this will allow to set losless yes/no and also
> quality presets like "Picture", "Photo", "Text" etc..

> Paint.NET can be used for free: <https://www.getpaint.net>

Mmnn! I'm aware of what Paint.Net can do, but that's not much help when
using PSP 2022 which is my default graphics app.

In comparison of course Paint.NET is a bit of a toy app.

Thanks for the thought, appreciated.

D.

Arno Welzel <usenet@arnowelzel.de> wrote:

> VanguardLH, 2023-10-17 22:19:
>
>> Also remember that Webp is not just employed in web servers and rendered
>> by web browsers. For anyone saving images from the web, their photo
>> store probably has lots of .webp image files. Users may not want to get
>> stuck having to rely on a web browser as the image handler for .webp
>> files. While Webp seems [now] ubiquitous across web browsers, image
>> viewing is not solely the domain of web browsers.
>
> Please name a major image editor/view which has no support for WebP.

I can only test the media players that I have. Obviously I cannot test
every media player that could be obtained today, and test them all. I
also download very little graphics (images, videos), so first must be
the web browser to show that content, and web browsers now support WebP.

https://developers.google.com/speed/webp/faq

They don't list all available web browsers, but WebP support should be
rather ubiquitous for all the latest versions of web browsers by now.

https://caniuse.com/webp

There are some issues when added security is added to web browsers, like
Application Guard to Edge:

https://www.ctrl.blog/entry/windows-webp-appguard.html
https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-overview

WebP support in my media players
VideoLAN VLC: yes
MPC HC (come with K-lite codec pack): yes
XnView Classic: yes
Movies & TV app (Windows-bundled): yes
Windows Media Player: yes

That the ones I use support WebP doesn't dictate what all other viewers
support. I only have a tiny sampling. WebP is a derivative of VP8
which has been around since 2008.

Know of any sites, like caniuse, that will list the top media players
(NOT inside a web browser) that support WebP? Articles on WebP just
keep dumping me into discussions about web browsers. I can find:

https://www.makeuseof.com/windows-best-webp-image-viewers/
https://techviral.net/photo-viewer-to-open-webp-files/

and similar articles, but those only mention a few recommended viewers
for WebP. No listing of supported viewers to get a grasp on how
prevalent is WebP support amongst them.

So far, the "statistics" for asking how many blue-colored cars there are
is folks sitting alongside the street counting blue cars.