Reading this honestly made me laugh a little at the Marvin Minsky anecdote, the idea that “the problem of computer vision” could be assigned as a summer project feels almost delusional now, and I think the article uses that story perfectly to show how much we underestimate what vision actually means and what it really involves. What really stayed with me is the description of digital video as computationally “opaque,” because that word completely shifts how I think about it now. We all know text carries structure and meaning, whereas video is just, as stated in the text, rectangular pixel buffers with no built in meaning. Humans attach meaning almost instantly, whereas computers need instructions just to separate foreground from background.

I also found it interesting that many of the techniques that were mentioned in the reading, like frame differencing and brightness thresholding, sound simple but are actually incredibly dependent on the physical conditions of the place. The article kept on emphasizing that no algorithm is completely “general,” and that honesty stood out to me because it means computer vision only really works smoothly and successfully when the environment is carefully prepared for it, which is actually crazy if you think about it, because it feels like everything you once knew about how computers see was a lie. The workshop example with the white Foamcore made that very clear, since the students basically redesigned their physical space to make brightness thresholding easier. That detail made me realize that computer vision is not just about writing a more complex and smart code, but also about kind of staging reality so the system can read it, which feels less like artificial intelligence and more like controlled intelligence.

The surveillance themed works fropm the reading added another layer that I couldn’t ignore. When Rokeby describes his system as “looking for moving things that might be people,” the phrasing feels sort of purposefully detached, and that detachment made me feel a little unsettled. The same foundational techniques that allowed Videoplace to create playful full body interactions are also what made Suicide Box possible, quietly recording real tragedies, which is just so scary to think about. I think that tension is what makes computer vision in interactive art powerful and complicated at the same time, because it forces us to confront how easily bodies can be tracked and reorganized into data. For me personally, the most compelling idea that i got from this reading is that computer vision does not really just detect what is there, but kind of reflects what we choose to prioritize and make visible to the computer. Overall, this was an extremely fascinating reading and truly opened my eyes to the “true” meaning and reality behind computer vision.

The Concept:

I decided for this assignment to recreate the five-star rating system used for film ratings. So my plan was for there to be five stars, and once you click on any of the five, it will show you the films with an average rating of that particular star.

The Process:

I first loaded all my images, fonts, and csv file.

I thought this would be easier than it actually was; this was much, much harder than I expected. I first started by building my stars in a separate class to make it neater and easier for me to use. I followed this YouTube tutorial to make them since there is no star shape on p5, and trying to create the stars using lines that I would have to manually connect was too complex.

After creating the stars, I put them on my screen using a for loop to present 5 stars on the canvas. The first challenge I faced was getting the stars to light up or get filled in once my mouse was inside them. I tried using a particular if statement within a for loop, stating that if we were at index=0 to fill, but that did not work. I knew I had to do something with the distance between the mouse and each star’s outer radius.  So, I decided to create an if statement where I used the distance function, but I used for my parameters mouseX, mouseY, and the outer radius. Unfortunately, that did not work, so I had to use ChatGPT to fix it for me, and it instead included the x and y parameters of the stars. After that, I created an if statement where if the distance is less than the outer radius, the star would fill and “light up.” That’s when I faced another issue where, at some point, two stars would light up at the same time. I decided to call my sister, who is a computer science major, to help me solve the problem. We tried manipulating the x and y positions of the stars, but the problem persisted. My sister then suggested that the issue is with the if statement of the distance between the mouse and the outer radius, since there will always be an overlap between the stars’ outer radii. She suggested I do some addition/subtraction to the mouseX and mouseY positions within the if statement. Once I did that, the stars lit up successfully.

The real challenge was extracting the ratings of the data onto the canvas. I tried many different things such as a triple nested loop like this:

for(let i=0; i<numRows; i++){ for(let j=0; j<=Film_title; j++){ for(let k=0; k<ratingStar.length; k++){ if(mouseIsPressed&&d < ratingStar[i].outerRadius&&int(Average_rating[i])<1.5&&ratingStar[0]){ background(255) text(Film_title[j], 200, 200) } } } }

but it did not work. I knew I wouldn’t be able to work out the code, so I decided to go the peer tutors to figure something out. Although we couldn’t completely figure out what to do, she suggested I use ranges.

My friend then explained to me that I could create a minimum and a maximum and assign them to an array of ratings we created. While his method worked, it was difficult to understand for someone with minimal coding experience.

I asked for help from the professor as this stage, and she gave me a starting code that helped me understand what I needed to implement. After I applied the code, the code fully ran successfully.

Code I’m Proud of:

Even though I wrote out the code with the help of the professor, I still felt particularly proud of this chunk because it made me realize the logic behind what I wanted to do, and it felt like a moment of realization and understanding. Also this was the hardest part of the code I wanted to achieve so being finally able to do it was very relieving.

    } else if (status == 1) {
      for(i=0;i<TwoRatingFilms.length;i++){
      text(TwoRatingFilms[i], 260, 240+i*30);
      }
    } else if (status == 2) {
      for(i=0;i<ThreeRatingFilms.length;i++){
      text(ThreeRatingFilms[i], 420, 240+i*30);}
    } else if (status == 3) {
for(i=0;i<FourRatingFilms.length;i++){
      text(FourRatingFilms[i], 590, 240+i*30);}
    } else {
      for(i=0;i<FiveRatingFilms.length;i++){
      text(FiveRatingFilms[i], 540, 420+i*30);}
    }
  }

