New Image format Pik beats AV1, X265 and FLIF

[Neillithan]

Okay, so disclaimer up front. The title is a bit of a clickbait. Pik is some newfangled image format aimed at replacing jpeg, which is quickly becoming a saturated arena with web browsers scratching their heads at what to do. It *doesn't* beat AV1, x265 and FLIF in *all* scenarios, but it *certainly* beats them in *most*. Also, I'm not promoting this format, I'm simply fascinated by new emerging image formats that aim to replace JPEG. Also, when I say "x265", I'm referring to the range of derivatives such as BPG, HEIF, etc.

For instance, AV1 and X265 are intended to be video codecs, aimed at providing superior motion quality, but not really aimed at providing superior static image quality. So, while they're fantastic at improving gradient quality at a tiny filesize, they're not so fantastic at preserving granular details at a tiny filesize. And don't get me started on FLIF (Great once it's loaded, terrible until it's loaded).

https://i.imgur.com/3TRUeDh.png

The Pik image format aims to be a true *lossy* JPEG replacement, and it's not without it's pros and cons.

Pros:
- Preserves granular detail such a noise.
- Preserves micro detail in a sea of gradients that would otherwise be washed out or blurred due to the rigorous gradient preservation of AV1 and x265 (things such as wires, flag poles, light poles, stars, etc).
- Significant reduction of artifacts at tiny filesize.
- Preservation of gradients and limited or no unsightly banding.
- Fast encode and decode.


Cons:
- Might be 20-50KB larger than AV1 or X265 in some instances (Proof that people don't read, so I'm bolding this text so people might read it)
- Produces a lot of unsightly artifacts around edges of objects.
- Faces adoption issues because it doesn't have the backing of several dozen companies like AV1 does, and also web browsers like Firefox are rigid unmovable giants, burdened with philosophical ideologies, that refuse to change unless Google does it first and Firefox arbitrarily decides they should plagiarize their efforts #sickburn
- Probably many years away from completion.

To view comparison images, go here: https://wyohknott.github.io/image-formats-comparison/#kopenhagen&jp2=t&pik=t

Link to the project's GitHub page. https://github.com/google/pik

[ChaosKing]

Yeah Pik has sometimes compression artefacts from hell. Compare "Cecret Lake" AV1-2018 (small) and Pik (small). Av1 blurs too much, Pik has more details. Compare also with mozjpeg, still looks ok to me!

[Andouille]

Does"PIK" support variable resolution ? (https://forum.doom9.org/showthread.php?t=175285)

[Tommy Carrot]

Pik is basically a vastly improved JPEG. It looks very similarly, with similar artifacts, just at half the size, and with some additional minor improvements (no banding). The thing is, the new formats aimed to replace JPEG can in some cases look worse than it (they tend to blur the finer details a little too aggressively). Pik is always better than JPEG, in all cases.

[ChaosKing]

http://flif.info/ has something like a variable resolution for responsive loading.

[Neillithan]

http://flif.info/ has something like a variable resolution for responsive loading.

He was trolling. :)

[Neillithan]

The one thing that confuses me, is how PIK can losslessly compress better than FLIF. That doesn't make any sense to me how they achieved that.

EDIT: Nevermind! They didn't losslessly compress PIK. They simply chose the highest quality possible and marked it as Lossless. That's a bit misleading. I found this out by reading the Notes section below on the image formats comparison page.

[Atak_Snajpera]

Yet another "amazing" picture codec trying to beat old good jpeg. There is no real need for better lossy compression in still images these days. Days of 56k dial-up modems are long gone. Most of you have 5MBps+ internet connection now (https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds). I really see no reason to compress large images to silly ~100 KiB !

[Neillithan]

Yet another "amazing" picture codec trying to beat old good jpeg. There is no real need for better lossy compression in still images these days. Days of 56k dial-up modems are long gone. Most of you have 5MBps+ internet connection now (https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds). I really see no reason to compress images to silly ~30 KiB !

As somebody who developed a website for a customer, using JPEG was a no go due to the need for alpha channel due to the background being a parallax (fixed) image. PNG was a no go because images needed to be very large, and filesize was a major problem with PNG, especially for mobile users, which can cause long load times while 300-500KB images are downloaded. If your webpage has more than (say) 10 images on it, shaving off even 100KB per image could amount to 5-10 seconds of reduced page load time per user, especially concerning mobile users.

