search

indilib / indi

INDI Core Library Repository
https://www.indilib.org
GNU Lesser General Public License v2.1
372 stars 393 forks source link

Flats times inconsistent, got into a loop and stopped incrementing counter, too many shots. #1156

Closed phomer60 closed 4 years ago

phomer60 commented 4 years ago

Describe the bug I set up camera to take RGB flats (21 exposures each). It took 21 R but on close examination exposures 1-8 were 10.46 seconds but the rest were random. It took 22 (not 21) G with 1-18 of 11.52 and the rest random. It took 14 B with 1-2 of 13.03 and the rest random but it kept taking the 14th exposure looping indefinately. Note: Only minimal logging on.

To Reproduce Exact steps to reproduce the behavior.

  1. Calibration set to Manual
  2. Added sequences
  3. Run capture

Expected behavior A clear and concise description of what you expected to happen.

Screenshots Screen Sharing Picture 30 May 2020 at 9 51 23 am AEST

Desktop (please complete the following information):

Log Files log_08-12-53.txt

phomer60 commented 4 years ago

Screen Sharing Picture 30 May 2020 at 11 15 01 am AEST

phomer60 commented 4 years ago

Enabled capture logging and created new jobs which included times in file name. Stopped after Red filter showed issue. log_11-24-03.txt

TallFurryMan commented 4 years ago

Are these dawn/dusk flats? If that is the case, the behavior is expected. You need to adjust tolerance to a larger value. If not, then I need to double check your large log because the small one seems OK. Do you see the weird durations in the log or in your FITS files?

phomer60 commented 4 years ago

No, this is with a flat light source. Are you saying that once calibrated, the flats may vary in exposure time during a capture run? I can't say I have seen this behaviour previously and it is not what I want. Asking for 21 flats and getting 22 is definately unexpected. Infinite loop on 14/21 is also not desired. I can do this all manually but prefer to use the calibration option. Unfortunately I only had the minimum logging on when all three issues occurred.

TallFurryMan commented 4 years ago

This said, if we want to support dawn/dusk flats, we need to add a linear offset depending on time (even if that is not exact), so that we may predict the luminosity delta caused by the movement of the Sun. We could probably infer it from its current angle too.

Dawn/dusk flats, of course, are not really compatible with dark flats (which might be your requirement for single-exposure flats?), as it would be really cumbersome to associate exposures when they vary like this.

TallFurryMan commented 4 years ago

So this is with a flat light source. This is obviously highly unexpected! Chances are that there is a regression in the ADU calculation, but the numbers seem relatively good. Are you sure your luminosity is constant? No light infiltration anywhere?

phomer60 commented 4 years ago

I had a thought, if the brightness of the source varied, say due to a battery getting flatter, does it recalculate the exposure time during a run if it outside the tolerance? If so, then maybe the light source brightness is varying, I am going to test if with a mains powered adapter.

TallFurryMan commented 4 years ago

Yes the exposure variation is here to support the dawn/dusk luminosity variation. One thing we could to is to add an option to freeze the exposure when it is in the tolerance for the rest of the job, but that raises other questions.

TallFurryMan commented 4 years ago

What I see in your last log is that the luminosity increases over time, and that exposure diminishes as a result. Hence my remark about light infiltration.

phomer60 commented 4 years ago

Okay, the changes in the exposure time are now understood, I have learnt something new. I am wondering if that triggered the issue with loop and the extra flat, but at the moment everything is working fine.

knro commented 4 years ago

@TallFurryMan That's right, seems the source is not quite constant OR the camera response is not. At any rate, this is not really an INDI issue, it's Ekos, so closing this as bugs with Ekos need to be file at bugs.kde.org

TallFurryMan commented 4 years ago

@phomer60 when the exposure changes too many times, I think we do have a problem running the polynomial fitting. But as there is actually no official support for dawn/dusk flats, this remains as it is.

@knro will KDE shift to invent.kde.org for issues too in the future?

knro commented 4 years ago

@TallFurryMan yes, there is already ISSUES like Github on there. They didn't say whether bugzilla would be retired or not. They said issues would be used for internal tasks among developers.. still not clear.