5 ms·

Sounds complicated. I think we just need to do something similar to HTML5 'video' tags for the 'image' tag, where you simply put a list of file paths in the tag

Sounds complicated. I think we just need to do something similar to HTML5 'video' tags for the 'image' tag, where you simply put a list of file paths in the tag, and the browser selects the best one to request, only with different resolutions instead of different file encodings. We could have a standard notation like adding "_x2" to the double res image filenames, and the browser selects the appropriate one to load. Then, we can support current image formats in the way you envision. Also, anything you have vectorized should be in SVG format, including text in non-web fonts.

archgrove 15y ago
That's fine if a) you're willing to maintain two image sets and, b) the only two resolution images you need are "normal" and "2 x normal". The advantage of a progressive quality system is it scales to arbitrary requirements in a single resource. One file provides 1x, 2x, 3x, 3.14x etc.
- beagle3 15y ago
  Storage is too cheap to care these days. When $110 buys you 2TB (this morning on Newegg), then doing it on the fly and caching the result has about 100x better ROI than trying to solve it with a smart format. Remember, we're speaking about still photos here, where high retina quality ones rarely take more than 500k each, so 2TB buys you room for 4,000,000 photos (and since you'll be caching the lower res 200K images, it actually buys you room for 10,000,000 million photos) That's not the case for videos - netflix, hulu and friends have multiple copies of each 1GB optimized for different devices. On-the-fly conversion is not possible, and the stream are significantly difference. For them, a reasonable, universally supported progressive video format will indeed make a huge difference
  - scott_s 15y ago
    I don't think archgrove's point was about storage, but about the extra friction of tracking N files instead of 1.
    - beagle3 15y ago
      That might be, but with the right Apache, nginx, varnish (take your pick) module, this friction will be reduced to saying something like: lower_res { Request /lowres/*.jpg Provide /highres/$1.jpg Downscale 50%,50% Cached_on /mnt/cheapdisk_that_can_go_away_at_any_time } I'm not aware of such an existing module, but I'm sure a good one will appear within the next couple of years of it does not yet exist. Compared to developing and deploying a new progressive format (across users, web servers and web browsers), the effort -- both in developing this module, and in configuration, is negligible.
- WiseWeasel 15y ago
  Problem with new formats is legacy support. Something that could degrade gracefully on browsers that don't add support would be very welcome. Maybe the best solution is to keep the current 'img' tag notation, but somehow indicate to browsers that double-rez assets are likely to be available at something like 'filename_x2.ext', and they should request those when they come across an img tag, instead of 'filename.ext', falling back with a second request for the latter in case the '_x2' isn't found. Something like: <meta img-x2-res="_x2" /> Encoding the image twice with a standardized addition to the filename is just an extra bit to add to the export macro. The image storage is irrelevant for most cases (assuming you compress appropriately); it's the bandwidth and request volume that's precious.
  - saurik 15y ago
    If you are going to do that you may as well have a meta tag to set a suffix "to find the jpeg2000 version of the image", and browsers that understand that format can then get the better format.
    - WiseWeasel 15y ago
      Not a bad idea. The meta tag should be made our bitch, so we don't have to work so much, and our sites can degrade gracefully.
ryannielsen 15y ago
In fact, something very similar to what you describe is what's being implemented right now: https://bugs.webkit.org/show_bug.cgi?id=80322 https://bugs.webkit.org/show_bug.cgi?id=80322 I'd like to propose a new function for the Images module. This function will allow developers to provide, in a compact manner, multiple variants of the same image at differing resolutions. Using @media pushes the two asset references apart from one another, whereas such a function keeps related asset references together. It also helps keep selectors DRY. We've called it image-set(), and it takes one or more image specifiers.
- WiseWeasel 15y ago
  Wow, not only does that notation seem like a huge pain in the ass, but it's only for CSS; doesn't fix the html. https://plus.google.com/115203843155141445032/posts/BrrLGL5kREf https://plus.google.com/115203843155141445032/posts/BrrLGL5k... -webkit-image-set( url(image.png) 1x, url(image@2x.png) 2x ) That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there.
  - ryannielsen 15y ago
    Yep, a solution is still needed for content images. That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there. You assume the developers can guarantee all image assets will be 2x. For quite some time, I doubt that'll be the case. And, given that, if the browser just naively requested 2x assets, there would be some set of wasted http requests that just add overhead and significantly delay page load. Explicitly declaring the 1x and 2x images' existence is a far better solution, even if it is more verbose. The UA can't be guessing about the existence of resources if it's also to be efficient.
    - 15y ago

archgrove 15y ago

That's fine if a) you're willing to maintain two image sets and, b) the only two resolution images you need are "normal" and "2 x normal". The advantage of a progressive quality system is it scales to arbitrary requirements in a single resource. One file provides 1x, 2x, 3x, 3.14x etc.

beagle3 15y ago
Storage is too cheap to care these days. When $110 buys you 2TB (this morning on Newegg), then doing it on the fly and caching the result has about 100x better ROI than trying to solve it with a smart format. Remember, we're speaking about still photos here, where high retina quality ones rarely take more than 500k each, so 2TB buys you room for 4,000,000 photos (and since you'll be caching the lower res 200K images, it actually buys you room for 10,000,000 million photos) That's not the case for videos - netflix, hulu and friends have multiple copies of each 1GB optimized for different devices. On-the-fly conversion is not possible, and the stream are significantly difference. For them, a reasonable, universally supported progressive video format will indeed make a huge difference
- scott_s 15y ago
  I don't think archgrove's point was about storage, but about the extra friction of tracking N files instead of 1.
  - beagle3 15y ago
    That might be, but with the right Apache, nginx, varnish (take your pick) module, this friction will be reduced to saying something like: lower_res { Request /lowres/*.jpg Provide /highres/$1.jpg Downscale 50%,50% Cached_on /mnt/cheapdisk_that_can_go_away_at_any_time } I'm not aware of such an existing module, but I'm sure a good one will appear within the next couple of years of it does not yet exist. Compared to developing and deploying a new progressive format (across users, web servers and web browsers), the effort -- both in developing this module, and in configuration, is negligible.
WiseWeasel 15y ago
Problem with new formats is legacy support. Something that could degrade gracefully on browsers that don't add support would be very welcome. Maybe the best solution is to keep the current 'img' tag notation, but somehow indicate to browsers that double-rez assets are likely to be available at something like 'filename_x2.ext', and they should request those when they come across an img tag, instead of 'filename.ext', falling back with a second request for the latter in case the '_x2' isn't found. Something like: <meta img-x2-res="_x2" /> Encoding the image twice with a standardized addition to the filename is just an extra bit to add to the export macro. The image storage is irrelevant for most cases (assuming you compress appropriately); it's the bandwidth and request volume that's precious.
- saurik 15y ago
  If you are going to do that you may as well have a meta tag to set a suffix "to find the jpeg2000 version of the image", and browsers that understand that format can then get the better format.
  - WiseWeasel 15y ago
    Not a bad idea. The meta tag should be made our bitch, so we don't have to work so much, and our sites can degrade gracefully.

ryannielsen 15y ago

In fact, something very similar to what you describe is what's being implemented right now: https://bugs.webkit.org/show_bug.cgi?id=80322 https://bugs.webkit.org/show_bug.cgi?id=80322 I'd like to propose a new function for the Images module. This function will allow developers to provide, in a compact manner, multiple variants of the same image at differing resolutions. Using @media pushes the two asset references apart from one another, whereas such a function keeps related asset references together. It also helps keep selectors DRY. We've called it image-set(), and it takes one or more image specifiers.

WiseWeasel 15y ago
Wow, not only does that notation seem like a huge pain in the ass, but it's only for CSS; doesn't fix the html. https://plus.google.com/115203843155141445032/posts/BrrLGL5kREf https://plus.google.com/115203843155141445032/posts/BrrLGL5k... -webkit-image-set( url(image.png) 1x, url(image@2x.png) 2x ) That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there.
- ryannielsen 15y ago
  Yep, a solution is still needed for content images. That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there. You assume the developers can guarantee all image assets will be 2x. For quite some time, I doubt that'll be the case. And, given that, if the browser just naively requested 2x assets, there would be some set of wasted http requests that just add overhead and significantly delay page load. Explicitly declaring the 1x and 2x images' existence is a far better solution, even if it is more verbose. The UA can't be guessing about the existence of resources if it's also to be efficient.
  - 15y ago