All right. In 2010, a force to be reckoned with at Google, Urs Holzle, stepped on the stage and announced something very, very important for Google.

And that was, Google was getting into the web performance business. And one of the most memorable quotes that he said at this speech was, we're going to get something very, very high here, something like 100 milliseconds. His 100 milliseconds are really, really important. After he did this, Google started announcing things.

Amongst others, the WebP image format. Show of hands, who has heard of the WebP image format? OK, cool. That's a fair bunch. Thanks. WebP was trying to be all at once. I don't know how familiar you are with normal image

formats, but like PNG8 and PNG24, GIFs that could carry animations or not, JPEGs that could encode lossy. And WebP was trying to be all at once. So what's in Germany called the Eierliegen de Volmeich now. So do it all.

So WebP tried to incorporate animation. It tried to incorporate full alpha transparency while having 24-bit colors. It tried to do complete losslessness, which is something that JPEG still has to learn to do, and a couple of other exciting features. And it basically tried to solve all the image

problems the web developer community had to complain about. So people should be excited. However, of course, there were also critiques. People said, well, Google isn't actually interested in creating anything that's good for the web. They're just interested in creating something that has more metadata so they can scan images better and create better ads.

So that's their true motivation. But I wasn't going to sit there and just take this. So I thought, OK, let's put this to the test and go and do it for science. So I randomly sampled a couple of thousand JPEGs from the internet. So this is a distribution of 12,000 randomly sampled JPEGs.

And by randomly, of course, I mean pseudo-randomly, because true random is hard. So these are just sampled from things that were accessible on port 80 and from websites that were indexed by the HTTP Archive. So this is a fair JPEG sample. But it's, of course, biased in terms

of that it's publicly accessible. What you could see here is the quality distribution of that JPEG sample. You see the usual suspects, like qualities of 75, 85, 90, and unoptimized JPEGs at 99 and 100. And this is the size distribution of that JPEG sample. Lots of files under 10 kilobytes, and then some bigger and bigger and bigger.

And then, as you see, less and less images. And then there's a bigger bunch, again, about 100k. And now let's run this 12,000 times and see how well WebP actually does in terms of compression. This is what I got out. This is a very, very nicely shaped bell curve.

And what I got here is I can show you with that bell curve that WebP on a random sample like I just created compresses about 33% better than the JPEG encoders that were used when those JPEGs were put online. So WebP sliced 33% of all of these JPEGs. That is a very, very good result.

Of course, at that time, Google wasn't the only company trying to create new standards. Google and Microsoft had been fighting for new web standards for a long time. C, Speedy, which is now becoming HTTP2. Microsoft, of course, had to announce their own thing,

because they can't just go with the flow. So what they announced was JPEG XR. So coming from high dynamic images, high dynamic range images, Microsoft created something in their own, or tried to create an own standard, and said that there was performing much, much better. The thing that JPEG XR tried to solve

is that common JPEGs only have 24 bits of color. And for some technological things, you want more color granularity. You want finer colors, better colors. You don't want the lossiness of JPEG. This is what JPEG XR tried to solve. So you can say that JPEG XR was trying to be more precise than normal JPEG.

The thing is, this is a quote from a woman working on the X264 encoder, is that if you want to create the smallest image possible, maybe image precision isn't what you should be going for. Maybe what you should be going for is that the image looks good to the human eye. And the human eye is not a very good judge in terms of is this color actually the true color or not.

Human eyes are quite susceptible to influence, which we're going to see later. So Microsoft and Google taking on a battle against each other, trying to create a new image format in 2010 and 11. Who won the race? Let's find out. Yeah, nobody. This is how WebP is supported right now.

Oh yeah, again, my apologies for the cutting off, but I was preparing for a 16 by 9 presentation. Anyway, so WebP is currently supported on everything Google. And as you can clearly see, nothing else. So everything that's currently Blink-based, Blink, you know, the new rendering engine that is under the hood of Chrome and the Android browser,

that supports WebP and Opera now too, but nothing else. And Microsoft looks even worse. Microsoft is supported on the Trident engine and the new Microsoft browser Edge, but nothing else. So, you know, you could say at the end of the day, the problem that both companies faced is that they weren't going open source enough.

Google was a little better at this than Microsoft. Google was quite quick at releasing WebP as a GPL license, I think. Microsoft's JPEG XR was caught in a lot of battles in which license to apply to it, and therefore had an even worse pickup rate, so adoption rate.

