 Hi, everyone. Welcome to the CDS workshop, Intro to AVI Images. My name is Frank Hagen, and I'm an engineer at Google in charge of AVIF. I also work on image, video, and geometry compression as well. I just want to give you some prerequisites. I'm going to use AVIF to do some creating of AVIF images. But don't worry. Anything, if you want to follow along, I'll have links to all the images I either use as source or the images I create. So you can download them if you want to use them. Here, this is a little graphic showing the relative timeline for some of the major image codecs used on the web today. The ones most people are probably familiar with is GIF, JPEG, and PNG, which are somewhat from 35 to 25 years old. WebP, probably most people have heard of, came out about 10 years ago. And then AVIF, what we're talking about today, the specification came out in 2019. OK, a little bookkeeping. So what is a digital image? And I apologize if most people know this already. That's all right. Yeah, I think I can share the slide and the GitHub link for the AVIF. Sure, maybe I can. Someone could maybe post that link in the chat that would be good if you go into my next image. If not, I'll share it later. All right, so what is a digital image? So I think you've done it. Basically, digital images is a 2D representation of visual information. Typically, one unit of this 2D grid is called the pixel. You might also hear the term megapixels. That's basically 1 million pixels. So when you get your mobile phone or other cameras, they usually say, oh, I can shoot in 5 megapixels, 10 visit pixels, 48 megapixels. That's basically just a million pixels in this 2D grid. Most of the current smartphones take pictures with a resolution of 3,024 by 4,032 pixels, which is about 12 megapixels. And then pixels typically contain three channels which map to the red, green, and blue values that are mixed in the color we see rendered in the images. Typically, there's a lot more. You can have alpha and other things as well. OK, so why do we have image compression? The 12 megapixel image in compressed is about 36.6 megabytes. Or other people will refer to it as 24 bits per pixel. Again, this goes back to red, green, and blue, basically 8 bits for each value. Newer formats or images with alpha could be even bigger. JPEG and the web, they're usually compressed about 1 to 1 and 1 1⁄2 bits per pixel. So a 12 megapixel image would be about 2 megabytes. So great, we just made the images 20 times smaller. Thank you, everyone. I hope you like the presentation. All right, even though JPEGs are a lot smaller than uncompressed images, images still make up a good percentage of websites today. Paul Calvano gave a talk recently at the Image Ready conference listed on the slide. They looked at millions of sites, and 45% of the page weight was from images. Also, the median image size was 881 kilobytes. So there's also another piece of information from Paul again, because they found out that 40% of sites had an image element that triggers the LCP. I'll kind of go into the LCP a little later. In reality, this is even higher than 42%, because the next highest LCP event is the div element, which could contain text or image. So picking the correct image format can improve your core web vitals or CWV. I also want to mention that Lighthatch, which is a part of Chrome Developer Tools, will now estimate the savings if you switch your images to ADIF. Now also, I want to talk about the types of image compression. Basically, you start with two main types of image compression, loss list or lossy. So loss is compression will take the data in the source image, compress that data, and then decompressing the data will return the exact data from the source image. That's great. So why do we even have lossy compression? Lossy compression will usually create much smaller files. And also, depending on the compression format and settings, lossy compressed files can be compressed to what is known as visually lossless, meaning the lossy compressed is perceptually the same as the source image. So on the graph on the right, you can kind of see the PNG image format, which I haven't talked about too much to this point. PNG is a lossless format. It's used on the web for a lot of images. To show one difference between the lossists and the lossy compressed images, you can see it in the chart. I took about 20-year-old pictures captured from my camera at 12 megapixels. The average size of the captured images as JPEGs is about 3.5 megabytes per image. I then compressed the images PNG files. You can see the average image size for the PNG is about 13 megabytes, almost four times bigger. You can also see the yellow little sliver from the graph is the AIF average size, which is about 0.5 megabytes, or about 26 times smaller than PNG. One caveat is that PNG is probably best suited for non-photo-type images. So if you use PNG and those types of images, it might fare better than the graph you're seeing here. OK, so AVF is based off of the AV1 video format, which was released in 2019 by the ALIM organization. The AVIF specification was introduced by some people from Microsoft and Netflix. AVIF is open source and royalty-free. AVIF was first released in Chrome 85 for the desktop and Chrome 89 for mobile and Firefox 93 for desktop. And basically at a high level, we say AVIF compresses images from twice as small, and we have about 10 times smaller than JPEG for the same quality. The key point here is the same quality. So that's great and old, but has anybody actually ever used it? So I just want to highlight a few world usage that people have mentioned. Vimeo is serving AVF images, and in their blog post, they mentioned they're seeing about 30% savings versus WebP images and about 50% savings versus JPEG images. Note, a few slides ago, I showed a slide showing AVIF getting about 85% smaller than JPEG. A couple of things here. One, the JPEGs were captured from my mobile phone. And the JPEG compression was probably not as good if it used a better compressor like Moz JPEG. Those images are 12 megapixels. So in general, the larger resolution, the better AVIF can compress compared to JPEG. Unsplash was another company that recently tweeted, and they're seeing about 30% savings over WebP from switching to AVIF, pretty much the same as Vimeo. There was another developer who tweeted that they were seeing about an 11% LCP. Again, this is the largest contentable paint improvement when they switched over. They had about 14 million images across all of their various sites. So they were really happy with the improvement. Okay, so I'm going to back up a little bit here and talk about image quality. I mentioned it before, but what does that exactly mean? Well, everyone sit back for the next 12 hours and we can talk about image quality. Seriously, image quality is a very broad and complex topic. For the purposes of this presentation, we don't have the time to get into it, but when I'm talking about image quality, I'm usually talking about some objective value that tells us how similar one image is to another image. You most likely heard about PSNR, SSIM metrics, but there are many, many more, including BMath, they're ugly, MSSI-SIM, some Maraca, and many, many more. And the reason we talk about image quality is because when we are comparing lossy compression, we need to evaluate how similar the different codecs are compared to the source image. As an illustrative example, I could create an image codec that would take any image and change all the pixels to a single value. The compression ratio would be exponentially better than any other current codec, but the quality would be non-existent. So for this reason, when comparing lossy compression, the compression ratio and quality go hand in hand. No, when you see information comparing the size of one compressed image versus another lossy compressed image and there's no quality information, then you can usually assume the quality was the same or hopefully assume that. And then if you want to see more information on the subject, Jake Archibald had a great post on it. It compares AVIF to a lot of other image formats and it's listed here on the slide. If someone could be so kind as to copy in the chat, that would be great. Right, so now that was the first part of the talk. I just wanted to get a little background information for everyone and I wanted to kind of go into some tools to create AVIF images. Well, first I want to talk about image CDNs. Image CDNs are a really easy way to add support for image formats like AVIF to your website as well as other image formats like WebP. There are many image CDNs that have support for AVIF. I'm not going to go into detail on how to use any specific image CDN here as they all have their own APIs for hosting and transcoding. In general, most work, you upload your image to the CDN then you use the image CDN API to transcode the source image to AVIF and some other formats like WebP and then you add the image CDN serving code to your web page to serve the best image format. When quick, AVIF to the user. So they're a great way to do it but I just don't have time to go into every single one. There's many out there if you just search for them. You can find a bunch. Squoosh, okay. So an easy way to compress AVIF images is to use the Squoosh.app on the web. So let me switch my presentation over to Squoosh. Let's see, you should be seeing, okay, yeah. So now you can see Squoosh. So this is the main page for Squoosh. I'm just downloading the image and another computer. All right, so this is the main page for Squoosh again. As you can see, you can drag and drop images to the editor here or you can scroll down and they have different images here that you can try. I'm gonna pick an image that I listed earlier, a JPEG image. Drop it over. So the first thing I'm gonna do after the image pops up, I'm gonna change it to pick AVIF in the drop-down box. So what it'll do if you see it on the bottom right, the animated symbol, it's meaning it's compressing it as we speak. So all of the compression is done in your browser. So the image isn't actually uploaded anywhere. They do it through a Wasm encoder. Okay, so once Squoosh is done, as here, you can see that it compressed the original JPEG image to an AVIF file and it says it's 87% smaller, by 188 kilobytes. The source images on the left, the compress images on the right in the slider, you can move back and forth to see the difference. As you can see, I hope you might be a little hard with the presentation, but they're fairly similar. I'm gonna talk about the two sliders underneath. So here's over here, there's a quality slider, which the default is set at 30. This is basically the target quality you're trying to achieve. The higher the quality, the better image will look, but the file size will be bigger. For example, we put the quality to 55, and once it's done, you'll see that we're basically trading the size of the image for quality. Okay, so yeah, so now that it's done, you can see that the file is not only 45% smaller, about 606 kilobytes, but the quality should be much better. Again, it's probably hard to see over the video feed, but you can try this out on your own time. So now I'm gonna change the quality to five. So this will be much worse quality. I think you'll be able to see the difference. Again, once the excuse is done. Yeah, so now, I can definitely see it. I don't know if you can see it over the video feed, but it's 98% smaller. It's a pretty small file, but you can tell the quality is definitely not anywhere as close to the original. So let's put this back to 30 again. The nice thing, it kind of cash your settings. So let's talk about the effort slider. So first of all, change the effort to zero. So the effort is basically how fast you're allowing the compressor. You're basically trading time for size and or quality. So I have quality 30 and effort zero. So you can see the file is a little bit bigger. It's probably a little bit worse quality. Again, it might be hard to see over the video feed, but those are the two main settings for Scrooge. Here's some advanced settings. I don't know if you can see them, but the sub-sample for chroma is half. Sort of a lot of video images, they'll kind of sub-sample the chroma because usually you won't use as much information. If you have like text or other types of images or sharp lines, you might not wanna sub-sample the chroma. You can separate the alpha quad as you can give the alpha its own quality compared to the color image. Extra chroma professionals just try to compress the chroma more because a lot more people are sensitive to luma. And sharpness is just, it'll pre-sharpen the image. So that can be kind of good. So sometimes when you're compressing it can blur the images a little. Noise synthesis is it adds noise. It'll try to take away noise and try to add noise back in the original image. Tuning is just whether you wanna tune to a specific objective measurement. And the log two of tile rows and the log two of tile columns. I'll talk about this more later, but this basically you can split the image into different tiles which will help with multithreading both encoding and decoding at a very small loss maybe in quality around the tile edges. Okay, let me go back to the presentation. Oh, also if you click this kind of download symbol or this save as symbol this will save the image to your hard drive and switch back right. So I know that was kind of quick for Scrooge but I find it really a really easy tool if you wanna just do a couple quick test compressions to use. So this is some other tools that you can use on the desktop that support AVF GIMP. It is a pretty popular image editing program. It supports reading and writing AVF files. Paint.net is a Windows application which supports reading and writing AVF files. And there's even a Photoshop plugin. So you can read and write AVF images from Photoshop. Oh, so let me see. Is your weighted target size again recommended for it? Brett asked, is your weighted specify a target image size and get recommended format and quality settings for the best result? No, so you wanna set the target compress size not in Scrooge, I don't think. I think there's some other tools that will let you do that but typically you, if you wanna set a target size you might have to recompress a couple of times to try to hit that size. Let's see. The question is, how does JPEG XL compare to AVIF? Will you talk about this presentation? So I'm not planning to talk about JPEG XL in the presentation but I can talk about it here. JPEG XL is very close to AVIF. The quality is very close, especially if you're looking at perceptual quality or the objective measurements I talked about. I think they're really close. It depends on which measurements you're using. We actually work with the JPEG XL team very closely and the decoded and encode times are very close. In my experience, AVIF decodes a little bit fast in JPEG XL where JPEG XL encoders a little bit faster so but they're very close. Automated AVIF converters. Photoshop the best tool converting for images. I'm going to, Brent asked about automated AVIF converters and Photoshop the best tool for converting images. For instance, 100K. No, in the next few slides I'm going to talk about more kind of like command line tools that would be better for automated conversion of AVIF images. So here we go. I'm talking about, so here it is now. So a lot of the tools and applications that use to create AVIF either use live AVIF or live heat underneath. They're both two open source libraries that are on GitHub. The command line tool, AVIF from the live AVIF project is a powerful application for creating AVIF images. Now the steps are lower. The steps download and to build the AVIF command line application. So if someone could please put that in the posting chat, that would be great. So these are the recommended settings for what we found to be the best quality versus size and time trade-off. On my machine, using the source image that we used in the Squoosh demo, with the recommended settings, the file size we compressed to is about 189 kilobytes. The size is a little bigger than the file created in Squoosh as the settings were different. But I think the file we just, the file that I created with AVIF has better quality, especially if you look at the two images side-by-side. And they're gonna talk about the settings a little bit. The Minimax parameters tell the AV1 encoder that it can use the full range for the quantization. So quantization, you can kind of think of like reverse quality, a high quantization of like in the sixties would be very bad quality, much like the quality number five in Squoosh, while very low quantization in the single digits would be very high quality. Again, much like the 55 quality in the Squoosh demo. The end usage parameter tells the encoder to set constant quality mode, which the encoder will then use the CQ level parameter to set the target quantizer. Again, you can set it between zero and 63, I believe. So the CQ level parameter is again, the reverse quality parameter from Squoosh. High CQ level like in the sixties would be bad, low CQ level like in a single digit would be high quality. The three settings, tune equals SSIM, Delta Q, Delta mode equals three and sharpness equal three are settings that we found to just generate better quality for images, especially high quality images. And the last setting, Y dash Y 420, that's the one to sub-sample the chroma values. Again, if your images have a lot of text or very sharp lines, then you might not want to set this parameter and leave it out, which would then default to being 444, which is like full aluminum and full chroma. So the settings I used in the previous slide took about 3.2 seconds to encode the 2K ADF image on my machine. It all machines pretty fast, I think it's a few years old, but there's another parameter for ADIF, ADIF ink, it's the speed parameter. So the speed parameter is like the reverse of the effort parameter in the Scooch app. The speed parameter tells us how much time we're going to give ADIF ink to compress the ADIF image. A lower number will take longer to compress but will look better. A higher number will compress quicker but the size and or quality will be worse. The default speed for ADIF ink is six. We found this to be a good trade-off of quality and size for time. There's also one more setting that I recommend you set. This is the jobs parameter, which will tell ADIF ink how many threads to use when encoding the image. If I add the minus jobs eight parameter to the encoding, the same image took about 1.2 seconds versus 3.2. Now, so there's also another common use case for catalogs of a lot of images. Some companies create images on the fly based on demand and then we'll usually cast these images for a certain period of time. In this use case, encode speed is paramount. I think Vimeo talked about doing this for in their blog posts as well. The differences from the recommended settings is I remove the DeltaAQ mode, which is a little slow for this use case. I also changed the speed to nine and added the tile rows log and tile calls log parameters that I talked about before. Also, these parameters will, the tile calls log and tile rows log, if you give it a value of two, it's a log value so it'll actually make four. Just so you know. And then with these parameters, again, as I said before, they'll split up the encoder image into independent tiles for the encoder work on these sections independently using multiple threads. You can also add these parameters to the non on the fly use case encodes as they'll speed up encoding decoding as well. Using the on the fly encoding sec, using the on the fly encoding settings, ABAF ink took about 350 milliseconds to encode the 2K image of my machine. Also note that the decode of the JPEG image takes about 100 milliseconds on my machine. So if I were to pre decode the image into a raw format like Y4M, I could cut the encode done in the encode time down to about 250 milliseconds on my machine. So overall, we went from 3.2 seconds in the beginning using single thread encoding to 1.2 seconds using multiple threads down to about 350 milliseconds using the on the fly encode settings. One more thing to note before we move on is that we're actively working on this and making the encode of ADF faster and better. This graph tracks the transport time of 8.1 megapixel images for the past year. So you kind of see, you know, we went from about five seconds, it's hard to see, five seconds maybe, close to five seconds about a year ago. And speed six is the default setting for ADF ink. So that's down, you know, to about one second. And then the red line is on the fly encode settings, which are down to 300 milliseconds, something like that. And we're still working on this. I know in the past couple of weeks, we've gotten, you know, probably 10, 20% better. So those, you know, cannot all the time. Okay, so ABIF supports animated files. And ABIF ink supports these as well. You have to use, the input has to be Y4M, which I talked about before, it's basically a raw format. So you can use these to create animated ABIF images. You know what I'm asking, do you know what it's for me? It supports the effect Excel, behind the flag doesn't support ABIF at all. So yeah, so we talked to the Edge team, and they were prioritizing the AB1 video. I hope that they'll support ABIF soon, but it's really up to them. The last time we talked to them, they were just, you know, trying the resources to make sure that the AB1 video playback worked as best it could, because there's a lot of people. AB1 video has been out for a little bit longer than ABIF video, and I think there's a lot more people using AB1 video than ABIF images today, because that's newer. So, but I'm hoping it'll be out relatively soon. Okay, back to the presentation. Oh, and before anyone asks, I have no idea about Safari. Talk to your local Safari representative, but I really have no idea. All right, so I listed a way to create Y4M files using ffmpeg, I think that's what most people do. I started with from a GIF file. I added the link to the Y4M file I created. Just note, the Y4M files are not compressed and they can be very big. I tried to keep the resolution and length of the animation small because of that. I also listed the ABIF in command line to create an animated ABIF file. You can change, you know, other settings as well. This is just, I just used some default settings. And now that you created an animated ABIF file, that would be much like a GIF file in the Chrome browser. Currently, this only is supported in Chrome. I'm hoping, you know, the other browsers will, the Firefox, I hope it will add an animated ADF portion. All right, so that kind of brings us to the end of our creation part. Now I'm gonna go into the next section which talks about serving the ABIF images. So do not serve images straight through the image tag. You can serve ABIF images if you set the source attribute of the image tag. This is not recommended as the browsers that do not support ABIF will not render the image. The only way you should even do that is if you have some closed system that you know everyone will be on a browser that supports ABIF. So the best way to serve images is to wrap them in a picture element. The browser will consider each child source element to choose the best match among them. If there are no matches found, the browsers can support the picture element. The image element, child element will be used. So I'm gonna switch over to an example of serving the ABIF image we created earlier. Oh, thank you, Henry. You should see a code pen. I believe now. So add the ABIF image you created earlier in the source element. We don't see anything yet. For picture element, they want the fallback image tag. So I'm gonna add our original JPEG. Now you'll see below that they downloaded an image and rendered it. If I go to save image as should be, you can't see it. Come on, put it, trust me. It's the ABIF image. And also you should add WebP as well. If you can, because the browsers like Edge and Safari, that don't support ABF yet, it's better to add WebP. They'll give you much quicker time for download, better core web vitals if you're using WebP over JPEG for Safari and Edge. And I listed a code pen that's saved with this on the slide. Bear with me, I lost my presentation. So the next, I'm gonna show how to, I was just looking, okay, just in three more questions. All right, the next I'm gonna show how to serve an ABIF animated image. So as long as I don't lose everyone, I'm gonna go back to my code pen sandbox. Let me clear images, keep the picture tag again, add the animated ABIF as the first source, the animated WebP as second source, and then the fallback image as the GIF file. So again, on Chrome and Firefox, this will download and render the ABIF image on Edge and Safari. This will download the animated WebP images and then we have the fallback of the GIF for the older browsers. I think at this point, most people at least, but most browsers at least support WebP. Yes, the record, yes, we'll share the recorded sessions. I don't know where, but I know all the sessions recorded and will be shared. Anyone knows, please, please speak up if they know where they're gonna be shared, if they don't. So let me, I'll talk a little bit. So the animated WebP, the animated ABIF quality is much, much better and about 80% smaller than the GIF file. Also, the animated ABIF is only about 50% smaller than the animated WebP, while the quality is about the same. Couple of things about animated ABIF files, they're almost identical to AV1 video files. There are a few fields in the headers that are different and also, yeah, second, I was gonna say, we already said the only security in Chrome as of today. So now I'm gonna talk a little about ABIF and LCP. So LCP, I mentioned before, is the largest contentful paint. It's one of the core WebVital metrics that a lot of people look at and judge their, the quality of their site. So I was going to just show how to, how you can actually capture the LCP data. So let me switch back, get rid of the animated images. See nothing again. I'm also gonna add a little text area, just so we can output the LCP information on the Web page itself. Well, before we do that, I'll actually put in the JavaScript code to capture the LCP. So basically, the performance observer has one parameter, it's an entry list. The entry list should contain only one element and you can get the LCP from the start time attribute. I'm also gonna output the LCP time in the URL. The URL should match the URL of our ABIF file. So let me add ABIF image. I'm actually gonna add all of them. I'm copying and pasting just to save some time here. So I added the ABIF, the WebP and the JPEG to the picture. Now, the one thing to note, let's see if I reload this, I don't know why, but in CodePen, I don't always get the LCP. I think CodePen might be taking control of it, so it doesn't help. Oh, there we go. So sometimes it works in CodePen, sometimes it doesn't. I'm not quite exactly sure why, but outside of LCP, I'm just outside of CodePen, the LCP gets fired 100% to show you now. But I output it here, the LCP. So this is the LCP, the time is in milliseconds and you can see the URL is the ABIF file for the LCP. Yeah, there's not much going on in this example webpage. You just have a text area and then an image to a picture element. So let me go back to the presentation. All right, so it's a quick interlude, WebP. So WebP is supported in all browsers now. I mean, I know we're talking about ABIF, I just wanna kind of mention this here, because as Henry said, ABIF is kind of on the bleeding edge and we're starting to see some adoption is definitely growing a lot. But WebP is supported in all the major browsers now and WebP should be better than JPEG. Losses WebP should be better than PNG and animated WebP should be better than GIF. Basically, if you're still serving JPEG, PNG and or GIF, really should look into re-switching to WebP. As, since all the major browsers support it, there's very few reasons not to serve WebP over those other kind of more legacy image formats. I'm gonna talk about another way to kind of measure performance. This is for those developers that want to get a little more granular information than what LCP gives you. One alternative is to use the image decoder API from the WebCodex API. So I listed the URLs to get a little more info on both APIs. As you can see, the image decoder API is a relatively new API, only releasing in Chrome and Edge 94. Firefox also worked on the specification, so I'm assuming implementation will hopefully be there in the near future. So let me switch back and I'll show you how to use this. There's gonna be a lot more JavaScript code for this one. So if you wanna follow along, I have the image decoder example code pen shared at that link. Okay, so first let me get rid of the picture tag, the picture element. I'm gonna leave the text to area element and then I'm gonna add two buttons, one to load an ADIF image and one to load a JPEG. Yeah, I forgot to mention the other, with the LCP, like the reason I didn't have a button to load the image in the LCP example is because rendering the button will trigger the LCP. As you can see here, you have the LCP timing and the URL blank and it's not loading an image. It's basically from the LCP, so I'm gonna get rid of the JavaScript for the LCP. And then next, copy in some JavaScript. First part of the JavaScript is basically just some global variables to make life a little easier for this example. Then I'm gonna add two functions. So these are the functions that the buttons in the page call. So load, ADIF function, load JPEG function. Basically is telling the, the first part of functions is just telling the text area that it's loading a JPEG or an ABIF. And then we get the image URL and the mind type and we call the download image function, which I will add next. So the download image function and just takes the image URL and the mind type, gets the time right before the fetch. We're just using an XML HTTP request to get the image, the compressed image data. We call the onload function, which will, when the image is downloaded, we'll call the decode image function, which I will call copy now. Okay, so the decode image function takes the encoded image data and the mind type. I first get the time after the download so we can track that later. I create an image decoder using new image decoding API. And I actually decode the image and then I give it a callback for render image, which I will then go and copy now. And then, so here's the render image function. So the render image takes the decoded data. I first get the time for when the decode was ended. Then I get the canvas that I added below the two buttons. And then I draw the decoded image on the canvas, get the time after the render, and then I output all the download decoding render as well as the total time into the text area. So I'll go ahead and if everything is correct, I'll click the load JPEG button. So you can see the download, the decode, and the render time and the total time and we have our image that we've been using. So this is the JPEG. I'll do this a couple more times. Oh, so now the download is much quicker because we're using, because the image is cached. Let me put on the developer tool. Just so, and I have it set so to not cache in my developer tools. Okay, so we'll try this again. So now the JPEG is taking much longer. You can see, what you do, it's kind of ready, I guess in this server, I guess in the edge server, it goes much quicker. But on average, it takes, you know, probably 100, 150 milliseconds to download about 90 milliseconds to decode and then, you know, less than 10 milliseconds to render for the JPEG. Now, you can do the same for AVIF. You can see once you download the first time, it gets much quicker to download, you don't want a high-speed network. So it turns to about 50 milliseconds to download and then decode is about 48, 50 milliseconds to decode. So if you notice, the actual decode of the AVIF image is quicker than the decode of the JPEG image. This might be a little counterintuitive. Because the more modern codecs are more complex and should take more time to decode, which is usually true. But the other thing to note about image codecs that in general, the more data to decode, or put it another way, the bigger the encoded image, the longer it takes to decode in general. So what is happening is that our AVIF is about 80% smaller than our source JPEG. And for that reason, it's much quicker to decode. If you were to take the JPEG image, make it much smaller or maybe put it in a better compression or even make it about the same size as the AVIF, but at worst quality, I would expect the JPEG to decode faster. Back to the presentation. Okay, Henry says, size or weight, which matters more for decode speed? What do you mean by weight exactly? Just how the different options you give it to compress? Ah, okay. So all right, so like resolution versus size. I think in general, yeah, the resolution will affect the speed more than the size, in general. That's with everything with compression, it all depends on your source images and also kind of in your coding settings as well. But as a rule of thumb, the resolution will take longer to decode than the size, if you're going up in twice resolution versus twice the size, usually the resolution will take longer. So that actually concludes our session for CDS Intro to AVIF images. I just want to thank everyone for joining.