Kraig: Having trouble when splitting into two components. The first component is fixed at t=100. John: t=100 is the minimum time. Kraig: A lot of the time it says a1 is 0, even with t=100, which seems unintuitive, since you'd think even with a single fluorophore, you'd get a better fit with two (closely related) components. Kraig: SLIM has been consistent, but the workstation used to act differently than the SLIM. Stacy: Between 7-03, and 7-06, the workstation has acted differently. I get a spike at 100, and there is still another peak. Kevin: We did make a change (different amplifier and such), but I wouldn't think it would make a difference. We're now using the same hardware as the SLIM system. Both systems should behave the same way. Both have 742 detector, same lifetime board... John: The only difference is more memory capacity. Kevin: I don't understand why Kraig says it's different going all the way back. But the 7-04 date is when we replaced the bad amplifier. John: Getting back to software... you have to have two guess values for a 2-exponential, so if the second exponential isn't being detected (no second peak), it's not too surprising. Long: If the initial guesses are close, they'll converge to 50/50 for single exponentials, but if the guesses start farther apart, they will converge to 100/0. John: As you iterate, they will either migrate together, or one will fall off the end. Kraig: I didn't explain myself well. It fixes t1=100. a1 can flux, In the old system, I would get two exponentials that were closely linked, with a single fluorophore. In the new system, I get t1=100 and a2=0. Long: ... Matt: With the new amplifier, do we simply have more light scattering? If the laser timing is now off, is there renegade light causing scattering? John: ... Kevin: There are two issues. 1) Have a look at both systems to make certain the hardware is OK -- same data out of both. That takes care of any new data coming off the scopes. 2) Regarding the old data, how can we analyze it? Kevin: Paper that presents evidence that FRET/FLIM is better. John: It's particularly about FRET, but gives useful advice about using FLIM. You make an assumption that your two components are known, and plug those in. It's not relevant when you don't know the values (Stacy's work). But for Kraig's work, it is useful. Kevin: We want to address pitfalls in SPCImage by implementing things in Slim Plotter. Curtis: The major goal is interoperability between them, to take advantage of both. Long: For Kraig's data, the total is 10 ns instead of 12.5 ns, also for Stacy's data. That's why it's a different result from before. (?) Setting things back to the way they were before, we still can't replicate Kraig's original data. Kraig: This (on projector) is data that I generated in June. I know that there are two fluorophores in the embryo because I can see them. You can see on the two components that it's calculating these two numbers, that they're different, but not too far apart. The a values are about 50/50 (57.6/42.4). Same system, collected a month later, same optimization algorithm, and a1=0, a2=100. Very few of them have matched amplitides, whereas on the old datasets, all the pixels contained two components that are relatively close together. John: The system response curve (green) is different between old and new. On the old data, there is a big delay (a mismatch) between the decay curve and the system response. The new data lines up. Stacy: The filter wheel has been the same, and I didn't get scatter before. Kevin: Detector hasn't even been removed in a long, long time. It's very clear that something happened in late June/early July. John: But you've tried to change back? You should be able to go back, now that the laser has been fixed? Stacy: I've had a quantifiable difference in lifetime, because of the change in the system. Long: Stacy's problem is distinct from Kraig's. I noticed all the settings were off when Kraig showed me some data after the fourth. Stacy: Is all my data after the fourth unusable? Kevin: You can analyze it and see something, but is it comparable to the data from before? Long: Also, I used the wrong setting to get the system response. I changed the sync cable after July 4th, July 5th I think. I think I forgot to change some other parameter at that time. That's why Stacy's data after July 4th doesn't match the data from before. John: You adjusted the lengths of the cables to be commensurate with other things. So it would be difficult to perform any experiment like "go back to the way it was before," because you'd have to change the cables back. Long: Right. Kevin: So, can Stacy compare data from before to data after? John: Can we reproduce the old settings? And then can we look at Kevin: Can we reproduce both, and then use floroscene and a bead or something, to determine a conversion factor between the two? John: When people use the system response file, is this one file you (Long) set up for them? Long: Yes. Kevin: Every time we make a hardware change, there is a new (system response) file with a new date, and they use that date. Curtis: Does anybody else have data from both before and after? Kraig: I do. Curtis: Did you notice the shortening of the lifetimes like Stacy did? Kraig: No. John: So, Kraig is concerned the system is not working properly anymore, since two-exponentials don't fit the way they did before. Curtis: The current version of SPCImage fits the old data properly, and the new data incorrectly. So it's really a matter of determining the differences between the datasets, so we can understand what changed. ** After Kraig reanalyzes some of his data from before and after with a single exponential fit, it looks like his data shows a similar lifetime shift (2691 to 2458) to Stacy's data. Kevin: So what are the action items? Someone like Steve should be able to go to both systems and be able to get the same data, consistently. And a year from now, the same lifetime values. We're not quite there yet. Floroscene on the bead is a standard and is well advertised, and we've been successful matching that. 1) Take standards on both systems and compare. Make certain we're confident in the hardware. John: One word of caution about the beads: they're quite bright. Kevin: That's the beautiful thing about the filter wheel though. We can use it to correct for that. John: You can get erroneous values if you aren't careful. You've really gotta crank the value down. Kevin: 2) See if we can come up with a way to have some kind of exchange factor for your data, Stacy. Stacy: And if not, I just won't use the data from the 3rd. Lastly, is there a standardized way of analyzing this data? It keeps changing. Do we use the shift? Do we not anymore? Are we supposed to have it over 100, or over 1000? Long: If I don't fix the shift (leave it free), I get a more consistent result. John: And always use the improve matrix. That allows a better match for the shift. Kevin: That's one reason I really want to go back to standards. We have to make certain we always get the same values. Even with slight differences in analysis, we should get the same lifetime values.