The algorithm is very simple so that we can maintain a high framerate when running the sketch. I am using RGB colors and presorting them into a list. Ryan does the measurement to LAB and then does a conversion to RGB. I take the list and put it in a .csv file then I run this command on it so it sorts the list.

sort -g -n -r -t ',' -k 1,1 myfile.csv

Then I am calculating the distance from the Red value of the pixel from the camera to the nearest red value in the list of colors.

Why did I do this? Well, RGB is the native format for the hardware. I did a rough calculation and if we run the simulation at 30fps at 640×480 we do about 10,000,000 calculations per second. Every conversion we do from one representation to the next is going to multiply this number, as does the number of colors we compare. If we choose 100 colors then we do 1,000,000,000 calculations a second and then if we do color conversion we do about 4 times that much… it could get hairy.

I have included a small .csv file below that contains a subset. If you download the Processing code below you will need to call this set smallset.csv.

227,194,46
221,159,57
216,120,61
190,144,132
190,80,97
187,81,136
176,52,66
147,181,61
119,87,74
118,128,177
97,65,113
92,183,168
91,113,70
83,124,157
62,144,71
56,102,174
38,79,152

import processing.video.*;

int numberOfColors;
color mycolors[] ;
int numPixels;
Capture video;

void setup() {
  size(640, 480,P3D); // Change size to 320 x 240 if too slow at 640 x 480
  strokeWeight(5);
  // Uses the default video input, see the reference if this causes an error
  video = new Capture(this, width, height, 24);
  numPixels = video.width * video.height;

  loadColors("smallset.csv");

  noCursor();
  smooth();
}

void draw() {

  if (video.available()) {
    background(0);
    video.read();
    video.loadPixels();

    loadPixels();

    for (int i = 0; i < numPixels; i++) {

     float measure = red(video.pixels[i]);
     int whichcolor = 0;
       for (int j = 0 ; j < mycolors.length; j++){
         if(measure <= red(mycolors[j]) ){
             whichcolor++;
         }
         else{
                pixels[i] = mycolors[whichcolor];
                break;
         }
       }//iterate through colors

    }// iterate through pixels

    updatePixels();

  }// if video available
}

void loadColors(String filename){
  // laod the csv file
  String[] lines = loadStrings(filename);
  // one color per line so use that to set the length of destination color array
  mycolors = new color[lines.length];

  for ( int i = 0 ; i < lines.length; i++){
    String[] rgbvals = split(lines[i], ',');
    // assume it all worked out and there are only 3 values per row
    // no alpha or b/w pixels for now
    mycolors[i] = color ( int(rgbvals[0]) , int(rgbvals[1]) , int(rgbvals[2]) );
  }
}

The original Macbeth ColorChecker Color Rendition Chart was introduced in the summer of 1976, and was “developed to facilitate quantitative or visual evaluations of color reproduction processes employed in photography, television, and printing…” . It was a tool to provide a window back to reality and was largely based on colors used for “analytical studies” (although a few simulated colors are supposed to represent human skin, foliage, blue sky, and a blue flower).

Along with these colors, for this first test, we chose colors for our custom target that would better simulate the colors that would be found in common gallery environments- ones directly measured from life, as well as reproduced skin tones from google. Essentially, our color target blends historically important colors that photographers have relied on to determine accuracy with colors that extend the experiment to evaluate the effects of quantizing the real. The nature of the 6-bit image will always exaggerate and expose the inherent error within the scientific representation of reality.

A summary of the colors initially chosen for the 6 bit image posted on June 12th:

• The 24 original color patches of the original ColorChecker- a nod to one of the most photographed objects and utilized color control devices of all time. Read more about it here: http://www.ryanboatright.com/Images/ColorChecker%20Introduction.pdf

• 10 different color patches representing a myriad of skin tones and ethnicities seen through google.

• 30 various life readings from a domestic person’s wardrobe (pants, shirts, shoes, hats, gloves, etc…)

Total: 64 different color possibilities

The colors were all printed with an Epson 4880, and then read with a spectrophotometer. When an image from google was used, it was printed, read with a spectrophotometer, re-printed, and then re-read. This is an important step considering that we are thinking to include a large color target in the space of the installation. All readings need to be measured off the printed color target itself.

Once we map these colours onto the lab space, we use the following formula D= √((L₁-L₂)² + (a₁-a₂)²+(b₁-b₂)²)) to calculate the distance between the colours. The complication here is that each pixel will have to run this equation 64 times (assuming 6-bit per pixel) to determine which of our indexed colours is closest (distance in CIELAB 3d space) and then replace the original colour with its’ closest approximation yielding something like the image below.Many of the colours will have visual relationships and approximate the colours we have selected, but others may have a less corollary visual relationship.

If you want to get a visual representation of CIELAB space beyond the screen shots below, download PerfX 3D Gamut Viewer.

We have yet to run any tests on this beyond using indexed colour to limit a palette. Potential problems could include:

1. sRGB to CIELAB conversions to bring webcam data into a usable form.

2. Computational efficiency (which we are working on).

3. Visual relationships between mapped colours and their perceptual counterparts may be aesthetically complicated.

Below: Ryan in 256 Colours, Screen Shots of CIELAB Space.

Ryan Boatright’s Error v.1, Brown Pear utilizes color measurements taken with a spectrophotometer on an actual object, which are then translated to a particular color space (sRGB). A picture of the same object is made, the color measurements are compared, and the quantitative information is gathered pertaining to the differences found in the RGB values. A problem with the implementation of this exact process exists. When attempting to use this process in a gallery space in real time, the color measurements on the individual subjects (art viewers), during the exhibition, will not be able to be made. Pre-determined measurements would be possible via color targets measured and then photographed with the same camera, with all ambient lighting conditions standardized before the exhibition and then repeated during it. We discussed how the colors measured through the live recording could, pixel by pixel, shift themselves to the color of an associated color patch (they would essentially be quantisized into a standard color from the target) and then the representational gap (that was pre-reocrded) could be projected or displayed on a LCD in real time. Depending on the error of the camera, and the colors existing on the viewers, the image would appear very faint, like it does in the final representation of Ryan’s Error video.

Jordan and Adam suggested an alternative to the process, that would involve the basic premise of this process, but shift it slightly to provide two different representations. The colors gathered through the live recording would, pixel by pixel, shift themselves to the color of an associated color patch on a target in the space. If there were 500 different color pixels in one frame of the feed, than these colors what be shifted to match a maximum number of, for example, 50 possibilities. This would then be displayed. The second representation, running concurrently, would depict, in black and white, the amount of error associated with the color of each pixel- the amount of shifting that was necessary, and that occurred in the first representation. Adam believes that he could produce a custom program that could output both representations twice per second (two frames per second). The group believes that the evidence of computer processing in the final representation would be a positive aesthetic, and compliment the visual/conceptual aspects of this piece.

A preliminary discussion then pursued about the first installment of the work in Paris.

Some pertinent questions:

• Would the 2 representations be projected, or displayed on two LCD panels?
• Since a color target will be included in the background of the live video feed, which one shall be used? Should a custom-made, wall size, target be made as a constant backdrop? If so, which colors should be chosen?
• Should the two representations be shown side by side? Back to back?
• Should the black and white projection be projected onto the viewers?themselves? …creating a luminous aesthetic and integrating the work back to the viewers? This seems possible, although challenging because more parameters would have to be accounted for. It could be interesting to project the piece back onto the source.

Included below is a sketch of the TPTP space:

The TPTP Art Space (Colour Data Processing Exhibition)