NGC 104 + data

[Atmos]

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 :/

Red: https://dl.dropboxusercontent.com/u/27436364/NGC%20104/Red.fit.zip
Green: https://dl.dropboxusercontent.com/u/27436364/NGC%20104/Green.fit.zip
Blue: https://dl.dropboxusercontent.com/u/27436364/NGC%20104/Blue.fit.zip
Luminance: https://dl.dropboxusercontent.com/u/27436364/NGC%20104/Luminance.fit.zip

Feel free to have some fun.

[Somnium]

Just a thought Colin, are you stretching the data before combining or just trying to combine then pushing the saturation to get the colour?

[Atmos]

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.

That is it in a nutshell

[Somnium]

i am keen to have a look at the raw data but the links just go to a page of text ... i assume these Fits are stacked with darks and flats ?

[alpal]

Yes - I'm only getting a page of text too.

I wouldn't process them unless they are stacked with darks & flats.

cheers
Allan

[RickS]

The page of text is the browser trying to display the FITS file on your screen. Right click on the link and save it to a file instead...

[Atmos]

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.

[Somnium]

the red and the green data looks like it has been clipped significantly, could be causing the issue

[LewisM]

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? :P

[LewisM]

Agreed

[Somnium]

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.

[DJT]

Do you need luminance with a globular cluster ? Try processing without it.

[Atmos]

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.

[Somnium]

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

[Atmos]

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.

http://www.iceinspace.com.au/forum/showthread.php?t=139394

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.

[alpal]

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

[Atmos]

I should have mentioned it, I am using the ASCOM driver. It starts off at 100 for gain.

[Atmos]

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?

[alpal]

OK - so are your files correct & ready to process or
did the filter not change?

[Atmos]

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.

[alpal]

I wouldn't worry too much about your levels.
Just get more data with your present settings
otherwise your stacks will not work properly
when you combine all the data.

Just make sure that filter wheel is changing.

cheers
Allan

[Atmos]

3x200 RGB should be enough to get colour, half an hour of RGB on a bright cluster should work correct?
I've done something similar, one hour of RGB on NGC 2070 and having the same issue at 200s. I know that if I push it to ~600s it will fix the problem but that is 10x my sky limited.

[SamD]

If it helps, I've just run my recent NGC104 through some star ADU counts.

If I scatter plot my blue (y) vs red (x) ADU counts I get a fair amount of spread representing the different star colours. But doing the same with the blue and red fits you uploaded look pretty much identical - so it looks like the same channel has been captured in both.

For globular clusters I set the exposure times in each channel so that the brightest stars at the centre are close to, but not over, the full well levels of the camera pixels.