So yeah, you could say that open source might have solved this problem if they went for it fully fledged from day one. But at the end, it always reminds me of that XKCD comic about standards. You know, the companies go like, oh no, the web format for images is terrible. We need to create a new standard. And then a couple of months later, there's a new standard, and now we have like, you know, plus one standards,

but it's not really solved. So, okay, at this point in my talk, you might say, hold it right there. Why am I even listening to this? You know, storage space is cheap. Bandwidth is cheap. So the question comes to mind, why should you care? Why should you care about compression at all?

I mean, with data centers being that cheap, you know, bandwidth getting bigger and bigger, why should we care? Why are you sitting here? And I hope the answer for everybody here is, because you create for the users. You fight for the users. Because at the end of the day, what you can see is that images have a very high correlation to page load time,

and that the user experience on websites and everything gets public facing is directly impacted by low-performing images, and that's why we're trying to create high-performance images. So yes, why we could store JPEGs uncompressed on servers for cheap, shipping them to users on devices is really, really hard. And as you can see in this graph from HTTP Archive,

the websites load slowly when they have uncompressed or badly compressed images. So users hate to wait, and that's why the image compression community is working so hard to make things better. This is a graph that shows you bounces and abandonment rates from the Alexa top 2,000 websites

accumulated over a couple of years. You can see that there's a sweet spot around the one second load time, and everything else starts to accumulate abandons and then bounces and then abandonment. By the way, the difference is, bounces of course should be familiar, but abandonment means a user is not coming back

for six weeks after having bounced. So he's like a lost customer to the website. He will not convert ever properly. So as images have a very, very high correlation to page load time, you can see that creating high-performance websites and thus websites that ship high-performance images is really important to the user experience.

Which brings us to the next question. So if that's that important, what is out there that we can use? I mean, we just talked about WebP and JPEGXR. So what is out there? And I think at this time, it's time that I call it because that's what my talk is called. The king is dead, long-length the king, the king is JPEG. We can still rely on that JPEG format.

Images on websites make up 62% of all the byte data that is shipped with a common website, and JPEGs form like half of that. So they make the lion's share of all the images out there on the web. So this is why we should optimize for them. The first step we should do is try to optimize JPEG

because this will bring the biggest result. And here's the good news. JPEGs are supported everywhere. So this is Internet Explorer 2 and Netscape Navigator 2 in 1995 and 1996 respectively, and both are supporting JPEG. Isn't that fantastic? And that's all thanks to this guy, Marc Andreessen, because he put GIF support in Mosaic browser,

and then people said, well, that's kind of cool now. We can ship images. But these images look kind of grainy. We want something better, something with 24-bit color support. And this is where JPEG comes in. JPEG could do full color. And it was standardized in 1992, and was completely open source at that time.

So when the need for images arose in 1995, 1996, there was a standard available. This is why it got picked, basically. So again, yay for open source. It was here. So let's take a peek under the hood for JPEG so we understand what it actually does, so we understand how to optimize for it.

What we currently conceive as JPEGs on the internet is actually a combination of the JPEG codec for bitstream data and the file format declaration, something like Jiffy or EXIF. So the JPEG standard is actually far more comprehensive than that. But for us, for our purposes,

JPEG is formed by these two parts. And the JPEG is, this is actually freaking me out. And now it's going to freak you out, too. The JPEG standard actually specifies that an image is stored like this. So at the top right, you can see the complete image. This is the brightness map,

and then we have two color channels that form the complete image. And what few people know is JPEG is actually very, very cool because it's modeled after the human visual system. So when you look at something from 1992, you might say, wow, that's old. We should build something new. That's what Google and Microsoft did.

But the JPEG standard was actually conceived by very, very smart people. They already incorporated that the human visual system is faulty and can be tricked. So in Dungeons and Dragons terms, human vision might be plus two for brightness, but minus one for color. So human eyes are very, very good in distinguishing between differences in brightness.

But if it's exactly the XFF000 shade of red or the XFFC000 shade of red, human eye can't really see that. I mean, if you put the both colors right next to each other the human eye could differentiate. But if you give them two different samples,

you won't see anybody going like, oh, now that color is the right color. Human eye just doesn't see it that way. So this is where JPEG has its strong suit because this is where it can do lossy compression. It can be forgiving when forgetting information on the precision of color. This is how a JPEG works.

Lassy and lossy. That slide would also be funnier if I wasn't 60 to 90, sorry. So at the end of all that, the compression is done by a discrete causing transformation type two, doesn't really matter. Just put it in there. And this is basically what's creating the lossiness in JPEG. And this is what lossiness would look like.

