FAQ
Cover
This is the archive Discourse for the Processing (ALPHA) software.
Please visit the new Processing forum for current information.

   Processing 1.0 _ALPHA_
   Topics & Contributions
   Automated Systems
(Moderator: REAS)
   color drain
« Previous topic | Next topic »

Pages: 1 
   Author  Topic: color drain  (Read 3588 times)
rgovostes

rgovostes
color drain
« on: Feb 17th, 2004, 2:22am »

I had an idea today to write a "shifting blur" sketch. It starts like a normal blur algorithm - each pixel's color is determined by blending neighboring pixels together. However, it also adjusts the color a certain number of times (defined by 'complexity'), by randomly selecting a color attribute (red, green, or blue, or hue, saturation, or brightness) and adding or subtracting a random number from it (defined by the range '-maxDetail' to 'maxDetail').
 
There is no source image, though it could be adjusted to use one. It just starts with a random color in the top-left corner (a random hue value with saturation and brightness both set to 100%). Strangely, the starting color almost always seems to be red, green, or blue.
 
Anyway, it results in a nifty, color-changing streaks which move from top-left to bottom-right (which might be due to an error in my math =). I think it makes a very organic texture, such as if one were to look at an apple through a magnifying glass.
 
You can see the applet here (click to redraw). Please let me know what you think - this is only my forth or fifth published sketch, which means that I think it's cool, but others may not. I know that it isn't as impressive as most of the stuff that goes through here.
 
If anyone wants to look at the code, it's available from the site. The comments along the right side are just to help me keep track of the math needing to be done, and probably mean little to anyone else. Optimizations and suggestions are welcome!
 
Cheers,
Ryan Govostes
« Last Edit: Feb 17th, 2004, 2:41am by rgovostes »  
Glen Murphy

WWW Email
Re: color drain
« Reply #1 on: Feb 17th, 2004, 6:57am »

That certainly is pretty.
 
As with most static pieces, I'd love an animated one!
 
kevinP

Email
Re: color drain
« Reply #2 on: Feb 17th, 2004, 9:49am »

Very cool! It reminds me a little of something I saw in Photoshop (but now can't find, meaning that maybe it's in the new version), which was perhaps called something like "color spectrum noise" or? Not as nice as your delightful "Baumwoll-Fasching-Depths".
 
Would be nice to see the origin point change with the mouse click, or as already mentioned, to see this grow over time.
 
-K
 

Kevin Pfeiffer
arielm

WWW
Re: color drain
« Reply #3 on: Feb 17th, 2004, 10:53am »

on Feb 17th, 2004, 2:22am, rgovostes wrote:
There is no source image, though it could be adjusted to use one. It just starts with a random color in the top-left corner (a random hue value with saturation and brightness both set to 100%). Strangely, the starting color almost always seems to be red, green, or blue.

random or not, the chosen palette is great, always producing harmonic tones
 
on Feb 17th, 2004, 2:22am, rgovostes wrote:
I know that it isn't as impressive as most of the stuff that goes through here.

i think you're better at sketching than you may think
 

Ariel Malka | www.chronotext.org
rgovostes

rgovostes
Re: color drain
« Reply #4 on: Feb 17th, 2004, 6:30pm »

Thanks for the comments!
 
on Feb 17th, 2004, 9:49am, K wrote:
Would be nice to see the origin point change with the mouse click, or as already mentioned, to see this grow over time.

 
I thought about looping through again and doing a small, random change to each pixel. However, it already runs really slowly on my machine (4 seconds or so to render), so this won't be very practical until it's optimized (or I get a new computer!).
 
As for changing the origin, this would be a bit tricky. I use 4 different pieces of code for grabbing the average color of a pixel's neighbors:
first row - color is taken directly from pixel to left
first column - color is calculated from pixels above, above-right
last column - color is calculated from pixels left, above-left, above
anywhere else - color is calculated from pixels left, above-left, above, above-right

Since pixels below and to the right haven't been calculated, they are ignored in averaging. I would have to replace this with something that calculates the distance from the origin pixel, and more averaging would be needed (slower).
 
A few people suggested that I have a source picture from which this occurs. It would start as something simple, like a house, and gradually distort into a screen of random colors. I thought this would be neat, but it would require more averaging, too.
 
----
 
Well, I tried getting it to animate, without much luck. My first attempt was to go through every pixel and randomly adjust it, once, very subtly - it just made the picture grainy. The second attempt took the average of neighboring pixels again, then randomly adjusted it - it just made the picture blurry. I'm not sure what to do now, any suggestions
 
I'll try making the origin re-locatable later today.
 
----
 
I thought it might be worth trying to blend different images together to give the illusion of animation. I started trying to use the blend() function (I think someone was updating the documentation for it as I looked, heh), and then moved on to just giving it an alpha transparency value and overlaying it with image(). However, both of these just cause it to darken and recede into the top-left corner.
« Last Edit: Feb 17th, 2004, 11:57pm by rgovostes »  
benelek

35160983516098 WWW Email
Re: color drain
« Reply #5 on: Feb 19th, 2004, 12:18pm »

i haven't had a look at your code, but it seems to me that if you're using a whole lot of randoms to produce the changes, you might be able to use the noise() method instead. that'll allow you to make it a bit time-continuous. sorry if i'm wrong and this doesn't apply
 
if it's taking to long to render each frame, you might like to play around with buffering. that way you might be able to get 2 or 3 second bursts of action with 20 or 30 seconds in between.
 
rgovostes

rgovostes
Re: color drain
« Reply #6 on: Feb 19th, 2004, 9:41pm »

Noise would certainly create fluid animation and possibly make it run a little faster, but I'm not sure if it can be easily applied in this case.
 
I have made a few changes in version 2, such as more base colors (now has a random saturation, too). I am working on having it blur between pictures, which will hopefully make an illusion of a changing pattern
 
Pages: 1 

« Previous topic | Next topic »