Quite a while ago I’ve made some highspeed photos of water … ehm splashes. Things like http://blog.rdln.ro/highspeed-water-drops/. Which are, of course, absolutely impressive Better yet, pay a visit to http://www.markusreugels.de.
I think his are the first photos of this kind I’ve ever seen and although I’ve pursued the project more out of technical curiosity, I did spent a lot of time looking at his really cool shots., but still needing some improvements. I remember having quite a bit of fun last time I was doing this (the required softaware/hardware setup was a DIY solution), so, why not set things up again and take another shot? This and the following posts will focus on the technical solution and only to a lesser extent to photography.
Well, one reason would be that the hardware part is a bit cumbersome and I’m a ‘software’ engineer The other reason will follow after the mandatory equally cumbersome explanation..
What’s in the image? Short version: it’s a (small) drop of water hitting the water surface. But to get that shape you’ve got to freeze the image a few milliseconds after a drop of water hits the column of water created by another droplet which hit the water surface some other milliseconds before.
Ok, how to freeze the image? Dialing a DSLR camera to highest available shutter speed (1/8000s) won’t quite do it because the speed at which the water moves in this scenario still gives a lot of motion blur. But a strobe light will be fast enough – on a lower power setting will light the scene for only 1/64000th of a second or so.
Also, the height from which the water drop falls and the amount of water in the drop will have a direct impact of the height of the water column (it is macro photography).
So, let’s add a mechanism – water reservoir and a valve – which regulates the amount of water going down and which is fixed on a support above the place where the photo is taken. So the sequence roughly changes to open camera shutter, open the valve, close the valve, wait for impact, trigger the flash, close shutter.
At least in theory, if these events are spaced in time at the same intervals then the photo will be the same; change the intervals between the events and you get different shapes.
How to make these things happen always at the specified moment? Add a micro-controller which actuates the camera shutter, the flash and the (solenoid) valve. And the required electronic circuit, wires, water containers, and a rigid frame. Optionally, if you find yourself mistaking the kitchen for a makeshift “lab”, a good explanation and a dinner reservation might be additional, but valuable, prerequisites for this activity.
Ok, and now for the other reason: there’s a software part.
The software part got a bit fluffy also. Why? Because of the need to change the settings.
That micro-controller mentioned before is driven by a program which roughly consists in:
wait(delay1); //size of first water drop
wait(delay2); //interval between water drops
wait(delay3); //size of second water drop
wait(delay4); //wait until splash happens and pick a specific moment from the splash's lifetime
To do adjustments you change delay1..4, and for that you have:
Option a: add hard controls for them to the micro-controller – but this means more electronic components, hardwired circuit, and so on.
Option b: change the program on the micro-controller – but this means recompiling the program and flashing the micro-controller for each change made to that program which is a rather slow process and “eats” up the flash memory of the mc.
Option c: change the above mentioned program but don’t change the micro-controller’s program. Keep the mc linked to a computer, program it to wait for commands, and feed it a new set of instructions each time you have new “program” to run. You end up making two programs: one on micro-controller waiting and able to run a specific set of commands and another one on your (other) computer capable to create a list of commands understood by micro-controller’s program, but this allows faster updates and maybe a cleaner solution for separating the commands specific for controlling the photo rig from the other components.
What the software component ends up looking like: nice Gtk# based app where you can edit a small Lua script which gets translated in a “”proprietary”” list of [opCode[,parameter][,parameter]..] which can be executed by a program running on an Arduino board.
And this amazing solution got partially backed-up to /dev/null.
But that’s actually not that bad. While rehashing this topic I think there might be a slightly more elegant solution.
What I’ll try to do in the next post is next is to come up with a small improvement for ‘Option C’ implementation. And because I don’t remember finding a complete ‘tutorial’ on that highspeed-water-drops-photography topic, I think I’ll try covering the entire project in a series of following posts.
References [ + ]
|1.||↑||Better yet, pay a visit to http://www.markusreugels.de.|
I think his are the first photos of this kind I’ve ever seen and although I’ve pursued the project more out of technical curiosity, I did spent a lot of time looking at his really cool shots.
|2.||↑||This and the following posts will focus on the technical solution and only to a lesser extent to photography.|
|3.||↑||The other reason will follow after the mandatory equally cumbersome explanation.|
|4.||↑||Optionally, if you find yourself mistaking the kitchen for a makeshift “lab”, a good explanation and a dinner reservation might be additional, but valuable, prerequisites for this activity.|