The idea is to take a video input stream from the default webcam, and then translate each pixel into an ASCII character depending on it's
brightness
value and then print it into the terminal.The
brightness
orintensity
is calculated as amean
of the R, G and B values of each pixel.Each frame is thus encoded into a string of these characters and then printed into the terminal.
I played around with the string of characters that the brightness depends on, and figured it looks best when the shadows and highlights are "muted", i.e, having light characters.
I don't know, I just wanted to do it.
It seemed like fun and I haven't seen > anyone play with OpenCV in C++ before. It was a good learning experience, and I also got to put my C++ knowledge to the test.
- Just clone the repo
- Run the
Video_to_ASCII.sln
file in Visual Studio- As a pre-requisite, you need to have OpenCV installed on your system and linked to the project.
- Once that's done, simply hit
Build
and there you go!
There are 4 different "styles" of ASCII that have been implemented.
- Go from the camera screen to the Menu when user hits [Esc]
- You can increase/decrease the refresh rate of the output stream on the fly, however, this is limited by the speed of the webcam as well as the speed of printing characters in the terminal.
- You can also increase/decrease the resolution of the output stream on the fly, in the terminal window. However, this feature is buggy and increased resolution will put a harder hit on the CPU. As such it is not recommended, but it's there.
I thought about adding GPU acceleration to this, however, it doesn't make sense to run such a sequential program on a GPU. The overhead of copying data to and from the GPU would be too much and may even slow down the speed of the program significantly as compared to running it raw on the CPU.
Even in the case of parallelizing the program, I wasn't sure how to pull that off given the sequential nature of the program.
One feature that DEFINITELY can be implemented is a frame buffer, so that the program can run at a much smoother frame rate. Currently, the frames are all processed in real-time and directly pushed to terminal. Far from ideal, this is the main reason why the program is so slow when more colors are used.