These are, I don't know, 10 steps, I think. When you look closely, you can see compression artifacts rising while the quality of the image is degrading. This is a discrete causing a strength for an action. And this is what people like you, I mean, commonly know as the JPEG quality setting. Okay, another show of hands.

What is the best quality setting for JPEG? Is it 75? Yeah? Okay, is it 82? 85. Uh-huh, some more. 90.

92. Good, good, good, good. Any other takers? Is somebody shouting 100 or 94, or 59 or something? No? We are defined best, thank you. There is no quality setting. Thank you for playing the game. The thing is, the quality standard, the quality metric in JPEG is not defined in the JPEG standard.

Everybody talks about quality and goes like, when I save my JPEGs with save to web on quality 85, they look fine. But the thing is that quality setting is not defined. And every encoder does something differently under the hood when estimating quality. When we looked at the JPEG sample before, we saw all these nice spikes at 75 and 18, 85,

because this is what opinionated JPEG encoders at some point said would be the best setting for them. So at the end, you can actually say that JPEG encoders are something like highly opinionated Rube Goldberg machines. They do really, really weird stuff under the hood, and they have an opinion about it too.

So what they do is they go like, well, let's optimize this Huffman table once. Or no, let's optimize that Huffman table twice or nine times. And let's do trellis optimization, or let's not do trellis optimization. Let's do corner sharpening, or no. Every JPEG encoder does something completely different. Of course, Adobe, for example, says, oh, to hell with LIP JPEG,

we then created something completely different. That is why when you use Photoshop instead of GIMP or anything, you don't get a quality scale from zero to 99 or 100, but from, what is it, zero to nine or something, because they created a completely different library. This leads to very, very odd things.

Here's the story of a little blue-red riding hood. As you can see, the images are completely identical, but for the color of the riding hood. And the red riding hood is bigger. And the question is why? The human visual system? Yeah, we have rods and cones in our eyes.

And these rods and cones are for brightness and color. And we have different kinds of cones for different kinds of wavelengths of color. There's long, medium, and short cones. And they are distributed like this. They have a ratio of this. That long wave cones are much, much more abundant than short wave cones. That means warm colors are actually more likely to be seen,

and that makes us go yum. We have red cones. We have an eye very perceptible for red, because it tells us that something is edible, something is delicious and tasty and wants to be eaten. So red is good in our mind. And this is where many encoders are more like, oh, this is a red color.

I'm gonna be more conservative when compressing this, because JPEG encoders went like, if I'm gonna mess with red instead of blue, then maybe the human eye might detect that difference because there's more cones in there for red. So speaking of that lossiness that is there for blue and is not there for red,

there's also lossless operations for JPEG. Well, semi-lossless. One of the most well-known is JPEG-TRAN. And then there's the ugly step-sister JPEG rescan, which is basically a brute force script around JPEG-TRAN. What they do is they optimize Huffman tables. JPEG-TRAN tried to optimize Huffman tables once,

so it runs once, tries to find an optimized Huffman table for a JPEG, and then goes like, yeah, this might be better or not. And JPEG rescan goes like, no, I'm gonna run you like 100 times, and let's see which of the 100 Huffman tables I come up with is the best one. So kind of cool. So all of that saves bytes.

And because the Huffman tables just changed the DCT coefficients, this is actually a almost lossless optimization. So that's pretty cool. But yeah, enough of that mind-meld. Let's go back to the original story. So we've heard about WebP and JPEGXR, Microsoft and Google. And of course, that's not the end of the story,

because that was in 2010 and 11. So by the end of 2011, start of 2012, Mozilla got into the battle with Google and Microsoft. And what they did is they ran studies showing that neither WebP nor JPEGXR outperformed traditional JPEG if JPEG is encoded with a modern encoder,

not an encoder that is 15 years old. They ran a first study that was then renounced, and like nine months later, ran a second study that was taken up much more seriously. And after that, the guy who created the studies also announced the creation of a new tool by Mozilla, and that's called MODS-JPEG.

MODS-JPEG is the most modern JPEG encoder we have on our hands right now. It was announced in March 2014, and is now being backed by companies like Facebook, because Facebook has switched to and away from WebP. So now large companies are funding money into the open source development of MODS-JPEG.

MODS-JPEG is completely open source on GitHub, GitHub and is awesome. So what can MODS-JPEG do? It optimizes Huffman tables, and that many times. So basically it makes JPEG-TRAN and JPEG rescan redundant. Actually, MODS-JPEG has just replaced JPEG-TRAN in the famous ImageOptim by Kornel Lisinski.

