last night while waiting for The Moon to clear my viewpoint I thought I'd try out some Ha imaging but I am not very happy with the resulting integration.
I understand that only 3 Light subs is not going to give me the best or anywhere near the best result but the problems with this stack is more than that & I could do with some guidance.
Also I know that using NB filters with a colour camera will not let them shine to their full ability.
This was my 1st attempt to image using my NB filters & aside from the expected vignette on the Lights, individually they seemed to look OK.
I was also using Dither for the 1st time in BYEOS between each Light capture.
On previous occasions during imaging I had not used Dither and noticed resulting stack noise was bad and read that Dither will help alleviate this.
Here is the integration:
Here is my setup:-
EQUIPMENT
Celestron CPC9.25
Celestron f/6.3 Focal Reducer
Canon EOS750D modded
Baader 48mm H-alpha 7nm filter
CAPTURE SOFTWARE
BYEOS
PHD2
DATA
LIGHTS - 3 x 1200s @ ISO800
DARKS - 5 x 1200s @ ISO800
FLATS - 10 x 2.5s @ ISO800 (captured with lightpanel)
MB - 100 x ISO800
BPM
To me the integration shows clearly that the vignetting has been over-corrected but the Flats that I have taken, I have made in the usual way that I do when capturing non NB subs.
The image also shows horizontal banding and I have a strong suspicion that this is from my lightpanel used in Flats capture.
Also the resulting image is very, very noisy with a lot of detail lost compared to the captured Lights.
OK, I just ran my data again but using a new set of Bias (70 frames) to create a new MB & BPM. The result was exactly as previously with the Flat vignette appearing white/pale.
Here is a RAW Light Frame:
Here is that same frame once Calibrated:
Here is the resulting Integration after using a new MB & BPM:
I've spent most of the day today attempting to get to the bottom of this issue but found no resolution.
Looking at my Flats as Linear with DPP off & Black Point at 0, my ISO800 2.5s frames are the max I can get before hitting the right side of the histogram in APP.
Just for the sake of it I tried other iterations with Flats sets of 1.3, 1.6, 2.0, 3.2 & 4.0 seconds.
Anything up to and including 3.2s basically looked identical in the final Integration but 4s was decidedly worse with far more negative vignette showing.
I am now completely stumped and cannot progress any further using NB filters until I get this somehow resolved.
@mabula-admin if you could shed some light on my issue please.
So this is with OSC data, right, what happens if you process the data with the Ha-debayer algorithm in 0) Raw/FITS ?
This should leave you with the monochrome calibrated Ha-data.
Your flats should have been shot with the same optical train, so with your H-alpha filter, right?
Then you can't expect the Green and Blue channels to be of any good I think after flat-field calibration. These channels will get no light when you create the flats due to the H-a filter. So you should disregard anything happening in the green and blue channels 😉
Your data does not contain either bias or flat darks to subtract the bias pedestal from the flats... this is critical, so that should explain your problem.
APP will warn you that something is wrong with flat-field calibration 😉 due to missing bias/darkflats.
At least add some bias with the same gain/iso as the flats 😉
To me the integration shows clearly that the vignetting has been over-corrected but the Flats that I have taken, I have made in the usual way that I do when capturing non NB subs.
The image also shows horizontal banding and I have a strong suspicion that this is from my lightpanel used in Flats capture.
Also the resulting image is very, very noisy with a lot of detail lost compared to the captured Lights.
Could this all be down to dithering?
No, any dither will only improve the integration results and will never cause the problem that you face here. This is a fundamental calibration issue due to missing calibration data to be able to subtract the bias pedestal from the flats... 😉 Only darks for the lights is never sufficient to get proper (read optimal) flat-field correction.
This is what I get with the H-alpha debayer algorithm and missing bias/darkflats... it is not bad, but with at least bias it will certainly be better. The vignetting is not totally corrected :
I have had a look at your flats as well. Please look at the resulting masterflat in both RGB and H-a debayer:
It does not look like perfect flats at first glance, the bottom illumination might be bad, but perhaps this is the mirror chamber in your canon dslr, it usually looks differently though, only a small darker border at the bottom is usually seen, so there might be an issue with the flats as well.
First I double checked the DATA set that I uploaded to DropBox, there is a directory named 'Other Calibration Files' in there are the MB & BPM.
Anyway, I ran through my HorseHead data just to stage '2', using Ha Alogorithm from stage '0' and it's great. That is all that I was missing, here is a screen shot:
OK, I just tried to stack my Whale Galaxy data and also my HorseHead data & got this screen on both occasions, they both did stack before I used the Ha Algorithm option:
I think that I have tried all variations of the options listed in the message box to get the Lights to Reference but it keeps failing, any ideas?
OK, I just tried to stack my Whale Galaxy data and also my HorseHead data & got this screen on both occasions, they both did stack before I used the Ha Algorithm option:
I think that I have tried all variations of the options listed in the message box to get the Lights to Reference but it keeps failing, any ideas?
both sets of data integrate perfectly without any errors when using the default algorithm ‘adaptive airy disc’ but when I try to integrate either of the two datasets after using the ‘Hydrogen Alpha’ algorithm, they each fail on step 4 ‘Reference’ and show the error message as I’ve posted.
Oddly the star count on the Horsehead subs for instance show as more than 200 after upping the level in step 3.
I have found the issue with your data yesterday. Another APP user, @andersstange, also experienced difficulties with star analysis and registration and his issue was directly related. It turned out that hot pixels were detected as stars and not the stars. To solve this issue, I have added a new algorithm in the star analysis module that is capable of better discrimination between hot pixels and stars 😉
So the good news is that APP 1.072 will have the solution to this problem. All the testdata that I have including the data of you both work now robustly (without problems).
FIXED, IMPROVED, STAR ANALYSIS, star detection has been further improved by adding an algorithm that better discrimates between hot pixels/small FWHM stars/big FWHM stars. Some users experienced difficulties because hot pixels were detected as stars. The added algorithm studies the star size/FWHM distribution initially found. The details of the distribution are very usefull to make the discrimination between hot pixels/small FWHM stars/big FWHM stars.
I will try to release APP 1.072 within 1-2 days now 😉
I have found the issue with your data yesterday. Another APP user, @andersstange, also experienced difficulties with star analysis and registration and his issue was directly related. It turned out that hot pixels were detected as stars and not the stars. To solve this issue, I have added a new algorithm in the star analysis module that is capable of better discrimination between hot pixels and stars 😉
So the good news is that APP 1.072 will have the solution to this problem. All the testdata that I have including the data of you both work now robustly (without problems).
FIXED, IMPROVED, STAR ANALYSIS, star detection has been further improved by adding an algorithm that better discrimates between hot pixels/small FWHM stars/big FWHM stars. Some users experienced difficulties because hot pixels were detected as stars. The added algorithm studies the star size/FWHM distribution initially found. The details of the distribution are very usefull to make the discrimination between hot pixels/small FWHM stars/big FWHM stars.
I will try to release APP 1.072 within 1-2 days now 😉
I have just downloaded APP v1.072 and this did indeed solve the Registration issue, thanks for that fix.
I still seem to be having major issues with my Flats though and I do not know whether this is due to my use of a H-alpha NB filter on a colour DSLR.
I will try to explain in detail.
Firstly here is an integration of 2 sessions totaling 7 x 1200s ISO800 Light frames of B33 & calibrated using 10 x 1200s ISO800 Darks, 20 x 2.5s ISO800 Flats, 100 x ISO800 MB plus BPM with astro modded DSLR through Baader 7nm H-alpha filter.
Even after cropping away the 2 session stacking edges I am seeing a lot of noise where the vignette normally is.
For a more obvious & in-depth look here is an image in H-alpha of the Whale Galaxy using the same equipment as I did for my B33 capture, although this is only over a single session
Please forgive the overall quality as this is an ongoing project & currently only consists of 4 x 900s ISO800 Light frames & calibrated using 8 x 900s ISO800 Dark, 10 x 2.5s ISO800 Flats, 100 x ISO800 MB plus BPM
It is very obvious in this image to see the light areas where the vignette is located, particularly along the bottom edge as well as a curved structure at the right hand edge.
I am using the H-alpha algorithm in 'TAB 0' for these Integrations but below I will show how a single Flat & the Master Flat appear in both H-alpha & normal Airy Disc in APP.
SINGLE FLAT Airy Disc
SINGLE FLAT H-alpha
MASTER FLAT Airy Disc
MASTER FLAT H-alpha
In my single Flat (Airy Disc) the RED channel is already showing that a small part of the data is at the right hand edge of the histogram, so it would be impossible for me capture a longer exposure and the (H-alpha) version of the same Flat shows a very good histogram.
Now this is a different story with the Master Flat as this is quite obviously showing clipping to the left hand side of the histogram in both (Airy Disc) & (H-alpha) versions but in a very small section of the RED channel for the (Airy Disc) version of the Master Flat, this is touching the right hand side of the histogram.
I cannot see a way to rectify my Flats issue.
I have read in various forums that although the vignette been light seems like it is over correcting, it is actually the case that Flat frames are under exposed which causes the lightness.
I only seem to be seeing this problem since attempting H-alpha narrowband imaging using my DSLR. I am pretty sure that I have not seen this when capturing regular broadband images, especially since Mabula helped me out a while ago understanding capturing Flats correctly.
I capture my Flats using a light panel with my optical train and focus left in exactly the same position as when capturing my Light frames.
The excessive looking vignette at the bottom of my Flats is the shadow of the prism of my OAG.
All seemed to be going OK, I loaded all my files and it Integrated & I could easily load the Linear Integration but as soon as I changed the viewer drop-down option to calibrated I got this error message:
I then decided to just choose the 'Split Channels' option in the Calibration Tab & save the calibrated frames, that's when this error appeared:
So I went back to the drawing board and ran all my data once again with the algorithm set as Hydrogen-Alpha, here is the result and I have purposely not cropped the image, leaving the stacking artifacts intact:
Now I cleared everything out of APP, set the algorithm to Adaptive Airy Disc, loaded all my files ran calibration, chose the 'Split Channels' option and saved the calibrated frames.
Then I once again cleared all data from APP and only loaded the RED channel frames that were split and continued to Integration with just these, here is the result:
Right, straight away the output from using the HA algorithm is brighter but it is also a whole lot noisier especially around the central bottom area of the image where the vast majority of my vignette/prism shadow appears.
In my single Flat (Airy Disc) the RED channel is already showing that a small part of the data is at the right hand edge of the histogram, so it would be impossible for me capture a longer exposure and the (H-alpha) version of the same Flat shows a very good histogram.
Now this is a different story with the Master Flat as this is quite obviously showing clipping to the left hand side of the histogram in both (Airy Disc) & (H-alpha) versions but in a very small section of the RED channel for the (Airy Disc) version of the Master Flat, this is touching the right hand side of the histogram.
No, this conclusion is not correct. The clipping that you see in the histogram of the masterflat is actually the dslr's sensor raw border 😉
APP uses the whole sensor to calibrate the data. After calibration these raw borders are always cropped away from the calibrated light frame. So if you look at the MasterFlat, you actually see the whole sensor, please check the image dimensions and zoom in on the raw borders, you can see these in the masters.
I think there should be nothing wrong here, the red channel looks well illuminated and green and blue are 100% irrelevant since you are using a H-alpha filter.
All seemed to be going OK, I loaded all my files and it Integrated & I could easily load the Linear Integration but as soon as I changed the viewer drop-down option to calibrated I got this error message:
I then decided to just choose the 'Split Channels' option in the Calibration Tab & save the calibrated frames, that's when this error appeared:
The Super Pixel debayer algorithm was broken, it is fixed in APP 1.073 😉
To be clear, I can think of no good reason to process data with the Super Pixel algorithm. It will have a serious bad effect on registration precision and you throw away half of your resolution. Using Super Pixel and then extracting the red channel is really an inferior processing workflow compared to the H-a debayer algorithm.
Having said this, whatever demosaic algorithm you choose, it has 0% influence on data calibration, at least in APP. Calibration is done on the Bayer CFA pixels before debayering/demosaicing is done 😉
So I went back to the drawing board and ran all my data once again with the algorithm set as Hydrogen-Alpha, here is the result and I have purposely not cropped the image, leaving the stacking artifacts intact:
Now I cleared everything out of APP, set the algorithm to Adaptive Airy Disc, loaded all my files ran calibration, chose the 'Split Channels' option and saved the calibrated frames.
Then I once again cleared all data from APP and only loaded the RED channel frames that were split and continued to Integration with just these, here is the result:
Right, straight away the output from using the HA algorithm is brighter but it is also a whole lot noisier especially around the central bottom area of the image where the vast majority of my vignette/prism shadow appears.
Could be my eyes deceiving me though.
Kirk
So if you see differences between Adaptive Airy Disc and H-alpha debayer it has to do with the actual stretching of the data. The H-a debayered data is monochrome and thus the stretch parameters will only be based on this single channel. On the Adaptive Airy disc data, the stretch parameters are based on 3 channels, the red channel with your H-a data and 2 channels (G,B) with mostly noise, this has the effect that the stretch parameters are reduced, which might give you the impression that there is less noise, where in fact, there is more in 2 channels which you don't need I think. So you need to take into account how the data is stretched.
Please let me know if this is clear 😉
I would really think that your horsehead result is a good start and I am sure that If you add more data it will improve significantly! You have only 7 frames of 1200 seconds with a 7nm filter in front of a bayer cfa sensor, really, what you have now, is not bad at all to start with I would think. Realise that with only 7nm, very little light is reaching the sensor, off course the H-alpha nebula will get better contrast when compared to a shooting with a broader filter, but the remaining sky background will still be very black and will be dominated by noise. More data and perhaps even longer exposures will surely help.
Cheers,
Mabula
This post was modified 4 years ago by Mabula-Admin
)
