Bug by First Last, on FlickrFast Stacker (Arduino based automated focus stacking rail)
Moderators: rjlittlefield, ChrisR, Chris S., Pau
I believe I've zoomed in on what would be the best PP for focus stacked extreme macro shots. There is a very active ongoing academic research in this field. One has to google for "wide-field microscopy 3D stack blind deconvolution" to get the relevant hits. This recent (2013) research paper looks the most promising:
Blind Deconvolution of Widefield Fluorescence Microscopic Data by Regularization of the Optical Transfer Function (OTF)
The research problem they are facing is pretty much what macro photographers need: remove the out-of-focus stuff from individual stack frames, before doing focus stacking (in addition to the standard diffraction deconvolution). And the method they employ doesn't require any special equipment, as it is a blind deconvolution method (when you recover both the original unblurred image and the instrumental 3D point spread function, PSF, in a single optimization procedure). Unlike similar recent research papers, this one is different in that they constrain ("regularize" in their slang) the 3D PSF not in real space, but in Fourier (frequency) space, which according to the authors gets rid of the typical deconvolution artifacts (ringing).
They don't provide their software (I suspect it is just a Matlab script), but do provide all the equations. It is just a matter of turning those equations into a code. I'll be looking into that.
Blind Deconvolution of Widefield Fluorescence Microscopic Data by Regularization of the Optical Transfer Function (OTF)
The research problem they are facing is pretty much what macro photographers need: remove the out-of-focus stuff from individual stack frames, before doing focus stacking (in addition to the standard diffraction deconvolution). And the method they employ doesn't require any special equipment, as it is a blind deconvolution method (when you recover both the original unblurred image and the instrumental 3D point spread function, PSF, in a single optimization procedure). Unlike similar recent research papers, this one is different in that they constrain ("regularize" in their slang) the 3D PSF not in real space, but in Fourier (frequency) space, which according to the authors gets rid of the typical deconvolution artifacts (ringing).
They don't provide their software (I suspect it is just a Matlab script), but do provide all the equations. It is just a matter of turning those equations into a code. I'll be looking into that.
New public release of the rail software s1.16. Just one change: fixed the annoying bug in the EXTENDED_REWIND section: multiple frequent presses of the key "1" often resulted in the rail refusing to stop (it keeps moving towards the foreground until you hit any key). In this new version s1.16 the bug is fixed.
See http://pulsar124.wikia.com/wiki/Whats_new
In other news: the project is now hosted on github.com:
https://github.com/pulsar123/Fast-Stacker
See http://pulsar124.wikia.com/wiki/Whats_new
In other news: the project is now hosted on github.com:
https://github.com/pulsar123/Fast-Stacker
I am amazed at how different my rail is by comparison.
I based mine around a picaxe and uM FPU. although its faster than hand I have never actually run it at it max speed so don't know how it compares on that front.
I am interested in how you dealt with the maths in your system, was the basic floating point of Arduino enough? My rail which I am currently updating was built for resolution and the inaccuracies that can be caused by micro stepping to be so small that they did not matter.
I have gotten the resolution to down to 0.3125 micro meters. as a result the basic integer maths of picaxe and even the basic floating point maths of Arduino was not able to cope.
I may look at adding a high speed shooting menu, a place where settle time is ignored and the maths of DoF discarded (input of camera info is time consuming). All the will be needed is distance between shots and shutter duration. although being able to add presets that can be quickly called could add in the DoF. Sorry I am thinking aloud here
great work.
I based mine around a picaxe and uM FPU. although its faster than hand I have never actually run it at it max speed so don't know how it compares on that front.
I am interested in how you dealt with the maths in your system, was the basic floating point of Arduino enough? My rail which I am currently updating was built for resolution and the inaccuracies that can be caused by micro stepping to be so small that they did not matter.
I have gotten the resolution to down to 0.3125 micro meters. as a result the basic integer maths of picaxe and even the basic floating point maths of Arduino was not able to cope.
I may look at adding a high speed shooting menu, a place where settle time is ignored and the maths of DoF discarded (input of camera info is time consuming). All the will be needed is distance between shots and shutter duration. although being able to add presets that can be quickly called could add in the DoF. Sorry I am thinking aloud here
great work.
Wow, 0.3 um - are you sure your rail can actually deliver that? How do you treat backlash? It is huge by comparison - my Velbon rail has it at 200 um, and the commercial StackShot has the same value. I put a lot of programming efforts into proper backlash compensation, and it works really well (at least at the resolution level I can detect with my 10x/0.25 objective - 2.5um) - any motions I do (fast forward, rewind, focus stacking) always end in a fully backlash compensated state (meaning my programmatic coordinates always = physical rail coordinates, when the rail is at rest, or when it is moving in the "good" direction) .
My single microstep is 2.5um. so that's the fundamental limit of how accurate my rail can or should be. At this level, floating point accuracy is totally adequate.
My single microstep is 2.5um. so that's the fundamental limit of how accurate my rail can or should be. At this level, floating point accuracy is totally adequate.
-
TheLostVertex
- Posts: 318
- Joined: Thu Sep 22, 2011 9:55 am
- Location: Florida
orac,
Are you looking to use your rail as a portable solution or as a tabletop/studio solution? If being tethered to a computer is fine, then maybe my DIY solution will work more for you. It can handle arbitrarily large numbers of steps and sizes. It also lets you select just the distance for step size/number of steps if wanted.
Are you looking to use your rail as a portable solution or as a tabletop/studio solution? If being tethered to a computer is fine, then maybe my DIY solution will work more for you. It can handle arbitrarily large numbers of steps and sizes. It also lets you select just the distance for step size/number of steps if wanted.
I use a ball screw and nut (same as CNC machines) to basically eliminate back lash, 4mm thread pitch and a 1/64th micro step on a 200 step bipolar stepper motor. The stack shot from what I understand uses a achme thread which is low back lash but more than a ball thread. its actual accuracy is more dependant on the accuracy of the driver and motor, with some quotes as low as 20% accurate on micro steps at the 1/64 level. but 20% of 0.0003125mm is 0.0000625mm. ever tried measuring below 0.01mm, at 0.3um pretty sure operating temperature is going to have a bearing on things. you should be able to eliminate backlash completely by preloading, but this will increase load on the motor.
the system has already been used to image flowers in the wild as well as desk work, but that was one version 2 software, version 1 and 3 never made it out of the "lets see if this works" stage. currently working on version 4 which does a better job of accounting for internally focusing lenses.
Numbers are not an issue, the uM FPU (Floating point unit) is a specialised maths co processor. using the 32bit variant is more than enough. Loading it with functions during development saves programme space on the main processor, follows mathematical order of operation, and handily is able to natively split numbers at the decimal point.
the last part is surprisingly handy. to get the number of steps and lead screw rotations you simply divide the distance by lead screw pitch. with a pitch of 4mm and a distance of 6mm you need 1.5 rotations of the lead screw. the motor is specified as a 200 step motor with a 64 micro step controller 200*64=12800 steps per rotation.
so
(200*64)/(6/4)=19200, which will fit into a standard word length variable. the problem arises when you get past 20mm and you exceed the max value of a word (64553).
we know that 12800 steps are needed for a single 4mm movement or 1 rotation. 6/4=1.5 rotations, split that and you get 1 and 0.5
or one rotation and then take the 0.5*12800=6400 extra clock signals to send to the motor controller. all this is done on the fpu once the CPU has loaded the values and the routine called. the only time the system track the position of the carriage is during the it positioning, after a each run the carriage is parked back to the start position.
Yesterdays test stack went quite well, although I didn't set the system for enough depth, more of an error on my part. it calculated 0.04468352mm between each shot an a DoF of 0.2234176mm and took 402 shots before I knocked the D-sub that connected the rail to the controller and triggered a rail error.
I haven't been able to overload my rail in normal use. using my hands (very scientific) with a fully charged battery I would say it should be able to lift vertically in excess of 20kg which is more than enough for just about every setup I can imagine.
the system has already been used to image flowers in the wild as well as desk work, but that was one version 2 software, version 1 and 3 never made it out of the "lets see if this works" stage. currently working on version 4 which does a better job of accounting for internally focusing lenses.
Numbers are not an issue, the uM FPU (Floating point unit) is a specialised maths co processor. using the 32bit variant is more than enough. Loading it with functions during development saves programme space on the main processor, follows mathematical order of operation, and handily is able to natively split numbers at the decimal point.
the last part is surprisingly handy. to get the number of steps and lead screw rotations you simply divide the distance by lead screw pitch. with a pitch of 4mm and a distance of 6mm you need 1.5 rotations of the lead screw. the motor is specified as a 200 step motor with a 64 micro step controller 200*64=12800 steps per rotation.
so
(200*64)/(6/4)=19200, which will fit into a standard word length variable. the problem arises when you get past 20mm and you exceed the max value of a word (64553).
we know that 12800 steps are needed for a single 4mm movement or 1 rotation. 6/4=1.5 rotations, split that and you get 1 and 0.5
or one rotation and then take the 0.5*12800=6400 extra clock signals to send to the motor controller. all this is done on the fpu once the CPU has loaded the values and the routine called. the only time the system track the position of the carriage is during the it positioning, after a each run the carriage is parked back to the start position.
Yesterdays test stack went quite well, although I didn't set the system for enough depth, more of an error on my part. it calculated 0.04468352mm between each shot an a DoF of 0.2234176mm and took 402 shots before I knocked the D-sub that connected the rail to the controller and triggered a rail error.
I haven't been able to overload my rail in normal use. using my hands (very scientific) with a fully charged battery I would say it should be able to lift vertically in excess of 20kg which is more than enough for just about every setup I can imagine.
-
Ultima_Gaina
- Posts: 108
- Joined: Sat Jan 28, 2017 11:19 pm
-
Ultima_Gaina
- Posts: 108
- Joined: Sat Jan 28, 2017 11:19 pm
Since I got request to clarify how I made the connection between the rail and the motor, I'm adding a few photos showcasing the upgrade I made last year, using servocity structural components.
If you want to follow this path, the main challenges are:
- modify on end of the 8mm Stainless Steel Precision Shafting to match the square profile of gear inside the rail (it takes patience, careful filing and frequent caliper measurements)
- accurately drill the 4 holes on the rail side to properly center the clamping hub on it.
Once these 2 steps are done, all other components will align perfectly.
That's the beauty of these servocity components.
https://www.servocity.com/
If you want to follow this path, the main challenges are:
- modify on end of the 8mm Stainless Steel Precision Shafting to match the square profile of gear inside the rail (it takes patience, careful filing and frequent caliper measurements)
- accurately drill the 4 holes on the rail side to properly center the clamping hub on it.
Once these 2 steps are done, all other components will align perfectly.
That's the beauty of these servocity components.
https://www.servocity.com/