Who of you is using a Mac? Okay, who of those knows JImage or ImageOptim? This is a nice tool where you can drag and drop images on it, it just does its magic, and every image is small. Okay, a couple, thank you, thank you. So JPEGOptim is one of the most famous open source tools for image optimization. And whatever ImageOptim does,

a lot of other tools try to imitate, because ImageOptim is the de facto standard for good GUI. And yeah, like I said, MODS-JPEG has just become the tool of choice under the hood for ImageOptim, because it's just better by now, it's just better than any other JPEG encoder that we have. Also, it can now shape custom quantization tables. This was not possible because of patenting issues

until a short while ago, but now the patent for this has expired and MODS-JPEG has already picked that up. Also, it does something that no other JPEG encoder does, it does trellis optimization. So in the lossy part of JPEG compression, it tries to find ways to make the DCT coefficients even smaller.

So we're resulting in smaller byte size, that's great. And it does optimize progressive encoding. So progressive JPEGs are like a layer cake, where when you download the image, you get a very low resolution image and then it starts to build up, almost like the modern times of old. So what MODS-JPEG does better

than any other encoder there is, the layers in which the image is shipped actually are arranged in a way that they have minimum byte size, which is also very, very cool. And all of that is done with minimal impact on the SM score. Oh, damn, didn't tell you about that, the SM score.

Let's take a holiday photo of a crazy person and let's compress it. And when I compress it and look at the pixels that have changed during lossy compression, this is what I can get out. This is a map of pixels being touched by a JPEG encoder when lossy compressing crazy person's photo.

And this is something we can express in a number and then make use of in JPEG encoders. And the tool of choice is right now the similarity, the structural similarity index. The structural similarity index has replaced the peak signal to noise ratio by now, which was a number we measured quality of an image by earlier. But the structural similarity index

is actually much, much closer to the human eye already, which is cool. It's still not optimal. There are papers being written at universities like this one, where new variants of the structural similarity index are being published, which are even closer to the human eye. I don't even remember all the acronyms,

like C-Y-S-M and whatever. You can just Google SM and find papers from a university with authors trying to find visual structural algorithms that are then lies closer to the human visual system. What I'm using right now is, again, Konner Lisinski's dissimilarity index.

To show you the dissimilarity of the picture that you've just seen, it has a dissimilarity of 0.13%. So 0.13% of the image have been touched during encoding. And this is a number I can measure and put into tools. Now you might ask yourself, what percentage of differentiation during a lossy encoding

might be okay, and which one is bad? So if the image changed by 50%, would the human eye see that? And the answer is yes. What human eyes can't see probably, I mean, there's always edge cases, are differences of 1.5% between two images. So if you give a test group images

with slight differences of 1.5% and just encoding differences, the human eye, the average human eye within a significant amount of time cannot differentiate if one is different from the other. And it's a little bit like those search images, like find the seven differences. You can do this with a usability test.

So when we have the dissimilarity index, we can actually automate JPEG quality encoding. That's pretty cool. We can use something like a tool that I created. It's called CJPEGDSIM. And what it does is it gets rid of the notion that you need to define

one certain JPEG quality for your encoder. Like we just talked about, if you go like, oh no, I'm gonna compress all my images with 85 or 75 or whatever, maybe that's not a good idea. Maybe certain images would benefit from higher compression ratios, while other images would be better with lower compression ratios.

So CJPEGDSIM actually uses the similarity index, compresses an image, finds out if the difference to the output image is acceptable to the human eye, and if yes, yay, if not, it re-compresses with a different setting, trying to find an optimal sweet spot of 1.5% of difference.

Funnily enough, when I ran this through my data set, I found out that I often can reuse much, much lower JPEG qualities than I was expecting. So for example, 59 came up a lot with my tool, which is funny, I didn't expect that. But there are so many JPEGs out there

that have just smooth gradients or are blurred because of depth of field photography, and they benefit a lot from high compression ratios. You can compress them strongly without creating artifacts. So this is where a tool like this comes in handy, because you can automate that process while deploying. Speaking of automated deployment, there's another idea.

If we are automating JPEG quality already, why not adapt it to a user's current situation? If I'm on a train riding through, you know, with that metal tube riding through Siegburg, I might have a very, very bad data connection.

You know, like edge. So I have like 800 milliseconds of round-trip time, and that's really, really bad. So if I try to open a website, that website might actually never load. So what we could do is we could find out that the user currently has a very, very high latency connection, say edge,

and we can compress images strongly for that specific session. And when the user has a high-performance connection like 4G or is even on Wi-Fi at home, on his tablet or their tablet, whatever, we can ship high-resolution images with weak compression. And again, this would look like that.

