I notice more sites serving webp for webkit/blink based browsers

I notice more sites serving webp for webkit/blink based browsers.

So what is the absolute state of webp at the end of 2017?

Other urls found in this thread:

bugzil.la/18574
twitter.com/NSFWRedditImage

Most image viewers / editors can't read that shit.
But hey, the image file was 14kbyte smaller, that would be a great timesaver if today's websites wouldn't load 50 MB of frameworks for everything.

It's incredibly fucking annoying as almost nothing works with webp. If I save some pic and then want to send it via some other service there's zero chance it works.

webp (lossless) is okay (better than PNG) but FLIF is even better.
webp (lossy) is shit, in fact worse than correctly cooked JPEG (mozjpeg). because it can't into full resolution chroma, and therefore it can't encode many images transparently at any quality setting.


no big deal, webp was a dud overall

I suppose it's part of google's plan to keep people from going outside of their ecosystem.

Soon we will need dedicated image decoding hardware like today's MPEG GPU decoders because no processor would be able to adequately run decompression in real-time software instructions.

Webp is an open format but apparently it's quite sophisticated in its capabilities, it's apparently on the sophistication level of a video codec. Tests done in the past have shown minimal improvements over more established and less sophisticated formats. This means that the free software writers have been hesitant to invest any more time beyond evaluating the feasibility of Webp. I'm sure if you worked with Mozilla, they'd be happy to accept patches to integrate Webp support into Gecko.

webp is proprietary (developed by google alone with no one else having a say in it) and only exists to give google unilateral control over image formats, like vp*. FLIF is the way to go.

Webp is an open format and it does pretty much everything you need. Why would you need to add anything else in a complete format?

Its not open, google alone has control over the "standard". h264 is open because it was developed by a consortium that anyone could join. You confuse open formats with open source, ooxml is "open" like wepb/webm. Licensing fees != proprietary.

Also their is merit in having different types of images be in different formats, and for everything webp does there are superior alternatives.

So it's a jack of all trades and master of none?

google has the clout to push webp though.

who will ever push FLIF?

lol
learn the topic before posting


not of all trades. but yes, the master of none.


anonymous, who else?

Mozilla doesn't want to add webp support because Google refuses to add apng and mozjpeg support to Chrome.

They also got burned by not implementing h264 because google promised they'd remove it. I bet they will bow to the G once again like the spineless traitors they are.

Stupid, pointless format is stupid and pointless. There are better animation formats (WebM for video, APNG for animation) and there are better still image formats. WebP tries to be a jack of all trades and excels at none.

Actually APNG is getting into Chrome now, and it's already in the webkit background.

H264 is not an open format because it is covered by software patents in many countries. People are required to buy H264 patents in order to work with H264 technology in those countries. Webp is different. Everybody automatically has a patent license to use Webp.


So what? It has a lossy mode, that's all it needs.

OOXML is "open" and you automatically have a license to use it. In practice everyone depends on the MS implementation, just like everyone depends on google for webp and webm. No one has a say in the development and specification of those formats, unlike with h264, which was a collaborative effort. Software patents are orthogonal to webp being proprietary (single vendor) in contrast to h264 and not a thing in civilized countries anyways.
Also if google "believe in the open source model", where is chrome's source? Or the play store's? Or the source code of their privacy-destroying and immensely profitable Services as Software Substitutes?
0.05 Play Store Coins have been deposited into your account, pajeet.

You don't know what you're talking about. Do some research first.

You know what you're talking about. Do some research first.

If I wanted to get technical that would be chromium (to a point).

That's their problem. Get better software.

They said the same about .png back when everything was .gif. Get on with the times, faggot.

No u

You don't know what you're talking about. Do some research first.

unlike PNG, WEBP doesn't solve any of the problems it was aiming for.
at most, it's a slightly more efficient than PNG lossless format. (but which, on the other hand, doesn't support higher than 8 bit sample precision)
and the lossy WEBP is a complete dud.
if anything, FLIF should be adopted by the web. and then some efficient lossy format, probably based on AV1.
and WEBP belongs to the trash.

WebP is what happens when unaccountable corporations are allowed to EEE open standards to push their own agenda of outright destroying other open standards cough bugzil.la/18574 cough

More like, no one else feels like supporting Google's "next image format", and instead want to make their own.

Anyways, I used to like the idea of WebP, but in retrospect, it doesn't do much that other (widely accepted) formats don't already do. Its improvement over PNG is nice, but its attempt to be everything can be confusing.
The main thing WebP had over its competition is lossy alpha channels, with the only alternative on non-Blink browsers is to use an SVG hack.

[Citation Needed]

Why is it important that it doesn't do much more than what already exists? From my point of view, it's trivial to pick up an existing webp implementation and add that to the list of image formats to use.

...

It's not that important for me, but like others said, it's a "jack of all" sort of format; it does everything, but there are already widely used formats that do those things, sometimes better.
Now that it's already used by more than just Google though, I don't see an issue with it getting widely adopted. Just that the format itself is mostly redundant.

It doesn't do even everything that JPEG did, because the lossy mode requires chroma subsampling. And don't try to argue that it's always invisible, I have undeniable proofs of the contrary.
Releasing such an impotent format doesn't make sense.

It supports lossy compression of images with an alpha channel
It supports GIF-like animations with 24-bit color frames that can be lossily or losslessly compressed (or even a mix of both types)
Its decoding can be offloaded to dedicated hardware on a lot of existing chips, since it's basically VP8 key frames and VP8 (as the default WEBM video codec) gets hardware decoders in most SoCs these days. This is important for mobile devices' battery life.

That's quite a few problems it does solve.

for tracking, that's how they probe your asshole and make their money, good luck getting rid of that

So does animated PNG, only it does the lossless part better. Lossy animation is a niche begging for a purpose; just use a video format if you want it lossy.

Yet it's not a proper 'superset' neither for PNG (higher bit depths), nor JPEG (full resolution chroma). The latter is a very big fuck-up, for many images the chroma subsampling alone destroys important details.
Perhaps their plan is to drive quality to shit everywhere, as the only advantage of webp lossy is that it doesn't show obvious blocks when the quality level is moved to shit and it's obviously blurred shit at this point.

In case you haven't noticed, image quality is already shit everywhere well before the existance of Webp. Webp isn't going to make it worse than it already is.

not everywhere yet.
only on high load normie friendly garbage trash cans.

THIS, especially for HEIF and BPG aka x264/x265

Noted

PNG is good

So basically webm with no audio?

Final note, VP* is not open source like x26*

FLIF and JPEG can be decompressed in reasonable time on most CPUs.