Fail to use channel registration

[yemaopt]

Hi Talley! Thank you so much for writing this excellent tool to process LLS dataset! I am currently trying using the channel registration function, but I am not sure whether the raw data or deskewed data of tetraspec bead should be used for generating the registration file. Also, right now I cannot successfully generating the registration file for either case, the t-form matrix is blank and the "ref channel" and "mode" is blank for "Register Fiducial Data". Pressing it will end up with the error as attached. Our OS is Windows 10 and work well with deskew/deconvolution function. Could you help us to solve this issue? Many thanks! Sincerely yours, Ye

[tlambert03]

Hi Ye, Happy to help try to solve it... My guess is that your bead sample is not quite "easy enough" for the automated detection (either too few beads, or too clumpy). I tried to make it as parameter-free as possible, but that unfortunately often comes at the cost of failed calibration... so some amount of tweaking of the "min number of beads" is often necessary. However, there's not a whole lot of visual feedback, so you sometimes have to "shoot blindly" a bit to get it to work. To answer your question though: you do it on the raw, pre-deskewed data.

If you send me an example of the raw tetraspeck bead stack (pre-deskewed) that you acquired, along with the settings.txt file for it. I can see whether I can make it work and let you know what parameters it required. Also, you can try this example dataset: https://www.dropbox.com/s/aynbkks9egk5ce9/lattice_reg_ex2.zip?dl=0

and just to double check, make sure you've read through the docs here: https://llspy.readthedocs.io/en/latest/registration.html

[WillGiang]

Do you really have three cameras?

[tlambert03]

what makes you say that? cause he has three wavelengths?

[yemaopt]

Hi Talley! Got it. The tetraspec bead I used is indeed very sparse. I will make a new and denser one and try it again. Thank you so much for your help! Sincerely yours, Ye

[WillGiang]

what makes you say that? cause he has three wavelengths?

Yes. Am I misunderstanding something? We've just got a single camera set-up, so I'm not sure what the multi-cam configuration is. Since there's an SLM, it's still got to be sequential acquisition, right?

[tlambert03]

yeah, it's always sequential, single-cam or multi-cam. Perhaps the confusion is in the need for registration? Having a single camera makes the registration a bit better than even a well-aligned dual-cam system... but it does not obviate the need for post-acquisition channel registration. Particularly along the optical axis, you will see a lot of chromatic aberration. This is not lattice specific: all multi-channel datasets acquired on any microscope stand to be improved by registration.

[WillGiang]

Yes, that's the source of my confusion.

I can understand needing to register if one of the following (non-exhaustive) statements are true:

• using an objective which isn't spec'd for fixing chromatic aberration in one of your channels
• incorrect cover glass thickness
• index of refraction mismatch
• filter problems
• multi-cam

For correcting axial chromatic aberration, do you personally try to fix it during acquisition (by setting z-offsets) or during pre-processing? Feel free to say "wait two weeks for the workshop"

Meanwhile, I'll make some more bead slides and see what happens.

Thanks for the discussion!

[tlambert03]

i think the main issue is in your first bullet point: even a plan apo lens that is "spec'd for fixing chromatic aberration" won't be perfectly corrected. Lenses vary quite a bit from lens to lens (see image below of four identical model PlanApo 100x/1.4NA lenses... obviously one has a big problem, but even the others vary along the optical axis)

In my lattice detection objective, I see a shift of about 600nm along the optical axis between the far red channel and the green channel, and less between green/red. I personally don't try to fix this on the acquisition side, since that would require whipping the objective piezo around furiously during acquisition, or acquiring z stacks separately per channel, and even still you're liable to have some residual misregistration... so for all those reasons, I just accept that I'll always need to do a registration after acquisition. Of course, sometimes you just really don't care that much about the precise relationship between the channels, and you just let it stay. But if your analysis depends on cross-channel distance measurements or relationships, you're better off calibrating with tetraspecks and correcting every time.

[WillGiang]

Interesting. Thanks for your help! And sorry for hijacking this thread.

On Tue, May 21, 2019, 08:55 Talley Lambert notifications@github.com wrote:

i think the main issue is in your first bullet point: even a plan apo lens that is "spec'd for fixing chromatic aberration" won't be perfectly corrected. Lenses vary quite a bit from lens to lens (see image below of four identical model PlanApo 100x/1.4NA lenses... obviously one has a big problem, but even the others vary along the optical axis)

[image: Screen Shot 2019-05-21 at 8 22 49 AM] https://user-images.githubusercontent.com/1609449/58095791-bf3e6800-7ba1-11e9-8f00-23bff2c02964.png

In my lattice detection objective, I see a shift of about 600nm along the optical axis between the far red channel and the green channel, and less between green/red. I personally don't try to fix this on the acquisition side, since that would require whipping the objective piezo around furiously during acquisition, or acquiring z stacks separately per channel, and even still you're liable to have some residual misregistration... so for all those reasons, I just accept that I'll always need to do a registration after acquisition. Of course, sometimes you just really don't care that much about the precise relationship between the channels, and you just let it stay. But if your analysis depends on cross-channel distance measurements or relationships, you're better off calibrating with tetraspecks and correcting every time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tlambert03/LLSpy/issues/17?email_source=notifications&email_token=AH5SGKMDKURAJH5S6QTZGATPWPWKLA5CNFSM4HOGMMGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV3Z63A#issuecomment-494378860, or mute the thread https://github.com/notifications/unsubscribe-auth/AH5SGKJETFIW3H5AWY2KFELPWPWKLANCNFSM4HOGMMGA .