The high-resolution image versus the low-resolution image, which saved bytes while shipping. That's really cool, and it's called AIC. The technique is out on several CDN vendors by now, and you can also, with the HTML5 Navigation Timing API, create this yourself on your server.

So either you can buy this as a product or you can build it yourself just reading out round-trip time performance of your current user sessions and adapting JPEG quality accordingly, thereby creating a good user experience for all your users and people convert or do whatever you want on their website. In this notion, I also thought,

well, it's kind of cool to be able to find out, to automatically find out one JPEG setting for each image, but why isn't it possible to adapt the JPEG quality within an image? Wouldn't that be cool? So if I had a photo of a sky and then some people in front of that,

I could compress that sky far more strongly than the people. But if I just used something like SN on the entire image, I would get compression artifacts around the people if I used a high compression ratio. So I was thinking there must be a way around this. So again, let's take the holiday photo of crazy people and let's find out where I would incur

compression artifacts. This is a all directional Sobel edge detection algorithm on the holiday photo. And you can see that all the edges have been highlighted. And these edges are the most likely places where compression artifacts would occur if I compressed this very, very strongly.

This is because that's JPEG, that's how JPEG works. So I thought if I could just use an encoder that would iterate over the image from, say, left top to bottom right, because this is how the JPEG encoder works. It works by 8 by 8 blocks going left top to bottom right. And I could just find corner, corner, corner, corner, corner, corner, stop, sky, sky, sky, sky, sky.

And then next row, blah, blah, blah, blah, blah. And I could just adapt JPEG quality per tile. Then I could save even more bytes. That's what I was trying to get to using ADAPT, which is nothing but a 300 line bash script, which I whipped up together just to demo that this is possible.

After creating this demo, this tech demo, with the Sobel edge detection algorithm, I actually found out Sobel might not be the best idea. Because within a corner, within something that has corners, I might also have details that I want to preserve. So the next logical step for me was to find out how can I highlight entire salient regions

of an image. Salient regions means regions of an image that are interesting to the human eye. There is also algorithms to discover this, because we are currently trying to teach computers how to see. So we have to find out algorithms to make a computer see which areas of an image are interesting.

We do this by a combination of sharpness, color vibrance, et cetera, et cetera, et cetera. So what I did, I looked through lots of these saliency algorithms and tried to find out the one that would be beneficial to my cause. And what I found out is the maximum symmetric surround

saliency algorithm created by a guy in Switzerland. And I asked him if he could open source this. And he said, yeah, go on, cool. Just do whatever you want with it. So I released it as an open source, had a colleague of mine help me port it to C, by actually to C++. And now we can do this. This is a saliency map of the holiday photo. And to make it more visually astounding,

this is the saliency map with only black and white. So as you can see, the saliency mapper has found out that the banana plantage is interesting, and the guy is interesting, and the car is in the house. But the sky and the sea, where the background are not as interesting. So when I now run this through a JPEG encoder that goes tile by tile and assesses if the JPEG quality can change

for the tile, I get something like this. You can see that the encoder has found out that these tiles, the dark red tiles, can be highly compressed without altering the message of the image too much. And therefore, these tiles are exposed to a high compression,

while the whiter tiles are only exposed to a weak compression, which means these tiles will retain their visual detail, which is really neat. So this is what ADAPT has demoed. And this is what is currently being ported into MODS JPEG. So I'm kind of happy about that somebody who knows image compression a little better than me

is picking this up. And now they're building this into MODS JPEG at some point, which is really, really cool. And actually, this is something where I'm seeing computer compression for images getting in more and more. I don't know how many of you followed that computer vision

challenges by Google and other companies. This is a result of one of them, where computer vision systems that used neural networks were actually very successful in detecting objects with an image successfully using a huge database at the back to find out what is inside an image.

Now, of course, this is cool for things like indexing images, and you're making images more accessible to people. So this is really, really nice. This is also a huge benefit for the image compression community. Because at this point, what we can do now is we can go and say, hey, look at this block. There's a cat in here.

Cats have fur. Fur is detailed. And we might even read out the color of the fur and optimize for that. We could go like, this is a screen. Screens are usually black and boring. So why not compress that more strongly? Because the screen might actually not incur compression artifacts, because it's just a black shape. And everything else that is not salient for the human eye,

not important for the human eye to see in these images, can be compressed more strongly. For example, if you looked at this at a supermarket website to shop for fruit, you don't give a crap if that table is highly compressed or not you're interested in the fruit. So I could go and compress that table texture very, very strongly.

