[wonderlg]

Years ago I remember seeing a progressive image format that was supposed to solve the resolution issue. The loader could stop loading as soon as it figured it had enough quality. This meant that you could have a single, large image file, that could weigh a few KB when displayed as a thumbnail.

It’s 2020 and its mind-boggling that this isn’t a standard behavior already.

Imagine right-clicking on a thumbnail and being able to natively save a 4MB file from it.

Imagine having a single <img> that can be zoomed in all the way to 100% just like your phone’s Photos app can do, without loading the whole image beforehand.

[bscphil]

The codec you're thinking of is FLIF. [1]

The issue with doing this is not with the basic idea, obviously it would be desirable if we could do it, but with the fact that it's actually much less efficient to encode the entire file this way if you want real progressive loading (i.e. stop at any point). It's much more reasonable at present to just dynamically load a reasonably sized image for the current viewport, even before you get to issues like format support.

[1] https://flif.info

[SahAssar]

That argument ignores everything that new formats and container formats can allow for. And if the argument is to put older formats "first" then you need to download older formats first to get the features of new formats and need to figure out the order of competing modern formats (like JPEGXR vs JPEG2000 vs WEBP).

This is basically a solved problem when people use mime types properly for formats. For sizes we'd need a similar way to mime types to ask for a size, html solves this for images with srcset but I'd rather it be within the transport mechanism rather than in the markup.

Requesting an image should be requesting a image, not a specific representation of that image. The representation should be part of the content negotiation that is already a part of the protocol.

[wonderlg]

I think you completely misunderstood.

> Requesting an image should be requesting a image, not a specific representation of that image.

This is exactly what I’m saying. The image is one, it’s the browser that decides how much of it to load.

It’s the current picture/srcset-based situation that is “a specific representation of that image”

> For sizes we'd need a similar way to mime types to ask for a size

Now that is complicating things. Suddenly the server has to produce/return different resources based on a header. The solution I described could be delivered by any dumb HTTP2 server, without preprocessing.

Technically what I’m describing is already possible with any progressive format like JPEG; The only missing part is that the browser should pause/resume the loading as it sees fit.

All I want for Christmas is:

    <img src="you.jpg" progressive>

The obvious advantage is that if the window size changes, the browser only has to fetch the missing data, not a whole new file.

[Traster]

I think what they were descrbing was more like this: A JPEG uses a Discrete Cosine Transform and then throws away the lower power (higher frequency) values, but does it in a fixed way(blocking). If you re-order the data such that you get all the blocks dc frequency first (rather than all the frequencies for block 0 first) you can stop at any time and you'll have the resolution you "paid" for - ie, your bandwidth is all used for resolution. It's not a bad idea, although I suspect the reason this isn't done is because you don't really need to decided between a 72kb and 73kb image, and in reality there's more to different resolution images than just saving fewere bits (read: interpolation techniques)