Bug reports and development proposals for rapidSTORM 3.x

[Sven Proppert]

Hi everybody,

I hope this thread can help identifying and handling errors / bugs in rapidSTORM 3.x in a way, that Steve has a chance to hopefully fix them, if possible.
Just to point that out clearly: This thread's aim is not to grumble how bad things are but to help developing by indication of problems! Additionally, it would be nice, if anyone who thinks "I always wanted that functionality" would take the time to write it down in this group.

To start with some bugs:
- to my knowledge no support for Umlaute
- density map output does not indicate the target file
- rapidSTORM crashes if user tries to remove an output (seems to only appear on Windows machines)
- 32 bit Windows version still not running (starts, but crashes when tif file is loaded (tested with 3.3 32 bit on a 64 bit Windows 7)
- track emissions is a hassle
- two color alignment also needs min and max positions and thus a lot of expert knowledger about rapidSTORM is needed

Proposal:
- If handling many files with the GUI, it is a bit frustrating to scroll through the whole menu each time you want to load a new file and then again to click the run button. May it be possible to transfer the run button to an independent extra tiny window? I think, that might make everyday use a bit more comfortable.
- If the image output is changed, the image window disappears from the position where one dragged it to and opens in its initial position (where you did not want it to be). Is it possible, that the image window remembers its old position and reopens there?
- It would be awesome, if the settings (filters, thresholds, linear drift correction etc.) that are entered during evaluation, i.e., after hitting the run button would be saved too. Maybe to a seperate settings-file, if that is handier.

I hope that a fruitful discussion may emerge, knowing that not every wish can be covered.

Cheers,
Sven

[Steve Wolter]

Hi Sven,

thanks for the suggestions. One thread for everything doesn't really work out in most mail clients, so new threads for new issues would be much appreciated. I'll take a look at some of the stuff when I find time.

Best regards, Steve

--
You received this message because you are subscribed to the Google Groups "rapidstorm-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rapidstorm-disc...@googlegroups.com.
To post to this group, send email to rapidstor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Wolter]

Let's go with the easy ones:

 

To start with some bugs: 

- density map output does not indicate the target file

Already fixed, scheduled for 3.4.

 

- rapidSTORM crashes if user tries to remove an output (seems to only appear on Windows machines)

Thanks for that pointer. Some structure was referenced instead of copied, and then not available when GUI elements were removed. Fixed in commit 24a9bf3, scheduled for 3.4.

 

- track emissions is a hassle

Could you please be more precise here?

 

- two color alignment also needs min and max positions and thus a lot of expert knowledger about rapidSTORM is needed

You are referring to your procedure of checking the two-color alignment, aren't you? It looks like this?

 - Fit channel A only and get image A

 - Fit channel B only and get image B

 - Apply bUnwarpJ to compute a transformation from A to B

 * Fit A only while applying the transformation, getting image C

 * Use ImageJ to overlay A and C to check the transformation.

 - If all looks good, fit A and B concurrently while applying the transformation to A

[Sven Proppert]

track emissions:
Indeed, my description was not too precise...
Unfortunately I don't know much about track emissions. I only know that especially here, people stick to 2.21! I think, Sepp will know and as well, Sebastian Letschert will know, why he doesn't use 3.x. As far as I remember, the biggest problem was, that minposx,y and maxposx,y have to be set in order to get a reasonable output and that the module-tree does not build automatically. Afaik, you were in contact with Sepp about the issues. Maybe, that wiki-post helps:
https://idefix.biozentrum.uni-wuerzburg.de/wiki/index.php/RapidSTORM-instructions

Two color:
Yes, I think we're both saying the same thing, but I will try to sum up the process in my own words:
0. take beads as 2-color calibration data (to be taken for steps 1-4)
1. evaluate red channel and green channel without alignment.
2. feed the outputs to bUnwarpJ (red source, green target)
2.1 try to find bUnwarpJ settings (landmarks if nececcary) in a way, that the images are aligned after transformation
2.2 convert elastic transformation to raw transformation
3. take raw transformation as input for the green channel
3.1. manually set minposx,y and maxposx,y to the size of the red image (this is what could be easier and is not intuitive)
3.2 run the job
4. take the untransformed / initial red image and the green image that should now be transformed by rapidSTORM
4.1 overlay both in Fiji and check by eye, if the transformation computed by rapidSTORM is significantly worse than the one computed by bUnwarpJ
5. if there is no significant difference, consider the raw-trafo correct and apply it to "real" data