Because you're not buying the table, you're buying the fruit. So computer vision is what I think is the future for image optimization. And this is why we should follow this with interest and see where this is going. And all of these algorithms actually, most of them are open source. And I think almost all the teams that

have taken part in these challenges are now creating startups because of that. Because they found out this has a high benefit for lots of use cases. So they got funding for this and now working on products to make these algorithms better. Of course, computer vision sometimes

turns out weird stuff. We do the weird stuff. Who remembers this? Was it called a couple of weeks ago? Yeah, Google Deep Dream. This is what computers come up with when they try to dream up images. Also very, very weird. Even disturbing sometimes, but well, it's funny.

So I think computer vision is something really, really interesting where we can expect lots from in the future. But it's all not good news. We've talked a lot about what JPEG can do now, how we can optimize JPEG and its compression, how we can sharpen areas that are interesting. But there's just some things that JPEG

can't really do very well. Not yet anyway. So there is a working group out right now, the Joint Photographic Experts Group is working on something new for JPEG. And that is called JPEG XT. JPEG XT, in comparison to, say, what WebP was trying to do

or JPEG XR was trying to do, is fully backwards compatible. That means every browser, every viewer that currently supports JPEG will be able to display what JPEG XT will output in the future, which is awesome, because this is what WebP had as a problem. WebP, no matter how well it performed,

was only able to be viewed in Chrome. You say you want to open a photo and it's saved as WebP, and the viewer, your operating system tells you to use this Chrome. That's just weird. So JPEG XT can make use of all the image processing tools that we have, every JPEG viewer, because it's fully backwards compatible. That's a huge plus.

And it tries to address all the weak points that JPEG had as a format. It can carry more bit depths. It will carry full alpha transparency, so not just Boolean alpha transparency, but full alpha transparency maps. It can store HDR photos and has much, much more exciting features. The working group, working on JPEG XT,

also released the first couple of studies on how it's performing. And according to these studies, it outperforms everything we've seen so far. This is from this year. So it's very, very cool. You can see that JPEG XR and JPEG 2000, which is always cried after, like, oh my god, if we had only JPEG 2000,

everything would be better. No, actually, JPEG XT is going to outperform all of them. So it's really, really, really neat. And at this point, when JPEG XT is out, these semi-proprietary attempts by Google and Microsoft will just become redundant.

The nice thing is also the discussion about JPEG XT is completely open. It's a working group. You can join them like any other W3C working group. You can write an email to that email list, explain why you want to be on that group, and just start chatting. You'll get access to the tech demos. You can discuss feature requests or bugs

and just become a productive member of the JPEG working community. If you don't have the time, however, you can, of course, create alpha transparency right now. But I'm not talking about PNG 24. Actually, if you want to use alpha transparency right

now, one of the features that JPEG cannot do natively, you can always use PNG 8 with the full alpha transparency channels. This is something that I always found out that very, very few people know. People always think that PNG 8 can only carry Boolean alpha, so full alpha or no alpha. But actually, alpha PNG 8 can carry full alpha transparency

with 255 steps of alpha transparency. This is the old way of how you would have done it. Three tools to create from a PNG 24 a PNG 8 with full alpha channel. But don't do this. There's a new way. Again, my favorite person on the whole world

world in terms of image optimization, Konner Lisinski, is working on PNG quant 2. And PNG quant 2 can do this much, much, much better. Here's a PNG 24 of a neat motorcycle. And this is PNG quant 2 by Konner Lisinski with proper dithering.

The cool thing about this is that it is much better in terms of color dithering than the Floyd Steinberg algorithm that is currently being applied when you convert from PNG 24 to PNG 8. So the color gradients on objects look much, much better when you use Cornell's version. So I strongly encourage you to check that out. PNG quant 2 also on GitHub, also open source.

Another alternative that is really, really weird is you can go vector if you want to have alpha transparency for a raster image. Yeah, throw stones at me. That's possible. Well, you do this by creating an alpha transparency map. You basically ship the raster image, and you wrap it around an SVG container.

And inside the SVG container, there's also a transparency map. And this is being subtracted. And then you basically have a raster image with the nice performance that a highly compressed JPEG can carry, while you also have full alpha transparency. Of course, this has the slight downside that it only works in every browser that can do SVG.

But honestly, most of the modern browsers can do this now. There's a tool for that, too. It's called Zorro SVG. You can check that out. Just dump a JPEG in there, and it'll create the alpha transparent JPEG mask with SVG container for you. SVG actually is becoming more and more popular.

