Tag: imaging

  • Starlyte Nebula Driver FAQ

    TL:DR

    Live Debugging

    Get a Full list of Supported Drivers

    Testing a Specific Driver File

    Testing Host and Sub Devices

    Live Debugging

    Due to the open nature of our driver system, it’s relatively straightforward to write a new driver file for almost any imaginable device in Nebula. However, driver development can be a pain, so I though I’d share some debugging tricks.

    For all commands, we will navigate to the command line using windows Command prompt or powershell. Here I show command prompt syntax. Nebula is commonly installed under program files. So in the windows start bar type “cmd” and press enter. This should open the command prompt. The commands below navigate to the install location.

    cd\
    
    c:\>cd "Program Files"
    
    c:\Program Files>cd Nebula
    
    c:\Program Files\Nebula>

    First, is the use of logging to the command line. When Nebula is launched from the command line, a series of optional switches can be used to report logged output. By opening this alongside the app, it’s very fast to figure out what or where something is going wrong. To see log output, use –printlog.

    c:\Program Files\Nebula>Nebula.exe --printlog

    This launches the app, but shows a live log output on the console at the same time.

    Get a full list of Supported Drivers

    This command will return a complete list of drivers found in the Nebula supported list. To print this list, use:

    c:\Program Files\Nebula>Nebula.exe --listdrivers

    Here is live example of that command and the expected result. A list of drivers is shown, press enter to close the listing.

    Testing a specific Driver File

    Next, let’s load up one of these drivers in the test utility. Now, this is where things get cool! The test utility can load a host device driver, inspect it’s shown devices, attempt to connect them, and even test every sub-device!

    So, let’s assume we have a new camera driver we want to work on. The camera should do things like snap an image, show various properties etc. In my example I use a real UVC (web) camera, and inspect the driver. The driver actually pulls the real camera info and even snaps a test image. The goal of this function is twofold, first to validate a given driver, and second to validate the device itself.

    For this command we will use –testdriver *drivername* and optionally –port *portname*, for example, COM5

    c:\Program Files\Nebula>Nebula.exe --testdriver --driver UVC_Camera

    Here we can watch the expected output in real time. Note a new window is spawned to show us the results for these tests.

    Testing Host and Sub Devices

    Let’s say we have a controller, for example, an ASI or Marzhauser box, which has a Z motor attached. In Nebula, the controller can be thought of as the Host (the resident controlling brain), and the device can be considered an appendage attached to the host. So all drivers must have a Host, but a Host may only have one device. In this example, we use a demo Focus device. First the host is loaded and analyzed, and then, you ca select to test any device provided by that host. I choose option # 1 (focus) and the test runs, even showing my driver has a small error I missed!

    Obviously, if you have a driver which isn’t behaving, please contact us – yet I hope these options provide a first-line of interface for power users, so simple things can be corrected and analyzed quickly!

    -Austin

  • Starlyte Nebula Now Supports Opto Gmbh Microsocpes

    Thomas Spieker from Opto Gmbh was kind enough to send us a demo assembly of several microscopes made by his company. Opto manufactures a series of highly integrated microscope modules, all provided in a small, integrated form factor.

    I was able to work with two different variations. One is a complete transmitted illumination setup with camera and objective at 20x. The second is a reflected light device with integrated LED illuminators.

    It’s neat to see such a compact setup on the desk. Using the 20x with a typical gut section stained sample was a piece of cake. Field uniformity on the illuminator was great, and color balance was as expected.

    The reflected design unit has both a coaxial and ring-style illuminator position – both are provided in Nebula as control LED options.

    Use of the camera was straightforward. It supports 8 and 12 bit readout on a color sensor. I can definitely imagine hooking this up to a small XYZ gantry or even a 3d printer for inspection use. Thanks to Opto for the demo unit!

    Here is a video review and live demo of hte unit while running on Starlyte Nebula.

  • Design of a cemented doublet lens using AI

    How well can modern AI agents produce engineering designs for optics? Well – I wanted to find out.

    To test this, I’ll walk through my goal. I need to get a lens made and I need it fast. I also need it to work properly. Lastly, I need it to be manufacturable at scale which means using glass substitutes often found in China.

    So – using Claude Chat, I took performance specs from several existing lenses, handed them over and added:

    “Make me a lens design that meets these general performance criteria.”

    I also asked :

    • Use Chinese available glass (e.g. K series)
    • Validate the design using a raytrace
    • produce estimated performance data
    • produce design drawings
    • produce a prescription
    • produce a ZMX file

    Here is the design it produced, it sure doesn’t look bad so far!

    After a while it decided to build it’s own python analysis tool using multiple metrics, it did the job and generally things look ok. However – is this actually OK? Let’s drop the lens design into Zemax.

    Using a COTS 200mm doublet as a comparison, I pulled a image, plot, ray fan and Huygens spot to inspect. All look quite similar, the spot size can be realized a bit better, but consider the aperture on the reference file was slightly larger, so that means difference in NA.

    AI Doublet Left — COTS Design at right

    Ray Fan Diagram

    Note there is a difference here, this design is not optimized – with an optimized second surface, it’s obvious a lot of improvement can be made. Yet for a commercial type lens, I think this is a good example of a sufficient result – it’s less than the diffraction limit, which is a suitable bar for pass failure.

    Huygens spot size is below, again note the difference in the psf due to optimization missed.

    Finally, we can compare the simulated image formation – here I don’t think there is a clear winner, which is what we are shooting for in a commercially produced result. Very cool.

  • Triggerscope Mini Released

    Compact, Simplified TTL and DAC – Micromanager Native

    I’m happy to share a new device I’ve been working on after encouragement from numerous clients. This new smaller version of the Triggerscope is intended to bridge the gap between large complex systems and more streamlined setups.

    With the Mini you get:

    • 4 TTL Outputs at 5V
    • 2 DAC Outputs at 5V
    • 1 3.3V to 5V input Trigger
    • Status LEDs for all connections!
    • A single USB-C Connection to the computer
    • Full supported Micromanager Triggerscope-Hub Behavior

    This was a super fun project for me, as for the first time this board uses a bare MCU, which enabled my team to use any connector we wanted (hence the USB C) as well as full USB-Serial emulation on our own terms.

    I’m also quite fond of the baby side-emitting LEDs on the outputs. These LED’s draw almost no current, but having them for all of the outputs makes it so easy to know whether a given control line is on or off. For the DAC LED’s, they change brightness with the output!

    I tried to keep this design in-line with the current TG4, as it’s worked well for us over the years. This one is of course thinner, lighter and smaller, but in effect a truly miniaturized version of the larger model.

    If you’d like to buy a Mini, we have them ready for sale on the store page here. For more information on the unit please see this flyer or the product page, thanks!

  • Starlyte Nebula Adds Drag+Drop Merge Captures

    Tool simplifies manual capture

    We had a recent customer asking to solve a rather standard but annoying problem. If I have a manual filter turret, and still want to overlay images, how easy is it to do?

    To solve this, we added the ability to drag+drop any image from our capture sidebar into our main view. By adding a demo filter turret to the system config, we captured the real ex, di and em filter settings from the image, insuring metadata is transferred with the images collected. The resulting view is a true multi-dim architecture, saved as an OME set or RGB combined view. Our team made the addition, ran bug testing and edge case validation, pushed the changes and compiled the application in 1 business day.

    Being able to react to our customers’ needs in a short timeframe is one of the best parts of working with my team. Nice work!

    -Austin

  • High Speed Triggering for Micromanager using Triggerscope Stream Script

    Over the past few years, I’ve often battled the Micromanager MDA window, when needing to perform high speed triggered acquisitions. While the system works well for multi channel Z stacks, running timelapse 2 channel streams, or “Z first” streams, didn’t work well. To overcome this, I’ve written a script that pulls all of the MDA user settings out of the window, loads up the Triggerscope, and captures the sequence.

    This approach gives any user of the triggerscope far greater control over how sequences are run, and offers users the ability to customize external device commands if needed.

    I’ve cooked up a brief video overview here, with some example screenshots of the results on an oscilloscope below.

    A basic example of a Z stack in a single channel is shown below. In this configuration, 1 channel is selected in the MDA window, and a single Z stack is collected. The Yellow line indicates intensity of a laser or LED on Ch1, the pink line indicates the Z voltage output, and the blue line indicates a TTL input from the camera.

    In the next example, output from a “channel first” Z capture is shown. Here Channel is prioritized, so the system runs Ch1 , then captures all Z frames, thens witches to Ch2, and captures all Z frames.

    Next, is an example of a capture previously impossible in MM. In this capture we stream 3 time loops back to back, with no delay.

    Next up is an example of a “Z First” capture, where all channels are acquired for a single Z position.

    Finally, a multi channel example can be seen in this image, with 2 channels running in a time series.

    Those are the highlights – I hope others find this useful!

    -Austin

  • Pt Grey Camera Driver for MicroManager unleashes low-cost microscopy

    Let’s say you want to build an imaging system, but you want to attach 2 cameras for time-correlated 2 channel imaging. The limiting factor for such an arrangement is usually cost, that cost being $10,000 USD per camera means $20,000 for such a setup! A result of this is most researchers end up not using time correlation at such an accuracy, and resort to filter cube switching or emission wheels. Enter the new release of Micro-Manager drivers for Pt. Grey cameras. Through the hard work of Nico Stuurman, Micro-Manager now supports most of the low cost USB cameras offered by this machine vision camera manufacturer. Kurt Thorn has an excellent report on his blog with performance data from one of Pt. Grey’s CMOS cameras.

    The key point? Most microscopy cameras start @ $6,000 USD, and go up from there. By comparison, Pt Grey cameras usually run less than $1,000 USD!

    So why is it that such a camera can cost 1/10 of a typical microscopy camera? The major cause is the ongoing market cycle of entrenched mature products and services, vs. disruptive technologies and products. Clayton Christensen explains the nature of this process in his excellent book, “The Innovator’s Dilemma“, but let’s look at the top 2 reasons for the price delta.

    Cooling: Most of the big camera manufacturers chase each other on performance specifications. If you’ve attempted to purchase one of these cameras through an on-site demo, you’ve likely heard the “spec war” sales pitch, wherein camera company A explains the important numeric advantages (quantum efficiency, read noise, dark current, etc)  over companies B, C etc. Of course, this rises out of a need to improve a camera’s performance as much as possible, to win sales. While this is all great for both product variation and for economic advantage (better product at a lower cost through competition), it assumes that the people driving these specs actually understand how important they are to the end user. In the past, dark noise was an easy problem to “one up” on performance. How? Simply cool the sensor! So peltier coolers (thermoelectric plates) were attached to the backside of sensors, with large radiators used to vent drawn heat on the back of the camera. This gave us heavy, large cameras with very low dark current of 0.03 electrons per pixel per second. But how does this relate to the average user? Normal exposure times are < 1 sec. Read noise levels on quiet cameras are ~ 3 electrons. So one would need to capture an image for an exposure time of 3 / 0.01 = 300 seconds, in order to reach a thermal issue with the camera! But the better spec gave an advantage to sales, and therefore this performance was considered standard in the industry, even though 99% of end users don’t need it.

     

    Peltier device

    Of course, other issues pop up when adding such extreme cooling. One is condensation. Because these chips would be cooled to -30c or lower, condensation loved to form on the face of the sensor, which obscures the image, and shorts the sensor. As a result, a vacuum sealed window must be placed around the sensor. Dry nitrogen may be back-filled into the chamber, but in the end, you have a chamber waiting for a leak. The manufacturing process is costly. All of this adds up to $$$$, which transfers down to the customer. Finally this trend is changing. Today, Hamamatsu, Pt Grey and others offer ambient (read un-cooled) camera options, resulting in substantial cost savings to customers.

    Example of ice on a sensor. This is what a typical low temperature camera will produce when active, and when a seal is broken. condensation freezes due to the low sensor temp, producing images which look like crystals, or water droplets at lower temps.
    Example of ice on a sensor. This is what a typical low temperature camera will produce when active, and when a seal is broken. condensation freezes due to the low sensor temp, producing images which look like crystals, or water droplets at lower temps.

    Manufacturing: CCD sensors were initially produced on accident. RAM designers found that configurations of chip layouts were light sensitive, and as a result discovered they could be used to detect light in an array. Soon after CCDs began a strong fabrication growth, conventional memory switch from serial addressed layouts to dynamically addressed layouts. This resulted in CCD manufacturers being able to only build CCD chips, and not other, newer forms of memory. Single-use costs of such facilities caused prices to stay relatively high, as how many end-users require monochrome sensors, high sensitivity, precision, etc etc? Most consumers of sensor technology want to see a pretty picture on a phone! So CCD sensor production became a high cost problem. CMOS technology unlocked this problem, allowing conventional memory production houses to build CMOS sensors. As sensor production expanded, “modular” sensor packages went from the exception to the rule for the majority of cameras sold today. In the past, camera companies purchased a “chip” which had only the sensor, and access pins attached to it. It was required for the camera company to add a window, seal or other protective assembly, readout electronics, etc. Beginning with the ICX series from Sony, things changed. Instead of purchasing only a sensor, you could purchase a pre-built package right from the sensor manufacturer, including a complete window, and in some cases, the ADC and clocks all ready for use. Both of these changes in how sensors are produced have given rise to two new entrants in the camera market – low cost camera companies, who do as minimal work as required to get a camera out for sale, and more manufacturing houses capable of producing sensors. All this adds up to more choice for the consumer at a lower, more competitive price.

    So what does this mean for you? Check out the Pt Grey camera line! It’ll save you a bundle on your imaging system, and may unlock your options for more multi-channel imaging!

    -Austin

  • uPeek iPhone based Microscope

    Kickstarter has another iphone microscope project, this time it looks like an attachment which includes a 4 line LED, focusing and optical element system, and machined body. Looks cool!

     

     

    -Austin

     

Social Media Auto Publish Powered By : XYZScripts.com