Hope, that helps...

[Sebastian]

Hi Steve, hi Sven and hi everybody,

I read my name, so maybe it's time to make a contribution to this discussion forum ;)
A few month ago I switched to version 3.3 and I use the tracking function very often. Until now, I'm quite happy with 3.3 - however,  there are two points I want to mention:

1.  Concerning the problem with the image display after track emissions: One can also save only the tracked localization file (w/o an image) and then use the replay function to generate an image. In this case, you don't need to set the dimensions (minposx,y and maxposx,y) and the image is shown in the correct way. Anyway, the best way would be, to do this in one job without setting the dimensions manually - if this has not be done already in 3.31 (?)...

2. Could it be, that there is a difference between 2.21 and 3.3 regarding the tracking algorithm and the boundary conditions, respectively? An example: When I track localizations over the whole stack (e.g. 15000 frames -> allow blinking interval) with a high 'tracking radius' (Distance threshold = 2 and, let's say sigmaposx,y = 90 nm (in 2.21: SD of expected distance between tracked localizations). Values are just for demonstrating the problem more clearly) I get an image with rastered localizations (traces) - like a grid. This is because of the high tracking radius - until now, it's fine. But then, the 2.21 image shows an area at the lower and right edges (high x and low y coords) with single localizations that are not tracked. The 3.3 image is completely tracked. The same for the tracked localization files: I got, for example, 1700 traces with 3.3 and 4800 with 2.21. The difference is because of all the 'untracked' localizations (or traces with only one localization) at the image edges in 2.21 - I guess.
Since I'm now using 3.3 it's not my problem anymore, but maybe it's interesting for others. Or have I missed something?
For better understanding I attached the two png files - hope this will work...

Cheers,
Sebastian

--

[Steve Wolter]

Hi Sebastian,

regarding (1), this was fixed and released in 3.3.1:

https://github.com/stevewolter/rapidSTORM/commit/9564097924e6d671799665588105cc1b1004ebf4

regarding (2), this commit fixed some very similar-looking tracking issues:

https://github.com/stevewolter/rapidSTORM/commit/2b62b23f22bf57200a408c5710198cc293834e88

It was released in rapidSTORM 3.3.0.

Best regards, Steve

[Sven Proppert]

Hi friends,

hope you all are doing well. Here are some issues with RS 3.3.1 I recently encountered:

minor issue: "Determine length of file" gives a wrong number. Interestingly enough, it is not an arbitrary number but reproducible. For example, I have a measurement of 20,000 frames, split into two parts with 16,298 and 3,702 frames respectively. However, Dlof gives 10,946 and 2,584 frames. I think this is only a display-error, as RS does not stop at the respective frames, but according to the localisation file nicely finds the full 20,000 frames...

I spent some time on the density map output. If no one is reporting differnetly, I would assume, that it works just fine as I didn't have problems generating the text file with reasonable content. There is one thing, that is counter-intuitive for me: The options of the density map only appear prior to running the experiment and cannot be readjusted later. I think it might be worth considering to give the ability to adjust the voxel-sizes and ticking the "make 3D" box after evaluating the job, as you can do it with images.

Two things seriously bothering me on ubuntu-machines. Both are no issues under Windows (it surprises me most, that there are features, that are worse on linux than on windows ;-) ) :
- Drag and Drop does not work
- Open dialogues always jump to "frequently used" and thus inhibit fast navigation to files. For example, after I loaded a tif file, I need to load the sigma-table, which is located in the same folder, but as RS does not remember the folder, I again have to navigate all the way there.

More of a side-note: Microsoft security essentials (Windows 7) seems not to like the libsifread-1.dll (see image)

A last thing: For data visualization in 3D it is sometimes advantageous to adjust the upper and lower bound of the color code. For example, the sigma-table may cover plusminus 1 µm, but the data only spreads pm 0.5 µm, so it makes no sense to have the bounds for the color-code set to pm 1 µm. Even worse, sometimes it is even nicer to not set it to pm 0.5 µm but instead some smaller interval to get crisper colors. I well know that you can do this in the image display, but afaik that only works for 2D projections, but you do not have that option anymore when closing the image window in order to / and saving a 3D stack. Thus it would be nice to move those inputs for the color-code's upper- and lower bounds to the job options, as they are not only affecting the image display and would this way be more versatile. If possible, of course...

I wish you all to have a great week :-)

Cheers,
Sven

[Steve Wolter]

Hi Sven,

