Approximating images with Voronoi diagrams
codegolf.stackexchange.com
Approximating images with Voronoi diagrams
1–10 of 12 posts
Re: Approximating images with Voronoi diagrams
#2Re: Approximating images with Voronoi diagrams
#3Cool effect, though.
Re: Approximating images with Voronoi diagrams
#4An idea breading for long time already: in image compression, wouldn't a processing pass subtracting such a raw approximation of the image from the actual image allow for better compression? Is this used in any of the actually used image compression formats? If not why not? Why is jpg f.e. using only tiny local windows/blocks for processing?
See: https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml
Re: Approximating images with Voronoi diagrams
#5An idea breading for long time already: in image compression, wouldn't a processing pass subtracting such a raw approximation of the image from the actual image allow for better compression? Is this used in any of the actually used image compression formats? If not why not? Why is jpg f.e. using only tiny local windows/blocks for processing?
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...
Re: Approximating images with Voronoi diagrams
#6An idea breading for long time already: in image compression, wouldn't a processing pass subtracting such a raw approximation of the image from the actual image allow for better compression? Is this used in any of the actually used image compression formats? If not why not? Why is jpg f.e. using only tiny local windows/blocks for processing?
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 2k…
Re: Approximating images with Voronoi diagrams
#7Re: Approximating images with Voronoi diagrams
#8An idea breading for long time already: in image compression, wouldn't a processing pass subtracting such a raw approximation of the image from the actual image allow for better compression? Is this used in any of the actually used image compression formats? If not why not? Why is jpg f.e. using only tiny local windows/blocks for processing?
As to why it wasn't done for JPEG, etc.? Mostly the cost of hardware implementations in compute and memory. Think of all the cheap cameras etc. that used JPEG, the 8x8 block coding and integer representation of the discrete cosine transform coding made this possible.
Re: Approximating images with Voronoi diagrams
#9Earlier quoted context omitted.
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 2k…
First! We need a cool name! ;)
Re: Approximating images with Voronoi diagrams
#10Earlier quoted context omitted.
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 2k…
First! We need a cool name! ;)