\n \n Skarminspelning.2024-07-11.111523.mp4\n \n
\n\n \nThe behavior you are describing is characteristic of the progressive decoding process used in WebP images, specifically for the lossy WebP format. Progressive decoding allows an image to be partially decoded and displayed before the entire file has been downloaded, improving the perceived load time on slow connections. Here’s a breakdown of how this works:
\n- \n
- \n
Initial Decoding (Grayscale or Low-Quality Color): The WebP format first decodes a low-quality preview of the image. This initial pass often involves only the luminance (grayscale) data, giving a quick but rough idea of the image's overall structure and content. This step is fast because it processes less data.
\n \n - \n
Intermediate Decoding (Green Tint): During this stage, additional chrominance data is decoded and applied. Sometimes, due to the way chrominance data is processed, you may see a color cast, often green, which is one of the primary color channels. This step refines the image further, adding more detail and color information, but it may still be incomplete.
\n \n - \n
Final Decoding (Full Color): In the final stage, all remaining data is decoded, resulting in a full-color image with complete detail. This stage ensures that the image is displayed as intended with all the color channels accurately rendered.
\n \n
This progressive decoding technique is particularly beneficial for users on slow connections, as it allows them to see a quick preview of the image, improving the user experience while waiting for the complete image to load.
\nProgressive decoding in WebP is similar to other formats like JPEG 2000 and interlaced PNGs, where multiple passes refine the image quality progressively.
\nSwitching to lossless WebP would prevent the staged decoding behavior you described. Here’s why:
\n- \n
- \n
Lossless WebP Decoding: Lossless WebP images do not use progressive decoding. Instead, they are decoded fully once the entire image data is available. This means that the image will not appear in stages (grayscale, green, then color) but will be displayed in its full fidelity only after the complete data is downloaded.
\n \n - \n
Instant Full Quality: Since lossless WebP images are designed to preserve all original data without any loss, they don’t employ the same progressive techniques used in lossy WebP. The entire image is decoded at once, ensuring that users see the complete image in full color and detail immediately after it finishes downloading.
\n \n
While lossless WebP images eliminate the staged decoding issue, they typically have larger file sizes compared to lossy WebP images, which can lead to longer download times, especially on slow connections like 3G. It’s a trade-off between avoiding progressive rendering and managing file sizes and download speeds.
\nIf you prioritize preventing the progressive appearance of images, using lossless WebP is a viable solution. However, be mindful of the potential impact on loading times and bandwidth usage.
","upvoteCount":1,"url":"https://GitHub.com/SixLabors/ImageSharp.Web/discussions/371#discussioncomment-10020062"}}}Loading resized images in layers on slow connections #371
-
|
Having implemented ImageSharp and resizing images used for background image in Hero top of the page. Image does not load like this without the resizing utility, and having tried format/encoder WEBP and JPEG. Are there any solutions not to load images in this way? /my-image.jpg?format=wepb&quality=90&width=1920&height=1080 Skarminspelning.2024-07-11.111523.mp4 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
The behavior you are describing is characteristic of the progressive decoding process used in WebP images, specifically for the lossy WebP format. Progressive decoding allows an image to be partially decoded and displayed before the entire file has been downloaded, improving the perceived load time on slow connections. Here’s a breakdown of how this works:
This progressive decoding technique is particularly beneficial for users on slow connections, as it allows them to see a quick preview of the image, improving the user experience while waiting for the complete image to load. Progressive decoding in WebP is similar to other formats like JPEG 2000 and interlaced PNGs, where multiple passes refine the image quality progressively. Switching to lossless WebP would prevent the staged decoding behavior you described. Here’s why:
While lossless WebP images eliminate the staged decoding issue, they typically have larger file sizes compared to lossy WebP images, which can lead to longer download times, especially on slow connections like 3G. It’s a trade-off between avoiding progressive rendering and managing file sizes and download speeds. If you prioritize preventing the progressive appearance of images, using lossless WebP is a viable solution. However, be mindful of the potential impact on loading times and bandwidth usage. |
Beta Was this translation helpful? Give feedback.
-
|
Great explaination, James! Thanks. Ill do some further testing and inform the customer/client. |
Beta Was this translation helpful? Give feedback.
-
|
Is it just the FileFormat parameter that I change or is it also something else? |
Beta Was this translation helpful? Give feedback.
-
|
That’s the one yes. |
Beta Was this translation helpful? Give feedback.
The behavior you are describing is characteristic of the progressive decoding process used in WebP images, specifically for the lossy WebP format. Progressive decoding allows an image to be partially decoded and displayed before the entire file has been downloaded, improving the perceived load time on slow connections. Here’s a breakdown of how this works:
Initial Decoding (Grayscale or Low-Quality Color): The WebP format first decodes a low-quality preview of the image. This initial pass often involves only the luminance (grayscale) data, giving a quick but rough idea of the image's overall structure and content. This step is fast because it processes less data.
Intermediate Decoding…