I ended up using WebP for Chrome and Lossy PNG as a fallback for Firefox, Edge and IE users.

These new image formats all support an alpha channel. So, if you have a need for an alpha channel, but want something higher quality than WebP and you also want all web browsers to support it, then it would be good to try and get a new image format to replace JPEG and also good for all web browsers to adopt it.

Also, Netflix uses WebP for chrome users.

A lot of people think JPEG is just fine, but it's actually not, not until Elon Musk's SpaceX program starts deploying world wide, low orbit, affordable satellite internet.

So, while a replacement to JPEG would be good in the present, it'll probably become unnecessary in 15-20 years. Also, I happen to be a fan of newer, superior technologies, instead of lugging around antiquated ones for decades. Progress is good, no matter how unnecessary you might think it is. A lot of people think they're being witty, clever, or smart by mocking the existence of a newer technology, but a lot of people also happen to be ignorant morons. Coincidence?

[Clare]

The one thing that confuses me, is how PIK can losslessly compress better than FLIF. That doesn't make any sense to me how they achieved that.

EDIT: Nevermind! They didn't losslessly compress PIK. They simply chose the highest quality possible and marked it as Lossless. That's a bit misleading. I found this out by reading the Notes section below on the image formats comparison page.

Yes there's no lossless mode for PIK. And the minimum quality (small and tiny) are bigger than the other file formats so it's not comparable. Please check the filesize while comparing to see if they are actually similar.

For example in the example you've posted, you're comparing a 67.5 KiB JPEG to a 110KiB PIK.

[Neillithan]

Please check the filesize while comparing to see if they are actually similar. For example in the example you've posted, you're comparing a 67.5 KiB JPEG to a 110KiB PIK.

I mean, I did list that as a con in my OP. It's not like I didn't already know that.

Cons:
- Might be 20-50KB larger than AV1 or X265 in some instances.

You can't judge whether an image is lossless by comparing filesizes. You need some kind of understanding of how a format works, or some kind of explanation. Just simply marking it as "lossless" and then expecting people to read the notes below isn't enough to convey to people, "hey, maybe this isn't actually lossless". It's misleading. They should've labeled it as "highest Quality" for PIK instead of "Lossless" to eliminate confusion.

[iwod]

I just wish we can solve the Alpha Channel problem to. To be honest I dont see the improvement is that much, i.e I dont see a 50% reduction in bitrate compared to jpeg. I want it to look "better" then the 120KB Jpeg at 60KB. Or Sub 100KB to look better then Sub 200KB Jpeg. Currently this doesn't seems to be the case here.

and also web browsers like Firefox are rigid unmovable giants, burdened with philosophical ideologies, that refuse to change unless Google does it first and Firefox arbitrarily decides they should plagiarize their efforts

God I love this!.

[iwod]

I just spent way too much time at the Image comparison site. But I do thanks who ever is keeping that site up, brilliant place, no additional opinion or spin trying to convince you what is good or not. Just plan old information and "facts", you get to decide what you want from it. ( Which really is what journalism should be, but is not these days )

Below are my personal opinions.

Tl;dr : Mozjpeg is bloody amazing.

Firstly I am only comparing tiny and small, mainly used in certain domain.

One of the first few things I notice is how i do not prefer all the newer codec. AV1 and BPG. They wash out details. And mostly in a way I dont like. AV1 being worst, actually 2016 build wasn't that bad at all, it manage to get worst in 2017 and 2018.

Having said that, I was comparing to Original, i.e Once you knew there are stuff you missed it, the perfectionist of me didn't like it, I rather details were there not good then gone missing or being replaced. If i didn't have the original, my guess is that most would like the newer codec.

So I generally like it blocky rather then washy. Now I think this is really a matter of taste and personal preference. So may be some will prefer AV1 or BPG.

I discover the blocky issues when in some cases I prefer even the KDU over AV1. KDU was... in some way crap, but it tries to retain details whenever possible. It feels honest, so even if it looked bad, it is like telling you I am bad, instead of faking it out for you.

And my personal favourite was Daala. And I had to recheck a few times to confirm, because I wasn't expecting any decent results. Daala is now a discontinued project. And it didn't have billions of R&D, multiple years of fine tuning, it is unfinished, and no way near ready for release. So what was I expecting? Nothing. Nothing Good at all, but turns out it was the best for me.

