continuous acquisition with intervals

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

continuous acquisition with intervals

Jeff Spector
Greetings,
 I'm trying to write a script that will let us record fast, say 10 frames at 20 fps (50 ms continuous exposure) and then wait for ~5 seconds and repeat for a designated number of times. I can do this by running a quick acquisition each time vai a script, but then I end up with a folder for each acquisition and putting things back together ges cumbersome when there are thousands of folders. Is there a nie (current) example of how to do this so that all the images go in to the same file? 
do I have to record them and put them in the acquisition one by one? 
Thanks,
  - Jeff


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: continuous acquisition with intervals

Stuurman, Nico
HI Jeff,
>  I'm trying to write a script that will let us record fast, say 10
> frames at 20 fps (50 ms continuous exposure) and then wait for ~5
> seconds and repeat for a designated number of times. I can do this by
> running a quick acquisition each time vai a script, but then I end up
> with a folder for each acquisition and putting things back together
> ges cumbersome when there are thousands of folders. Is there a nie
> (current) example of how to do this so that all the images go in to
> the same file?
> do I have to record them and put them in the acquisition one by one?

Look at the "burstAcquisition.bsh" script
(https://raw.githubusercontent.com/nicost/micro-manager/ViewerPlusCV/scripts/burstAcquisition.bsh).


Actually, while testing (in 2.0-gamma) to make sure it works, I wrote it
for you:



/**
  * Example of running multiple sequence acquisitions (a.k.a. burst
acquisitions).
  */

nrTimes = 10;
secSleep = 2;
nrFrames = 5;
exposureMs = mmc.getExposure();
// Create a Datastore for the images to be stored in, in RAM.
store = mm.data().createRAMDatastore();
// Create a display to show images as they are acquired.
mm.displays().createDisplay(store);
// Have Micro-Manager handle logic for ensuring data is saved to disk.
mm.displays().manage(store);


// Start collecting images.
// Arguments are the number of images to collect, the amount of time to wait
// between images, and whether or not to halt the acquisition if the
// sequence buffer overflows.

for (int i = 0; i < nrTimes; i++) {

     mmc.startSequenceAcquisition(nrFrames, 0, true);
     // Set up a Coords.CoordsBuilder for applying coordinates to each
image.
     builder =
mm.data().getCoordsBuilder().z(0).channel(0).stagePosition(0);
     int curFrame = 0;
     while (mmc.getRemainingImageCount() > 0 ||
mmc.isSequenceRunning(mmc.getCameraDevice())) {
        if (mmc.getRemainingImageCount() > 0) {
           tagged = mmc.popNextTaggedImage();
           // Convert to an Image at the desired timepoint.
           image = mm.data().convertTaggedImage(tagged,
              builder.time(curFrame + i * nrFrames).build(), null);
           store.putImage(image);
           curFrame++;
        }
        else {
           // Wait for another image to arrive.
           mmc.sleep(Math.min(.5 * exposureMs, 20));
        }
     }
     mmc.stopSequenceAcquisition();
     Thread.sleep(1000 * secSleep);
}





_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: continuous acquisition with intervals

Jeff Spector
I'll test it out today. Thanks!

On Mon, Aug 12, 2019 at 5:38 PM Stuurman, Nico <[hidden email]> wrote:
HI Jeff,
>  I'm trying to write a script that will let us record fast, say 10
> frames at 20 fps (50 ms continuous exposure) and then wait for ~5
> seconds and repeat for a designated number of times. I can do this by
> running a quick acquisition each time vai a script, but then I end up
> with a folder for each acquisition and putting things back together
> ges cumbersome when there are thousands of folders. Is there a nie
> (current) example of how to do this so that all the images go in to
> the same file?
> do I have to record them and put them in the acquisition one by one?

Look at the "burstAcquisition.bsh" script
(https://raw.githubusercontent.com/nicost/micro-manager/ViewerPlusCV/scripts/burstAcquisition.bsh).


Actually, while testing (in 2.0-gamma) to make sure it works, I wrote it
for you:



/**
  * Example of running multiple sequence acquisitions (a.k.a. burst
acquisitions).
  */

nrTimes = 10;
secSleep = 2;
nrFrames = 5;
exposureMs = mmc.getExposure();
// Create a Datastore for the images to be stored in, in RAM.
store = mm.data().createRAMDatastore();
// Create a display to show images as they are acquired.
mm.displays().createDisplay(store);
// Have Micro-Manager handle logic for ensuring data is saved to disk.
mm.displays().manage(store);


// Start collecting images.
// Arguments are the number of images to collect, the amount of time to wait
// between images, and whether or not to halt the acquisition if the
// sequence buffer overflows.

for (int i = 0; i < nrTimes; i++) {

     mmc.startSequenceAcquisition(nrFrames, 0, true);
     // Set up a Coords.CoordsBuilder for applying coordinates to each
image.
     builder =
mm.data().getCoordsBuilder().z(0).channel(0).stagePosition(0);
     int curFrame = 0;
     while (mmc.getRemainingImageCount() > 0 ||
mmc.isSequenceRunning(mmc.getCameraDevice())) {
        if (mmc.getRemainingImageCount() > 0) {
           tagged = mmc.popNextTaggedImage();
           // Convert to an Image at the desired timepoint.
           image = mm.data().convertTaggedImage(tagged,
              builder.time(curFrame + i * nrFrames).build(), null);
           store.putImage(image);
           curFrame++;
        }
        else {
           // Wait for another image to arrive.
           mmc.sleep(Math.min(.5 * exposureMs, 20));
        }
     }
     mmc.stopSequenceAcquisition();
     Thread.sleep(1000 * secSleep);
}





_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: continuous acquisition with intervals

Jeff Spector
In reply to this post by Stuurman, Nico

Hi,
 
On Mon, Aug 12, 2019 at 5:38 PM Stuurman, Nico <[hidden email]> wrote:
HI Jeff,
>  I'm trying to write a script that will let us record fast, say 10
> frames at 20 fps (50 ms continuous exposure) and then wait for ~5
> seconds and repeat for a designated number of times. I can do this by
> running a quick acquisition each time vai a script, but then I end up
> with a folder for each acquisition and putting things back together
> ges cumbersome when there are thousands of folders. Is there a nie
> (current) example of how to do this so that all the images go in to
> the same file?
> do I have to record them and put them in the acquisition one by one?

Look at the "burstAcquisition.bsh" script
(https://raw.githubusercontent.com/nicost/micro-manager/ViewerPlusCV/scripts/burstAcquisition.bsh).


Actually, while testing (in 2.0-gamma) to make sure it works, I wrote it
for you:



/**
  * Example of running multiple sequence acquisitions (a.k.a. burst
acquisitions).
  */

nrTimes = 10;
secSleep = 2;
nrFrames = 5;
exposureMs = mmc.getExposure();
// Create a Datastore for the images to be stored in, in RAM.
store = mm.data().createRAMDatastore();
// Create a display to show images as they are acquired.
mm.displays().createDisplay(store);
// Have Micro-Manager handle logic for ensuring data is saved to disk.
mm.displays().manage(store);


// Start collecting images.
// Arguments are the number of images to collect, the amount of time to wait
// between images, and whether or not to halt the acquisition if the
// sequence buffer overflows.

for (int i = 0; i < nrTimes; i++) {

     mmc.startSequenceAcquisition(nrFrames, 0, true);
     // Set up a Coords.CoordsBuilder for applying coordinates to each
image.
     builder =
mm.data().getCoordsBuilder().z(0).channel(0).stagePosition(0);
     int curFrame = 0;
     while (mmc.getRemainingImageCount() > 0 ||
mmc.isSequenceRunning(mmc.getCameraDevice())) {
        if (mmc.getRemainingImageCount() > 0) {
           tagged = mmc.popNextTaggedImage();
           // Convert to an Image at the desired timepoint.
           image = mm.data().convertTaggedImage(tagged,
              builder.time(curFrame + i * nrFrames).build(), null);
           store.putImage(image);
           curFrame++;
        }
        else {
           // Wait for another image to arrive.
           mmc.sleep(Math.min(.5 * exposureMs, 20));
        }
     }
     mmc.stopSequenceAcquisition();
     Thread.sleep(1000 * secSleep);
}



 Thanks for the script it appears to be working well. As I've been looking at other examples I have a few questions about the timing, in particualr usin system.curentTimeMillis.  if I do something like

start = system.currentTimeMillis()
 // start the acquisition here
// close it here 
end = system.currentTimeMillis()

and then look at  end-start  the time it takes appears to be much larger than it should. For example if I do  10 frames at a 50 ms exposure and then want to wait for 1 second and repeat it by using the system.currentTimeMillis() method to check how long the sequence took (so that I know how long to wait) it always says around 1500 ms, which would mean that I have to have a delay between bursts of at least that much, however if I do the exact same thing with custom time intervals manually entered into the multi-D window and check the time stamps they are separated by the correct amount of time. So it appears that using the system.currentTimeMillis() is NOT a good way to time an acquisition. Is this true or am I missing something? I only ask because I came across several  example scripts that all use this method to keep track of time. Thanks.
-Jeff
 


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: continuous acquisition with intervals

Stuurman, Nico
Hi Jeff,

>
>     >  I'm trying to write a script that will let us record fast, say 10
>     > frames at 20 fps (50 ms continuous exposure) and then wait for ~5
>     > seconds and repeat for a designated number of times.
>
>
>  Thanks for the script it appears to be working well. As I've been
> looking at other examples I have a few questions about the timing, in
> particualr usin system.curentTimeMillis.  if I do something like
>
> start = system.currentTimeMillis()
>  // start the acquisition here
> // close it here
> end = system.currentTimeMillis()
>
> and then look at  end-start  the time it takes appears to be much
> larger than it should. For example if I do  10 frames at a 50 ms
> exposure and then want to wait for 1 second and repeat it by using the
> system.currentTimeMillis() method to check how long the sequence took
> (so that I know how long to wait) it always says around 1500 ms, which
> would mean that I have to have a delay between bursts of at least that
> much, however if I do the exact same thing with custom time intervals
> manually entered into the multi-D window and check the time stamps
> they are separated by the correct amount of time. So it appears that
> using the system.currentTimeMillis() is NOT a good way to time an
> acquisition. Is this true or am I missing something? I only ask
> because I came across several  example scripts that all use this
> method to keep track of time.

Interesting.  I ran some tests, and it appears that
store.putImage(image) is the time-consuming step.  When I comment that
line out, end-start gets pretty close to the expected value (kind of
curious what is going on there).  Removing that line is not an option. 
So, if you want fixed intervals, calculate the time to sleep as follows:

waitTimeMs = desiredIntervalMs - (end - start);
if (waitTimeMs > 0) {
     Thread.SleepMs(waitTimeMs);
}


Best,

Nico


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: continuous acquisition with intervals

Jeff Spector
Hi,
 

On Thu, Aug 15, 2019 at 4:44 PM Stuurman, Nico <[hidden email]> wrote:
Hi Jeff,

>
>     >  I'm trying to write a script that will let us record fast, say 10
>     > frames at 20 fps (50 ms continuous exposure) and then wait for ~5
>     > seconds and repeat for a designated number of times.
>
>
>  Thanks for the script it appears to be working well. As I've been
> looking at other examples I have a few questions about the timing, in
> particualr usin system.curentTimeMillis.  if I do something like
>
> start = system.currentTimeMillis()
>  // start the acquisition here
> // close it here
> end = system.currentTimeMillis()
>
> and then look at  end-start  the time it takes appears to be much
> larger than it should. For example if I do  10 frames at a 50 ms
> exposure and then want to wait for 1 second and repeat it by using the
> system.currentTimeMillis() method to check how long the sequence took
> (so that I know how long to wait) it always says around 1500 ms, which
> would mean that I have to have a delay between bursts of at least that
> much, however if I do the exact same thing with custom time intervals
> manually entered into the multi-D window and check the time stamps
> they are separated by the correct amount of time. So it appears that
> using the system.currentTimeMillis() is NOT a good way to time an
> acquisition. Is this true or am I missing something? I only ask
> because I came across several  example scripts that all use this
> method to keep track of time.

Interesting.  I ran some tests, and it appears that
store.putImage(image) is the time-consuming step.  When I comment that
line out, end-start gets pretty close to the expected value (kind of
curious what is going on there).  Removing that line is not an option. 
So, if you want fixed intervals, calculate the time to sleep as follows:

waitTimeMs = desiredIntervalMs - (end - start);
if (waitTimeMs > 0) {
     Thread.SleepMs(waitTimeMs);
}


Best,

Nico



Thanks for looking at this for me. Does this mean that the fastest interval I can use then is end-start (which is around 1.5 seconds in my case?) 
- Jeff


 


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general