Future Reflection:

Honestly for the future I would try to aim for something only a little bit outside my comfort zone. I would also not underestimate what I would have to do like I did in this project.

References:

https://youtu.be/rSp5iSTXwAY?si=RaaxtuAu8XivtpAF

 

The reading made me think back on how invisible software work used to be in the past and how easily important contributions can be overlooked nowadays, especially when they do not fit dominant expectations of who a “technical innovator” should actually be. The article highlights that software wasn’t even considered important in the early Apollo mission planning, which aligns with how many modern technological systems still undervalue behind-the-scenes digital labor. From my own experience studying technology and creative coding, I see a similar pattern which is that people often praise visible outputs (design, hardware, final product) while ignoring the programming logic that makes everything function. This actually supports the author’s point that Hamilton’s work was revolutionary not only technically but conceptually, because she helped establish software as a legitimate engineering discipline. But at the same time, the reading also challenges my previous assumption that space exploration was mainly about hardware and astronauts; it made me reconsider how much critical decision-making and problem-solving actually happens in code and systems design.

However, the author might show some bias by strongly linking Hamilton as a singular heroic figure, which risks simplifying the collaborative nature of large-scale scientific projects. While the article acknowledges teams and engineers, it still centers a narrative of individual genius, which is common in technical journalism and can actually overlook collective labor and institutional structures. This raises questions for me about how history chooses which contributors to actually highlight and which to marginalize. I also wonder whether the article’s emphasis on gender barriers, while being important, might shape the story to fit a modern narrative about women in tech rather than fully exploring the technical debates and engineering processes of the time. The reading ultimately makes me question how innovation is actually thought off. Do we celebrate people based on their actual impact, or based on how well their story fits contemporary social values and narratives about progress and inclusion?

I used to assume computer vision worked like human vision, just less advanced, but I realized the difference is definitely bigger. Human vision automatically understands meaning, like someone’s face, while digital video is “computationally opaque”. It basically shows that a camera image is just pixel buffers with no meaning unless an algorithm like frame differencing, background subtraction, or brightness thresholding interprets it. I was surprised that simple techniques like object tracking can detect motion just by comparing the pixels. The vision systems do not have to be so complex. Even basic detection can be powerful if the physical environment factors in the code are designed well.

One example that stuck with me was Myron Kruger’s videoplace. I found it really interesting that early interactive art already used vision tracking to let people draw with their bodies. It made me realize how computer vision can expand the way we can interact with technology. At the same time, Rafael Lozano Hemmer’s work shows more of a critical side. His belt tracking piece turns surveillance into art, which made me wonder whether interactive work with surveillance abilities that track viewers is also training us to accept being watched. 

The reading left me to question if computer vision works best when environments are made specifically so that the computer can easily detect it, does that mean future spaces will be designed more for machines, made accessible for machines, than us humans? Like, will there be now more controlled lightning, infrared illumination, and retroreflective material? I think this text definitely shifted my perspective from seeing computer vision just as a technical tool to also seeing it as a cultural force that affects art and even social power.

For this assignment, I wanted to create something interactive but still simple enough to fully understand and explain. Instead of focusing on complex visuals, I decided to make a reaction time test, where the user presses the space bar as quickly as possible when the screen turns green. I liked this idea because the interaction itself generates the data, instead of relying on an external file.

The sketch starts with a short instruction screen. Once the user presses the space bar, the screen switches to a “wait” state for a random amount of time, and then turns green to signal the user to respond. The reaction time is recorded for each trial, and after a set number of trials, the sketch displays the results. I kept the visuals very minimal and focused more on clarity than decoration.

Embedded Sketch:

For the results, I used three images (a rabbit, a human, and a turtle) to represent fast, average, and slow reaction times. I also added a simple bar chart where each bar represents one trial. Faster reaction times result in shorter bars, while slower reaction times create taller bars. This helped make the differences between trials easier to see.

let barH = map(rt, 200, 2000, 20, 160);
   barH = constrain(barH, 20, 160);

   fill(255, 120, 170);
   rect(chartX + i * barW, chartY - barH, 45, barH);

I’m proud of this section of the code because it takes a the reaction time value and turns it into something visual. By using map(), I was able to convert reaction times into bar heights, which made the results much easier to interpret.

Most of the sketch was built using variables, arrays, conditional statements, functions, and simple state management. Using different states (intro, wait, go, and results) made the interaction much easier to organize. I also used millis() to measure reaction time, which I learned more from p5.js reference and looking at simple reaction-time examples online.

Overall, I’m happy with how this sketch turned out. It helped me understand how user input can be treated as data and then visualized in a clear way. The most challenging part was making sure the input behaved correctly in each state, especially preventing early presses from being counted. For future assignments, I would like to experiment with more detailed feedback per trial or different ways of visualizing reaction time beyond a bar chart.

Reading Reflection:

Norman’s reading made me realize that many everyday frustrations come from poor design rather than user error. He explains how objects often fail to clearly communicate how they should be used, which causes confusion even in simple situations like opening a door. This made me think about how important clarity and feedback are in interactive design.

Relating this to my own work, I realized that even small design choices in my sketches affect how intuitive they feel. If an interaction is not clear, users may not know what to do or may assume something is broken. Norman’s ideas encouraged me to think more carefully about how my sketches guide the user, and how simple visual cues or feedback can make interactions feel more natural and less frustrating.