And later I realize, KDU is actually Jpeg2000, which is a wavelet codec. The same as Daala, I wonder if this is coincidence or is wavelet better for Image encoding.

I wonder if we could continue to develop Daala just for images.

But generally I am really surprised at MozJPEG, it was very good, not the best but considering its age I was expecting all the other codec beat the hell out of it at low bitrate. And the difference turns out to be much small then what I expect, I guess I have to read up on MozJpeg. It somehow manage to optimize out the ringing issues at low bitrate, it is still there but not as annoying. The biggest limitation of Jpeg is alpha channel, which is one reason I still want jpeg to be replaced.

One of the problem with preference on blocky over washy images is when you look at photos with faces, they tend to not be as good especially at low bitrate, I wonder if some facial recognition or other tools on the encoding side might help. ( Not a big issues because higher bitrate tends to solve this problem. )

Then I remember in the era of RMVB, washy or digitally cleaned video vs x264 blocky but retained at lower bitrate. For different bitrate there is different trade off, at very low bitrate I preferred RMVB, but once Internet connection got faster and storage space becomes cheaper I much prefer x264 encoding.

I wonder if some day 5G and 6G mobile network means low bitrate usage will be a thing of the past.

[SeeMoreDigital]

67.5KB to 110KB is a difference of 63%. Which is huge!

[Neillithan]

I wonder if some day 5G and 6G mobile network means low bitrate usage will be a thing of the past.

The future is not super low bitrate, low filesize paradise. Instead, the future will be all about high resolution, HDR (10bit or greater). This comes at a significant cost.

Let's look at BMP for instance. BMP is undeniably the best quality because it's uncompressed. Anything uncompressed is highest, but then you run straight into a brick wall where, BMP is a terrible format to deliver across the internet due to bandwidth reasons. Okay, so now in this era, BMP isn't such a big problem anymore, until you start getting up into the higher resolutions. 4K+ images are insane to deliver as BMP, so we're back to hitting a brick wall.

The lesson I'm trying to get at is, just because you have improvements in network, does not mean that an unoptimized, or poorly optimized format is going to suddenly become the mainstay. If this were the case, we'd be capturing 8K resolution 60fps movies in BMP. You have hardware constraints, as well as bandwidth constraints.

Now, you might jump to PNG over BMP, but let's look at the facts there. PNG is fantastic for low to medium resolution images (basically images 2K and smaller). Once you get up to 4K, 8K, and even higher territory, no amount of PNG optimization is sufficient. You start hitting walls in both filesize, bandwidth, encode time, decode time, and all sorts of issues.

Now you have FLIF, which claims to solve all sorts of problems, but it doesn't solve the encode time, in fact it does the exact opposite by super inflating it. Saving a 4K image as FLIF takes like, 8 times longer than PNG before you apply the other crush algorithms to it.

Now, imagine an 8K resolution, 10-bit future. Should we still be using PNG for this? Absolutely not. The filesize grows exponentially. The encode and decode time grows exponentially. Everything about it grows exponentially. But with 8K HDR monitors on the horizon, the web will inevitably transition to high resolution, 16-bit images to take advantage of the higher dynamic range and pixel density. And with that, you will need to continue using a lossy format that can optimize better than current day formats.

This is why it's so important to improve upon a 2 decade old format. It doesn't help us transition to the future, in fact it hurts us.

If anybody feels like arguing, just ask yourself why HEVC exists? It exists to solve 2 problems. Enable low bitrate, low resolution situations for bandwidth limited situations, and also propel us into the future with 8K, HDR, high framerate situations.

That's why I feel like anybody mocking the existence of all these new image formats is a moron. They're so smug about it, but yet they're complete morons and just simply don't realize it.

We still have a decade or 2 left before the constraints of today cease being a major issue due to improvements in hardware and network, but solving those problems now, will enable even less saturated hardware and networks in the future, and promote further growth.

[iwod]

BMP and PNG are Lossless, so you are comparing Apple to orange.

The point is assuming all these alternative to JPEG can only do 30% improvement comparing to 1MB JPEG pics, in Web Scale, and Browser with an extremely long road to have these implemented, may be bandwidth will outshine what ever work being done. That is of course not saying alternative arent good, it is just we may have even BETTER alternative down the road.

