AustinBlanco.com

Category: uManager

  • Cooling a Pt Grey Camera

    I’ve been working with Pt Grey (now FLIR) cameras for a few years now, and one nagging question in the back of my mind has been whether or not it is possible to cool them via external means. There are basically 3 categories of cooling when it comes to low light cameras:

    • no cooling whatsoever
    • cooling to + or – some delta from ambient
    • fixed-temperature cooling to some set point.

    Of these methods, the fixed temp cooling is the most difficult to achieve, for a number of reasons, and I don’t believe these types of cameras would benefit greatly from such an attempt, so my idea was to simply answer the question, “Will cooling improve the performance of these cameras in a measurable way?”

    Normally, the cooling of a sensor takes place as close as possible to the back side of the sensor itself. In this case, I started with an already-encased camera, the Pt Grey Chameleon 3. Because I didn’t have access to the sensor back directly, I figured making contact with the case, at as much surface as possible, would suffice. In order to do that I simply used 2 l channel strips of aluminum, and placed thermal tape on all 3 sides touching the camera. The graphic below shows what was added after the aluminum wrapper. First, a peltier (thermo-electric heat exchanger) was coupled to the aluminum. From there, a large CPU heat sink/cooler was attached to the hot side of the TEC. The general idea here is that the aluminum should absorb the heat from the camera. The peltier moves a lot of that heat to the CPU cooler, which radiates the heat into the air. This is a rather rudimentary setup, but it works for the proof of concept.

     

     

    Below is an image of the assembled system. To provide the required 5V and 12V power to the cooler and peltier, I used my old reliable ATX Power supply.  This assembly low cost components from Amazon and the like. I think the total cost was $27 or so. Maybe more including thermal tape.

    So how did the system perform?

    First I allowed the stack to heat up for ~ 30 minutes. I wanted the camera to heat-soak the wrapper, so that when cooling was applied any measurable change could be collected. I think the act of adding the non-powered stack aided in the camera performance a bit, as simply having the radiator attached means that the hot camera can cool more readily from greater surface area exposure. In any case, a thermal camera was used in timelapse mode to collect the change in temperature over time. The recording was started after 30 minutes of warm-up. Images from the thermal camera were captured during a 1 hour period, while the camera was run in timelapse mode using Micro-Manager 1.4. First, here’s a GIF showing a time-compressed thermal image.

    Several things to note here. One is the large drop in camera body temp during the experiment. Another is the subsequent increase in radiator temperature, as it works to shunt the heat from the peltier. Also note the wings on each side of the camera body. They start at a similar temp as the camera body, then drop in temperature significantly (40-50°F) over the duration of the timelapse. It’s important to also note that the emissivity of the plastic camera body differs from that of the aluminum. As a result, even if the temperature is exactly the same, a slight difference in the IR image will be visible.

    Below are the results of the image captures. First is a graph showing maximum measured intensity of any pixel in-frame, over the duration of the timelapse (120 frames @ 30Seconds interval). In the case of “hot pixels”, as the camera temperature decreases, the collected signal from those pixels drops.

    Graph of measured 8-bit maximum intensity in image over time of experiment. Orange line represents a 20 point moving average trend.

     

    Next, I wanted to measure the total # of hot pixels. Now, it’s somewhat nebulous to define a hot pixel, but I used anything 1.5x greater in intensity than the minimum background, or offset, of the image. On this experiment, the average background was ~ 14, resulting in a threshold of 21. I was really surprised by this one. There is a rather large spike in the data, and I’m not certain what that is from. However, this again shows that the cooling is indeed reducing the hot pixel count, as would be expected. Additionally, the count can be seen to normalize at around 1500 pixels, which I expect is where the system started to thermal stabilize.

     

    For a final set of interesting images. Here’s a shot of the stack after the experiment finished. Note the low temp of the wings and the back wrapper block.

    Another interesting shot, this one of the sensor face. Using the cooling system it was at 104°F.

    Turning the system off produced a temp of ~ 130°F.

    My conclusion is that it is possible to cool even encased cameras using external cooling methods, to improve the performance of the camera(s). I do not think such adaptation will yield comparable results to a camera designed with cooling from the start, but this is an interesting option to achieve better results from a camera with a low price point.

     

    -Austin

     

     

     

     

     

     

     

     

     

  • Automated Capture and Save script for Micro-Manager

    I wrote this for a client, but figured others could make use of it. This code simply captures a number of images as defined by the user, and saves them to the specified folder without displaying them. This is useful if you don’t want all of the images open in memory during a timelapse.

    Simple Capture and Save Beanshell Script

    -Austin

     

     

     

  • Triggerscope & Micro-Manager Demo LED

    With ASCB right around the corner, I’ve been looking for opportunities to showcase the controller, so I’m happy and grateful to announce that the TriggerScope16 will be demonstrated at the Open-Imaging Micro-Manager booth (#1312)  this year!

    Here’s a short video I made showing the new display which will be at the booth. The display uses a NeopIxel (WS2812) strip, housed in a 1″ square extrusion, capped with a milled acrylic rod.

     

     

  • Acquisition Speed Comparison of MetaMorph, NIS Elements, Micro-Manager

    How fast can a typical imaging system really run? What factors affect this? While most research might not require rapid sequential capture, almost all experiments can benefiet from tight exposure/illumination timing, yet few microscope users are aware of timing delays injected into experiments by the control software they are using. So how much delay is caused by software? I’ve long wanted to look into this, and finally got the chance!

    In order to accomplish this, I programmed a microcontroller to accept commands from the Lumencor Spectra-X. This high power/high speed LED engine is popular for fluorescent excitation, as a result, almost every available software application can control it. I set up my code to measure the time in which a known shutter, or known wavelength command was received on the serial line (well, USB serial).

    The team at Technical instruments were kind enough to loan me the use of their equipment, so a generous thanks to Reese Allen and the entire Technical instrument staff!

    Experimental conditions were as follows:

    • All software packages were installed on a clean OS install of Win7/x64
    • Test machine was a Dell Precision series
    • Tests were performed by configuring the camera to run ~100fps. This was accomplished using a 4×4 binning, and an exposure of 9.8mS.
    • All software applications were set to send at minimum one shutter and one wavelength change per acquisition cycle. (i.e. 1 picture from the camera, + 1 wavelength change + open shutter, then switch wavelength and cycle shutter).
    • All applications were first tested in a “free run” mode, to confirm the camera configuration was capable of 100fps at minimum.
    • No other devices were installed for these tests.

    The results were quite interesting:

    Software
    NIS Elements V4.30
    Micro-Manager V1.4.22
    Metamorph V7.8.12
    Metamorph Streaming
    Average Overhead
    60mS
    71mS
    65mS
    11mS
    Max FPS
    16
    14
    15
    90

     

     

     

    Here are some videos showing each of the programs performing. You can see some timing variation (likely caused by my capture device) but the averages are easy to resolve, and they correlate to the speed seen on the captured image stacks.

    NIS Elements

    Micro-Manager

    MetaMorph

    What becomes quickly apparent is the influence of asynchronous device control using metamorph’s “Stream” function. This is making use of a patented computer-based device sequencing technique. This technique waits for a camera “event flag” (interrupt) to fire, and when it does, a pre-defined set of events occur which control devices. This is similar to what many external trigger devices do, such as a configured national instruments card , or a pulse oscillator, or the triggerscope. The key difference here is that an external card and/or device isn’t needed, this occurs within the PC itself.

    Some further thoughts:

    • Micromanager is a great open-source competitor to other pay-for solutions. Good speed performance for a low up-front cost! (the cost of setting it up!)
    • It’s interesting that this never really seems to come up for 90% of customers who purchase “high speed” devices. Either the exposure times needed for acquisition of dim signal are so long as to never reach the speed thresholds shown here, or the capture frequency needed for a given study doesn’t require these speeds, or some other cause, but in my experience this is rarely a complaint on behalf of clients. Why isn’t this a bigger problem?
    • Many, many devices can’t reach the speeds shown here. In my tests I was using an LED driver. LED’s should have a switch time in the <5mS range. The slowest components usually found on a common automated microscope are the filter wheels and turrets, which usually run at the 50ms range when fully loaded with filters. (that’s on the fast side). So is this the reason the problem isn’t exposed more often?
    • By far, the slowest components you’ll find for microscopy are found on automated microscopes. Shutter open/close times on a common scope (i.e. big 4 name brand scope) can be in the upwards of 100ms! Moving a big filter turret usually takes 200mS. Again, this begs the question of how important speed really is for the common researcher….
    • For those who want the fastest possible speeds, have no fear! I’ll be announcing some major improvements to my triggerscope soon, to include programmable high speed sequencing capability!

    -Austin

     

     

     

  • ImageJ Counting Macro for Known Field Values

    Here’s a simple method to deal with varying intensities in a large run of images, assuming you have a known number of cells in a field. If I assume I should see, say, more than X cells per area, I can adjust my threshold to slowly increase it’s aggressiveness until that minimum counted value is met. The code can be downloaded as an imageJ macro here. but here’s a walk through of this simple script. My comments are preceded by a *.:

    rnum = 0; *this creates a new variable, or container, for our # of regions

 tval = 2000; *this is the starting object threshold value. 
 while (rnum<500) *this is a "while" loop. The loop runs until the argument is satisfied.
 { 
 setAutoThreshold("Default"); 
 setThreshold(tval, 4095); *note that tval = the minimum threshold value
 run("Analyze Particles...", "size=0-Infinity circularity=0.00-1.00 show=Nothing display clear add"); 
 rnum = roiManager("count"); 
 tval = tval - 100; *tval continues to become more aggressive in counting objects until the argument is met. 
 }

    Simple routines like these can reduce your headache factor by a large margin if you learn how to harness the power of macros!

    -Austin

     

     

     

     

  • Updating Software? A pre-chaos checklist…

    A few years after your shiny new system is installed, you’ll inevitably look at it just like you look at a car. What was once running flawlessly now has a few bugs, some dust, is slower and generally worn in. So, at some point you’ll decide it’s time for an upgrade. This may consist of new or updated hardware, probably a PC and software, but for now let’s assume all we are going to do is patch the software.

    Most software packages depend on a licensing scheme in order to run an update. If you have uManager, this won’t be a problem, but most commonly I work with MetaMorph and Elements, so I’ll be covering those exclusively.

    What version do I have?

    If you have Meta and you want to check your version and it’s capabilities, you can either call the office, or check the software update site here.

    If you have Nikon Elements, you can view your info by selecting the Elements program folder from the start menu, then clicking “Hasp Info”. Here’s what my hasp info looked like:

    If this was a consumer key, it would show an update expiration date (the date at which, once passed, new versions need to be purchased) and list the modules you own.

    Once you’ve decided on upgrade options etc, it’s time to look at what devices are installed on your system. I like to categorize devices based on how they communicate with the computer, as this is the primary factor in determining compatibility problems.

    • Serial, or USB to Serial devices and triggered devices  – Serial devices will be connected via a 9-Pin cable, and will use a COM port on the computer. You can check COM ports using windows device manager. USB falls into two general categories – Serial Emulators or direct drivers. USB to Serial Emulated devices simply create a fake serial port at the device side, so when you plug the device in and power it, you’ll see a new COM port appear in your ports list under windows device manager. Some systems, like the Sutter 10-3, use a driver which allows you to select either VCP (Virtual Com Port) or driver-only. Triggered devices use TTL signaling to communicate, and typically are connected via BNC cables to either another device or a custom board on the PC, so this could mean life is easy or hard, depending on what you have.
    • USB Driver Devices – Any device which, once loaded, appears in the windows device manager under it’s own category, uses a direct driver. A good example would be a Ti-E microscope. You’ll find the scope appear under “Imaging Devices”. While generally speaking, USB connected devices are straightforward to work with, it would be prudent to confirm that the firmware of the device, and the driver version for the device, are both compatible with the new version of software you’ll be installing.
    • PCI/PCIe Card Devices – Cameras usually fall into this category more than anything else, but there are devices such as an Andor Revolution Laser Combiner, or a Mosaic Illumination system, that also require the use of a card installed in the computer. For these devices it’s important to check firmware and driver support for your software upgrade, and it’s extremely important to consider the card type, it’s height requirements, and it’s connector (like PCI vs. PCie x16 etc) when purchasing a new computer.
    Note the "Virtual Com Port" vs. the standard "communications port". The former is a USB to Serial Adapter.

    Once you’ve collected the above info for each device which is run through your imaging software, you can go through a straightforward checklist of the required communication items for that device. Keep in mind that for most software companies, they build a driver for a given instrument at a single point in time, and don’t update that driver until there is a good reason to do so. Version changes between the software, firmware, and drivers may cause problems, so we’ll investigate this entire chain for our devices:

    1. What is the version number of the software you’ll be upgrading to?
    2. For that version of software, what are the driver versions required for your devices? In Meta, you can view the Supported Hardware page, to check the minimum version for your device. Nikon has a support document, which can be found on the download site (enter any username, and your Hasp ID for the password), under “Device/Camera/Firmware Documents, or just click this link after logging in.
    3. If your device driver needs to be upgraded, does the firmware in your device need an upgrade as well? This can be investigated by contacting the device manufacturer.
    4. Is either the device manufacturer, or the software developer, aware of known major bugs or issues with the versions you’ll be upgrading to? Normally there are always a few bugs, the question is whether or not they’ll be a problem for your work.
    5. If you are considering moving from an x32 to an x64 system, make sure to check for 100% support in x64, I’ll be writing more on this on a separate post, as it’s a constant problem for me right now.

     

    Example of a Supported device on Meta's hardware page. Note this device says it is not supported in Windows x64!

    Armed with the answers to the above questions, you’ll be well prepared to perform an upgrade on your instrument! As always, you may wish to do this yourself, or pay your local sales rep to take on this headache. As a general rule software upgrades are a lot of work, and provide a chance to break an otherwise functional system, so service and sales reps are understandably wary of upgrades. You can help your rep a lot by bring this info to them at the beginning of the upgrade process (or at least providing the version #’s and device types on your system).

    This process will obviously take some time to complete, but it’s a very small investment to reduce the chance of the system going down due to a half-update, or performing the update only to find some major bug which will render the system unusable! You’ll never guess how I learned to be wary of this…:-) Ultimately, software updates can provide new capability, fix bugs on the device or software side, and are an important aspect to the overall maintenance of an instrument. With proper planning, the operation can go from chaos to an enjoyable experience.

    – Austin

     

     

     

     

     

  • Acquisition crashes, and power settings in Win7

    Windows 7 has a new power management interface, and the design of modern motherboards, along with win7 Automatic Power Management (APM), can cause some insidious device-based software crashes if power options aren’t set correctly. Here’s how to make sure your system is running in the best mode.

    • Open the Windows Control panel
    • Search for and open “Power Options”

    • You’ll see a “power plan” like the one below. Click the “Show Additional Plans” button, and check the radio button for the “High Performance” plan.
    • Click on the “Change Plan Settings” link, then click “change advanced power settings”.  This window is where the real control over the power plan exists.

    • Browse through each item provided, and set power management to either disabled, maximum performance, or off, depending on the item. Things like turning off the hard drives are a bad idea on an acquisition system, as this can cause problems with long term timelapse.
    • One key item is the PCI link state power management. This should be set to “Off”. This item selectively disables power to the PCI bus. Some of the cameras and devices used in acquisition systems rely on PCI / PciE based cards to operate, and cutting power to these cards can cause all sorts of havoc.

    • Another common problem, probably the biggest I’ve seen, is the USB suspend entry. Again this function turns off the USB bus when not in use. This has caused crashes in software when operating USB devices, so it should be set to “Disabled”.

    • Once you’ve investigated each item and made any desired changes, click OK, and then close out of the power option windows.

    Making the changes noted above should make a big impact on the stability of your imaging system. Hopefully this guide helps you to avoid acquisition crashes on your system!

    -Austin

  • Determining background sources in fluorescence

    For microscopy engineers and suppliers like me, the background produced in an image is of importance, if that background is created by the imaging system itself. What so many of us on this side of the scope (vs the user side) forget to train on and talk about is the specimen side of the background. So, how can you figure out where the background is coming from in your image?

    Example of two noise sources, one distributed and the other localized.

    Background Sources

    Usually background sources mentioned are those produced by the imaging system. I’d like to cover instead those produced by the specimen and the imaging system. These can be:

    System Background Sources

    • Fluorescent filter crosstalk/performance limitations
    • Objective and other optical limitations (aberration/convolution etc.)
    • Camera measurement noise (A/D Read Noise)
    • Camera-produced background noise (heat that the camera sees as signal)

    Specimen Background Sources

    • Auto-fluorescence produced by cells and/or media
    • Refraction/reflection of excitation light by specimen container (think plastic multi-well plate)
    • Ambient light in the room where the microscope is located
    • Byproduct remaining from sample preparation protocol (stain that remains after a rinse, etc.)

    Identification and Removal

    Instead of reviewing each noise source type and it’s cause, let’s instead perform a gross identification scheme to determine where the greatest noise source exists.

    Method 1: System vs. Specimen Measurement
    1. Configure your microscope and imaging system, and place your specimen on the scope.
    2. Focus on your specimen.
    3. Acquire 2-3 images of various locations of the specimen.
    4. Remove the specimen from the microscope entirely, not changing the scope at all (don’t drop the focus or change filters).
    5. Acquire 2-3 images with the scope in this state.
    6. Using either the ROI tools, or other tools available in your software of choice, measure the average intensity value, for the non-exciting area of your 2-3 specimen-present images, that we acquired in step 3.
    7. Measure the entire image field of the  2-3 images we acquired in step 5.
    8. We now have an intensity measurement of the amount of background for the imaging system + specimen, and the imaging system only.
    • If the image intensities remain relatively unchanged between the two image groups, the source of noise is in the imaging system.
    • If the intensities from the images in step 5 are significantly lower than those from step 3, noise is being produced by the specimen, or specimen container.

     

    In my next post I’ll cover how to further pinpoint noise sources, and how to eliminate them.

    – Austin

     

     

  • *UPDATED* Micro-Manager Tethered to a Nikon Digital SLR

    ***UPDATE 3/3/2014***

    After a few requests for a report on x64 capability using this tethering technique, I tried installing the NK Remote software on a rather fresh copy of Windows 7×64 – it did not communicate with the camera at all. On the other hand, the open source application “DigiCamControl“, worked perfectly. Now, as far as micro-manager goes, there isn’t a connection from DigiCamControl to micro-manager. So – short term solution is to run the proposed setup below on an x32 system – if anyone gets x64 working please post here!!! -Austin

    So I had a customer interested in a macro application for scanning. In some cases, applications like these don’t require a telecentric optical system such as the AZ-100, nor do they fit into a typical stereo microscope application. So, what to do? Well, when your object for imaging is too large for a microscope, one option may be a macro lens on a digital camera. Something like this:

    Copy stand for SLR

    This type of system will allow for a stable focusing and zoom setup, but is limited in magnification power and light control. In some cases though, this is the way to go.

    The next problem is that of focal and positional control. No microscopy device control software available, such as elements or metamorph, supports non-scientific grade cameras. So, how do we position a specimen under this camera in an automated fashion? Well, it turns out micro-manager has a plugin available for such work, and it’s available in the nightly builds here .

    What you end up with is a camera that can be controlled from a laptop, along with a stage, z motor and other automated imaging hardware. Here’s an example of my setup running on a windows 7 x64 laptop and a D80.

    D80 and Win7 x64

    Requirements

    This setup requires the following items:

    1. Suitable camera and lens (see below)

    2. Copystand for camera.

    3. Computer for control.

    4. External power supply for camera or a battery extension (more for ease of use but I consider it a requirement).

    5. USB Cable to camera.

    6. Control Software for interfacing to uManager. This is pay-for software, found here. The software currently ranges from $90-180.

    7. A right angle view finder isn’t required, if you don’t mind a stiff neck!

    Setup:

    So, follow the instructions found here for setup. My summary of setup, which took a whopping 5 minutes (this is amazingly quick for open source software!) went as follows:

    1. Download Breeze Systems trial for NKRemote & Install.

    2. Download nightly uManager build & Install.

    3. Set camera to PTP mode.

    4. Run NKRemote and snap image to confirm communication with camera.

    5. Run uManager. Edit hardware seup using the “Setup hardware” tool and removed the demo camera, and added the NikonDSLR.

    6. started snapping images! Here is an example of running in uManager (click on the picture for a higher res version):

    Nikon D-80 acquiring images in uManager

    What cameras are supported:

    All of the basic DSLR models from Nikon are included with the NKRemote software. Tethercam is the driver used for the uManager side, and it states an “incomplete list” of cameras as follows:

    Nikon D7000, Nikon D90, Nikon D5000, Nikon D300, Nikon D300s, Nikon D700, Nikon D3X, Nikon D3s, Nikon D3, Nikon D200, Nikon D80.

    Lenses to Use:

    Some lenses that work as portrait lenses like a Nikon 50mm will work adequately as macro lenses. On the other hand, it’s recommended to shell out the extra cash for a well-made macro lens, such as this one. The nice thing about working with commonly available photo gear is that in many cases you can even rent lenses to see what works best for the job at hand.

    This was a fun and quick test and I am excited to see how this capability is used for macro work in the future!

    -Austin

Social Media Auto Publish Powered By : XYZScripts.com