Hacker News Reader

Comment by moskie | Hacker News Reader

Would also be interesting to see if they could recreate the effect of the original video in JS also.

Isn't the algorithm just, filter out the greenscreen, for each remaining pixel draw it to the buffer, draw the buffer to the screen?

That doesn't seem more complicated than the examples they showed.

No one said it would be MORE complicated than the examples.

"Would also be interesting" and "fun to compare" give no implication of relative difficulty. I would like to see the algorithm though so please post the code if you get it working in JS! That would be awesome!

It is actually slightly more complicated. The existing effects work in GLSL and are just transforming single frames of video. For that effect to work, you need the previous buffer states; this means that seeking will cause the image to be different, and you need to feed the previous render state back as a texture.

Just draw the frames to a 2D canvas, without clearing it, then back to the background buffer.

You still need to remove the green-screen. This either means an expensive process on the CPU side, or pushing the frame to the GPU to remove it with a shader and then using RTT and rendering that or reading the framebuffer and drawing that to a canvas. Note, it's really not difficult to do this, it's just slightly more complex than the other effects, is all.

The demo is already removing the green-screen, I don't think that's the most expensive part.

Well no, the demo is removing the green screen but only in the shaders. As I said, this really isn't a big deal, but it does add complexity.

Deleted comment

Well no, because each frame builds on all the frames before it. Either way, seeking is still broken unless you run through all the frames up to that point.

Deleted comment

Each frame has the greenscreen turned into a fully transparent pixel, then gets blitted onto a buffer containing all of the existing buffer's data. That means that for each frame, you're building on the data from every frame that came before. This is fine if you're playing from beginning to end, but when you seek, you're going to break that continuity.

Deleted comment

Yes, you do need to process from beginning to end. If you look at the original video, you see that each frame builds on the one before it, which builds on the one before that. Remember, the buffer is never cleared -- it's just overwritten with a few new pixels (the dude moving) each room.

Deleted comment

Oh, yes! My apologies. I'm talking about the original video here: http://www.youtube.com/watch?v=12zJw9varYE

I (very hackishly, but nonetheless) got it to sort of work:

http://imgur.com/a/PQX63#1

It's full of lots of (mostly green) noise because the demo's chroma key algorithm/parameters aren't that good, but it was fun to do!

Reply on news.ycombinator.com