I have some questions about the solar system sequencer regarding long duration automated planetary imaging. I may have more.
1. In the solar system sequencer there is a command "Solar system auto set exposure/gain", or AUTOEXPOSE SOLARSYSTEM TARGET <N> FPS in code. How does this work exactly? It looks like it automatically adjusts the exposure/FPS, yes? Within what limits? Does it leave the gain fixed?
2. Is SharpCap's Feature Tracking considered a "Guiding application" if it is open? I see no facility to start and stop Feature Tracking otherwise. Is there no way to do this? If so it's a deal breaker. I believe I need the sequencer to:
1. Capture until the target is past the meridian (no problem)
2. Switch to maximum ROI, which will turn off Feature Tracking
3. Change to the electronic finder camera and re-GOTO the target (with offset plate solve enabled), which will automatically flip the scope
4. Switch back to the main imaging camera
5. Turn on Feature Tracking and give it a minute to guide the planet to the center of the FOV
6. Switch back to capture ROI, which will turn off Feature Tracking
7. Turn on Feature Tracking
8. Begin capturing
Can SharpCap's solar system sequencer currently do all that?
Questions
-
admin
- Site Admin
- Posts: 17552
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Questions
Hi Mike,
the solar system autoexpose routine prioritizes attaining at least the FPS that you set (or, rather, having an exposure low enough that the FPS you have chosen is possible, so please set an FPS that is within reach of the camera you are using at the ROI in use!). Given that there is a ceiling on the exposure that can be used due to needing to be able to reach the FPS target, if the image is too dim then the gain will be increased to try to hit the required brightness. If the image is too bright, the gain is reduced first, and if still too bright then the exposure is reduced.
On the other hand there is currently no access to the feature tracking from the scripting or sequencer, so there is no supported way to turn the feature tracking back on - that would require some work on my side to make the feature tracking functionality first available via the script interface (most of the work) and then build a sequencer step to re-enable it (the easy part). Alternatively there are almost certainly command line type tools out there that can find and press a button that could be launched from a sequencer step (those sort of tools are often used for automated software testing).
cheers,
Robin
the solar system autoexpose routine prioritizes attaining at least the FPS that you set (or, rather, having an exposure low enough that the FPS you have chosen is possible, so please set an FPS that is within reach of the camera you are using at the ROI in use!). Given that there is a ceiling on the exposure that can be used due to needing to be able to reach the FPS target, if the image is too dim then the gain will be increased to try to hit the required brightness. If the image is too bright, the gain is reduced first, and if still too bright then the exposure is reduced.
On the other hand there is currently no access to the feature tracking from the scripting or sequencer, so there is no supported way to turn the feature tracking back on - that would require some work on my side to make the feature tracking functionality first available via the script interface (most of the work) and then build a sequencer step to re-enable it (the easy part). Alternatively there are almost certainly command line type tools out there that can find and press a button that could be launched from a sequencer step (those sort of tools are often used for automated software testing).
cheers,
Robin
Re: Questions
Thanks for the info, Robin. Some feedback:
In my opinion getting an auto-histogram functionality correct for planetary imaging is tricky. I posted a thread about an auto-histogram script I wrote that has some details, but basically adjusting the gain instead of the exposure causes problems downstream during stacking where the dimmest frames (in terms of real photons captured) get gained up, and because they are noisier, which the contrast metric cannot distinguish from higher contrast, they are marked higher quality and the stack becomes dominated by the worst frames. A better way to compensate for variable transparency is to increase the exposure when the transparency drops in order to try to capture a similar amount of total photons, which preserves the SNR, allowing the stacking application to properly assess quality. There will inevitably be some variability in the number of photons captured as the transparency varies and the scheme tries to scale up and down the exposure, but as long as the target window of the histogram is fairly narrow (I was using * or / 1.15, so the SNR would vary by around 7 or 8%) the variability in contrast (i.e. true "quality") should dominate.
Adjusting the gain would be fine in the case, for example, where the target is rising from low in the sky (and hence relatively dimmer) to high in the sky (and hence relatively brighter) but there is no real variable transparency expected. On the other hand there's no real point in that case; just set the histogram conservatively low so it has room to increase. Just target 60% histogram instead of 80% or whatever at your desired exposure/frame rate.
So a version of that auto-histogram sequencer command that could do something like what I described above would be an improvement over the gain adjusting version in my opinion. Since you already have a gain adjusting version perhaps it wouldn't be too hard to modify it for exposure adjustment instead.
Regarding getting Feature Tracking to work from the sequencer (and/or scripting?), It would be nice to see that working, but it is not an immediate priority. Jupiter will shortly be transiting before midnight and I will not have to stay up so late to manually handle the meridian flip. So maybe stick it somewhere in your stack of post-in notes for a rainy day. ;O)
Cheers,
Mike
In my opinion getting an auto-histogram functionality correct for planetary imaging is tricky. I posted a thread about an auto-histogram script I wrote that has some details, but basically adjusting the gain instead of the exposure causes problems downstream during stacking where the dimmest frames (in terms of real photons captured) get gained up, and because they are noisier, which the contrast metric cannot distinguish from higher contrast, they are marked higher quality and the stack becomes dominated by the worst frames. A better way to compensate for variable transparency is to increase the exposure when the transparency drops in order to try to capture a similar amount of total photons, which preserves the SNR, allowing the stacking application to properly assess quality. There will inevitably be some variability in the number of photons captured as the transparency varies and the scheme tries to scale up and down the exposure, but as long as the target window of the histogram is fairly narrow (I was using * or / 1.15, so the SNR would vary by around 7 or 8%) the variability in contrast (i.e. true "quality") should dominate.
Adjusting the gain would be fine in the case, for example, where the target is rising from low in the sky (and hence relatively dimmer) to high in the sky (and hence relatively brighter) but there is no real variable transparency expected. On the other hand there's no real point in that case; just set the histogram conservatively low so it has room to increase. Just target 60% histogram instead of 80% or whatever at your desired exposure/frame rate.
So a version of that auto-histogram sequencer command that could do something like what I described above would be an improvement over the gain adjusting version in my opinion. Since you already have a gain adjusting version perhaps it wouldn't be too hard to modify it for exposure adjustment instead.
Regarding getting Feature Tracking to work from the sequencer (and/or scripting?), It would be nice to see that working, but it is not an immediate priority. Jupiter will shortly be transiting before midnight and I will not have to stay up so late to manually handle the meridian flip. So maybe stick it somewhere in your stack of post-in notes for a rainy day. ;O)
Cheers,
Mike
-
admin
- Site Admin
- Posts: 17552
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Questions
Hi Mike,
I saw your post about the changes in gain and hence noise and frame selection - makes sense in one way, but I would also suggest that if that is happening then the noise reduction going on in the frame quality measurement is probably insufficient... Ideally you would want enough that changes in seeing/focus affecting the true image would give a bigger effect than the remnants of the shot noise.
Anyway, it's not desperately hard to make the code I have adjust the exposure in preference to the gain - I built the whole thing to be modular and in fact already have an 'ExposureFirstAdjustmentStrategy' that will try to adjust the exposure in preference to the gain. You still need a maximum exposure (target FPS) though because otherwise the adjustment could happily set the exposure to a length that would no longer freeze the seeing. You then end up with a less predictable outcome, as if you hit the maximum exposure when adjusting and the image is still too dim the gain would need to rise. Then if the brightness increases, the priority would be to reduce the exposure leaving the gain still increased. It feels more like an advanced user thing as to work properly the settings need to be reasonable initially.
On the subject of scripting/sequencer in feature tracking, that will end up being a SC 4.2 thing...
cheers,
Robin
I saw your post about the changes in gain and hence noise and frame selection - makes sense in one way, but I would also suggest that if that is happening then the noise reduction going on in the frame quality measurement is probably insufficient... Ideally you would want enough that changes in seeing/focus affecting the true image would give a bigger effect than the remnants of the shot noise.
Anyway, it's not desperately hard to make the code I have adjust the exposure in preference to the gain - I built the whole thing to be modular and in fact already have an 'ExposureFirstAdjustmentStrategy' that will try to adjust the exposure in preference to the gain. You still need a maximum exposure (target FPS) though because otherwise the adjustment could happily set the exposure to a length that would no longer freeze the seeing. You then end up with a less predictable outcome, as if you hit the maximum exposure when adjusting and the image is still too dim the gain would need to rise. Then if the brightness increases, the priority would be to reduce the exposure leaving the gain still increased. It feels more like an advanced user thing as to work properly the settings need to be reasonable initially.
On the subject of scripting/sequencer in feature tracking, that will end up being a SC 4.2 thing...
cheers,
Robin
Re: Questions
Robin,
Yes, you would need a maximum exposure setting lest it crank the exposure up to 10 minutes when a cloud passes. But the fact that you are no longer "freezing the seeing" isn't really relevant in my experience. If you gain up dim frames the stacking software cannot distinguish good frames from bad frames anyway in that case, because the contrast metric becomes dominated by shot noise. If you instead increase the exposure and those frames aren't as sharp, they will be correctly marked lower quality, despite their high SNR, and the software will be able to properly stack the best frames. In fact I would prefer that if the histogram cannot be maintained even at the maximum exposure, that the gain *not* be adjusted. Just let the histogram go at that point. Those frames will be dim and will be marked as poor, as they should be. That's the way my auto-histogram scripts work; try to adjust exposure within the limits, and do not touch the gain at all.
Happy to hear that FT will be automatable (is that a word?) in 4.2.
Cheers,
Mike
Yes, you would need a maximum exposure setting lest it crank the exposure up to 10 minutes when a cloud passes. But the fact that you are no longer "freezing the seeing" isn't really relevant in my experience. If you gain up dim frames the stacking software cannot distinguish good frames from bad frames anyway in that case, because the contrast metric becomes dominated by shot noise. If you instead increase the exposure and those frames aren't as sharp, they will be correctly marked lower quality, despite their high SNR, and the software will be able to properly stack the best frames. In fact I would prefer that if the histogram cannot be maintained even at the maximum exposure, that the gain *not* be adjusted. Just let the histogram go at that point. Those frames will be dim and will be marked as poor, as they should be. That's the way my auto-histogram scripts work; try to adjust exposure within the limits, and do not touch the gain at all.
Happy to hear that FT will be automatable (is that a word?) in 4.2.
Cheers,
Mike
-
admin
- Site Admin
- Posts: 17552
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Questions
Hi Mike,
actually, maybe that viewpoint makes things easier... What if I added a 'lock gain' option to the current autoexposure (default off). Check that box and it will only adjust the exposure, subject to the same limit of wanting to get a certain FPS (you can set that to 10fps if you are happy with the exposure going up to 100ms say).
cheers,
Robin
actually, maybe that viewpoint makes things easier... What if I added a 'lock gain' option to the current autoexposure (default off). Check that box and it will only adjust the exposure, subject to the same limit of wanting to get a certain FPS (you can set that to 10fps if you are happy with the exposure going up to 100ms say).
cheers,
Robin
Re: Questions
Robin,
That sounds perfect.
Cheers,
Mike
That sounds perfect.
Cheers,
Mike