Skip to content

RGB 3-Color Mixing from B&W, Part III

I wanted to give this another try.  Practice makes perfect.  Almost there.  Now I’m really confident the only thing holding me back from upping the ante on these images is the tripod.  A new camera might help too, but I really like squeezing every last drop out of a lemon!

Here are the merged layers prior to adjustments.  I used Auto Color, Contrast and Tone, in that order.  Playing around with the order does seem to make some difference.

And the B&W images, RGB order:

Lenticular 3D!

This is pretty awesome.  Just shot 13 images of my now world-famous fruit bowl and made a lenticular out of them.  13’s total overkill–a baker’s dozen–but what the heck!  I figured I could throw a few out, but they all turned out okay.

Here are the layers superimposed:

The tangerine in the center of the bowl was my “picture point”–the point on the picture plane.  Specifically, I shot for the shadow at the bottom.  I brought all the images into Photoshop on separate layers at 50% opacity, and worked on aligning that point.  Then I cropped the final image to eliminate empty background, but I’m not sure that was really necessary.

Here’s my bootleg camera setup:

I moved the camera left 10mm at a time, always aiming to center the picture point.

Next, I downloaded Lenticular Image Creator  by Jameson Bennett  (http://lenticularimagecreator.com), which is painfully easy to use.  A really nice program.  Here are the screen shots:

I saved it as a .png, but it will be worth playing around with all these settings.

Nature of Code: the final, and saddest day.

I cannot believe the semester is already over.  Clearly I’ve been remiss in posting about Nature of Code here.

It’s all on the class wiki here: http://itp.nyu.edu/varwiki/Nature/Nature.  I’ll link to this work individually once the dust settles.

Background

I find again and again that natural motion provides rich material for the study of animation.  Last semester in Big Screens, Patrick Hebron and I were inspired by Harold Fisk’s geological maps of the meandering motion of the Mississippi River over thousands of years to generate an algorithmic piece called MeandriCA.

Here’s a video of that project:

MeandriCA by Morgen Fleisig & Patrick Hebron from Patrick Hebron on Vimeo.

[http://vimeo.com/17859695]

Documentation: http://mfleisig.wordpress.com/2010/10/01/the-meander/

NoC Final

Harold Fisk’s maps continue to suggest new projects, and I’ve worked with them still further in the investigation of other algorithmic techniques this semester in Nature of Code.

Here are two screen shots of my latest sketches:

Java Applet and Processing Code: http://itp.nyu.edu/~mif226/NoC/Final/1_3D/

Java Applet and Processing Code: http://itp.nyu.edu/~mif226/NoC/Final/1_3E/

So what’s going on here and why?

Ever since Patrick introduced me to the darker side of image mapping–specifically of generating images with Perlin Noise and swapping them out with interchangeable arrays on the graphics card–I’ve been somewhat obsessed with the idea of images within images, of hidden images within more obvious ones.  Perspectives, erasures, tracings, reflections in still lifes, anamorphoses, architectural drawings in their two-dimensional projection of the three-dimensional world, Abbott’s Flatland–all are examples of this.

In much the same way, I’ve been fascinated with other ways of generating images besides Perlin Noise, and it occurred to me this semester that any array would do–they’re just numerical values.  Perlin Noise has the advantage that the adjacent values have a smooth relationship, but any values will do, as long as their inherent relative qualities are exploited.

For this project, I had a simple aim: map the motion, color, size and any other relevant qualities of a particle to the pixels of an underlying image.  In presenting this at the Midterm, Dan suggested I start with a much simpler image, and it occurred to me at that moment that the motion behavior and other qualities did not necessarily need to come from the same image.  That’s what I’ve implemented here.  The motion is being mapped by a vector field generated by a simple representation of a segment of the meandering Mississippi, reduced to black and white:

If you are saying to yourself that there’s something wrong with that vector field, you’d be right.  I’ll come back to that shortly.

The first image has hard-coded colors, but the second one is sampling the colors from Harold Fisk’s maps themselves:

Rabbit Holes

or What I’ve learned and what still needs to be done.

So what’s up with those vectors?  I realized yesterday morning after painstakingly doctoring a pixellated seed image of the Mississippi that all this time I’ve been adding my vectors incorrectly.  I’ve been doing this:

          field[i][j] = PVector.add(v0,v1); //add self to neighbors
          field[i][j] = PVector.add(v0,v2);
          field[i][j] = PVector.add(v0,v3);
          field[i][j] = PVector.add(v0,v4);
          field[i][j] = PVector.add(v0,v5);
          field[i][j] = PVector.add(v0,v6);
          field[i][j] = PVector.add(v0,v7);
          field[i][j] = PVector.add(v0,v8);

Thinking I’ve been adding them together, I’m actually simply adding v0 and v8: each addition step is overwritten by the previous one–they’re not cumulative.  I should be doing this:

          PVector temp = new PVector(0,0);
          temp = PVector.add(temp,v1);
          temp = PVector.add(temp,v2);
          temp = PVector.add(temp,v3);
          temp = PVector.add(temp,v4);
          temp = PVector.add(temp,v5);
          temp = PVector.add(temp,v6);
          temp = PVector.add(temp,v7);
          temp = PVector.add(temp,v8); 

          field[i][j] = temp;

I fixed that, and then got this:

I tried it with a simpler gradated field, but still got a good deal of chaos:

I tried it with a simpler image in which the field is all black:

I corrected the algorithm and got most of the horizontal vectors tracking the river’s course, which is exciting, but I am still flummoxed by what’s happening with the boids at the turns.  Going through pixel by pixel, I realized that the algorithm works well now on the straightaways, but in the turns the fact that it is adding the previous and subsequent pixels together is throwing off the resulting vector.  Effectively, I’m evaluating the pixels as free-body diagrams, multiplying adjacent brightnesses by their respective vectors, treating them as forces in tension:

Clearly I need to adjust the algorithm so that it ignores the pixel it just came from, and I’m going to come back to that, but as Falstaff said, “The better part of valour is discretion.”  Having not gotten past rendering the flow field as triangular boids, I decided to set this enquiry aside for a bit and work on rendering boids instead.

Boids as Particles.  My plan all along had been to render the boids as the particles I had developed based on Karl Sims’ Siggraph paper, “Particle Animation and Rendering Using Data Parallel Computation”.  The reason being that the particle more closely approximates the behavior of a water droplet with a head and tail, for the reasons he describes.

• I had worked this particle out to some extent in week 4:  http://itp.nyu.edu/~mif226/NoC/week4/particleStudy3/.

My other plan was to continue on with the work I had done subsequently, using an underlying image for the particle to sample color.  This I had worked out in week 6 for the Midterm.

• Here I’m sampling from a photo I took in Oregon of a cow:  http://itp.nyu.edu/~mif226/NoC/week6_Midterm/cow/.

• Here I’m sampling from Harold Fisk’s map:  http://itp.nyu.edu/~mif226/NoC/week6_Midterm/fisk/.

So the main work in all of this was assembling these different strategies.

Next Steps.

1. Fix the flow field algorithm.

A. In the case of a black background, track the previous pixel and do not add it’s vector to the resultant.

B. The gradated backgrounds are not helping at the moment.  After mastering the algorithm for the bright pixels the next simplest step might actually be to write a loop that checks adjacent dark pixels and adjusts them based on how near they are to a bright pixel.  Gradating the pixels by hand is also a massive pain… more about that below.

C. Implement a better algorithm that modifies non-river pixels over time by adding a fraction of the value of the river pixel to them, emulating erosion.

2. Modify the color sampling algorithm so that the particle maintains the color from birth to death.

3. Implement the particles’ lifetime.  I like the current density that the Iterator produces, but it obviously ultimately bogs down the processor.

4. Implement a layered background.  One idea that Patrick and I have been talking about for a long time is how to also algorithmically generate man-made intrusions into the landscape, such as the property lines visible on Fisk’s maps.  It is interesting that the lots were originally laid out perpendicularly to the banks of the Mississippi–in Louisiana at least–but that over time, that geometric condition becomes less obvious as the river meanders.  Sometimes the property even becomes submerged and then ends up on the opposite bank.

5. Pixel doping.  Optimally, this project would work with a normal image, for example:

Once I get the field flow algorithm working properly I think it will, but there’s a lot too that, and until then I’ll be working with very simple pixellated images.  I began by posterizing the image above in Photoshop:


Then, on Dan’s suggestion, I reduced it to the ultimate number of columns and rows in the flow field to make evaluation easier.  This resulted in a 30×35 pixel grid:

I upped the contrast on it four times, and then went in and doctored the pixels individually with the pencil tool:

Based on my thinking about the pixels in the straightaways (see above), I felt compelled to go in and increment the brightness of each pixel in the river up to 255 at the bottom of the screen:

Many thanks to Don Miller for recommending Pixen (http://pixen.en.softonic.com/mac)–it’s way easier to use than Photoshop for stuff like this.  It crashed frequently, however.  I’m not sure whether it’s a Snow Leopard issue, insufficient memory, or what, but save frequently.  I colored the balance of the river so that I could keep track of which pixels I had finished.  I spent a lot of time feathering the field too, and now I wish I had not because that did not solve my field flow issues:

Optimally, this work would happen in the body of the code.  I got this far with that project before I set it aside as well:

(Actual Size)

I think there are perhaps two people at ITP that would be marginally interested in me finishing it.  Here’s a Pixen image of it:

Java Applet and Processing Code: http://itp.nyu.edu/~mif226/NoC/Final/PixelPathEvaluator/

A final footnote: all of this work is premised on the idea that a flow field is the optimal approach.  During my Midterm presentation, several other options were discussed–path following, attractors and repellers, and an actual physical model in Box 2D.  Each of course would produce a different effect, and I would like to explore each to better understand how to exploit those effects.  For example, I worked up this sketch “Meander #9″ based on Dan’s path following examples back in October when Patrick and I were developing our ideas for Big Screens:

http://itp.nyu.edu/~mif226/bigScreens/Meander_mf009_002/

Credits:

Much credit for my code goes of course to Dan Shiffman, Craig Reynolds and Karl Sims for their work, and I’ve given them credit in the body of the code where I hope it is most appropriate.  I must add Harold Fisk and Sid Gray for turning me onto him, Patrick Hebron, and Lewis Carroll and John Tenniel as well.

The One-Bit Adder

Just found the original Texas Instruments chip that solves the same problem in a fraction of the real estate:

sn7480

RGB 3-Color Mixing from B&W, Part II

I never tried photographing food before.  Obviously.  Unless it’s a bowl of fruit, it’s messy, and a lot more difficult than you’d think.  I just shot this in black and white, three times with three filters (Red, Green, Blue), and then auto-adjusted the levels in Photoshop:

Merged Channels RGB_2 Levels

Here’s Canon’s in-camera color algorithm:

IMG_6845

Auto-adjusted by Adobe:

IMG_6845_Levels

Here are the B&W images:

IMG_6851 Blue

 

IMG_6852 Green

IMG_6853 Red

And here are the merged RGB channels prior to level adjustment:

Merged Channels RGB_2

 

RGB 3-Color Mixing from Black & White

Eric showed us how to combine three B&W shots taken through Red, Green and Blue filters as separate alpha channels in Photoshop.  Here’s a normal color shot for comparison:

I auto-adjusted the levels on the one at the top.  Here it is immediately after being mixed:

With a sturdier tripod (I’m using the Joby Gorillapod) this would certainly be sharper.  I love the colors–they evoke pre-digital Technicolor.

Here are the levels of the merged images prior to adjustment:

and post:

For filters, Eric recommended Rosco or Permacolor — I used Rosco:

BLUE: Permacolor 31080 or Rosco R80
GREEN: Permacolor 35156 or Rosco R389
RED: Permacolor 36500 or Rosco R26
Here are the black and white separations:
Red:
Green:
Blue:
His advice, well-heeded:
  1. Take them in RGB order.
  2. Label them R,G and B.
  3. Open them in Photoshop.
  4. Convert them to grayscale.
  5. Go to Window > Channels and open the drop-down menu on the upper right of the channel menu.
  6. Merge the channels in RGB taking care to see that the correct files are assigned to the correct channels.
  7. Adjust levels in Image > Adjustments.

Miniaturization, Magnification and Magic: The Aesthetics of Computation

Midterm Presentation:

https://prezi.com/secure/ef86b8951f188c1d19963d34ed658ad3cd827d8a/

Logic Gates:

http://itp.nyu.edu/~mif226/thesis/code/logicGates/AND_1fps.swf

http://itp.nyu.edu/~mif226/thesis/code/logicGates/OR_1fps.swf

http://itp.nyu.edu/~mif226/thesis/code/logicGates/NAND_1fps.swf

http://itp.nyu.edu/~mif226/thesis/code/logicGates/NOR_1fps.swf

Flip Flops:

http://itp.nyu.edu/~mif226/thesis/code/flipflopRS/FlipFlop_Redrawn2.swf

http://itp.nyu.edu/~mif226/thesis/airLogic/Flip%20Flop%20Air%20Logic2.swf

Drafts:

Draft 2: https://prezi.com/secure/1e4223b5f54f53b3daf6f03ca1442dc6b302d5bb/

Draft 1: https://prezi.com/secure/b7695d3949ea2e80e8cc9a7ee91f018701f004a4/

Follow

Get every new post delivered to your Inbox.