Bigboard Rembrandt (Pcomp – Nov 1)

This week in Pcomp, I successfully completed the goal of last week’s Pcomp midterm of translating Rembrandt’s The Philosopher in Meditation up on my big LED board, using data extracted from the jpg image. Here is the result:


  • I could not get a handle on the bottom 3 LED rows that seem to act sporadically still. I have no idea how to control them or why they are not behaving when the rest of the LED matrix seems fine.


  • Creation of colour is different RGB value on a screen than on an LED light painting.
  • Transplant of image alone is not enough for an artistic rendering of Rembrandt’s Philosopher in Meditation on the bigboard.
  • Great, subtle range of detail is possible even with an inaccurate LED matrix. The human element shows (in line with the conclusions drawn from Danny’s wooden mirror).


I used the code from last week’s successfully transplant of a 9×9 pixel gif to the 9×9 (81 LED) matrix. With adjustment for the larger LED board and image (only adjustment of dimensions), and directly applying the code, at at the onset, the result looked like this.

With screen in front – quite a beautiful pattern, but not what I’m looking for. Why was the image so sporatic? I checked the data coming in from P5 and it looks like its correlated to the Rembrandt image. Why did the images work last week and not work this week?


I realized last week’s methods were appropriate for some symmetrical images, but inappropriate for asymmetrical images. I also knew that it displayed on the pixels differently than the image orientation. For instance see the following image and its display output:

This was the first clue something was insufficient about the code for my purposes.

I realized the problem was the conflict between directionality of the way the LEDs were wired (which starts from the bottom-right and proceeds in a zigzag left-to-right, right-to-left pattern) and how I programmed the p5 get() function (in loop that collects pixel data in a left-to-right way). The order of which to light the LEDs on a row that runs left-to-right is different from a row that runs right-to-left. Thus, I needed to find a way to construct the array to collect the LEDs in the exact opposite way the LEDs are wired to flow.

This involved intense manual calculations of where each LED row on the board start and ended. Precise LED locations for each row. (This was very difficult to do manually, given my tendency to make errors, so in the end I did it on Mac Numbers).

In the end even Numbers didn’t give me the accurate values. I tried to map out all the numbers ahead of time and it took a few hours. So I occurred to me to do it the manual debugging way: testing each row through commenting it out, and light up each row at a time, using different colours. Low-tech and effective.

After confirming accurate location of the rows, the information displayed still seemed quite sporadic.

I realised an error was that I was sending an array that was too large on P5 by making getPix() in the draw loop instead of the MousePressed function. Basically this means I was making my array way too large to be useful.

De-focusing my ambition of getting a rembrandt image right away, I settled on uploading a simple X image.

The output was somewhere, but still sporadic.

I tried to isolate it by row, but its still sporadic.

I tried using other types of images too but there was still inconsistency.


During the difficulties, the key thing for me at this point is that there doesn’t seem to be a reliable way to verify precise serial data coming in from P5 on the arduino without contaminating the serial port.

For instance, when I tried to debug by serial.print() and display on the P5 console, the values stop at around the hundred-something mark and then the loop takes about half a second to complete (which I verifyed by blinking the pin 13 LED.)

if (Serial.available() > 0) { // if there’s serial data available
for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt(); // read it


Why does this happen? When I comment it out, it works again. It “works” meaning it displays on the LED matrix, albeit incorrectly.

This is important to know because at the moment, I’m not sure if the problem is: (A) the way I am displaying the P5 data on the neopixels, of (B) if the way I am displaying the P5 data is fine and it’s the P5 data itself is corrupted going through the serial port.


  • Confusion over what ParseInt() does. The Arduino website says that it returns “parseInt() returns the first valid (long) integer number from the serial buffer.” However, my actual experience shows that it returns not just the first, but a series of values that allow them to populate the array that I am able to then transfer on to the Neopixel matrix. How exactly does


  • Data from Chrome Javascript Console (CJS) is correct and reflects configuration of pixels on image.
  • Arduino code to write to neopixel matrix (NM) has been confirmed to be accurate based on colour test.
  • Image printout to NM is sporatic and changes depending on which iteration I click, despite the fact that the P5 data is the exact same every time.
    • possible solution: I will code a NM reset to zero whenever the loop begins and before serial input is received.


  • Problem is in here:

for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt();

  • Something about the above does not create the appropriate inData[] array that contains the appropriate pixel value.
  • Oh wait, another clue. After printing out the array length on P5 it seems the array has 5145 elements… definitely not the 2240 that I am looking for. Oh wait no that makes sense since the “JustR” array is not an array but a big string that keeps getting appended with more information and “,” in between. So that number makes sense. NEVERMIND.
  • Back to the original idea. I now coded it so that the beginning of the void loops completely empties the array of any values so that the array is completely fresh for whatever serial data brings. And when do mousepressed more than once, again it prints to the array in different configurations. Which makes me think its some issue of timing between serial data and the array storing it. Maybe the timing is not right between P5 and the arudino and the array is not capturing the parseInt() string data?
  • I notice that when I put things in the parseInt() part of the code, the NM does not light up and the pin 13 LED lights up for a while fast and then goes very slowly with a delay longer than I specified.

for (int i=0; i<=2239; i++) {
inData[i] = Serial.parseInt(); // read it


  • I suddenly received an intuition that maybe I need to time the delay the in above loop in the right way to ensure the timing of the P5 serial data is the same timing as the Arduino. I remember Tom Igoe said something about this in his video. — NOPE THIS DIDN’T WORK.
  • It seemed that clearing the array at the start of each loop led to an accurate image at the first MousePressed data send from P5.
  • Update: 8:11pm Monday Oct 30. It seems like the top 29 rows are fine… it’s just the bottoms 3 rows that are off.

At a certain point, I just stopped trying to get a handle on the first 3 rows and decide to try the Rembrandt image again. And it worked. What I also realized was that RBG values for making colours on a screen are different than RBG values for making colours for a light painting.

I adjusted the colour by mapping the input based on different RBG values of the work as a whole:

for (int i=0; i<=2239; i++) {
RData[i] = map(Serial.parseInt(),0,255,0,50); // read it
for (int i=0; i<=2239; i++) {
GData[i] = map(Serial.parseInt(),0,255,0,30); // read it
for (int i=0; i<=2239; i++) {
BData[i] = map(Serial.parseInt(),0,255,0,10); // read it

UNRESOLVED ISSUES: why does the LED matrix do stuff like this? 

Leave a Reply

Your email address will not be published. Required fields are marked *