SharpCap Forums

Hi forum!

Sharpcap scales output files from live stacks to consume the entire 32 bits. When using that output in many other programs that handle "unscaled" 32 bit files well, things just don't work all that well.

For example, I used Sharpcap to make a number of sub-stacks for final stacking in APP. APP cannot read these files properly, and ignored half of the data values contained in the giles. Half the dynamic range of the data is just ignored.

In PixInsight, the raw file histogram looks like this (after enabling the checkbox for floating point for GIMP): To get the histogram black point where it needs to be entails clipping about 10,000 "scaled" pixels to black. Maybe those pixels are junk, maybe it's faint detail. I'll never know, because I have to clip them all to see any detail in the highly scaled, washed out image.

I do not want to use the 16 bit stacks, they just don't have what it takes to smooth out gradients in nebulae.

Is there a way to either save stacks as un-scaled 32 bit floating point files or to "un-scale" these files to a 32bit floating point file that I can use across platforms? I'd be totally OK with having to use pixelmath or something to un-scale these files without otherwise changing the data.

Thanks
Al

(on an somewhat unrelated note, It would be EXTREMELY convenient if the "save and reset every x minutes" control on the folder monitor camera worked when enabled. I'd be using this functionality in an attempt to reduce the processing load that the sheer volume of data my C6 Hyperstar and a QHY183C camera generate.)

Hi Al,

there is an option in the saving settings to make the 32 bit FITS files be saved in floating point format, which should hopefully fix your issues. In integer form they are deliberately scaled up to use nearly the full range to avoid the images appearing black when loaded into viewing software.

I must admit that I have never tried the auto save and reset with the folder monitor camera, but I do wonder if it might work. It does not use time from the system clock to trigger the reset, instead it uses the Total Exposure shown in the live stack summary. If the files you are stacking are in FITS format then the exposure should get read from the FITS file along with the image data and the Total Exposure should update correctly, triggering the reset when appropriate.

cheers,

Robin

Thanks Robin

Regarding the folder monitor camera reset:

Fits files are being stacked. The frame count and total exposure time increment in the live stacking window by the exposure time in the fits header. No problem there! However, the stack never saves or resets, even though the "save and reset" checkbox is ticked. This does work when I use SharpCap to acquire the frames directly from a camera.

I prefer not to use SharpCap for long exposure data acquisition with my QHY183 cameras because the "amp glow suppression" functionality in the SDK does not appear to have been implemented. My dark and light frames captured with SharpCap display significantly more amp glow than frames captured in NINA or CCDCiel.

What I'm trying to accomplish is:
to use NINA to manage the data capture. <----- on the remote mount computer
to use SharpCap live stacking on my processing laptop to monitor the files as they are saved on the mount computer,
-Filter on FWHM and brightness.
-Calibrate and stack 16 frames - for use as a substack in APP/PI (Just an OCD thing about quadrupling initial SNR)
-Save stacked frames in a designated folder on the network (Until I'm comfortable saving only substacks).

WHY?
Too much data being generated by C6 Hyperstar and QHY183 camera. I want to use existing software to deal with this.
-I do not have the capacity to store and process the 1000 raw subs that this scope/camera combination generates in a night. (Will throw money at this eventually)
-Substacks would reduce data storage needs by about 70%
-Stacking substacks in APP allows me to utilize some of the batch processes/algorithms to finish clipping those satellite trails, etc much, much quicker because of the significant reduction in frames that need to be processed.

I'm trying to use PixInsight statistics and some pixelmath to document the differences in the final stack between three options:
-Batch stack in APP or PI,
-live stack subframes with SharpCap for later batch stacking in PI or APP,
-Stack everything with SharpCap.

Without an unscaled, linear output file, I cannot complete my testing. Neither PI nor APP like any of the 32 bit files I've been getting from ShrpCap.

Regarding 32bit file formats:

In the picture attached to the first post, this is what a 32bit floating point livestacked file looks like when I open it in PixInsight. The histogram peak is just under 50%. When the "compatible with GIMP" checkbox is not checked, the 32bit integer file has a histogram peak at what looks like exactly 50%.

Would it help if I made a sample file of each 32 bit output format available for examination? They are about 225MB each.

Used version 4.0968 (64bit) to generate the output files that I've been discussing in this thread, but the same issues existed with the prior version I'd used.

Anyway, thanks very much for your response. I didn't want to write an essay in the first post, but thought I'd better add some context about what I'm trying to accomplish with your software into the conversation.

Clear Skies
Al

Hi Al,

right, I see the problem with the save and reset - there was a specific bit of code saying 'don't do this for the folder monitor camera'. It obviously seemed like a good idea at the time when I hadn't imagined your sort of use case. I can remove that easily enough.

For the output files I will have a play to see what I see in similar circumstances (I can create some easily enough to do initial tests with). I'll come back to you once I have checked it out fully.

cheers,

Robin

Hi Al,

in my testing, the mid grey image background that you posted in the first screenshot is typical of loading the 32 bit integer FITS files from SharpCap into PixInsight, and the problem does not occur with the 32 bit floating point FITS images.

To check for a particular existing image, open the FITS file in FITSLiberator and look at the Image Headers. If the BITPIX header is 32 then it is an integer FITS. If the BITPIX is -32 then it is floating point.

The issue with the grey background is (in my opinion) a problem with the way PixInsight interprets the 32 bit integer FITS files. These files contained signed 32 bit data that can go from -2,147,483,648 up to +2,147,483,647. SharpCap uses only the range from zero upwards (unless you have something odd like your dark is brighter than your light frames). Pixinsight seems to want to interpret the zero value as 50% brightness, which is incorrect - if that was the intended result then it is possible to use the FITS BZERO header to specify an offset. I can't find any other software that does the same mid-grey interpretation of these files (AstroArt, DSS, etc)

If you want to use the integer files in PixInsight, use a PixelMath to subtract 0.5 from pixel values to get rid of the background grey.

If you do have a true floating point FITS file from SharpCap that shows the mid grey problem then please share it and I will investigate further - I can't make this happen in my testing.

Hope this helps,

Robin

Thank you very much on all counts.

If you happen to remove that bit of code blocking the auto save and reset in the next release, I'd really appreciate it!

I'm wondering if I just didn't commit the "save as floating point" setting properly, or maybe I just needed to restart SharpCap after making the change. I processed another stack this evening, and the 32 bit floating point data was saved in a linear state. Most likely user error on my part, then.

The support here is amazing!.

Thanks
Al

Hi Al,

glad that turned out to be the solution - I did make the change to enable the reset on the folder monitor camera and that change should be in next week's update.

I have to say that support is much easier when people take the time to put together a really good report about what is going on and what they have tried - like you did. The tricky ones are the ones that just say 'XYZ didn't work' without any background info like what camera, what settings, what version of SharpCap, etc.

cheers,

Robin