As this project evolves, we’ll be making changes to the guide. This includes changing the recommended components, updating software, and adding pages. My plan is to use the “Blog” page to document any changes that are made to the site and try to provide some rationale for why. If you visit the site often, I’d recommend checking out the blog first to see if there have been any updates since last time you checked-in.
This will also be the place where we’ll post openSFDI news. If you successfully build a system, send pictures! We’ll post them here. Hopefully as more systems get built in the community we’ll also be able to post links to publications that use the openSFDI platform.
Ben Mellors at the University of Birmingham found a some interesting behavior (behaviour?) in the LabView code. I’ll let him tell it:
I have come across an interesting aspect of the Lab View code that I thought was worth a mention. I have transferred the system across to another PC and all was running fine except the pattern display. When the Main.vi was running and measurements were set, the projectsinwave.vi opened as expected on the DMD display but no stripes were being projected. I then swapped out the DMD for a regular desktop monitor, and the patterns were showing. After a bit of investing I have found that the problem occurs when the DMDs location in relation to the main display is set to the left hand side. Once this is simply swapped over in the display orientation settings of the graphics card menu, the problem is resolved and the DMD displays the patterns as expected.
So keep an eye out where the external monitoring is appearing.
Rolf Saager has updated his excellent processing tutorial with new tips for diagnostics and debugging as well as a detailed guide to developing a Monte Carlo model for use with SFDI. Check it out here!
Rolf Saager has put together an excellent SFDI processing tutorial for openSFDI. It walks through SFDI processing step-by-step and includes example code for you to modify and expand upon. As you develop your own processing workflow you can use AppSFDI to validate your code.
I’ve just updated the openSFDI control software (available here) to address some problems that could cause stripes in the demodulated images.
The issue was that the FLIR camera recommended on this site has automatic gain control and gamma correction enabled by default. The gain control can cause some of the images to be brighter than others which can lead to poor demodulation. The Gamma correction is a little more pernicious because it’s nonlinear, so can add harmonics to the projected sinewaves. Harmonics inevitably lead to stripes in the demodulated images. I didn’t realize these adjustments were applied until I dug through the camera settings menu.
Even if you aren’t using the FLIR camera, make sure you turn any auto exposure or gain settings off, and switch off gamma correction.
Joe Angelo and Sylvain Gioux have put together a list of SFDI publications that they’ve graciously shared with openSFDI. You can find a searchable Excel sheet with titles, authors, journals, URLs, and DOI information on the SFDI 101 page. Each publication is also labeled with a Category such as “Clinical,” “Instrumentation,” or “Theory” to help guide your reading.
Big thanks to Joe and Sylvain for all the hard work!
Working with one of our openSFDI systems, we were getting some strange results related to demodulation of the AC images. Sometimes the demodulation would work well, other times there would be stripes in the image at the same spatial frequency as the projection.
On examination of the data, we found that one of the AC images had a higher DC offset than the other two, which is what was causing stripes in the demodulated images.. What seems to be happening is that if any of the images have regions of saturation (pixel counts of 65530) none of the wavelengths would demodulate properly. Reducing the exposure time of the offending wavelength such that there was no saturation in any of the images solved this problem.
A more permanent solution might be to change the order that images are acquired. The way the control code is currently designed, it displays a pattern on the DMD and collects images for each wavelength before switching patterns. Changing it so all the patterns for a wavelength are collected before the wavelength changes, might prevent a single image with saturation from corrupting the entire dataset.
I’m not sure if this is an issue with the camera, the software, or something else. Let me know if you have thoughts in the comments (or via e-mail).
I just uploaded a new version of the Labview control software (specifically “Main.vi”). The old version contained an absolute path to the projectSinewave VI which caused problems if you try to use the software on other PCs. You can download the new version from the github or, if you want to make the change yourself, just delete the absolute path in the “Init” state and replace it with a relative path to the projectSinewave function.