I am guessing that this is an issue with my processing more than data acquisition.
This has been taken with my 130mm refractor, QHY9 and LRGB.
3xRGB, 9xL
Each sub is 200s so it is totally 1 hour of data. I am having serious issues dragging any colour from the stars without introducing HUGE amounts of noise. Basically I am pushing the saturation really hard just to get anything other than white.
So I thought it could be good to put up the data files and see what others may be able to achieve, hopefully something that makes mine look like the beginner processor that I am
What I am personally finding at the moment is that I need to be pushing exposure times towards the 10m (600s) mark just to be able to manipulate the colours without introducing more problems :/
My typical process in PI has been to combine the RGB, do the Background and Colour Calibration and then put the RGB through the Histogram Transformation.
Then I start working on the Luminance, do a deconvolution and then do Transform this.
Then I do a LRGB combine to do the saturation, the Chrominance Reduction works really well. Then I go and put it further in the Curves Transformation because it is still looking really bland.
Everything has been Biased, Darked and Flattened. Currently uploading them as .zips so that no one has to worry about the .fits files just being as text. Will put up the links when they finish uploading.
EDIT: I have changed the links in the original posts.
Silly question, but are you SURE the filter wheel worked?
I just ran the lot through CCDStack. All I got was a tinge of purplish blue when stretched excessively after colour creation.
Are you SURE you didn't just shoot BLUE filter?
i was just about to ask this question. a while back i was struggling to get colour in my stars and couldn't do it no matter what i did, turns out that the filter wheel wasn't rotating.
I assume that the filter wheel worked. When I have done it in PI I have been able to get tiny tinges of blue in what I am guessing is the blue stragglers. I have been able to get very VERY small amounts from excessive saturation.
When I did these files they were saved as 32-bit but I have subsequently uploaded them as 16-bit just in case some software packed don't like the 32-bit that comes from PI. I know that MaxIM DL and PI don't like sharing their 32-bit files.
I assume that the filter wheel worked. When I have done it in PI I have been able to get tiny tinges of blue in what I am guessing is the blue stragglers. I have been able to get very VERY small amounts from excessive saturation.
When I did these files they were saved as 32-bit but I have subsequently uploaded them as 16-bit just in case some software packed don't like the 32-bit that comes from PI. I know that MaxIM DL and PI don't like sharing their 32-bit files.
just from the looks of the raw data it really looks as though the images were all taken with the same filter , try taking a pic of the helix nebula , the 3 images should look very different
These are some images that I took the following evening. This evening was my rest to see whether exposure times several times longer would yield better results. Much easier to process and didn't require too much pushing.
Here is another few of M42, the first of which I ran into similar issues as I am having with now, ie. having to push the saturation pretty hard. The colour calibration also didn't go well at first as it noted by the golden parts of the nebula. My second attempt with longer exposures (200 vs 60) yielded much better results... Even if the diagonal introduces some artefacts as Lewis pointed out.
I have attempted NGC 104 & NGC 2070 on two occasions so far. Firstly with subs of 60s unguided and secondly as 200s. Until now I have just assumed that it was my inept process ice ability doing it, now I am thinking that I may have to tweak the camera settings.
Using a QHY9 with the gain set to 126 and offset at 102. The "correct" value for this camera should be a gain of 121 but it was suggested to add ~5% to remove some of the non linear portion of the camera as it approaches saturation, was a suggestion in a manual for calibrating a QHY.
These are some images that I took the following evening. This evening was my rest to see whether exposure times several times longer would yield better results. Much easier to process and didn't require too much pushing.
Here is another few of M42, the first of which I ran into similar issues as I am having with now, ie. having to push the saturation pretty hard. The colour calibration also didn't go well at first as it noted by the golden parts of the nebula. My second attempt with longer exposures (200 vs 60) yielded much better results... Even if the diagonal introduces some artefacts as Lewis pointed out.
I have attempted NGC 104 & NGC 2070 on two occasions so far. Firstly with subs of 60s unguided and secondly as 200s. Until now I have just assumed that it was my inept process ice ability doing it, now I am thinking that I may have to tweak the camera settings.
Using a QHY9 with the gain set to 126 and offset at 102. The "correct" value for this camera should be a gain of 121 but it was suggested to add ~5% to remove some of the non linear portion of the camera as it approaches saturation, was a suggestion in a manual for calibrating a QHY.
You can't get a gain of 126 with the QHY9m camera.
The highest gain is 68 ( I think )
I've been running mine at a gain of 5 which is not allowing me to reach the full 65536 16 bit well depth.
I should be running around 10 to 12 to achieve that.
I use an offset of 101 but 112 would be better.
Use Ezycap when you use a QHY9 & look at the subframes as they download.
You'll see that RGB frames will all look different.
You'll also get a message on the screen as the wheel changes & a LED will light up on the top of the filter wheel.
You can't get a gain of 126 with the QHY9m camera.
The highest gain is 68 ( I think )
I've been running mine at a gain of 5 which is not allowing me to reach the full 65536 16 bit well depth.
I should be running around 10 to 12 to achieve that.
I use an offset of 101 but 112 would be better.
Use Ezycap when you use a QHY9 & look at the subframes as they download.
You'll see that RGB frames will all look different.
You'll also get a message on the screen as the wheel changes & a LED will light up on the top of the filter wheel.
cheers
Allan
I should have mentioned it, I am using the ASCOM driver. It starts off at 100 for gain.
Okay, done a little bit of testing. As it was mentioned that the back end of the histogram was being clipped I tried processing some of the raw data files, had the thought while I was at work today that it may have been caused by the calibration files doing something they're not supposed to do.
Hasn't made any difference so I am assuming that the problem is at the point of taking the images.
I probably should have checked and not gone from memory, I have Gain at 26% and Offset at 102 when at normal readout speed. When running at high readout I run at Offset of 75 with the same gain. Guess I'll have to do some more testing, maybe I am clipping it a bit :/
EDIT:
Decided to mathematically calculate the what number should be. At a gain of 26% I have an e/ADU of 0.491. With a full well of ~25,500 and a full ADU of 65535 I should have a gain of 0.3891. Ultimately this corresponds to a gain of 20.6%. I originally calculated 21% and then added 5% to take off the non-linear aspect of the CCD.
So, from what I can tell the best I can do is drop the Gain down to 21% which will increase the dynamic range a bit but it shouldn't be having any effect on the data being obtained. Back to where I started again.
Okay, done a little bit of testing. As it was mentioned that the back end of the histogram was being clipped I tried processing some of the raw data files, had the thought while I was at work today that it may have been caused by the calibration files doing something they're not supposed to do.
Hasn't made any difference so I am assuming that the problem is at the point of taking the images.
I probably should have checked and not gone from memory, I have Gain at 26% and Offset at 102 when at normal readout speed. When running at high readout I run at Offset of 75 with the same gain. Guess I'll have to do some more testing, maybe I am clipping it a bit :/
EDIT:
Decided to mathematically calculate the what number should be. At a gain of 26% I have an e/ADU of 0.491. With a full well of ~25,500 and a full ADU of 65535 I should have a gain of 0.3891. Ultimately this corresponds to a gain of 20.6%. I originally calculated 21% and then added 5% to take off the non-linear aspect of the CCD.
So, from what I can tell the best I can do is drop the Gain down to 21% which will increase the dynamic range a bit but it shouldn't be having any effect on the data being obtained. Back to where I started again.
Any thoughts anyone?
OK - so are your files correct & ready to process or
did the filter not change?
OK - so are your files correct & ready to process or
did the filter not change?
I cannot think of a reason why the filter wheel wouldn't have moved. I wasn't watching it at the time but it was working at other times, did the flat fields later on without any problems. I cannot think of a reason why the filter wheel wouldn't have been working.
The files that are up have been fully calibrated and aligned. Really not sure what is going on. Tomorrow I am going to start afresh, drop the Gain from 26 back to 21 and then recalculate the Offset, might try 105 or something. If 102 is causing a clip of the lower end of the files then maybe it just needs to be increased. At 102 I am getting ~550 ADU (levels on the bias) so not quite sure.
