search

FLIF-hub / FLIF

Free Lossless Image Format
Other
3.72k stars 228 forks source link

Getting byte offsets by API? #440

Open saschanaz opened 7 years ago

saschanaz commented 7 years ago

I have been thought that FLIF can introduce <picture>-like behavior on traditional <img> element if a browser can access byte offset information of a FLIF image.

My expectation:

  1. A browser first downloads the first few bytes of a FLIF file for its metadata.
  2. The browser gets a byte offset from the metadata to get the first progressive wave of the image.
  3. It also gets the byte offsets for further waves, and decides whether it needs them or not considering the current element size and DPI.
  4. The browser then downloads more bytes to show the best image quality with the minimum data transfer on the given element.
  5. (Resizing will trigger step 4)

I need a way to get byte offsets to do this, is this a possible scenario?

jonsneyers commented 7 years ago

The current metadata does not contain this information. There have been proposals to add a metadata chunk specifically for this purpose (see https://github.com/FLIF-hub/FLIF/blob/master/doc/metadata#L36), but unless we make it obligatory, it will only work if people actually add that chunk.

The problem with the above approach is that it requires an extra request just to load the information on how many bytes to request. The only way to avoid that is to put that information in the HTML in some way. One way to do it (theoretically) with currently available mechanisms is as follows:

<img src="image.flif" srcset="image.flif?truncate=12345 300w, image.flif?truncate=34567 600w"> where you would need a web server that parses these ?truncate=NNN query strings and simply returns a truncated version of the requested file. If some convention can be agreed upon, it could also be the browser who parses that, so they can request the indicated number of bytes (and if a resize/zoom in happens, it could be smart enough to see it's the same file so it doesn't need to request the first part again when loading the higher res image). This would be a nice way to add the functionality with graceful degradation. CDNs could also be made smart enough to understand the truncation offsets so they only have to cache one file.

Of course you would need some automated way to inject these truncation offsets into the HTML -- this is why I added the --breakpoints option to the flif utility, since that would be the main thing you need for that.

This approach would also be useful for progressive JPEGs by the way.