research diary

I went to the library looking for the The Radon Transform and some of its applications book, but it wasn't on the shelf. The librarian (who had eyed me suspiciously and pointed at the sign that says "Summer students must have their advisors check out books for them" when I walked in) took up my query and was ired to discover that the book's last borrower had left the Institute without returning his library books. There was one book, 75 Years of the Radon Transform or something like that that contained an amusing article of the The Radon Transform and Me nature, in which the author explained that, as a physicist in Capetown, he had been asked to serve as a radiologist at the understaffed hospital, and there he came up with a rudementary yet prescient CAT-scan scheme out of curiosity.

Asmahan and I went over Ed's script for particle-picking using cross-correlation. The script works by taking an image containing particles, and a smaller reference image of a single particle, and looks for locations in the big image that match the smaller image. It does this by padding the reference image (increasing its dimensions to that of the larger image) and then looking for peaks in the cross-correlation between these two images. It does this once for 45 rotations of the reference image. Finally, the script does some nearest-neighbor elimination.

I wrote a C program (spi_conv.c) that reads in a SPIDER image file and dumps it as space-deliminated ASCII. This was pretty easy; the only trickery is that SPIDER uses floating point numbers for everything (even those things that are integral, such as the image dimensions in pixels) and big-endian byte order (the files were created on SGI IRIX). My program works and I was able to load its output into MATLAB with dlmread without problem. I think it will be quite easy to reimplement Ed's script in Matlab in a very concise and readable way.

Ed's scheme is well suited to parallelization along "embarassingly parallel" lines, namely that each rotation of the reference image is an independent task. That provides a clean separation into approx. 45 equally difficult yet independent tasks. It would be fun to play with parallelizing the linear algebra / fourier transform tasks, but that's probably not necessary. Maybe there's legitimate work to be done in parallelizing the Radon transform. The annoying part about reimplementing the algorithm in C is that library functions for image rotation with interpolation (etc) might not be available/convenient.

I'd like to learn more about correlation functions; right now I just take it for granted that they work. The correlation function we're using is simply convolution, so it can be done easily by transforming to fourier space, multiplying elementwise, and then taking the inverse transform. (Although, unless there's some other stage that's easy to do in the fourier domain, this might be more work than simply doing a coordinate-space convolution.)

Ate lunch at Santa Maria (?) with Asmahan and her friend, and Ilija (the yugoslavian) showed up too.