So also keep out an eye for an open eye and ear for SVG. One of the things where SVG has become more and more popular is what's called the clown car technique. And that was a tool by Estelle Weil, where she used an SVG container to ship multiple resolutions

of JPEG images for responsive images on responsive websites before Joao Weiss saved us all by standardizing picture and source set inside the major browsers. So SVG got a lot of traction because of that, because it solved a major pain point that web developers had. Also, SVG is cool because it replaced the horrible icon

forms that we shipped on websites. SVG renders very, very performant now. And it is much smaller, and it's better maintainable than icon forms. So when web developers nowadays use one of the ship icons, they tend to go to SVG because SVG is just better.

Also, SVG compresses very well. What you can see here is a tool that compresses SVG code, which is just XML under the hood, by rounding off integers, removing all the craft to the commons and the unnecessary source code, invisible layers, et cetera, et cetera, et cetera.

There's a couple of tools who claim to do that.

So the question is, isn't SVG a performance slowdown in comparison to JPEG because XML has to be parsed, and then the browser has to put that out? The answer is yes, it used to be, but not anymore. So when you opened an SVG four years ago,

you could basically see the browser going like, oh, this is difficult to process. What are you doing to me? You can really see the image coming in. It was terrible. But now SVG is hardware accelerated when being processed, when being rendered. It's very, very fast. So the SVG rendering in browsers has picked up significantly.

OK. So if you want to ship SVG for the web, or you want to ship the smallest SVG possible because you care about your users, you should use a SVG compressor as well. There are several tools that can do this. The most famous one out of the old days is called Scour, a Python script.

But I would now actually encourage you all to check out SVGO. Or I always pronounce it SVGO because it's kind of cool. SVGO, yay! Because SVG is awesome. SVGO is available as a node module and in several other iterations. And it can be easily installed and integrated

into your deployment infrastructure and optimizes all the SVGs that you ship. And it saves a lot of bytes. So it's really, really neat. OK. At the end of the day, however, at some points, no matter how strongly you encode, how much you try to save things, images don't become lighter anymore.

So what can you do? This is what's called LKIP, a low quality image placeholder made famous in 2013, 2014 by a former colleague of mine, Guy Pajami,

and is being adopted also by Facebook. Facebook just put a nice post on their developers blog about how they're doing this, how they ship 200 byte low resolution preview images to increase the user experience. So if you care about user experience and you have already deployed your JPEG encoders

and you make sure that your websites load fast and you still think you need to do better, you could think about using something like low quality image placeholders to ship something like this that already slightly resembles the image that is about to be shipped to the user. And then when the high resolution image is downloaded on the 2G connection

or whatever the user has, it gets replaced. So this way, the user still already can see some part of the image. The rendering engine inside a browser can already allocate the space for it, so that's kind of neat. And then when the high resolution image is there, we can just replace that on the fly. This is Guy Pajami's introduction of LKIP,

and this is the Facebook post. By the way, these slides are going to be on speaker deck after this talk, so we don't even need to take photos of that. I am also working on something really weird. I'm calling it SKIP. This is the same as LKIP, only that I'm going to be using vector, because I think I

can be smaller than 200 bytes. So this is a raster image that is being forced to 200 bytes by Facebook, which is cool, really, really cool. But not everybody is Facebook, and it's difficult to deploy this kind of infrastructure. For example, they're not shipping the JPEG headers. This, with SVG, can be possible for anybody

without buying into large infrastructure. So I'm thinking SKIP is something I'm going to invest some more time in to make things better. So maybe at the end of the day, we're going to have a scalable image placeholder, which is going to be really cool. And then we can replace the high resolution image once it's been fully downloaded. Right. That was a lot, a lot of stuff.

So let's wrap it up with takeaways. We've heard about WebP. Is WebP open source? Yes, it is. Is WebP worth shipping? Yes, I think it is. Is WebP worth helping? No, I don't think so. A, because it has Google at the back. It doesn't need our love.

Also, I think, like I said with JPEG XT, I think WebP is cool because it's supported on Chrome. And Chrome has a lot of traffic right now. But it will become redundant at some point. So if you are looking for a pet project of image optimization where you want to help, whether it's open source, I wouldn't encourage you to go and help Google with WebP

because, nah, it's good enough. And it'll be replaced. The same kind of holds true for JPEG XR from Microsoft. It's not really open source now. That's why I put the stop hand here. It didn't used to be open source. But now it's open source, and the licensing issues have been solved.

Is it worth shipping to Microsoft browsers if you have proper user agent detection? Yes. Is it worth helping? No, same argument. The dissimilarity index, or basically any similarity index algorithm, is it open source? Yes. Is it worth shipping? Well, it doesn't apply. You don't ship this when you encode an image.

