Archive for the 'Help!' Category

Mars Altimetery Graph // ver A

Friday, May 30th, 2008

Code of Mars Altimetery Graph
download the sketch—view the code

What is it?
I thought it might help me figure out the MEGDR Viewer if I looked at the same data in a different way. This sketch is meant to render an area graph of Mars altimetry data. It is written to run in basic mode since it is meant to render one image and there is no interactivity. But… it doesn’t work. I either get a file not accessible error on the loadBytes line, or the drawing window simply never pops up. Maybe I’m being too impatient and I should let it run overnight. But even if that is the case, something must still be wrong with my code because this shouldn’t be that hard for the computer.

Mars Global Surveyor: MEGDR Viewer // ver D

Thursday, May 29th, 2008

Mars Global Surveyor: MEGDR Viewer// ver D
run the sketch—view the code—download

How do you use it?
Press any key to switch between the color and grayscale rendering of the data file.

What is it?
The continuation of version C. Because these were the first images I saw, I was mistakenly assuming there was color information in the data file. So all of my attempts to extract RGB values from the data were pointless.

Mars Global Surveyor: MEGDR Viewer // ver C

Wednesday, May 28th, 2008

Mars Global Surveyor: MEGDR Viewer// ver C
run the sketch—view the code

How do you use it?
Move the mouse up and down to adjust the color offset.

What is it?
This is an interactive version of Monday’s sketch. It’s another attempt at rendering an image from a Mars Orbiter Laser Altimetry data file. It’s also confounding, infuriating, and not working. I can’t quite get my head wrapped around the bitwise operations and the bitmasking. It’s getting a wider range of colors, and it’s revealing more detail in the image, but I don’t understand why the colors aren’t smooth.

Mars Global Surveyor: MEGDR Viewer // ver B

Monday, May 26th, 2008

My Mars topography mine Their Mars topography theirs
download the sketch folder—view the code

How do you use it?
You have to tinker directly with the code to make this do anything.
This one doesn’t run in continuous mode and it isn’t interactive so there is no link to run it in the browser. Also, it processes a 2MB data file so it would be ridiculously slow to download an run it as an applet.

What is it?
As I mentioned yesterday, I’m geeking-out about Mars right now. I was surfing around some NASA and JPL web sites looking for more digital elevation maps and found a lot of data from the Mars Orbiter Laser Altimeter. This is an instrument on the Mars Global Surveyor craft that mapped the Red Planet from 1999 to 2006. Unlike the false-color topographic map I used in yesterday’s sketch, these new files I found are NOT images. They are data files that need to be rendered into images with special visualization software. Unfortunately—or perhaps, fortunately—I couldn’t find an OS X version of any of these software packages. So I thought (encouraged by Ben Fry’s Visualizing Data book), “I bet I can write something in Processing that could view these files.” Well, it’s been a long night, I’m not sure exactly how it works, and it sure ain’t perfect, but I’ve got something. The sketch reads the altitude data from the .img files, parses that into the pixel array and displays the resulting image.

If you run this yourself, be prepared, the image size is 1440 x 720 pixels.

Why is it cool?
There are so many reasons… but one thing that really shocked me is that it’s only 9 lines of code.

Dynamic Mask // ver A

Wednesday, May 21st, 2008

run the sketch—view the code

How do you use it?
If it worked, you would just move the mouse around.

What is it?
The intent is to make an interactive, dynamic image mask (like a “spotlight” effect). The mask method requires either an grayscale image file or an integer array containing the pixel gray values to be used for the mask. My idea is to update the pixels[] array of the mask image each time draw() loops.


Tuesday, May 20th, 2008

run the sketch(P3D) (OpenGL)—view the code (OpenGL)—download (OpenGL)

How do you use it?
Follow the on-screen instructions.

What is it?
This is based on the Rudolph helix series from Nov 2007. I’ve been tinkering with it off-and-on for a while so I decided it was time to show off the latest version. This one has an optional GUI layer built into it. This time I’m using the OpenGL renderer instead of P3D (both are posted for comparison). The weird thing is, with OpenGL the transparent pixels in the image are only transparent in one direction. With P3D, the transparency works both ways, but it doesn’t handle z-translations entirely right…

In the P3D version you’ll notice the small “farther away in space” images remain at a reduced size even when they are rotated to the front. I understand why this happens* but I’m not sure how to correct for it. Perhaps I should rotate the camera instead of rotating the coordinate space. Any thoughts?

*P3D is reducing the size of the images that are positioned on the negative z-axis. Similarly, an image with a positive z-coordinate is made bigger. This is done absolutely, without regard for the POV of the viewer; negative z = smaller, positive z = bigger. When you move the mouse left or right, you are spinning the entire coordinate matrix about the y-axis, This eventually brings the negative z-axis to the front and with it come the scaled-down images.

mondayBanner // 12 May 2008

Monday, May 12th, 2008

run the sketch—view the code

How do you use it?
-Move the mouse left and right to spin the cube.
-Move the mouse up and down to zoom in or out.
-Click and shift-click to tilt the cube.
-Space bar saves a .tif of the image. (only in Processing, doesn’t work in browser)

What is it?
A function called grid() uses two nested for() loops to determine the X- and Y-coordinates for a grid of circles. A separate for() loop translates the drawing matrix along the Z-axis and draws a grid each time. The result is a three dimensional matrix of circles.

I originally wanted to do it with spheres, but it seems that 1000 spheres is too much for the processor to keep up with. With only 125 spheres it barely worked. There was no real difference in performance between OpenGL and P3D. I have a hunch that the code could be optimized to handle larger numbers but I’m not sure where to start. Any suggestions? Should I recall the coordinates from an array? Should I go OO? I welcome comments…