Much like how bandwidth has improved, AAC or MP3 didn't matter much any more. We can all afford 192Kbps Streaming, and even more so once technology improves even more. We choose AAC not because MP3 is much worse, but it has its own problem like clipping and continuous playing that is inherent in the codec. Much like JPEG doesn't support Alpha Channel that cant be fix without a new codec.

That is why you see the next biggest option poll in the picture format is JPEG sticking around. Alpha Channel is mostly a web problem. For lots of other people bumping up a little more bitrate will do. Storage Price is cheap, and will only get cheaper. The roadmap for HDD wasn't clear enough before, as we have doubt on HAMR technology ever working. But WD MAMR is much simpler solution that offers up to 50TB per HDD. We have Massive MIMO that offers 3 - 5x capacity improvement, and more from LAA, 5G with NR and mmWave offers much more capacity, it is not hard to imagine your mobile phone will have a consistent connection with at least 100Mbps performance in 5 years time.

We need a alternative for Jpeg, sure, but I dont see a clear winner yet. Not one with performance, patents and other benefits that outshine Jpeg.

We have AI and machine learning improving Opus quality even more, that is in nearly 20 years with numerous codec promising mp3 128Kbps quality at 64Kbps, we finally might have one. And it is royalty free, and still Opus is not widely supported, yet.

[Neillithan]

BMP and PNG are Lossless, so you are comparing Apple to orange.

You seem to be missing my point though. As of present, the only web browser supported lossy format that supports alpha channel is WebP and it's limited to Chrome (and don't say GIF or Lossy PNG, those don't count. Reducing color palette does not work well at providing a convincing high quality result to the human eye. We need more sophisticated ways to achieve lossy without the apparent visual loss of quality).

The reason people continue to use PNG is not for its superior image quality due to it being a lossless format. People use PNG because it supports an alpha channel.

When you start saving 2K res PNGs with alpha channel, and you've applied all of the optimizations to it to crush it as small as you can get, it still comes in at a hefty filesize of 700KB-1.5MB in many instances. It's unreasonable to use PNG, yet people use it.

So, comparing an apple to an orange is ABSOLUTELY necessary in this case because 40% of browser marketshare is not google chrome, and if you're comparing the pros and cons of an image format, at some point you will have to compare PNG to WebP or PIK or some other image format because the alpha channel requires people to use PNG on browsers other than google chrome.

And besides, you're preaching to the quire here. I know the difference between a lossy, lossless, and uncompressed image format. Under normal circumstances you really shouldn't compare these formats to each other, you should normally compare "similar" formats. But for the reasons stated above, we have to do it.

We have AI and machine learning improving Opus quality even more, that is in nearly 20 years with numerous codec promising mp3 128Kbps quality at 64Kbps, we finally might have one. And it is royalty free, and still Opus is not widely supported, yet.

A lot of people can hear a difference between 128kbps and 320kbps.... so to achieve the same quality as 128kbps at 64kbps, isn't a magnificent thing. Besides, there's a HUGE fundamental difference between audio and image:

Image: we want that shit to load instantaneously, or as fast as humanly possible, so that we can see it immediately.

Audio: We want to hear this over *time*. The fantastic thing about *time* is that you can't hear 3 minutes of music instantaneously, so you can stream an audio file. It's really really easy to stream 320kbps MP3, which offers a nearly transparent (in terms of quality) listening experience. So, if you're wondering why 64kbps opus for music hasn't exactly caught on and replaced all other scenarios, this is why. It's not hard to deliver a 320kbps audio file, but it's still quite difficult to deliver a 2MB image instantaneously over the internet.

Again, you might say "comparing apples to oranges" here, but that's essentially what you did. You're relating the low adoption rate of an audio format, to the low adoption rate of an image format, and calling it a settled argument, when in actuality it's not.

There's massive room for improvement for image quality, whereas audio quality doesn't necessarily need that much improvement. I'm sure some audiophiles would disagree, but only because they don't understand the premise of my statement in regards to delivery (i.e. nearly instantaneous vs streaming)

[Snap]

You seem to be missing my point though. As of present, the only web browser supported lossy format that supports alpha channel is WebP and it's limited to Chrome.

The reason people continue to use PNG is not for its superior image quality due to it being a lossless format. People use PNG because it supports an alpha channel.

It's possible to use JPEG(s) within an SVG for lossy images with alpha transparency, either with dual images (one for image the other for the alpha mask) or combined into a single image and the image/mask areas cropped for each purpose.

