Here's a first stab at processing my M31 from October DSC.
101x5min at ISO 800
10x1min at ISO 400
10x20sec at ISO 100
Usual Canon 350D on Tak Epsilon 180ED ( F2.8 )
(http://www.markshelley.co.uk/Astronomy/2012/m31_13102012_small.jpg)
Larger version here:
http://www.markshelley.co.uk/Astronomy/2012/m31_13102012.jpg
Jon, I seem to be suffering the same posterisation problems as you! Not sure of the cause yet.
I've also got a LOT of background gradients to sort out. It's going to be a lot of work to get this image into a reasonable shape!
Colours aren't quite right either. But at least it gives a good idea of what data I have available to play with.
Mark
Such an interesting comparison in the difference the data our two setups have gathered!
Bizarre you seem to have the same posterization as me, most notably in the blue like mine also, although I don't think it is anything like as defined as I have found. I wonder if perhaps this is a common feature of M31 when dealing with high numbers of subs?
Did you also find a slightly excessive abundance of very bright blue stars? I had a nightmare calming them all down.
This really does show how much more data your telescope has gathered for a very similar number of subs. Although your core seems much brighter than mine at the very centre, the detail in the darker lanes is much more defined and remains right into the core.
Also you have many more stars and have found the outer extents much better than me!
I also had gradients that refused to naff off, but ended up cheating by heavily darkening the background until they just couldn't be seen. Although I think this has caused more harm than good in the final image and I possibly lost a lot of detail in the process.
I've discovered the cause of the posterisation in my case. It was the sigma stacking. Sigma stacking often causes effects like this when the subs have different background gradients. This tends to be caused by one long very imaging session or by using subs taken on different nights. The solution to this is twofold:
(1) Adjust the subs so the mean level in each sub is identical (the NOFFSET2 command in IRIS achieves this)
(2) Choose the sub with the least gradients and use this as the reference for removing the differential gradients from all the other subs.
I'm still experimenting with (2). This is done after registration of the subs but before stacking. Essentially the technique is to subtract the reference sub from the working sub; remove the stars (possibly by clipping); and then severely blur. This blur is then the differential gradient which can then be subtracted from the working sub. Repeat for each sub!
That would possibly explain it for me as well then as I also used sigma stacking.
And the process of fixing the posterization doubles up to tame some of the gradients too?
But performing that on each sub is going to take one hell of a long time! :o
Incidentally, if sigma stacking it proving to be the cause for the posterization which I am guessing it must be due to us both having very similar problems, can it not be overcome with a different stacking method?
Perhaps sigma is not the best method for very large amounts of data?
I'm only guessing here as I pretty much know nothing about the way the subs can be stacked and less still as to how they actually work!
But this does once again lead my thoughts back to a full re-stack and use the merge_hdr command to stack all the subs.
In the end you need to do a sigma stack if you don't want an image full of hot pixels, satellite trails, meteor trails, laser pointer trails, aircraft lights and cosmic ray hits i.e. you need to reject the outliers in the data.
Another possiblity I've just thought of is to do the image calibrations and registrations in Iris and then perform the stack in DSS. I think DSS uses a 32bit numerical representation which avoids the problems caused by Iris downsampling to 16bit signed integers.
But we are still left with the question of whether or not the DSS sigma stack will lead to the same posterisation.
I'm sorry to tell you that you've jumped straight into the deep end by attempting an image of 90 subs!
Ahh ok, you'll have to bear with me, my knowledge is still trying to catch up with what I'm trying to do!
If anything then using the merge_hdr function to stack all the subs would be a bad idea as it is designed to bring out data over the full dynamic range. Thus if anything it would enhance all the satelite trails etc etc! Well that has saved me a lot of time!
Oh no, don't be sorry! In fact the total oposite!
This is my idea of a good time, the amount I am learning in doing this is brilliant, it just shows how much the game changes when you start dealing with very high numbers of subs!
Plus when I step down to a more normal handful of subs processing will be so easy I'll laugh it off! Well that's the theory anyway.... ;)
Jon it sounds like you need to invest in a more powerful PC for processing ;)
QuoteJon it sounds like you need to invest in a more powerful PC for processing
Tell me about it, my poor old Dell is having a real hard time handling this and it's really slowing down my progress!
But as much as I need (want) a new laptop the bank balance says NO! :(
Anyone care to sponsor me something with oooomph? :lol:
Thinking about that method of stacking in DSS with Iris registered files Mark, will that be possible with the file format Iris uses?
I'm not sure but I don't think DSS works with .pic files so all the subs would have to be converted to something else, would this not in tern have the same effect of downsampling?
Of course i could also be talking a load of twoddle here....
I guess you would have to save the files as TIF. That's assuming DSS accepts TIF.
But would that not then reduce the images from 48bit to 16bit and loose data?
Or could this be overcome by offsetting and multiplying the pixel values?
I think DSS will work with .fit files as does Iris so that would be an option if not tiff's.
The TIF files saved by IRIS have the same dynamic range as the PIC files (except that you need to clip the negative values to 0 before saving as TIF). The quoted 48bits is 16bits/channel - so no loss.
Yes, FITS files are also a good idea.
I don't really understand how that works, showing my lack of knowledge again!
But if you say it will that's good enough for me.
So I take it the idea is to register etc in Iris, save/convert all the registered .pic files as something DSS will recognise and stack then use the 32bit file DSS outputs for processing.
Looking potentially very good again Mark. I look forward to next revision when you have sorted out the edges of the galaxies. Like you said as well the background looks messy. Very milky & colourful as usual though.
Nice one, John