Hi Robin, I presume I first uninstall SharpCap, then edit the registry so I am left with an effectively cleaned out pc, then do a fresh download and install? Here’s hoping! Ed
No need to uninstall – just make sure SharpCap is closed.
You should also consider removing the auto saved camera settings (which SharpCap uses to restore the same settings when you open the same camera again). These can be found in the folder
Got there in the end! I actually uninstalled the program, cleaned up the register with CCleaner (removed one path remnant), deleted the registry entries remaining, and deleted all Astrosharp and SharpCap entries in \AppData\Roaming\etc. I then made a fresh installation and copied in my Pro license and there it was in full RGB!
Many thanks for continuing support and ideas.
I also cannot use live stacking with my OSC camera (ASI2600MC). Ok, you can force the image display to be debayered, but this does not help for a stacked image because debayering must be done before stacking, or R,G,B pixels will be stacked on top of one another losing the bayer matrix. THe result will treat differences in R, G, and B as noise and the stacked image will be in "colour" but will appear greyscale. Is there a way to change the colourspace of folder monitored live stacking to RGB16 from MONO16, so that each image is debayered prior to going stacking, the same way as a colour camera connected to sharpcap. Otherwise, I will have to debayer the folder (with another folder monitoring program), and save to a different directory that Sharpcap would monitor. I think this is the gist of this forum topic, so any suggestions would be appreciated.
yes, you can do this - when the folder monitor camera is working with mono images (including RAW ones), the option to 'Debayer Preview' should appear just below the colour space - set this to the correct pattern for your camera and you should be OK.
Thanks for the reply. Yes I can force the preview to do a Debayer. The problem is that this only works for the screen. The debayering is not done before Live Stacking, though. What happens is, the LiveStacker will stack non-debayered images as if they were mono, FIRST. This ruins the bayer pattern - essentially stacking the colour pixels on top of one another. Then, the forced debayer for preview debayers the result (SECOND), which of course is meaningless (you actually lose all colours if you stack enough images with random dithers).
The solution would be would be to debayer the images first, and then stack. This is can be achieved by setting the colour space first. However, Sharpcap won't let me change the colour space under my Folder Monitor camera. The files were written in ASCOM, and when the FITS files are read, the camera is not recognized (it is actually called 'ASCOM Camera(1)' in the FITS header), so Sharpcap takes it upon itself to disable the ability to change the colour space.
THe camera I am actually using is a ZWO ASI2600MC. If the FITS files were written by Sharpcap, then the camera is recognized, then the colour space of RAW16 is used, as it should. However, if the FITS files were written by another program (say SGPro), then the camera is not recognized and the colour space is SET to MONO16 and the user cannot change it.
The net result of all this, is that live stacking of colour FITS files using folder monitoring can only be done if the captures were performed by Sharpcap. I think the fix for this would be simple - allow the user to change the colour space if the camera is not recognized by Sharpcap.
I hope this clarifies.
Dave
so SharpCap looks for the 'BAYERPAT' header when loading the fits file and if it finds that then it will show up as RAW16. SharpCap writes that keyword, I guess other programs may not, explaining why they may end up as MONO16.
However, setting the Debayer to FORCE XXXX still works in live stacking as far as I can tell - I removed the code that reads the BAYERPAT header as a test and ended up with MONO 16 being chosen, then I selected the right pattern and live stacked and got a colour image
Capture.JPG (191.26 KiB) Viewed 1962 times
As you can see, this was testing in 4.0 beta, but I don't recall fixing this since 3.2, so I would have thought it worked there too. If not then maybe give 4.0 beta a try
what you are seeing, is likely the residual of the bayer pattern. Yes the force debayer will debayer the pattern from the stacked image, but this bayer pattern will be somewhat corrupted. If you stack many images, the color will fade to B&W. THis is because debayering must be done before stacking, so that the colours are kept intact.
I started another post, but why can't you still select RAW16, even if the FITS keyword is missing?