15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
This is my first post here and I would like to highlight the great quality of this software.
I use a cooled QHY178M camera. This camera, like others, is affected by a large amp-glow.
Before posting here, I read all the topics dealing with amp-glow including the recent one on the IMX183. I also processed the same subs with PixInsight. There is no amp-glow left on the PixInsight processing. All subs were taken at the same temperature (-20°C) as well as at the same gain (5) and offset (250).
Although I use "Adaptative pedestal/reduce amp-glow" and BPM, there is still a residual amp-glow that does not allow for quality integration.
I have posted 5 views of each DOF and light in a dropbox
I am finishing this post in order to open another one allowing the insertion of images and link
First of all sorry for your trouble with the forum, I think we need to make it more clear that when starting, links are removed automatically. This is a measure to avoid spam.
Since you already took many of the options there are to reduce this, I think we have to wait for an answer from Mabula on this (@mabula-admin), he's back from a holiday next week.
My friend who own QHY10 told me that his ccd never has much amp grow like mine when he used with another astro-processing application. However, after I used longer exposure from 300s to 600s ,the amp grow was much better. It was quite contrast with my first hypothesis on too long exposure was the cause of it.
I have made progress in solving my problem. The cause of the problem seems to be bias. If we remove the bias from the treatment, the ampglow disappears
For the sake of awareness, I'm going to do a new batch of bias acquisition.
by making comparisons with the process I use under PixInsight, I think I have identified the cause of the problem. It seems that there is a clipping when generating the MasterDark. I got the confirmation by subtracting a small offset (-100) from the MasterBias before starting the calibration. Under PixInsight, this corresponds to the Pedestal during calibration The ampglow has completely disappeared
I am looking at your data now, first thing that I notice is the the bias frames and dark frames are not consistent/compatible technically. The resulting Dark Master has a lower median/mean value than the MasterBias which should never occur, since a dark normally is the bias + dark current/amp glow signals.
MasterBias has
HDU1 - MEAN = ' 1,00E+03' / mean of channel HDU1 - MED = ' 1,00E+03' / median of channel
MasterDark has
HDU1 - MEAN = ' 9,91E+02' / mean of channel HDU1 - MED = ' 9,88E+02' / median of channel
This is not good and either indicates a camera issue or that the data was captured with a different offset. I do see that gain values are the same.
Do you have control over the cmos offset in your camera?( I can't find a reference to sensor offset in the metadata.) If not, then this issue should at least be reported to QHY I think.
Metadata of the masters:
FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jan 29 13:02:17 CET 2019 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 3056 / size of the n'th axis HDU1 - NAXIS2 = 2048 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 1.0 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2019-01-29T12:03:40' / creation date of MasterBias HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.071 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'MasterBias' / master bias frame HDU1 - INSTRUME= 'QHYCCD-Cameras-Capture' / instrument name HDU1 - CFAIMAGE= 'no ' / Color Filter Array pattern HDU1 - GAIN = 5.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 0.001 / exposure time (s) HDU1 - MEAN = ' 1,00E+03' / mean of channel HDU1 - MED = ' 1,00E+03' / median of channel HDU1 - SIGMA = ' 6,74E+00' / standard deviation of channel HDU1 - NOISE = ' 6,47E+00' / MRS gaussian noise estimate of channel HDU1 - NUMFRAME= 5 / # number of frames used in MasterBias creation HDU1 - END
FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Tue Jan 29 13:02:17 CET 2019 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 3056 / size of the n'th axis HDU1 - NAXIS2 = 2048 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 1.0 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2019-01-29T12:03:50' / creation date of MasterDark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.071 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'MasterDark' / master dark frame HDU1 - INSTRUME= 'QHYCCD-Cameras-Capture' / instrument name HDU1 - CFAIMAGE= 'no ' / Color Filter Array pattern HDU1 - GAIN = 5.0 / gain or ISO depending on instrument HDU1 - EXPTIME = 300.0 / exposure time (s) HDU1 - MEAN = ' 9,91E+02' / mean of channel HDU1 - MED = ' 9,88E+02' / median of channel HDU1 - SIGMA = ' 7,93E+01' / standard deviation of channel HDU1 - NOISE = ' 9,47E+00' / MRS gaussian noise estimate of channel HDU1 - NUMFRAME= 5 / # number of frames used in MasterDark creation HDU1 - END
I will do some more analysis and testing to see if I can improve the calibration results and possibly find a solution for the bad offset values of the masters 😉
by making comparisons with the process I use under PixInsight, I think I have identified the cause of the problem. It seems that there is a clipping when generating the MasterDark. I got the confirmation by subtracting a small offset (-100) from the MasterBias before starting the calibration. Under PixInsight, this corresponds to the Pedestal during calibration The ampglow has completely disappeared
There is no clipping here when the masterdark is created, since the MasterBias is not subtracted from the darks to create the MasterDark (App will never do this, very old versions used to do it though...).
It actually is the camera that has made incompatible bias and dark frames it seems. The darks clearly have a lower offset. By subtracting a pedestal of 100 adu from the MasterBias you compensate this effect and than all goes well 😉
I think Pixinsight internally detects this and makes the compensation automatically or did you do this yourself in Pixinsight as well?
I will try to automate this in APP to see if all goes well then automatically.
It actually is the camera that has made incompatible bias and dark frames it seems. The darks clearly have a lower offset. By subtracting a pedestal of 100 adu from the MasterBias you compensate this effect and than all goes well 😉
I think Pixinsight internally detects this and makes the compensation automatically or did you do this yourself in Pixinsight as well?
I will try to automate this in APP to see if all goes well then automatically.
Mabula
PixInsight has a Pedestal field. If I set it to 0, the result is the same as APP
It actually is the camera that has made incompatible bias and dark frames it seems. The darks clearly have a lower offset. By subtracting a pedestal of 100 adu from the MasterBias you compensate this effect and than all goes well 😉
I think Pixinsight internally detects this and makes the compensation automatically or did you do this yourself in Pixinsight as well?
I will try to automate this in APP to see if all goes well then automatically.
Mabula
PixInsight has a Pedestal field. If I set it to 0, the result is the same as APP
Thanks, yes I am aware. I will try solve this in a more automatic sense. Basically the Adaptive Pedestal should solve this, I need to add a minor tweak probably for the instance when the masterbias median is higer than the MasterDark Median 😉
Thank you very much Francis for sharing this issue with your data.
You were totally right, there actually was a black clipping occuring in the calibration code which would only happen when, like in your case, the bias signal had higher values than the dark signal. Normally this would not happen, but with your particular QHY camera it certainly does and this now shows the bug. I have corrected all code for all affected calibration paths, so it should not happen again 😉
I will try to release APP 1.071 with this fix as soon as possible.
You will still need to enable the Adaptive Data Pedestal in this case to make sure no residual amp-glow remains from biased integration to the upside in the amp-glow areas.
FIXED, Calibration AMP-GLOW, a specific calibration issue was mentioned in topic : Another residual amp-glow issue, https://www.astropixelprocessor.com/community/main-forum/another-residual-amp-glow-issue/ This issue was made apparent by a specific sensor characteristic of a QHY178M camera. The median of the MasterBias had a higher value than the median of the MasterDark which caused a clipping problem in the calibration code for certain calibration paths. Not all paths were affected. Calibration with only a masterdark worked fine, but not with a Masterbias, MasterDark and Masterflat loaded. All code for all affected calibration paths have been corrected now. Data from a camera with such clear amp-glow still needs to be calibrated with the Adaptive Data Pedestal enabled to prevent skewed integration in the amp-glow areas.
Without-Adaptive-Data-Pedestal-Without-Fix
Without-Adaptive-Data-Pedestal-With-Fix
With-Adaptive-Data-Pedestal-Without-Fix
With-Adaptive-Data-Pedestal-With-Fix
Kind regards,
Mabula
This post was modified 5 years ago 2 times by Mabula-Admin
I have just checked, my solution applies to your data as well. Your data has the same issue. The MasterBias has a higher median value than the median value of the MasterDark.
APP 1.070, AMP GLOW visible at borders:
APP 1.071-beta AMP Glow is corrected
Kind regards,
Mabula
This post was modified 5 years ago by Mabula-Admin
