Yet another responsive image system
Hi all,
I was surprised to see this method hadn’t been attempted before so I put together a demo (full explanatory post is here), here’s the tl;dr :
A resolution and bandwidth responsive image system is shown. All img tags start pointing to the low res image versions, then javascript downloads (in the background) difference files to upgrade the low resolution images into a high resolution images, and as such doesn’t waste http requests or data… oh and there are some fun kitten demos as well. All files can be found at github.com/pci/deltaimg.
I realise it probably only has niche usage, but it’d love some feedback.
This is a great idea! Using an existing standard to enhance images. Nice.
But… The diff files, in your kitty examples are too large to really make this useful.
For example:
place_kitty_3.jpg – 17.73 Kb
place_kitty_3_low – 7.73 Kb
place_kitty_3_low_to_med_diff – 18.83Kb – larger than the original, you could have just downloaded the original to replace the image.
place_kitty_3_med_to_full_diff – 52.66Kb! Alot bigger than the original!
Whilst I do appreciate that if the low res image size + diff image size is larger than the original there maybe some merit in this, but if the diff image is larger than the original, then I can’t see the point.
Do you have example of this working were the diff files are smaller than the original?
Haha – nice spot!
That’s actually because the cat diff jpegs were saved at 100% quality (while I was prototyping), switching to a more reasonably 80% makes them much smaller without any noticeable deterioration in resulting picture and, from memory, the combine total is similar to the full picture size. Also c.f. the second demo where 80% encoding is used and the total size of all three images is actually considerably less than the original.
I’ll push the smaller cat diff pictures to github tonight.
I did see the second example, I’m just surprised to see
( Low res size + low to medium diff size + medium to high diff size ) < original size.
I'd expect it to be higher – if not you've found some new magic compression!
Looking at it a bit closer – I think, your code creates the smaller images at 80% compression, and then creates the diff images, from the smaller images at 80% compression, thus (sort of) double compressing them at 80%. I'm assuming, and please correct me if I'm wrong, you haven't compressed the original in the same way, which is why it is so huge.
I had a look at the bridge image, I think I'd compress the full image to 650Kb (ish), which avoids any noticeable distortion. (Although I admit I don't have a great eye for these things!) I'd love to see what you could compress the low res + diff images down too, while avoiding noticeable distortion.
Chris.
Chris,
You’re right, I haven’t invented a new super compression!
The method is lossy, that’s just part of the method. It’s also why it can happen that (sum of 3 images < starting image). The final resulting deltaImg picture from the demo would be about 1.2Mb, so you download 1.3Mb to end up with a 1.2Mb image.
Double compression – the low-to-med-diff image is indeed a compression based of a compression, however the med-to-full-diff uses the original image so only has a single compression step. A reflow of the script could also remove the double compression of the first diff and would be an interesting experiment!
As for how much you can decrease the full image by – well that is very much the problem at hand. For some cases 650Kb might be fine, for others the full 5.3Mb file might be required. The point I was trying to convey with the demo was more that you could get a usable image in a fraction of the time and then go from there, rather than having only the top 10% of the image loaded by the time you've finished reading the page in question.
Phil
Sorry I think you misunderstood me. This example doesn’t display real file sizes, as the low res / diff images are compressed, while the original image isn’t –
Low res image loaded (88Kb) – compressed
Medium res image loaded (321Kb) – compressed
Final delta image loaded (1.3Mb) – compressed
Total – 1.3Mb(ish)
Full Image 5.3Mb – no compression
Total – 5.3Mb
In this case, it’s the compression that makes the file sizes smaller, not the fact that they are a ‘diff’ image.
For your bridge image, this image, I’d reduced it to 650Kb (Max, this is being quite generous I’d probably make it smaller) – this is much smaller than your diff images. I’d love to see what you could compress the low res + diff images down too, while avoiding noticeable distortion.
Unless the diff image, for this image is smaller than 650Kb, than you may as well download the original.
Chris.
Chris,
It seems we’ve hit the indention limit, so I’ll have to reply in-line.
Firstly, the original 5.3Mb jpeg is compressed (in this can a compressed version of a flipping big NEF file). The diff’s are based of this and so when they’re saved this introduces a second lossy compression, so the final image from deltaImg will always be a lossy version of the original.
As for the question about how low you can push the filesizes before noticing a difference – I don’t really know. It’ll depend a lot on the image in question: size, type, composition, even the colourings used can make a difference; but it is a very interesting question.
Your right it is an interesting question! The usefulness of your code / concept is based on file sizes!
Your concept of downloading a ‘diff’ image to enhance the original file, is based on the assumption that the diff image file will be smaller than a compressed version of the original.
But you don’t have a real example that shows this, yet!
Chris.
I’ve updated demo 2 to have a more equivalent final image (but bare in mind it’s not an exact science!). So the total download for deltaImg is 1.3Mb and the equivalent right-hand image is 1.2Mb.
By improving the encoding/decoding scheme the diff file compression could probably be improved a bit further without losing any information, but that’s a job for another day.
Hi Phil,
How did you get to 1.2Mb? Is this an 80% compression of the same image that deltaImg runs from?
If so then this is a really good sign!
I’m not sure I can judge that these images are equivalent though, because neither is compressed anywhere near enough to start to distort – take the orginal bridge image and save it at 1.2Mb, and 1.3Mb, and you won’t be able to tell the difference very easily, which is where you example is currently at. Yes we can see the downloaded images are a similar file size, but this doesn’t necessarily mean equivalent image quality.
Take the bridge image and save it at 650Kb, and 550Kb, and you will be able to tell the difference, you can then really judge equivalance.
I’m sorry to bang on about file sizes, but I really think they are the key here – if the med to large diff image is smaller than a properly compressed full size version, then thats what you’ll want to download.
For this bridge image, I’d compress it down and serve it up at 650Kb.
Can the med to large diff bridge image come in smaller than this, and deliver an equivalent high quality image?
Also in you blog you talk about this being a solution to the responsive images problem, but this could be more than that! Think image scrollers, you could enhance the thumb to become the normal size, and then enhance the normal size to become the lightbox size!
Chris.
Chris,
I don’t have node.js installed here so checking the 650Kb will have to wait. But the two current images should be comparable:
The right-hand side image is a 80% compression of the original, but to show their equivalent I did a little digging.
Comparing the absolute difference of both images (RHS and final delta image) with the original shows the differences are in the same areas, mainly where the light hits the water, and both are of a similar amplitude.
Looking then to the standard deviation of the RGB channels from the original:
RHS – 4.04475
Delta – 3.72749
Which, if anything, suggests the final delta image is very slightly better than the RHS image.
Hope this helps
Clever, i like it! It’s potentially a useful way of dealing with this now, but I think answers a slightly different use case than picture itself – in that this solution can only be used to change the resolution of an image and not to supply a different image (it’s the same limitation that Adaptive Images has).
Of interest, what happens when a CDN or Proxy hits this? Would those devices cache the no-JS low resolution version? If so, that means anyone behind a proxy or wanting to use a CDN potentially couldn’t.
The CDN/proxy question is a good one.
My gut reaction would be that the proxy would cache the page (and the low quality image with it), but the first user visiting the site behind the proxy will fire off the ajax calls through the proxy, so the proxy will end up caching all three files and the method would still function.
Having tested it at lunch – it definitely works through my work’s proxy, so that’s at least one it works on!
Ooo, very nice!
Very clever.
Please read my proposal and tell me what you think:
http://opensores.za.net/2012/responsive-images/