So not perhaps a one-click exportable option out of an image editor but works in all browsers. The downside is it either requires extra page markup (adding the SVG code within the page), multiple files (SVG, image(s)), or to base64 the image(s) used in the SVG as a single file, the latter of which comes with its own set of varying browser support.

[Mystery Keeper]

The reason people continue to use PNG is not for its superior image quality due to it being a lossless format. People use PNG because it supports an alpha channel.
Lie. I use PNG exactly because it is lossless. And when it comes to compress artificial art with many flat areas and hard edges - it does it much much better (smaller file size) than any DCT-based compression. I would use WebP if it had wider support. I don't understand why it doesn't.

[Neillithan]

Lie. I use PNG exactly because it is lossless. And when it comes to compress artificial art with many flat areas and hard edges - it does it much much better (smaller file size) than any DCT-based compression. I would use WebP if it had wider support. I don't understand why it doesn't.

Okay, well your usage case is very specific, isn't it? Very small images under 128x128px compress very well as PNG, and images with lots of flat details compress very well as PNG. That's not exactly a future proof format if it compresses well in very few circumstances, is it? I know this because I was creating my own sprite sheet at one point, and when the icons started going above 128px, I started seeing noticeable improvements by switching to WebP. But, for the most part, smaller icons for sprite sheets compressed better as PNG.

For the sake of staying on topic, I'm mostly referring to 2K, 4K, 8K and beyond resolutions. Unless large portions of your image is flat detail, PNG is not going to fair well against a lossy format. That's just a fact.

It wasn't a lie so much as it was ignoring specific use case scenarios such as that. A lossy format would in most cases, actually, undeniably, most cases, be a better choice if you're looking for near instantaneous delivery across a network.

So while, I'll accept fault for exaggerating, I'll still be quick to point out that the context of this thread is important to understand.

And as a bonus note, a superior lossy format would be able to recognize large flat areas of detail, and target those areas with a different compression method. That would absolutely defeat PNG in that ONE usage scenario, and I see no reason why it wouldn't if properly implemented. That format doesn't happen to exist yet, so I would propose someone get to it. ;)

And one final final note:


Lie. I use PNG exactly because it is lossless. And...

If you're exclusively using lossless under any situation.... which seems to be the case because of your wording here... (I'll give you the benefit of the doubt and say maybe you just poorly worded this).... then you're not operating a website or webpage with lots of high resolution images with alpha channel, and grainy, noisy, images with micro details (i.e. photographs), with a need for those images to be delivered quickly to both desktop and mobile users. I happen to be in that situation, so using PNG would result in 700KB-1.5MB images, which is why I had to start serving WebP to chrome users, and LossyPNG to everyone else. Your situation must differ drastically from mine. And even if you (generally speaking) have no need for an alpha channel (such as the case of Netflix -even they decided WebP was a good idea for their preview images versus a different format), there are many situations in which using an alternative format other than JPG or PNG would be beneficial. I guess it depends on what your content is, how much content you have, and how you're delivering it. In which case, even with all of these "ifs", you're still better off, 90% of the time using something other than PNG for images 2K and larger. You probably fit somewhere within that 10% range, and that's being modest.

[Neillithan]

It's possible to use JPEG(s) within an SVG for lossy images with alpha transparency, either with dual images (one for image the other for the alpha mask) or combined into a single image and the image/mask areas cropped for each purpose.

So not perhaps a one-click exportable option out of an image editor but works in all browsers. The downside is it either requires extra page markup (adding the SVG code within the page), multiple files (SVG, image(s)), or to base64 the image(s) used in the SVG as a single file, the latter of which comes with its own set of varying browser support.

My experience using SVG masks has been less than satisfactory. Cumbersome, glitchy, problematic, etc. Unless you find a way to automate this process, that's more trouble than its worth.

Not to mention, I can't imagine that being more performant than an tidly packaged image with an alpha channel. SVG masks would add tons of extra crap to a web page. Oh, and the added request required to load the image mask independently from the image--no thanks. Cool idea, but I'll just wait for a better actual solution to come around.

