Page 1 of 1
Processing mono
Posted: Wed Sep 07, 2016 5:57 pm
by ecuador
So, I've been happy with processing my DSLR images with ST and I think I know the basics reasonably well, so when I tried using my mono planetary camera and a reducer with a deep space target as a test, I thought I'd do similar processing in ST to see what I can get. I am not happy with the result, I can't seem to get rid of nearly as much noise as I can with DSLR images, but before declaring that my test shows that it is not a worthwhile alternative method to my DSLR, perhaps you guys could take a look in case I just don't know how to process a mono image?
Don't worry about the stars not looking good, the SCT needed collimation but I skipped it since I wanted to do the test before it gets cloudy and stars are a little "comet-ey", so I am interested more in noise handling. It is a stack of 500/1600 4sec exposures with flat/dark/bias calibration:
https://drive.google.com/open?id=0B1c3j ... zF3VXByWUk
Example processing that doesn't look that great to me:
https://drive.google.com/open?id=0B1c3j ... zdFRzFlSFU
Notice that there is some vertical banding as well, which the banding module can't deal with. With DSLR vertical banding that module always helped...
TIA!
Re: Processing mono
Posted: Sun Sep 18, 2016 5:15 am
by admin
The problem with many (not all) cameras intended for planetary imaging, is that they perform onboard processing.
It appears that this camera is no exception - at the very least the image appears to have been stretched. StarTools can attempt to reverse this stretching when you load the image though.
Without knowing how you stacked the frames or what the source is (TIFF, video, FITS, JPEG), it's also hard to say whether the noise (which is visible in the stack without any processing) is due to low bit-depth quantization or something else.
Whatever the case, the reason why the result isn't that great is because - unfortunately - the data isn't that great...
Re: Processing mono
Posted: Sun Sep 18, 2016 8:40 am
by Guy
Hi,
I'm new to analysing images myself - so I may be wrong here - but I looked at the stacked TIF file and I noticed the following:
i) A 4 second exposure is very short time for a sub-frame of a faint DSO - so it may be that you just aren't capturing enough light in each sub-frame to get a good signal-to-noise ratio no matter how many images are stacked. It may be that increasing the exposure time would help but I know this is a planetary camera so it may be at its limit. I would guess this is the main issue.
ii) The image histogram looks odd (see below) - it shows that there is a main background threshold of about 9400 (of 65535) which seems very high to me.
-
- Histogram of stacked image
- histogram1.jpg (32.72 KiB) Viewed 4259 times
To my mind this reduces the dynamic range available and, depending on how it was caused, may be masking detail. Is it possible that something happened in the stacking process to cause this? This may be an effect of the stretching Ivo refers to.
Guy
Re: Processing mono
Posted: Sun Sep 18, 2016 6:03 pm
by ecuador
The specifics are that it is a QHY5L-II mono, I used Firecapture at 16bit mode, gain set to 60, saving in SER. I tried two targets as a test, this one is the one with the most exposures, but DSS did not recognize enough stars (even at very low threshold), it was too dark, so I calibrated through PIPP and set a 3x gain, and DSS then could see stars and did only the stacking. So the 3x additional gain would be I guess the cause for this offset. The smaller set with a brighter target got processed through DSS, but did not have less noise (less frames).
So, I just wanted to make sure I am not doing something wrong on StarTools and you guys seem to confirm that.
Perhaps I'll give one more go with 10sec exposures, but it seems the QHY is better to stay on planets
One more reason I wanted to try it is because I am thinking of getting a QHY Cold CMOS for deep space and though I'd get a feel of the differences in acquiring and processing with a mono CMOS, but I guess the the un-cooled cmos can't really simulate the experience...