Odd flatbox/light panel behavior

After a 2 year or so hiatus from astrophotography, I am getting back into it. In the meantime, I had to completely rebuild my observatory computer and I also upgraded from 3.Xsomething to the most recent version (4.3.1305). I’m still trying to figure out AutoFlats, but in the meantime, I wanted to go with my old tried-and-true methos of collecting flats. What I used to be able to do was set the flat panel brightness (It’s a DIY panel that uses the Anlitak interface) and experiment with frame and focus to get the right panel brightness and exposure length. The problem I am encountering is that whenever I take a frame and focus frame, SGP turns the light panel off. I’m sure it’s something silly that I am doing, but can someone tell me how to take a frame and focus frame without turning the light panel off?



OK, I found this thread:
Alnitak flat man control is not working - Sequence Generator / Equipment Compatibility - Main Sequence Software (sequencegeneratorpro.com)

So it seems that this is the intended behavior - which is different from my older version. If I am understanding this correctly, it is simply no longer possible to take any test images to determine the correct flat panel setting for a given exposure. It also seems that this makes the Flat Box module obsolete.

I would like to use Auto Flats, but my use case doesn’t seem to fit the Auto Flats model. My imaging train stays in the same configuration all the time and I only collect flats a couple of times a year - or if a new dust mote shows up on the sensor. So I am accustomed to setting up the “No FIlter Flats Data” (I use OSC) in the Equipment profile manager for my exposure and flat box settings. Problem is, now where doesn’t seem to be a way for me to experimentally determine the flat box values.

The biggest issue I think I have with Auto Flats (which may be complicate by my ignorance) is that it seems to find the correct exposure length for a given flat box setting. Since I dark-correct my flats, I would like to choose the exposure length (that is already in my dark library) and adjust the flat panel to get the right exposure.

Anyhow, if anyone knows how to take test exposures by varying the light panel settings, please let me know. Otherwise, I’ll muddle through with Auto Flats.

It is true. SGPro does not expect frame and focus to be used this way as it is a “light frame” tool and, as such makes sure that light frames are captured.

As you note, AutoFlats is intended so you absolutely do not need to go through these types of chores. I understand, completely, that it seems like a lot, but I can promise you, that for most users, it’s pretty straightforward. It seems complex primarily because it has 70 pages of docs for people that need extreme flexibility (and most don’t).

If you’re still not up to the task of tackling AutoFlats just yet, I can recommend its predecessor, the “Flats Calibration Wizard”. It too alleviates you from having to fiddle with brightness and exposure length in order to get your flat frames, but it stops there (whereas AutoFlats does this AND handles data collection). The Flats Cal Wizard comes out the issue from the “other direction”. It asks you what ADU you’re after and it will tell you how to get there via exposure length and brightness settings. Exposure length is always adjusted first, but if you set a “max” exposure length, it will start adjusting brightness afterward.

More here:

Flats Calibration Wizard (sequencegeneratorpro.com)

Thanks for the response Ken.

I suppose I need to just get with the times. I have played around with AutoFlats a bit, but haven’t been able to get it to actually work. That’s not a complaint - just an acknowledgement of my reluctance to take the time to RTFM.

Please post any questions you have… happy to provide guidance there.

I got it working. I think I was thrown off by the manual stating that Autoflats can be run independent of a sequence - or words to that effect. So I tried to do it with no sequence loaded (other than the unpopulated startup sequence). It just would not run, nor did it give any kind of error message. I’m guessing that it needs a sequence with a related equipment profile loaded to run. When I had a proper sequence loaded, it ran fine.

One thought for your consideration if you decide to tweak things a bit in future releases. For my big scope (Edge14), I need an exposure length of about a tenth of a second with my light box. For those flats, I need matching dark flats. So the exposure needs to be the same for the flats and darks. I was able to constrain the exposure length in Autoflats by putting 0.1s in both the lower and upper limits for exposure length. This seems to force Autoflats to leave exposure alone. Then, though, Autoflats changes the light box settings for each exposure. I can understand it doing that for sky flats since the sky brightness will vary from exposure to exposure as the sky darkens (or lightens). But it isn’t necessary for a light panel. The brightness setting for the first one would be correct for all of them. It’s a minor nit admittedly, so it is no big deal if you’re not interested in addressing it. The other thing I offer for your consideration is to make exposure priority a bit more intuitive. I can see this as being particularly useful for cameras with shutters combined with light boxes. A longer exposure is needed, but matching dark flat frames are also desired, necessitating the same exposure length for each flat.

Anyway, I’m in business now, and I have to admit that Autoflats was pretty awesome once I got it working.

1 Like

OK, thanks for the feedback. I’ll think of some better way to communicate that in all cases, AutoFlats is dependent on a valid Equipment Profile, but can be run as a standalone tool or as part of a sequence.

Unfortunately, it is for some. Flat panel brightness can and often does vary over time depending on power supply, temperature and duration of illumination. That said, I understand your point. There could definitely be a “once in range” stop checking option or something like that where future out of range frames would just send a warning message and continue without change.