2014-06-03 16:06 GMT+02:00 Sven Proppert <svenpr...@gmail.com>:

I spent some time on the density map output. If no one is reporting differnetly, I would assume, that it works just fine as I didn't have problems generating the text file with reasonable content. There is one thing, that is counter-intuitive for me: The options of the density map only appear prior to running the experiment and cannot be readjusted later. I think it might be worth considering to give the ability to adjust the voxel-sizes and ticking the "make 3D" box after evaluating the job, as you can do it with images.

I'll take a look. The code for the viewer is a giant pile of poo because it has to support all these change-during-job options, but maybe we can use the same pile of poo for the density map. 

 

A last thing: For data visualization in 3D it is sometimes advantageous to adjust the upper and lower bound of the color code. For example, the sigma-table may cover plusminus 1 µm, but the data only spreads pm 0.5 µm, so it makes no sense to have the bounds for the color-code set to pm 1 µm. Even worse, sometimes it is even nicer to not set it to pm 0.5 µm but instead some smaller interval to get crisper colors. I well know that you can do this in the image display, but afaik that only works for 2D projections, but you do not have that option anymore when closing the image window in order to / and saving a 3D stack. Thus it would be nice to move those inputs for the color-code's upper- and lower bounds to the job options, as they are not only affecting the image display and would this way be more versatile. If possible, of course...

You should be able achieve the same thing right now by setting the bounds in the expression filter (even though that only works when setting it before the job is started, I think). Have you tried that, or do you need to fiddle with the color scale after the job has started?

[Sven Proppert]

Hi friends,

please be aware that the linear drift correction is apparently corrupted... To cut it short, the linear drift correction works fine but gives wrong values. If  for example you need to subtract a linear drift of 1 pm/fr to get a drift-free image, the real value subtracted is 3. In other words: If you did the drift correction manually with a data handling software like Origin, you would need to subtract a drift of 3 pm/fr in order to get the same result.
This should not bother you too much in most cases but becomes a problem when doing sequential two color dSTORM because in order to get colocalization of corresponding signals, you need to subtract the drift that occured in the first measurement thom the found localizations of the second color. If you would subtract the value estimated with the linear drift correction module (1 pm/fr * 10.000 frames), your data will be shifted because you should have subtracted 3 * 1 pm/fr * frame. When entering the correct value, the measurements will give the correct result.

For debugging purposes, I uploaded exemplary data (~15 MB) to my dropbox account which can be downloaded here: https://dl.dropboxusercontent.com/u/1078013/lindrift-usecase.zip
The data consists of a 100 nm Tetraspeck bead on a glass surface surrounded by water. The movement in y was induced by moving the stage manually with a more or less constant velocity. The asymmetric pixel sizes stem from the fact that this was a 3D measurement, but the data can without any problems be evaluated in 2D when the pixel sizes are set appropriately (85 nm in x and 110 nm in y for the red channel). You should increase the PSF FWHM value slightly (maybe to 500 nm) because the image is not sharp (astigmatic distortion).
I added some instructions for 2D and 3D evaluation as well as for readily transformed evaluation of the green signal. After drift correction, the red and the green localization cloud should mostly coincide with a small offset remaining, als the transformation data apparently was not perfect...

The bug showed up when I tried to do two-color 3D with a channel-alignment  raw-transformation fed to rapidSTORM, but I also tried the most basic case (2D fitting, no two channel alignment) and the bug remains. So to make it clear: I have no reason to assume that the bug has anything to do with channel alignment or 3D but is a general issue.

A last remark: I do not know whether the factor is exactly 3. It might also be Pi or sqrt(10) or other "typical candidates" but it looks as if it was rather 2.9 - 3 than a higher value. A closer look to the source might give clarity...

If you have questions, please contact me by posting to this newsgroup.

Cheers,
Sven

[Steve Wolter]

The factor is exactly 3. At some point, I managed to loop over all 3 dimensions (x, y, z) and still list them explicitly. Sorry, really stupid mistake that should have been caught by a unit test.

Fix is in the master branch: https://github.com/stevewolter/rapidSTORM/commit/78e384f8b06c421669d87a22c464f5be28c4a159

--

[Sven Proppert]

Hi Steve,

thanks for pointing at the erroneous part of the code and the information, that multiplicating with 3 bypasses the problem.

Did you post a desycription of how to build a new rapidSTORM version with the bugfixes included for Windows 64 bit somewhere? Or could you please give me advice how to get the up-to-date version out of github?

Thanks and best wishes,
Sven