It's just used within an image encoder. Is it worth helping? Yes, I think so. Because we're not there yet in creating the perfect measurement of an algorithm that can say if an image has changed to the human eye, yes or no. The similarity index is already much, much better than the peak signal to noise ratio, but it's not good enough yet, as you can see by all the publications coming out for this.

So if you want to dive into human visual systems and try to programmatically rebuild this visual system as an algorithm, go ahead. I think the community can benefit from that. The saliency algorithm, is it open source? Yes. Is it worth shipping again?

You're not shipping that. It's just used under the hood. Is the maximum symmetric surround saliency algorithm worth helping? Although it's my pet project, no. It's not worth helping. So don't help me with this. Because I'm not supporting it anymore, so neither should you. There's better saliency maps already out and available. This one is pretty neat, but it's not the best.

So don't waste your time. PNG 1, or under the hood called PNG 1.2, because it was actually a fork. Is it open source? Yes. Is it worth shipping? Hell yeah. It's cool. It's going to make your PNGs better. Is it worth helping? No. Because it's already pretty good. Cornell knows what he's doing. And again, with what's about to come,

I think also PNG is going to have a hard time holding on. So PNG might be on its way out in two or three years. SVGO, or any other SVG compressor, is it open source? Yes. Is it worth shipping? Hell yeah. It's going to make your SVGs smaller. Cool. Is it worth helping? No. They're already pretty good. So unless you're very, very optimistic about what

you can do with smart math to make curves more performant in terms of rendering, or how to express them more performantly smaller in XML, I don't think you should invest your time helping something like SVGO, although it's pretty good and it's going to help you. JPEG XT is a new kid on the block that's going to be awesome.

Is it open source yet? Yes, it is. So you can get the tech demos. It's not publicly released yet, but you can get the tech demos and all the licensing issues for open source have already been solved. So it's open source. Is it worth shipping? It will be, because it's fully backwards compatible. That's what's going to make it awesome.

Is it worth helping? Yeah, definitely. Just go to that mailing list, subscribe there, get the info. They just had a meeting in Warsaw where they worked on this for some time. So I think following JPEG XT development and also compiling, reporting bugs back, and maybe even

feature requests if you're confident enough is going to be right at this point, because they just started discussing this heavily in the last couple of months. And then last but not least, and also I think the most important part, not JPEG. The best JPEG encoder we have right now. Is it open source? Yes. Is it worth shipping?

Hell yeah, because it's going to make every JPEG better. And is it worth helping? Yes. There's lots and lots of open issues. And the people can actually really benefit from some smart insights. So you don't have to be a complete JPEG nerd to be able to help there. So for example, they have stuff like, oh, we need to find out how to discover

if an image has more grain in one corner than the other. And they are looking for creative solutions. So if you feel confident that you can come up with creative solutions to interesting problems, look through the modsjpeg GitHub page and their issues. They have a lot of things where they are benefiting from input. And I think we can all help them and make JPEGs better right now, and modsjpeg's already on the way there.

That's all from me. Thank you so much. We have like five minutes for questions. Five minutes for questions.

Of course. So the question is, can I talk about JPEG 2000? Yes and no. JPEG 2000 had a huge licensing problem. And that is why it wasn't deployed widely. After the licensing problem, it was solved. JPEG, as the normal JPEG, was already predominant.

And since JPEG 2000 and JPEG were not compatible, they're not backwards compatible, that wasn't used. Oh, sorry. OK, the question is, what would I use for animated GIFs and stuff?

As my slides have shown, animated GIFs. So there is something called APNG, Animated PNG. It has too little support. WebP also does animation. So you could use WebP with a GIF fallback. That would work.

And if you only use interface animations, like folding menus up and down, switching arrows, et cetera, go with CSS transitions. So you can actually create very complex CSS transitions right now. And the nice thing about CSS transitions is they are supported by the GPU. So they render much more performantly.

So unless you need something like my jumping goat, then try to find an alternative. And then maybe WebP animated for Chrome, everything Blink-based, which actually makes up like 60% of most website traffic right now. So it's worth investing in. And then a GIF as a fallback for everybody else.

Oh yes, actually, that's what I've mentioned about mods.jpeg. That's happened like three weeks ago,

or maybe even two weeks ago. There was a pattern that was expired. And people just went to the GitHub page and reported, hey, look, this pattern just expired. And the mods.jpeg people were like, woo-hoo! And they immediately implemented this. So it's really, really cool, yeah. Thank you so much.