When the LvStk button is pressed in the PEAAnuts main window, a live stacking process is started and another window opens for displaying
its results. In the top line of this live stack window, there are several buttons for optional actions, the centre area shows the live stack
(when ready), optionally postprocessed dependent on the current settings. Below the image field a graph displays the actual quality of the
incoming frames, and in the bottom, 2 lines of data provide info about the stack in progress and the one just finished.
Important parameters for the live stacking can be adjusted in the Stacking parameters and Postproc. parameters dialogs.
Stacking process basics
In principle, there is no difference between live stacking and stacking a recorded stream. Images are just added up.
Some aspects however need to be understood in order to make the best use of the plugin.
Stack size
In contrast to stacking recorded streams, where you select a fraction to the totally recorded streams for accumulation, in live stacking the
stack count specifies the amount of frames to stack, i.e. the final stack size. The process examines and accepts/rejects incoming frames
until this stack count is reached. So the number of processed frames will be higher in general, dependent on the circumstances and the
chosen quality settings. When you change the stack count parameter, the new value will take effect only with the beginning of the next stack,
not immediately for the one currently in process.
Alignment
Alignment is critical for stacking. Although the plugin tries to do this, the best result can be achieved by doing it twice.
So make sure to activate FireCaptures alignment feature 'Auto align', too.
Quality based frame rejection/acceptance
During stacking a simple quality estimation is performed on each incoming frame, which decides upon frame acceptance or rejection. This
needs 2 initializing runs at the beginning of each live stacking process. During initializing, all frames are accepted
for stacking. By default, a reduced stack count is used. So the first two images will generally appear quickly,
but show a very low quality. The color of the second data line
at the bottom informs about the image status. Red means first, yellow means second initializing image. From the third image onward,
the line appears green, indicating the normal or full operating state with quality based rejection/acceptance.
On the fly postprocessing
When the specified stack count is reached, the new stack is displayed immediately. The image will show either the pure stack, or, if activated,
a postprocessed (usually sharpenend) version. Currently, 2 sharpening modules are available, LR deconvolution, and unsharp masking. A
wavelet module is in state of development, but not yet ready. One or more of the available postprocessing modules can be selected.
Consecutive image replacement
The live stacking process continues until explicitely stopped. While the actually finished
image is visible in the live stack window, the next stacking run proceeds in the background. Each new image will automatically replace the old
one when it is ready. Replaced images are discarded by default, but may of course be saved to disk (see below).
Session start/stop, normal start/stop, pause and resume
It may sound a bit confusing at the beginning, but once you get it, the matter is quite understandable. There are 3 different types of
start/stop actions for the live stacking.
- Session start/stop
Starting the live stacking from the PEAAnuts main window means a 'session start', with initializing the quality algorithm. Stopping
the session by clicking again on the LvStk button really means stopping everything, with discarding all quality check
initialization data. Thus on start of a new session, the quality algorithm must be initialized again. This is generally necessary resp.
a good idea when conditions have changed significantly (sky transparency, seeing) or exposure settings (gain, exposure time, gamma, etc.)
have been modified.
- Normal start/stop
During a session, after initialization, i.e. when the second data line appears green,
the live stacking can be stopped by clicking the 'S' button in the top row of the EAA window. The current,
unfinished stack is discarded, but the initialization data are kept. This normal stopping and
restarting is recommended e.g. to fine tune the postprocessing parameters. Parameter effects can be judged immediately
on the stack still in memory. Sky conditions and FC exposure settings however should remain constant during that time, to avoid that
the quality algorithm will operate on an invalid base when resuming. Note that the 'S' changes to '>', for
restarting. When clicked, stacking continues directly with a new stack, by using the current quality reference.
- Pause and resume
Clicking on the button '||' (which then changes to '>' ) pauses the current stacking. Use this e.g. when some
clouds are passing quickly through the field of view, clicking on '>' resumes it. Keep planet rotation in mind, pausing a stacking run
should only be used for very short breaks.
It is important to understand the differences between these three start/stop options and to use the right one dependent on the situation
for achieving good results.
Quality algorithm & process info
In full operating mode, after initialization, the calculated quality of the incoming frames is displayed in the graph below the image.
The horizontal red line marks the currently chosen quality limit for frame acceptance. To the right of the frame quality graph, a small bar
indicator displays the current acceptance rate. In contrast to stacking recorded streams, in live stacking it is advisable to work with lower
quality demands. The quality algorithm in its actual state is rather simple, and also must provide results quickly. Taking too much time for
this task is prohibitive. So striving for the ultimate high quality usually does not pay off, rather work with acceptance rates between,
say, 30 and 70 %.
The quality algorithm is very sensitive to changed conditions, for example significant changes in image brightness like they are caused by
thin cirrus clouds, and/or long-term seeing changes. Of course, user-driven adjustments of gain a/o exposure time have the
same effect. An invalid internal reference for quality checking usually shows as (or results in) a dramatic drop of the acceptance rate.
Then it is necessary to do a session stop and restart to generate a new reference which fits to the actual circumstances.
Process info lines
1. line
Curr. |
stack number currently in process, excluding the initializing images (count in brackets includes them)
|
T [s] |
elapsed time since starting this stack (in seconds)
|
Proc. |
number of processed frames so far
|
Stck. |
number of accepted/stacked frames so far
|
2. line
Disp. |
stack or image number currently shown in the live stacking window
|
T [s] |
elapsed time for the actually displayed stack
|
AccR [%] |
acceptance ratio, quotient of stacked through processed frames, in percent
|
Lost |
number of dropped resp. lost frames. Note that FC feeds the plugin with new input continuously, and frames might be overwritten in the
ringbuffer if the stacking process incl. quality estimation cannot process them quickly enough
|
Optional actions
|| or > |
pause/resume. A running stacking process can be interrupted, e.g. when clouds move through your field of view.
Use this for short pauses only. How long the pause can be without rendering the stack useless depends on the planet and your
telescope resolution. The high speed rotators Saturn and Jupiter evidently only allow short pauses, with Mars and esp. Venus, things
are more relaxed. Note also, that conditions (seeing a/o transparency) might change, so in bad circumstances it will be better to
abandon the running stack and start a new process, which produces a new reference for the quality algorithm
|
S or > |
start/stop. Stop (and discard) the stack currently in process, and start with a new one if the button is clicked again. No new initializing
is done, so conditions and gain/exposure time settings should not change. This start/stop is helpful for fine-tuning the postprocessing
with the last finished stack which is still in memory/on display.
|
Save |
save the currently displayed image. Keep in mind that the image gets refreshed regularly,
so saving happens immediately, with an automatically generated name. No file name dialog opens up, this might take too much time.
Per default, a WinJupos compatible filename is generated, with a timestamp set to the middle of the elapsed stacking time (in UT).
|
AS |
This button toggles auto-saving. If on (green), each new image gets saved automatically. Only full operation mode
images are saved, the first two initializing images are ignored. They can however be saved manually, if this might be of interest.
|
Display scale |
a drop down list offers a set of scaling factors for image display. The scaling has an effect only on the display. Images
will be processed and saved in their original size.
|
ImgEd |
Opens a separate tool for modifying the final image (brightness/contrast). See separate chapter.
|
State of development
The quality algorithm is definitely a field of constant development. The matter seems to be difficult in general.
I noticed strange outcomes in the commonly used stacking programs where frames end up in the selection
which definitely look worse than others which are rejected. Hmmm ? So doing this quickly in live mode is even more tricky, and, as already
mentioned, it is advisable to reduce the demands. Do not expect too much.
So no matter if you use live stacking or the old school way of prostprocessing, the basic truth remains the same: If the seeing is
good, you will get good results, if the seeing is bad, you will get bad results. Life is hard.
|