coding
slitscan the can – s quatro
I’ve been developing my Processing slitscan filter to create a sequence of images from a single original source.
Although manipulating individual pixels led to some interesting effects, I couldn’t work out how to achieve what I was really after. I switched to using get() and set(), thus leaving the hard work of calculation to Processing, and we’re both happier as a result. The only drawback is that images drawn with set() can’t be tinted, so, to suggest distance, I added a narrow black rectangle over each row of pixels, filled with decreasing transparency towards the centre.
I’m still not there yet, but the following clip is much closer:
Here’s the source image:
scannin’ fodder
Following on from my previous poston slitscanning, I’ve been working on a Processing sketch to imitate the original slitscan technique, i.e. create a sequence of images from a static single original. I’ve never used images or video in Processing before, so it’s all new to me, and I’ve a way to go yet, but I’m getting there. So far, my sketch creates a new frame for each row of pixels in the original image, and adjusts each line in it with a flickering offset.
Here’s the output from the current version of the sketch:
… and here’s the original, rather cheesey image I used as a test source (taken from a website offering free desktop wallpapers):
algorithms for visual design
I know it’s geeky, but I’m excited that ‘Algorithms for Visual Design Using the Processing Language ‘ by Kostas Terzidis has arrived. It’s been on my wish list for many months, but a publishing date was specified by Amazon only recently. It appears to cover a lot of the same general topics as other Processing books, but it rushes through the basics then you’re into all sorts of complicated matters. I’ll have to take this book very slowly indeed.
it’ll be all right on the night
You may have noticed a lack of references recently in this blog to my coding. That’s because I haven’t done any. I’ve temporarily abandoned the circleLine idea, as I found I couldn’t concentrate while trying to debug the final stages, though I produced lots of unintentional effects. (Perhaps there ought to be a ‘Processing Sketches Do the Funniest Things’ programme on TV. My, how we laughed when that function kept calling itself with no escape condition…)
Until I resume work on that sketch, I’ve decided to develop some new ideas, exploring the possibilities of achieving interesting results from relatively simple behaviour. That seems to be where my reading and interests currently lie.
In the meantime, I leave you with a couple of hilarious out-takes. The first one is closer to what I was trying to achieve, though far too fast, and when I slow it down, it doesn’t work at all. The other is more sedate, giving the effect of rotating cones.
don’t push me ‘cos i’m close to the edge – g flash
I keep returning to the Tonematrix Flash application. It’s simple, but the choices made by its creator are very clever – the spread of notes, the reverb and the speed of the echo make it impossible to select dissonant patterns. Even the visual ripple adds to the effect.
…whirling silently in space…
My idea for the lighting effect was to use the sine of the angle of each criss-crossing line as the basis for the line’s saturation and brightness (using the HSB colour mode rather than RGB). That way, I figured, the lines would be brightest when sloping at 45 degrees, and darkest after they had turned a further 90 degrees. That should suggest a constant light source emitting parallel rays onto the rotating blobs.
It didn’t work, however, because the lines never changed their values, and it took me a while to work out why. By using pushMatrix(), translate(), rotate() and popMatrix() to handle all of the complex calculations, the angles remained constant because the drawing window was translated and rotated, not the lines themselves. I need to go back to my original intention to recalculate new values for the co-ordinates of each end of every line in every frame.
This may take a while…
…and the world is like an apple…
There was, indeed, a scaling factor creeping in, thanks to a fundamental error in my formula to calculate the y co-ordinates of the cross-hatching lines. I was introducing references to the centre of the screen, when the calculations should be purely relative to the blob’s centre.
At some stage, I intend to give the cross-hatching lines a bell-curve rather than a completely random distribution, which I hope will reduce the bunching at the sides of the implied circles, and to even out the spacing of the blobs around the centre. The main remaining task, however, is to attempt my proposed lighting effect. I have no idea whether it will work or not, but that’s what experimenting is all about.
…past the minutes of its face…
Yesterday’s progress in rotating the blobs around their own centres was achieved surprisingly easily, thanks to some timely reading of the third of my new acquisitions at work, Dan Shiffman’s Learning Processing, and using my old adversaries pushMatrix(), translate(), rotate() and popMatrix(). I’d been intending to calculate the translations of each line’s start and end co-ordinates from frame to frame, so thanks to Dan for saving me that effort (which I’m sure would not have been straightforward).
Today’s task, however, of making the blobs look more like circles, has gone slightly awry. As you can see, it works well for the central blob, but the others aren’t behaving at all. The lines are in the wrong places and, although you can’t tell from the still image, they are now spinning around points that aren’t their centres. An offset or scaling factor must be creeping in somewhere, but I can’t see where.
…like a clock whose hands are sweeping…
This is a little more like it, but there are still several steps to go.
…running rings around the moon…
Well, it’s not quite what I had in mind, but it’s progress of a sort.
Sorry, no Tweets were found.