Hacker News Reader

Comment by 1qaz2wsx3edc | Hacker News Reader

Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file.

It should be up to the browser and the image file format to determine the best option.

View on HN

JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality.

Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.

I really wish the open-source JP2 situation was better. OpenJPEG is looking good but it's still in need of some performance work – which is a real shame since, as you pointed out, it'd be perfect for responsive imaging - just use HTTP byte ranges and it'd work with most proxies and caches, too.

That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.

You could avoid that with a simple optimization where the page could indicate the byte ranges for a tile level. Suppose something like this worked:

    <picture>
      <source srcset="foo.jp2 100w 100h range=1-<first layer>">
      <source srcset="foo.jp2 500w 500h range=1-<middle>">
      <source srcset="foo.jp2 1000w 1000h">
    </picture>

That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.

Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.

> more verbose, more error-prone and more confusing than just specifying different resources

That's largely opinion: are byte ranges really better than having to maintain clusters of related images? Any serious site already has to deal with things like cache invalidation when a source file changes and by the scale of things which sites do for performance this is certainly no worse than, say, JavaScript/CSS minification or UA sniffing.

I'm not a network engineer. But perhaps this wouldn't be a problem once `SDPY` is popularized.

It would be less painful but still a problem: SPDY / HTTP/2.0 allows you to send more traffic over a connection but they can't do much for round-trip latency if you need to do something like ask what sizes of an image are available. That's particularly painful on cellular networks with a delay measured in hundreds of milliseconds – SPDY's ability to ship many things in parallel would only come into play after the browser knew which resources to request.

There was, long ago, the lowsrc attribute, with a similar intent. It was deprecated.

Reply on news.ycombinator.com