19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.
31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!
Frustrating times trying to process NGC6888 LRGB image files
Hi Vincent, Mabula,
I have been collecting LRGB data on Crescent Nebula as best I can during short summer nights and variable UK weather.
I think my LRGBHa stacks individually look reasonably good but despite numerous attempts I am still unable to get a result from Calibrate Star Colors that looks anything like the result I anticipate. I can get an image file from RGB combine that looks about right but after running CSC I always get a result that is either too Blue or too Magenta to be able to correct with the scope of corrections available in CSC.
By saving an RGB Combine result in TIF format and processing this file through Adobe Camera RAW / Photoshop I am able to get a result, see below, which is I think close to the best I can achieve - though still not sure about the Red/Magenta balance and Blue stars are not showing much Blue! I like the effect of the hugely energetic nebula buried in the clouds and filaments of dust and gas.
I am hoping that if I forward my LRGB stacks you might find time to give these a quick check and possibly also advise if you can get a result from RGB combine that does not go haywire in CSC.
I will add that while imaging this target last year I had problems because at some point while imaging my filter wheel disconnected and I had subs that were incorrectly labelled and I did not immediately spot that this had happened. I have carefully monitored for any reoccurrence of this problem and I am very confident that this year my stacks are 'clean'. This being so I am assuming that I am simply missing something in RGB combine (or just too heavy handed with the sliders) to get the suitable result for processing with CSC.
Sure, just upload the relevant files (including calibration subs and preferably in their raw format) to the APP server: server, log in with username and password: appuser and please create a folder with your name first. I'll then try to check the data within a week. Please send me a selection of the raw subs, not the stacks.
I have made a mistake logging onto your server - now getting a message that my IP has been locked owing to failed logon attempts.
I thought this might clear after waiting a while but no luck so far. Do you have instructions for unblocking? Not sure if action is needed at my end or yours.
And can you also clarify the username / password that I should be using?
Uname 'appuser', Pword 'appuser'?
No worries Mike, I'll ask Mabula to unlock it. Yes, it should be appuser for both.
And it's unlocked. A lock is placed when you log in wrong 5x within 5 minutes. Be aware it's case-sensitive so all lower-case.
I've uploaded a number of files as requested. Hopefully you will not need more but I have plenty more if needed!
Hoping that you find something.
Thank you, I'm downloading them now and will let you know within a few days.
So I analyzed the data and I'm having the same problem you are seeing. Even just combining R, G and B I get a very purple crescent. Changing the R with the B and after color calibration, I got something a bit more like what I would expect, but the graphs show me that the colors are a bit "all over the place", which to me indicates you might still have had mixed frames or mixed channels somehow.
These are the color calibration graphs on the R, G, B data as you provided. There's a very clear skew instead of a more normal distribution.
Going back to the subs and the signal in them, I thought it looked a bit like the G is actually B, the B is actually R and the R is actually G. Ofcourse I'm absolutely not sure, but combining this combo did produce a more sensible color for the crescent and the color calibration curves look less skewed and more normal. I think there is indeed some mix-up going on.
Here a crop I made of the above picture, I took the green out of the yellow using HSL selective color which makes it look even more "natural". I think the filter wheel needs some repair or there's an issue in software controlling the wheel.
At the moment I am even more confused:
a) I just opened my FW and the filters are located in the expected position and when I look at the sky through eg the R filter position I see very red coloured clouds.
b) I connected to the FW from SGP and when changing the filters using the FW control I see the filter wheel move to the expected position.
c) I look at the SGP Sequence and Profile and everything there looks correct.
: so at the moment I can't think what might be going wrong if your suggestion is correct
I will try a new RGB Combine assigning the stacks as per your suggestion and see what results. In support of your idea I had wondered why the Blue and Ha stacks looked very similar - I had assumed that the Blue filter was capturing H-beta light in the same regions as H-alpha but perhaps that is not right conclusion.
Thanks for taking a look. I'll keep you posted.
PS - I like your result, it looks far more natural than mine.
Like I said, I'm not 100% sure this is what is going on, but it does make a lot of sense given your statement about the issues you previously had with the filter-wheel and that the data looks much better when I change the colors around. It's just a matter of taking out 1 possible cause at a time to see if we can find the issue. Could you post a snapshot of the settings in SGP? And could you check the hardware configuration of SGP as well to make sure all is set well there?
Also, if my assumption is correct, would it make some sense in how the filters are put in your wheel that all 3 colours could have been reversed if e.g. the wheel turned the wrong way around? Just thinking out loud. 🙂
I quite understand what you are saying about trying to eliminate one thing at a time.
I am thinking this must be either a systemic issue eg filter positions not correctly matched to SGP config files (or possibly an APP fault), or an intermittent issue, eg faulty USB connection.
As far as I can tell the filters are all correctly mounted as per the config file but I am thinking I will email a picture of the wheel with the filters marked to SX and ask them to confirm that everything is mounted correctly. I can also ask them to confirm the position sensing magnets are installed correctly, but as I mentioned when I look at the wheel turning under instruction from SGP it does seem to move and stop as expected.
I am wondering if I might spot something by examining the star counts identified by APP. As a rule of thumb I think I should see the highest star counts in Lum, followed Green/Red, Blue and Ha owing to CCD sensitivity and filter band pass. Would you agree? By looking at the ranges in my Crescent subs I am wondering if I might spot an incorrect sequence or possibly a few outliers. I have looked at all the subs on several occasions and I have not noticed any obvious outliers which is making me think this is a systemic issue.
A couple of small things I can mention. First, I was imaging a couple of times during the recent very hot weather and discovered that the TEC cooling was close to its max rating and this resulted in some faint Moire like patterns on some subs - most noticealbly on Ha. I have mostly replaced these subs so I don't think this is the cause which I think would be no worse than a new dust bunny. Second I noticed I had a couple of Green subs with rather high Registration RMS numbers which showed up as a one sided green fringe on a few very bright stars when combined. I think I will eliminate these but again I am doubt ful this would cause the problem I am seeing.
Just to update you I ran Analyse Stars with Automatic Stars Target set to 10000.
Sorting the results on Star Density, I see a strong grouping of results with very little overlap between subs taken with the same filter and binning level.
L 1x1 120s: Apart from 2 exceptions (2456 and 4221), all L subs scored better than 8620 stars.
R 1x1 120s: Seventeen subs between 5661 and 7843, fifteen of which above 6423. One outlier at 2841. Remaining 3 at 4221, 5313 and 6060.
Green 1x1 120s: Seventeen subs between 4375 and 6254. Outliers at 2792, 2841, 3026 and 3720.
Blue 1x1 180s: Seven subs between 1901 and 2075. Because I was seeing such low star counts on my Blue subs I deliberately increased the exposeure on these B subs to 180s
Ha 1x1 300s: Fifteen between 2134 and 2626. Outliers at 1098, 1109, 1194 and 1616.
Red 2x2 120s: Twenty-two subs between 1338 to 2036
Green 2x2 120s: Twenty subs between 363 and 954
Blue 2x2 120s: Thirteen between 133 and 711. Outliers at 91 and 116.
This strong stratification of results makes me think this is a systemic issue rather than a few anomalous subs skewing the results. Would you somewhat agree?
I propose now to drop the obvious outliers and redo the integration.
Given the very low star scores achieved by the 2x2 binned subs I am wondering about the benefits of capturing binned subs in the future!
One question I have is what happens when, as I normally do, weight on quality during Integration. Is the weighting done on a global basis or within a single Filter / Bin level? If it is global it seems to me the Blue subs will be heavily penalised.
I'll have to give those things a long thought, I'm analyzing the subs in a few extra ways so maybe I can see something interesting. I kind of like some detective work. Not sure it will give me any answers though as I'm not sitting next to you to check the entire setup, which always helps. I'm pretty sure it isn't APP at fault though, although I never rule things like that out, but if it was we would have seen this issue a lot already.
If you choose to load in the subs based on the filter, it's quality stacking per filter.
With regard to star counts in binned frames, i would not worry about this. This is just logical, if you bin, the star FWHM sized are expected to be twice as small in pixels. So a lot of the weak stars in the unbinned data, will not be detected as stars in the binned data because these stars won't even occupy 4 pixels which is needed for detection.
I would try to first work with integrations with equal weights applied. If that gives much different results than it might have to do with the quality weights. If it does not, I would expect a problem with the data like Vincent is suggesting, but this is merely guessing at this point...
Please let us know what the results are with equal weight integrations 😉
I received the 5 integrations from Mike, thanks 😉
By looking at the 5 results per channel, I am very sure something is mixed with the filter assignments 😉
The Blue integration is almost identical to the H-alpha integration which I would never expect on this object:
So, this just looks very odd. I think that in data capture frames were assigned wrong filters, maybe all frames, or perhaps only some... My advice, would be to first study your individual frames and make sure you group all frames correctly for a later to be determined filter name 😉
Then we try to determine which set is for which filter and proceed from there.
Yes, when I looked at the subs seperately that was exactly my thought as well and why I started changing them around, with a better result as seen above. So, must be a case of switching then.
As seen in these graphs when switched around the distribution looks better.
Hi Mabula, Vincent,
I have read your notes above and will think about this further overnight.
a) I have examined my filter wheel setup and watched the filters move under control from SGP and all looks good on the set-up front. I will however try to speak wih SX to make sure I've not misunderstod their documentation in any way.
b) Having had a couple of issues of filter wheel disconnection I have been watching my imaging sessions closely and have not notced any problem.
c) When I examine the raw frames through SGP viewer I do not see any single frames that look anomalous to others recorded with the same filter so if there is a problem I think it must apply to every frame within a group.
d) When I looked at the Analyse Stars result from SGP I see a stratification of the results corresponding to the filter settings with frequencies which I think are logical ie Lum > Red > Green > Ha > Blue
e) I've redone the integrations after dropping a small number of the lowest scoring frames and using only 1x1 binned frames. I still get a similar result using assignments in line with the recorded filter (ie rather blue Cresent and background nebulosity) but the carbon star RS Cygni comes up showing Red. If I swap the channels as suggested by Vincent (G > B, B > R, R > G), the Crescent and background look much better but the RS Cygni shows bright Green.
I have had one further thought. In front of my filter wheel I have a Baader Neodymium (Moon & Skyglow) Filter. I've had this since I started imaging with DSLR to counter LP. I kept it in the imaging train when I moved to mono CCD thinking it would keep dust out of the filter wheel etc when not attched to the scope. I've never noticed a problem when imaging eg galaxies, but I'm now wondering if is perhaps harmfully affecting frequency response for targets with a high Ha background. If you think this might be the case, might it be possible to play with the strength / background sliders in RGB Combine to counteract?
Mappings as recorded at data capture - Blue nebulosity but RS Cygni about right
Adjusted mappings - Much redder background but very green RS Cygni
I would try to first work with integrations with equal weights applied. If that gives much different results than it might have to do with the quality weights. If it does not, I would expect a problem with the data like Vincent is suggesting, but this is merely guessing at this point.
Here are the resulting screen-shots:
And an unvarnished RGB Combine using the above - just add and calculate, no Ha