[FLIMfit-users] FLIMFit query
Sean Warren
s.warren at garvan.org.au
Thu Oct 8 13:03:33 BST 2015
Hi Ewan,
Hope you’re well. Ian forwarded me your email, I had a couple of comments below that might be helpful:
I’ve just been doing some double exponential fitting with FLIMFit and ran into a couple of “queries”…
1. When I used a pixel-by-pixel method you’d get a longer than expected lifetime and and shorter than expected lifetime (e.g. For a gfp-Tag-RFP fret pair, should be about 2.1 ns gfp lifetime, I got t1 = 3.2 ns and t2 = ~600 ps with b1 = ~0.3 and b2 = ~0.7), however, the weighted mean lifetime is the correct value?
Depending on how many photons you have, fitting on a pixel-pixel basis can be pretty challenging. If you’re using single pixel fitting with TCSPC data you need to make sure you’re using maximum likelihood fitting: in the advanced tab, set ‘Algorithm’ to ‘Maximum Likelihood’. This will avoid the bias you can get at low photon counts with standard weighting approaches.
In general the weighted mean will be closer to the value you get when fitting a single exponential decay.
A couple of other things to check:
* Are you estimating the background level correctly? In an empty part of an image (or, ideally, empty image with the same acquisition time), select a region and estimate the background level based on the ‘decay’ panel (will probably be low, like ~0.01-0.2 counts/timebin). In the ‘Background Light’ tab, set ‘Offset’ to this value.
* Are you using a recently measured and correctly background-subtracted IRF?
2. Sometime the beta were negative for b2 and over 1 for b1 e.g. b1 = 1.41 and b2 = -0.42?
By default, the contributions are not contained to 0<beta<1. This is partially for technical reasons but also because if the value is of beta truly lies around 0 or 1 you need to allow negative values to ensure the mean value of the distribution due to noise is not biased by the constraint. If you use maximum likelihood fitting this constraint should kick in and you will only get 0<=beta<=1.
I’m guessing that this is because the model is finding it hard to fit perhaps through lack of signal?
When I fit the same data using global fitting (but locally vary the contributions) it behaves a bit better.
The smodel settings I used were: Global fitting, Fit Contributions = Fitted locally, Fit Reference = Fitted, Fit IRF Shift = Fitted. Stray light tab: Offest = Fitted gloabally, Scatter = Fitted gloabally, TV Background = Fitted globally.
You’re leaving a lot of parameters free here, if possible it’s better to constrain parameters where you can
Fit Reference = Fitted,
Are you using a reference dye measurement for an IRF? If so it’s better to estimate the lifetime of the reference by tail fitting and then fixing the reference value.
If you’re not using a reference dye this will have no effect.
Fit IRF Shift = Fitted.
This will move the IRF in time. I generally try to do this only once when fitting a single exponential sample (e.g a chromaslide) to determine the IRF shift, then manually set the IRF shift to this value and fix it from then on
Specifically I generally follow this procedure:
* Open a reference sample such as a chroma slide or Atto dye and import the IRF
* Fit the sample with a single exponential decay, with a fitted IRF shift
* Record the t0 shift
* Open the data to fit
* In the IRF tab, set IRF shift to the negative of the fitted t0 shift value
* Fit the data with a fixed IRF shift
Stray light tab: Offest = Fitted globally,
If possible it’s better to fix the offset to a value determined from a sample free background image
Scatter = Fitted globally,
Unless you have a scatter contribution (i.e. a contribution to the decay which looks like the IRF) you should fix this to zero.
If your filters are set up correctly you shouldn’t need this.
TV Background = Fitted globally.
Are you importing a time varying background?
The fit results are:
tau 1 tau 2 b1 b2 weighted mean tau
mTagRFP 2374.9365 101.5567 1.04607 -0.0460605 2478.4242
control 2203.113 326.7455 0.60874 0.39126 2034.0543
wt - 2 2222.8235 74.7949 1.5714 -0.571393333 2258.200767
Where mTagRFP, is just GFP only so 2.5’ish ns expected, control is positive FRET so about 2 ns and wt-2 is the wild-type free to vary FRET sample (so somewhere between mTagRFP and control sample lifetimes).
Does this behaviour make sense to you?
Any help or insight would be really useful :-)
As a more general comment I would ask whether you need to use a double exponential model? Unless you’re actually interested in the exact values of the contributions from a biological perspective, fitting with a single exponential will give you the same contrast (as defined by the change in the estimated parameter divided by the noise on that parameter) as a double fit with quite a bit less effort. Either way the weighted mean should give you a reliable estimate of the level of FRET, even if the tau values are a bit off.
Hows things going otherwise? I shall email you the journal DOI when the paper is published that this is going into.
Speak to you soon,
Ewan
Cheers
Sean
Dr. Sean Warren | Research Officer
Invasion and Metastasis
Cancer Division
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5852 I E: s.warren at garvan.org.au<mailto:s.warren at garvan.org.au>
______________________________________________
FLIMfit-users mailing list
FLIMfit-users at lists.openmicroscopy.org.uk<mailto:FLIMfit-users at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/flimfit-users
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/flimfit-users/attachments/20151008/ef646f6e/attachment-0001.html>
More information about the FLIMfit-users
mailing list