It's like that one time when people discovered you could embed images in CSS files, and it started catching on quickly because people thought it was a fantastic new way to deliver icons, or small images. Just encode your image and plop it into CSS, that seems smart, right? Wrong, benchmarks showed that decoding an image from CSS was slower, and exponentially became slower the more images you decoded from CSS, and especially problematic on mobile (hurting battery life)... which was one of the reasons to even do this in the first place. It's hilarious. People started developing entire websites for converting images into CSS, and meanwhile, the original idea behind doing this is completely flawed. It's like a government program that has outlived its usefuless, yet continues to operate for god knows what reason.

[Snap]

My experience using SVG masks has been less than satisfactory. Cumbersome, glitchy, problematic, etc. Unless you find a way to automate this process, that's more trouble than its worth.

I've come across automated methods (http://www.useragentman.com/blog/2015/11/07/creating-alpha-channel-jpegs-using-svg/) for this. The dual images in their method could also be combined. The results are excellent imo.

SVG masks would add tons of extra crap to a web page. Oh, and the added request required to load the image mask independently from the image--no thanks.

Again, they can be combined into a single SVG file using data URIs, and then the whole SVG simply referenced like any other image in an img tag. The comment though wasn't about loading benchmarks (I'm not sure if any have been made for testing the perf difference) however, just a response wrt existing alternatives to embedding lossy graphics with alpha on sites using already supported formats.

[Neillithan]

I've come across automated methods (http://www.useragentman.com/blog/2015/11/07/creating-alpha-channel-jpegs-using-svg/) for this. The dual images in their method could also be combined. The results are excellent imo.



Again, they can be combined into a single SVG file using data URIs, and then the whole SVG simply referenced like any other image in an img tag. The comment though wasn't about loading benchmarks (I'm not sure if any have been made for testing the perf difference) however, just a response wrt existing alternatives to embedding lossy graphics with alpha on sites using already supported formats.

Just looked at the URL you posted. This is definitely *very* interesting. I can see how this would work across all browsers. Very cool.

Doesn't necessarily solve all problems but it's certainly a solution if you're wanting a cross platform solution that uses jpeg with an alpha channel.

There are 3 possible cons with this method:
1. Data URIs are slower to decode and can be battery sucker for mobile devices, at least from a CSS pov compared to <img> with a PNG or WebP source. I'm not sure of the impact of Data URIs in regards to SVGs. If you're using a lot of SVGs on one page, it could possibly become a problem.
2. Filesize might be larger than ... lets say... JPEG with an alpha channel format... not sure if Jpeg with an alpha channel format actually exists, so it would be hard to come to a conclusion about that.
3. Ease of use

I'll admit that these are pretty minor cons.


I would eventually like to see some benchmarks for webpages that make heavy use of this technique as opposed to using plain old PNG.


The solution I came up with is to just do WebP for chrome, and LossyPNG as a fallback for everyone else. I imagine Firefox will eventually support WebP - they appear to be working on it. When that day comes, nearly 70% of browser marketshare will support it. Then, it's up to edge and safari to fill the gap. I'm not getting my hopes up about that. Until then, I'm happy providing a LossyPNG fallback solution.

[foxyshadis]

Just looked at the URL you posted. This is definitely *very* interesting. I can see how this would work across all browsers. Very cool.

Doesn't necessarily solve all problems but it's certainly a solution if you're wanting a cross platform solution that uses jpeg with an alpha channel.

There are 3 possible cons with this method:
1. Data URIs are slower to decode and can be battery sucker for mobile devices, at least from a CSS pov compared to <img> with a PNG or WebP source. I'm not sure of the impact of Data URIs in regards to SVGs. If you're using a lot of SVGs on one page, it could possibly become a problem.
2. Filesize might be larger than ... lets say... JPEG with an alpha channel format... not sure if Jpeg with an alpha channel format actually exists, so it would be hard to come to a conclusion about that.
3. Ease of use

I'll admit that these are pretty minor cons.


I would eventually like to see some benchmarks for webpages that make heavy use of this technique as opposed to using plain old PNG.


The solution I came up with is to just do WebP for chrome, and LossyPNG as a fallback for everyone else. I imagine Firefox will eventually support WebP - they appear to be working on it. When that day comes, nearly 70% of browser marketshare will support it. Then, it's up to edge and safari to fill the gap. I'm not getting my hopes up about that. Until then, I'm happy providing a LossyPNG fallback solution.

