SharpCap Forums

Hi, as beginner I am still performing indoor learning exercises with a primitive optical setup. My test "stars" are quite extended; nevertheless SharpCap recognizes them, if I set the "Maximum FWHM" to a large value (or don't activate the FWHM filter). I hope that my wishes (A and B) do not appear too demanding considering the large variety of SharpCap actions already available. SharpCapPro v.4.0.9538,64 bit, ZWO ASI071 MC Pro (using 4.1 beta sems too early for my limited knowledge).

A: When I command "Live Stack" the stacking process starts immediately. If a wish to change the inputs (set during an earlier stacking) I have to "Pause" quickly and input the changes. In order to attempt a pure start without conflicting earlier data, I select "Clear", the stacking starts again. I did not find a button for an orderly stop (of course with completion of the ongoing frame, the stacking process, and proper file saving), so I have to use "Clear" or exit with deselecting "Live Stack". I would welcome a start/stop button on the left side of the stack window, the stop action should leave all informations accessible (e.g. Filter (FWHM), Filter (Brightness), Log). "Save and Reset every xx minutes..." is not an exact substitute for a start/stop button (in my opinion).

B: I welcome the optional enlargement of the horizontal axis of the stack histogram by the corresponding click. Some ticks for percent values would improve the judgement on the histogram.

C: In "Preprocessing" I have selected "Subtract Dark" and "Apply Flat" with appropriate files. If I perform
a: "Framing Shot" or "Snapshot",
b: "Live Stack", and "View individual frames",
then "Pixel Value Readouts" are quasi identical for both cases a: and b: as they should be.
However, with "View Stack" the "Pixel Value Readouts" appear with significantly larger values, the stack is brighter by a factor of roughly 1.5 ....2.0 (differently for the three colours) . Is this usual for SharpCap's stacking routine or did I miss something? Of course, I did not change anything like exposure, brightness, gain, or colour space.

Is the stacking process endangered by this enlarging of values in the stack? A "Framing Shot" in advance to a planned stacking, then, may not be sufficient in order to avoid stacked pixel values reaching 100 percent ADU range.

D: Possibly I may be asked to send a copy of the Log output of live stacking (perhaps now or for the case of future questions). Does a "log" file exist (in which folder?) which I could attach to my wording into the forum? With respect to the stacking actions performed so far, I see only WARNINGS of the type "Save failed as destination file D:\ ....... Stack_16bits_6frames_60s.fits already exists". Is the "Clear" button not sufficient for clearing all files of a previous Live Stack? At the end of the stacking process a red message appears above the image window; it is not readable, because it disappears quickly (less than a second).

With many thanks in advance for your help, Albrecht

Hi,

I know that the current reset/pause/resume options in live stacking don't always quite match the requirements, but so far have been unable to come up with a significant improvement (at least one that doesn't add significantly more complexity). I'm not at all sure about the need to have an option that waits for the current frame to finish before stopping - I am usually happy to save what I have now and let the current frame either go to waste or end up being the first one in the next stack.

There is a tweak for the the folder monitor camera in recent SharpCap versions that does help out though - since the folder monitor camera displays the first frame straight away, it would be missed if you then enable live stacking and start the rest of the frames running. However there is a replay frame button in the controls now that can be used to repeat the current frame (as many times as you like), so once you have everything set up and live stacking active, press the replay frame button to re-run the first frame, then press play to run the rest.

As to the histogram ticks - I will see if that is easy and how it looks to make sure it doesn't cause conflicts with the rest of the histogram, but it sounds sensible.

For stacking, there is no real reason that the pixel values will be the same - In some cases (where the input image does not have any pixels near the maximum possible value, SharpCap will scale the live stacking data automatically to make full use of the output value range. Also, there is the live stacking stretch function which (I believe) applies to the pixel value readout when live stacking is active.

The live stacking log is not saved, since it is mostly low value information (how many stars were detected in each frame, etc). Significant things from the live stacking log (serious errors, etc) are also sent to the main SharpCap log. SharpCap (latest versions) do save a 'Stacklog.csv' file that contains info about each frame and whether it was used in the stack.

Clearing the stack just clears the data in SharpCap's memory to enable a new stack to start - it does not (and is not intended to) delete any files on disk that have already been saved. Consider it a 'start new stack' button.

If you are encountering file overwrite problems, it's usually related to custom filename settings that do not include the time of day in the folder name or base filename - that means that if you capture the same target name twice on the same day, the same filenames are generated. If your SharpCap 4 is up-to-date then the filename settings page will warn you about this problem and help you to fix it.

cheers,

Robin

Hi, thanks for the comprehensive answers. With respect to the start/stop/ problem, I think I can live with the present status, especially since you mentioned significant complexity, if it is changed.

Due to your wording "SharpCap will scale the live stacking data automatically...." I have learned that the difference in pixel readout between stack and individual frames is not due to a commanding error by me but due to a planned SharpCap operation. This removes my doubts on the correctness of the stack action as commanded by me.

Some of your wording refers to the "latest version of SharpCap". My version is v.4.0.9538, 64 bit, that is identical to what you show in https://www.sharpcap.co.uk/sharpcap/downloads "Latest Version". Nevertheless, I commanded a new download. On a popup window there was a choice where I selected "repair" (I remember I could have chosen "uninstall" instead). After the following actions Sharpcap looks as before, in "About SharpCap" I find the date 23.01.2023. I have to assume that I cannot download a younger version, is this correct? If not, how should I download this possibly younger version? My question is driven by yours words "replay" (in connection with the folder monitor camera) and "Stacklog.csv". I have not found anywhere in the SharpCap controls the word "replay" and the Windows search routine (in the file manager) did not find Stacklog.csv. Do you refer in your answers to v.4.0.9538 or to 4.1 Beta?

With thanks in advance, Albrecht

Hi,

the very very very latest versions of SharpCap can now be found on the SharpCap 4.1 beta download page - https://www.sharpcap.co.uk/sharpcap/sha ... p-4-1-beta . Right now, I am only updating SharpCap 4.0 for serious bugs and manufacturer SDK updates to support new camera models.

I suspect that the stacklog.csv may be a SharpCap 4.1 feature - I'm afraid I have been working on 4.1 for some time now and have lost track a bit of what is new in 4.1 and what made it into SharpCpa 4.0

For the replay button, this is in the play/pause/rewind control group for the folder monitor camera - I have highlighted it below
cheers,

Robin