Leginon

Actually, Leginon's setting in switching mode, dimension, exposure etc has no relation to what you see in DM gui.
The calls we used in SerialEM plug in does not always change what is in DM gui.

1. We still need to work on the readout delay. Somehow Leginon's request for readout delay is not taken by the camera. Therefore, the delay is always 0
2. The frame exposure time is currently hard coded in pyscope/gatank2.py We plan to move it to the main interface, but haven't done it yet. You just gave us a reason to expedite this : )
3. The set value in gatank2.py for self.dosefrac_frame_time is 0.125 s. (You can change it there for now). Therefore in 4000 ms, it took 32 frames. Don't know where 33 is from, though.

The images Leginon gets (integrated and frames) are not DM software corrected (integer16).
If in counted or super-resolution mode is used, HW dark/gain are applied by DM. If in linear mode, HW dark and gain is not used. These are set in Leginon already.
Leginon still does its own dark and bright on the integrated image a.k.a. its software correction, then save the image as float32.

At the moment, this is the only way to run, since we had difficulty retrieving the software corrected counted mode image (float) through SerialEM plug-in when we worked on this in November. We may revisit this once the scope is more free.

By the way, what was in that image you have in the screen shot? It looks funny. On our camera, you see wide vertical strip Only if one of more digitizing board is malfunction. If it is rotated/flipped for Leginon, the bad strip is horizontal. It is never checkboardish. Regardless, if the digitizer functions correctly, you should not get the pattern whether there is beam or not.

Also, the leginon log does seem that you told it to collect an uncorrected image. Is this a new database that you use? Manual node default settings does uncorrected image so that people can do their very first test easily.

I used manual mode just to see what happened to the frames quickly and not starting up MSI with all the presets. I did not realize that it did not correct the image but that explains it. I will speak with Harry and change the frame exposure time to something that we would use but a setting in the main interface would be very useful depending on what dose rate we set things for. By the way whaat does frames to use represent in the interface? Thanks.
Bob

frames to use is a feature on DE camera. In one experiment, we had a negative readout delay and blast the sample with beam for 100 e/A^2, total of 100 frames or something to see what we can do with it. For example, we could use high dose image for alignment or study radiation damage by post processing some of the frames. The negative readout delay is there to make sure we catch the onset of the beam.

However, a very long exposure integrated image is not very useful in checking if we've got good ice or good freezing condition, or good protein, because of drift and degradation of the image by the damage over time. Since we only need about 1/10 to 1/5 of them to do these kinds of assessment, we made DE to return the integrated image for the specified frames. This way, we can avoid the beginning frames where our negative readout delay made them adding only noise, and use, say frame 2 to 10. Then we can use this nice crisp image for evaluation.

Uunfortunately, K2 can not do this, and our gui is not designed in the way that it will change the display according to the camera. I can only ask you to ignore it. Those who have DE camera will have to ignore the align frame gui, too.

We modified gatank2.py as you suggested and changed self.dosefrac_frame_time to 0.4 and also changed self_record_frame_time = 0.4 (what does this represent?DD related?) This saved the correct number of frames as we wanted and was very fast. When we selected the alignment of frames feature there was a significant delay which was probably expected so we will do the alignment offline in the future so as not to clog the data pipeline.

record_frame_time is used to make sure the exposure time we send to DM is a valid number, used when frame saving is not done (i.e., like when you select "record" rather than "dose fracationation" in DM). You must have noticed that if you put certain exposure time in DM, it would not accept it, but rather refresh to another number. It does the same thing when we send such a number through scripting.

Gatan said the base number will change in the future. On our camera, the base number is 0.125 s. We called it the record_frame_time in the code. With this number set to match your DM (by finding out what is the smallest exposure time accepted by it when you are in "record" mode), you can get the correct number back of a preset using "From scope" button after you send the invalid number "to the scope/camera" first. If all your users are aware of that they can not choose, i.e. 0.05 s exposure time on these type of camera, then we don't need this number. One day we will put this in the instruments.cfg. This behavior is actually common to all CMOS detector including Tietz F416, just less noticeable because the base frame is shorted.

Yes, the alignment frames feature that uses Gatan's alignment is painfully slow for us, too. We have been using Yifan's GPU program off gatan with Appion querying stream of images come in with frames saved. I have not written the instruction, but it is fully functional here. You are welcome to try it. We want it to be more parallel so that we can use GPU farm....

From what I understand the summit can take up to 40 frames per second which would translate to 0.025 sec.

I am not talking about dose fractionation mode, but the recording mode (non-dose fractionated). self.record_frame_rate is for the latter. Try it on your DM interface, and you will see what I mean. Just type a random number in the gui for the exposure time, and then tab or return. I found that on ours, numbers less than 0.125 s are not valid.

Thanks for the clarification. I tried setting the record time as you suggested and 0.125 is indeed the minimum record time.