WebP is a joke. It's a marginally improved JPEG at low bitrates, but it has zero quality of life features that all of the other JPEG replacements have, especially the current front-runner, HEIF. No deep color, terrible speed, mediocre interoperability, lousy efficiency, not even color profiles (making it even worse than JPEG) without nonstandard add-ons. WebP was created before Google understood anything about JPEG, when turning their VP8 acquisition into standards was all that mattered, and it deserves to wallow in obscurity. The new AV1 is shaping up to deliver a much better image codec, on par with HEIF or BPG.

SVG has been an interesting spoiler to newer codecs. It's limited to the limitations of JPEG or PNG compression efficiency, but it's able to combine both and potentially much more in the form of custom commands. It's difficult to just split a flat image into the most efficient coding format (DejaVu built a niche figuring out how to do that reasonably well), but it's easy to convert a layered image into an much more efficient and high-quality SVG, even with base-64, than forcing it to a bitmap format. SVGZ also removes most of the coding size penalty for embedding into JPEG.

[smok3]

I just wish we can solve the Alpha Channel problem to

That's one of the dumbest web problems imho and it would have been so easy, just split the bloody alpha to another image

<img rgb=image.jpg alpha=alpha.png>

Yeah, css longer than 5 lines makes me nervous.

[nevcairiel]

Please don't even suggest shit like that, having alpha in a separate source is terrible for everyone involved - not to mention that its an additional request with all the overhead that comes with that.

[smok3]

having alpha in a separate source is terrible for everyone involved
Care to explain why? Actually I'll write and email to mozila/google/apple/gates right now.
additional request with all the overhead that comes with that
Imagine situation with many buttons with different rgb and same alpha image for example.

[foxyshadis]

Please don't even suggest shit like that, having alpha in a separate source is terrible for everyone involved - not to mention that its an additional request with all the overhead that comes with that.

That's the reality of current jQuery uses though. The framework makes up for the deficiency of the format with a lot of convoluted JS and CSS.

[Neillithan]

WebP is a joke. It's a marginally improved JPEG at low bitrates, but it has zero quality of life features that all of the other JPEG replacements have, especially the current front-runner, HEIF. No deep color, terrible speed, mediocre interoperability, lousy efficiency, not even color profiles (making it even worse than JPEG) without nonstandard add-ons. WebP was created before Google understood anything about JPEG, when turning their VP8 acquisition into standards was all that mattered, and it deserves to wallow in obscurity. The new AV1 is shaping up to deliver a much better image codec, on par with HEIF or BPG.

You'll get no argument from me in regards to WebP being a less than satisfactory replacement to JPEG. I find that for most situations, 85-90% compression is good, but anything less than that and the image is destroyed and looks worse than JPEG.

The *only* reason I use WebP is because it allows me to use 2K res images with an alpha channel easily, and it noticeably beats a Lossy (Quantized) PNG. If I could achieve an acceptable result using a superior image format, I'd use it. Image formats are all feverishly trying to secure a foothold as a JPEG replacement, but web browsers are not quick to adopt.

You can absolutely count on AV1 image format becoming a JPEG replacement, and I look forward to that day. It may have some obvious cons, and may not beat PIK in terms of, noisy / grainy images... but it certainly has the potential to get adopted into Chrome, considering Google is a huge backer of AV1 and we're already seeing articles about an AV1 based image format... etc etc.... I'd like to see some more improvements to AV1 before an image format comes out, but I'll take what I can get. I'd love to start using something better than WebP.

However, many of the reasons you listed, are very minimal complaints when you consider it's the ONLY lossy image format with an alpha channel to gain a large browser marketshare (60+% for Chrome). So, while you might not think it's up to snuff as a future format, it solves a major problem right now, which is Alpha Channel in a lossy format, with a significant target audience.

So, granted, WebP is destined/doomed to obscurity, it's super nice to have right now considering the alternative is serving your audience 2MB Lossless PNGs... or 700KB Lossy PNGs - Ew.

When AV1 comes out and it's implemented into Chrome, I will begin using it ASAP while providing a LossyPNG fallback measure until other browsers fall into line.


SVG has been an interesting spoiler to newer codecs. It's limited to the limitations of JPEG or PNG compression efficiency, but it's able to combine both and potentially much more in the form of custom commands. It's difficult to just split a flat image into the most efficient coding format (DejaVu built a niche figuring out how to do that reasonably well), but it's easy to convert a layered image into an much more efficient and high-quality SVG, even with base-64, than forcing it to a bitmap format. SVGZ also removes most of the coding size penalty for embedding into JPEG.

ELI5?