6 ms·
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 fra
by hvm 11y ago
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-compression/ https://sonnati.wordpress.com/2010/10/19/h-264-for-image-com...
- pointernil 11y agoFirst! We need a cool name! ;)
- maxpersson 11y agoPied Piper :)
- pointernil 11y agoTo prevent confusion and to stay consistent with my nick, I suggest: "Piper pied"
- hvm 11y agoshadow codec - the 'shadow' is either the large approximated image or the small one that only shows the details. Probably the small one :D
- pointernil 11y agoYea! 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... ;)