News for hackers. Stuff that matters.
Re:Video Vectorization by gruez on Monday July 20, 2020 @09:27AM (#23897572)
>Our first vectorized proof of concept for animations is a 17 second clip of the Simpsons located here. Keep in mind, our technology is still at a very early stage, and this is much optimization work left to be done.

>https://files.vectorly.io/demo/v0-2-simpsons-250kbps/index.h...

There isn't a raster version to compare to, but that looks noticeably worse than what I'd expect from a raster version. There's a lot of artifacting when there's motion, and the linework looks.... off.

>https://files.vectorly.io/demo/khan-20kbps/index.html

The khan academy one looks much better, although there's still some minor artifacting, eg. when the mouse comes close to the "O" in "O_2" changes a bit.

Re:Video Vectorization by pixelhorse on Monday July 20, 2020 @10:22AM (#23898121)
Most hand drawn animation wont't actually vectorize well, especially the ones from the hand drawn era, where every cel is a real painting:

https://caseantiques.com/item/lot-738-the-simpsons-animation...

Look at all that line detail. It creates subtle gradients in the final film, which don't readily transfer to vector graphics.

In this case, I think with some better pixel-based filtering before vectorization, they could've gotten a better result.

However, the much bigger problem is that the vast majority of animation uses paintings for backgrounds that aren't just solid lines and colors.

Re:Video Vectorization by AstralStorm on Monday July 20, 2020 @10:47AM (#23898338)
You can extend this easily and obviously by fitting gradients.

No patent should be granted for this technique on general. It is known from late 80s. Maybe some details.

Also maybe the patent office shouldn't grant the patent because "use ANN to fit x" is also obvious. Again, only for details.

Re:Video Vectorization by Jasper_ on Monday July 20, 2020 @12:44PM (#23899539)
The goal of a video codec is to precisely recreate the input image, and measure error metrics against an uncompressed input. I don't even see basic error metrics listed, but the visual fidelity is so noticeably terrible it would likely be absurdly off the charts.

I did a similar thing for the same motivation a while back (compress Khan Academy videos to a miniscule amount of data), and spent an hour or two on it. http://funny.computer/cloud/Endless/khanvx/player.html and came away thinking it would be exceptionally difficult to work in a general case, but it might be a small useful subset of a larger video codec.

This is not the first time people have tried to do vector video codecs, either. Remember the VSV project from University of Bath? https://www.youtube.com/watch?v=LKaixODJEmo

Re:Video Vectorization by flgr on Monday July 20, 2020 @10:18AM (#23898084)
Hm, unless I miscalculated the bit rate they use for the Simpsons demo is about equivalent to YouTube's 240p rendition (which uses 257 kbps; they use 250 kbps).

Looking at https://www.youtube.com/watch?v=a1nmZq1KEHk at 240p I think their Simpsons rendition looks better. But that's probably because of the low resolution. Makes me wonder how well H264 would perform with the same bit rate but a higher resolution.

I think it'd be best to have a 1 to 1 comparison between the two right on the vectorly site. I'm thinking that they'd have done that if they believed they were already ready to outperform, but that's a bit of speculation.

Re:Video Vectorization by xhkkffbf on Monday July 20, 2020 @11:43AM (#23898919)
I think their demos are pretty good. But it would be nice to offer some comparison of the bandwidth savings.

That being said, they're just starting and I'm sure they could find some fat to squeeze out of the data stream.