OpenSFDI Blog

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.

New Version of AppSFDI

I hope everyone in the openSFDI community is doing okay right now.

I’m excited to announce that there’s a new version of AppSFDI available. This version comes complete with source code as well as executables. You can check it out here.

OpenSFDI publication

Hello Everyone,

I’m excited to announce that openSFDI is now published! You can download and read the paper here.

The paper describes the design, construction, and testing of 3 different openSFDI systems. Please cite it if you publish work on your own versions of openSFDI.

Thanks to all the authors on the paper who made it possible, and all of the early adopters of openSFDI who helped make the project better during its beta phase.

Small LabVIEW glitch

Hi Everyone,

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 was running and measurements were set, the 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.

Thanks Ben!


We’re happy to roll out a new SFDI processing tool: AppSFDI.

AppSFDI is an application that can be used to process SFDI data (fx = 0.2/mm and 3 phases). There is an installer (.msi) for use in Windows, as well as instructions for installation and use.

You can read more about AppSFDI and download it here.

Auto-gain and gamma correction

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.

List of SFDI Publications

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!

Saturation & Demodulation

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).

Absolute path in

I just uploaded a new version of the Labview control software (specifically “”). 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.

Thanks to Kavon Karrobi for noticing the error.