[hvm]

Lossy video compression currently does that - it creates key frames at regular intervals and all the frames between (i-frames) are based on the previous key frame. Some codecs have i-frames depend on multiple previous frames.

E.g. a 320x240 video has 3 seconds at 25fps, i.e. 75 frames and key frames are created each second. Frame sizes will then be something like:

  20kB 2kB 3kB 1kB 2kB [20 more frames] 22kB 2kB 1kB 2kB [...]

Now, this technique might be good when compressing images - have a large image that roughly approximates the original and then a smaller one reducing the errors. Or even better, multiple smaller images that correct local errors?

I suggest we create a startup immediately. Someone might already have a cool video explaining how their compression algorithm is going to change the web and the world.

edit: others already thought of this: https://sonnati.wordpress.com/2010/10/19/h-264-for-image-com...

[pointernil]

First! We need a cool name! ;)

[hvm]

shadow codec - the 'shadow' is either the large approximated image or the small one that only shows the details. Probably the small one :D

[pointernil]

Yea! To get the js-css-trickster-folks on board the first version works 'obviously' by splitting an image into the shadow and non-shadow parts offline. The result gets recombined in the browser by overlaying them and using some fancy blending modes. Some micro-benchmarking should be able to show that the two shadows (jpg compressed 'obviously') plus css and js put together are smaller than a simple jpg compressed version of the input image... Go! Go! Go! Before Hooli steals the idea... ;)

[maxpersson]

Pied Piper :)

[pointernil]

To prevent confusion and to stay consistent with my nick, I suggest: "Piper pied"