After getting started with the basic brightness tracking code for my project, I’ve now been continuing on with the coding of my Processing creation. As I pointed out last time, the first thing I needed to sort out was some kind of threshold light level where the system would start drawing from the input brightest point. The theory behind this is that that if I can control the environment to some extent that the sketch is positioned in, I can aim to ensure that the only light source above a certain level will be the light being controlled by the user as the interaction method.
To figure out a good level to start working with, I made a few small changes to the code I had already written. Firstly, after using OpenCV to find the brightest point of the image each frame, I then simply printed this value to the console so that I had an idea of what the brightest ambient light level generally was in the environment I was developing the project in (my room).
This code simply takes the vector location OpenCV gives as the brightest point in the image, and then finds the brightness of the pixel at that location in the camera feed. I then ran the code with this line added to it, and monitored the values it was returning. Then, to test the scenario of an input light being in use, I held the LED light on my mobile phone in front of the camera and looked at the brightest point values again.
I found the brightness of the brightest pixel under normal conditions (just ambient levels) to be generally under 200, with the value tending to stay between about 160 and 190. When I held the light in front of the camera to simulate a user being present, the value increased to over 250. With this in mind I chose a starting threshold to test at of 240 to allow for slight changes in the brightness of the light being used, although I realise this level may need to be changed when using the sketch in different spaces – unfortunately one of the issues with light tracking in the way I am going about it.
To help test the project, I then overlaid the output of the camera to the screen so I can see if the outcome of the input actions using the light source lines up correctly with the visuals produced. After making these changes, this is what I was left with.
As can be seen by this, these changes worked to ensure that currently the only light bright enough to be recognised as the input for a drawing is the one I intend the user to be holding. One thing I realised, however is that the input shows up on the screen in reverse from the perspective of the user, due to the nature of the camera’s perspective. This is something which I can fix by simply inverting the x-coordinates of the brightest point before drawing to the screen. For testing purposes, I will also invert the camera output, however I don’t intend this to stay as a feature of the final project.