5 ms·

This would be great. A lot of "responsive" sites nowadays use only one image as well, the highest resolution available. So you are downloading that 4K jpeg whet

• colanderman 11y ago
  Progressive JPEG has supported this for decades. Anyone over 25 should remember them from dial-up years.
  • hansjorg 11y ago
    I think the suggestion is that the client could just stop downloading at a set threshold, maybe taking current bandwidth, cost, etc. into consideration. Judging from the video, something like that could work very well (and much better than with progressive jpegs).
    • radarsat1 11y ago
      But how is that different from progressive JPEG?
    • guelo 11y ago
      It's an interesting concept. But I'm not sure how it could work. Resizing introduces artifacts so best quality is always going to be achieved by reencoding for different resolutions. Also, how would the client know when to stop downloading?
      • iopq 11y ago
        The client would download the first 1KB for an icon, 4K for a thumbnail and the whole image for the full size. The best part is that all of those are actually the same file, not separate embedded thumbnails inside the file. The client could decide BY ITSELF to download only 2K for a thumbnail because it's currently on 3g.
        • guelo 11y ago
          Where are you getting 1KB and 4KB from? The compression is highly dependent on the image so there's no way to know the quality of the thumbnail image.
          • iopq 11y ago
            Maybe a future version of the format would specify useful cut-off points for browsers to make the decision inside the header. Then the browser can decide to download 4K version on wifi and 1K version on 3g.
      • hansjorg 11y ago
        You'd need to set the thresholds in the file manually, based on the artists judgement of quality. It would take a few extra seconds when creating it, but could save both bandwidth and create a better user experience on mobile.
        • magicalist 11y ago
          This will have to be automated or it's going to be really annoying for development. To eliminate that, maybe the file format could incorporate some internal tags for good size thresholds, or even just a handful of coefficients at the beginning for a simple curve approximating the byte-to-resolution mapping.
  • jessaustin 11y ago
    However jpeg is lossy.
    • colanderman 11y ago
      So is a FLIF that you only download half of.
      • mthoms 11y ago
        If compared to the original yes, but that's apples to oranges. They are different resolutions. It'd be more accurate to compare it to a pre-generated resizing of the original image (at the same effective resolution as the "half downloaded" FLIF).
        • colanderman 11y ago
          A compressed image which does not reconstitute to the original image is by definition lossy. You can't scale a PNG down by 25% and call that "lossless compression". Though I'll gladly take your logic and call the first 1/64th of a progressive JPEG lossess (which it is, since at that point you only have the DC offsets of basic blocks, which undergo no lossy compression).
          • mthoms 11y ago
            It's lossless (in theory) when compared to a 1/64th scaled version of the original image (which is what was clearly meant).
          • jonsneyers 11y ago
            I think JPEG's color transform is lossy, so even those basic blocks are somewhat lossy. A better approximation of the entire 8x8 block than the exact pixel at the top-left position of the block, which is what FLIF and PNG with Adam7 interlacing do, but still lossy. If you would take an image, magnify it by a factor of 8 in both directions so each pixel gets blown up to an 8x8 block, then convert it to JPEG, there is still some information lost.
  • kevin_thibedeau 11y ago
    And then there was magic of watching interlaced GIFs download before the era of JREG.
• acdha 11y ago
  Your example also shows why it needs to be left up to the browser: downloading a large JPEG makes more sense on an iPhone 6S+ with a 1080p display and LTE than the 1024x768 computers at the local school sharing a basic cable modem. The part which would really make sense for this would be something like an extension to <picture> or <img srcset> which would allow you to provide the byte ranges for each resolution so the client could issue a standard HTTP range request for the level of pixels it actually needs. You'd still have one file to manage and CDNs could cache it intelligently rather than lowering hit rates by caching different versions.
  • zyxley 11y ago
    I wonder if it would be feasible to have browser functionality that starts the download, then stops it once it has enough data to make an image the width of the element on the page. (Maybe then continuing the download later if it's resized larger?)
    • acdha 11y ago
      You could certainly build that in as a heuristic similar to how many browsers implement <video>: issue Range requests for a certain chunk size and stop once you have enough data. It's not as efficient as being able to get it all in one go but if you have a progressive image format that might be a better experience if it can start rendering quickly and fill details later.
• err4nt 11y ago
  Snall screens dont always have small resolutions. There are more pixels on an iphone than my laptop!