Hey @kunal, welcome! Starting a new thread, since that other thread is ridiculously long.
We had successfully triggered the camera and captured images using the DCAM API before. Though I am struggling to replicate this right at this moment (hopefully @gaudi will help me tomorrow).
There is one crucial difference with the v4 API to the previous APIs: with v4 you are able to set the “line bundle height” to get more than 128 lines into one image when using TDI.
Hence we are using the v4 API in a special Micromanager device adapter (since HamatsuHam device adapter does not have this feature either, despite using v4, and is closed source). You can see my work in progress in the HiSeq2x00Camera adapter on the reseq branch on my GitHub fork.
How are you controlling the stage and arming for TDI? I have just implemented XY stage control in Micromanager but am struggling to see how to correctly do the control and arming/scanning.
I’ve just been sending serial commands to the XY stage and the FPGA in python.
I was just using the DCAM API that was installed on the system which is v3. I can see in the illumina log files that the line bundle height does get set to 128. But you’re right, when I try to change is it to 128 with V3 DCAM, it doesn’t accept it (maxes out at 64).
I was wondering how Illumina changed it to 128, or if they even actually did. But also is changing it to 128 very important? Wouldn’t you just take double the number of frames if the line bundle height is only 64?
Anways thank you @kaspar and @jmarkham for the links to the code. I’ll take a look at how the camera was configured and see if I can get scans.
I think 128 is the default. When we had this working before we set the line bundle height to 4000 and even 8000 to get larger scans. We want to enable this when using it with Micromanager.
If the Illumina software can set the frame buffer size then it must be possible through the v3 DLL. That being the case you should be able to find the function call (which will start with dcam_ - see here) inside the Illumina binary. Running it under a debugger might allow you to see the arguments. But I agree with @kunal that it should not be necessary if you are able to keep up with the smaller buffer sizes. The only reason this should be a problem is if the overhead for dcam_getdataframebytes() and the associated MM function is comparable to that of transferring the 64 lines of image. I think that this is unlikely although I stand to be corrected.
Thanks @kunal, will study your code and follow your updates there.
We just managed to get TDI scanning working using this simple script! We are acquired the image in Micromanager using out HiSeq2x00Camera adapter.
We tried stitching together images of 128 lines before and noticed that we lose some information. Hence we definitely wanted the line bundle height setting, since that way the hardware just handles it for us, and figured it’s easier just to implement what we need using the v4 API in the HiSeq2x00Camera adapter.
For us the next step is to integrate the TDI arming/moving the y stage into that same adapter so we can just snap images in one go. Should take some time to clean things up as well.
hei @kaspar, hope you all fine with all your great project. Just checkin and wanted to ask what is the latest github version of it? The one from @kunal or from @jmarkham.
and as a sidenote:
This saturday is the nomination of the science photo marathon, wish us (@gaudi) luck with our participation
I’m hoping that there is a @kaspar one. Mine is old and Kaspar was gonna re-write the camera device adaptor to make it work with the newest dcamapi. Where are we at with that Kaspar?
Hope the marathon went well. Is the output posted anywhere?
Hi @mamaya, I was wondering if you could share some of the photos from the photo marathon. With your permission, I was gonna get the communications/outreach person at work to celebrate them on the institute’s social media feeds. I don’t see any great payoff, and I know that I didn’t actually contribute to the effort, but it would be helpful me to me be able to point to a good news story like this when I’m asked why the franken-seq is taking up space in a lab. Ideally its presence would be justified by research output but in the absence of that being able to point to outreach achievements associated with the reseq project in general would be useful.
