×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Running a Sequence multiple times

  • Posts: 94
  • Thank you received: 8
I am recording time series of variable stars. To do this I need to:

1. Take and image with one filter
2. Switch to another filter and take a second image (possibly for a different length)
3. Then repeat 1 & 2 for around 200-300 times.

If I create a sequence that does 1 & 2, then I can use the scheduler to repeat it some number of times. This works, but I'm wondering is there is a more straightforward way to repeat a sequence some number of times. Using the scheduler seems like overkill.
2 months 1 week ago #98926

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
I realize the scheduler doesn't do quite what I need. It is common to want to delay after the second image for (say) 1 minute. In the sequence, I can specify a delay after the second image, but the scheduler seems to ignore this. After taking the second image, it starts the first one again without any delay.

Any way around this?
2 months 1 week ago #98928

Please Log in or Create an account to join the conversation.

  • Posts: 1221
  • Thank you received: 565
If the scheduler seems to ignore a sequence-final delay, perhaps add a dummy capture (e.g. your two desired images with delay after the 2nd, then a dummy capture with any other filter), and then use the scheduler to repeat.
The following user(s) said Thank You: Bill Tschumy
2 months 1 week ago #98941

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
Hy,

Yes, I can certainly do a dummy capture at the end of the sequence. Hopefully a delay in the middle of the captures won’t be ignored. I’ll experiment tomorrow.

I think you once told me you worked on the scheduler. Can you enter a bug report about the delay after last capture being ignored?

Bill
2 months 1 week ago #98942

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
OK, I just tried this. As I feared, delays seem to be ignored even if in the middle of a sequence. Maybe there is a good reason for this but it would be nice if it were possible.

Another workaround is to just expose the dummy image for the length of the delay. Not sure there is a disadvantage to doing that over the other workaround.
2 months 1 week ago #98945

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Bill,
it should be not a bigger problem to fix this. How precisely is your requirement regarding the delay?
When we add the delay at the end of a sequence, the overall time difference will be slightly bigger than in the middle of a sequence, since restarting a sequence might add a slight delay on its own due to code performance. If say 100ms difference is no issue (just guessing, haven’t measured it), then we could fix your problem.

Cheers
Wolfgang
The following user(s) said Thank You: Bill Tschumy
2 months 1 week ago #98947

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
Wolfgang,

In my case there is no great accuracy requirement. If the delay is accurate to a couple of seconds, that is good enough.

Thanks for responding,
Bill
2 months 1 week ago #98956

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
OK, fine, good to know. Capturing takes the delay only into account between capturing single frames. Therefore, capturing the first frame does not consider the delay and starts immediately.

From my perspective this isn't a consistent behavior. If I want to take 5 images, I could use a single frame sequence and repeat it five times with the scheduler, or use a sequence with five frames and run the sequence only once. In both cases, we should have the same delay pattern.

A change for this is already in preparation and - if everything goes fine - will be available after a couple of days in our nightly builds.

In the mean time, a workaround could also be a sequence file that has the desired number of frames. Maybe the easiest way is to create a single set of captures with the two filters and then multiplying the jobs by editing the .esq file.

Cheers
Wolfgang
Last edit: 2 months 1 week ago by Wolfgang Reissenberger.
2 months 1 week ago #98957

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8

Not sure I understand why these two situations would be different. If you had a single capture with a delay of (say) 1 minute and repeated it 5 times in the scheduler, I would expect:

image 1
[1 minute delay]
image 2
[1 minute delay]
image 3
[1 minute delay]
image 4
[1 minute delay]
image 5
[1 minute delay]
Done

I would expect the same pattern if the sequence had 5 images, each with a delay in it. Could you explain which one would be different and why? I just want to be sure the fix is going to solve my issue.

Thanks,
Bill
2 months 1 week ago #98960

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
You are absolutely right, they should be identical. But currently they aren't, since the first delay is missing. That's why I would like to change the behavior so that both are identical.
The following user(s) said Thank You: Bill Tschumy
2 months 1 week ago #98976

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
Yeah, that makes no since that the first delay is missing. It would be great to get that fixed. I think delays should be “first class citizens” just like exposure times. Neither should be skipped.

I do have a workaround for now, so there is no huge rush.
2 months 1 week ago #98985

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
The change is merged into the master source. It should be available from the nightly builds in the next few days.
The following user(s) said Thank You: Bill Tschumy
2 months 1 week ago #98990

Please Log in or Create an account to join the conversation.

Time to create page: 0.272 seconds