Appropriate number of darks depends on your exposure length and thus number of sub. If you are doing 10 min subs, you won't really want to be doing 50 darks! For short subs, I usually take up to 25 darks. For long subs, anywhere from half to equal number of darks vs subs.
(But I'm still very much in the process of what works best for me under different conditions, since I only took up the AP game recently)
I am using the Flattener H, only thing I found was that if you use the standard fittings as per the System Chart, I got elongated stars out on the edges. I got Peter Tan to machine up a couple of parts that were a couple of mm wider than the standard EOS Adapter, that made the world of difference.
The image below is an 80 second shot, just a single image, gives you an idea of how the scope is performing. No Darks, Bias, Flats or Dark Flats, just a test image. The Canon 60Da.
Interesting thread.
I am curious as to what software people are using to stack and whether this has any impact on the quality of the "product at the end".
In particular now I am curious as to how changing my RAW canon files to TIFFS before stacking would affect my process, plus in DSS how to stop the calibration of dark frames or opt out?
I have never stacked with anything else so would like to know what others are using (aprt from DSS)?
Graham
Graham,
I use AstroArtV5 for all my image acquisition with all my cameras (DSLR, Atik16 and ATik314.)
I also does all my pre-and post processing - batching of Lights/Darks/Flats stacking etc. etc. etc.
Not sure what others use Graham but I use ImagesPlus and have from the very early versions, it will automatically convert and stack all your various subs and convert from CR2 to either FITS or TIFS.
I normally do a slight stretch in IP then import into CS6 for further manipulation.
There are quite a number of different programs out there so other people can comment on them.
Graham,
I am very new to this but I use DSS. DSS does accept canon RAW files but it may modify them. I use Startools for processing, and it likes the stacked file to be as unprocessed as possible.
Hi Graham, my decision wasn't based on quality, but what worked.
I could never get DSS to work for me.
PI would stack no more than four(!) 60Da subs(18mpix) before I got 'out of memory' errors. Even then it was super slow. I spent ages trying PI memory management tips on threads etc but none worked and I gave up on PI. This was on a quad core i7 machine with 16GB ram!
I trialed AstroArt and whalla, it just worked. Very fast and I'm yet to hit a memory limit. As for output quality, no idea. It works so I bought it.
I have always used DSS so have nothing to compare with but I have Astroart5 so may try that now.
The star registration in DSS can be a bit sus, but I have never really tweaked any of the settings from the standard except recently tried sigma and kappa stacking.
Simon, did you have drizzling enabled? That is the single biggest cause of out of memory errors in DSS.
The memory errors were not with DSS but PI. And no, no drizzle.
At the time I tried DSS it couldn't handle the 60Da raws, from my dodgy memory, the output was a single pink thin vertical line. Others had complained of the same issue, I moved on.
DSS uses dcraw as its RAW decoder (get the latest 'beta'), so I'm not sure of the advantage of doing the conversion outside of the stacking program.
Yes it does Barry but it modifies the data. By using dcraw first with the arguments Ivo suggests it gives cleaner data.
This is how Ivo described it to me (I hope he doesn't mind me reproducing this here):
The main thing is that DSS no longer should meddle with the colour balance and should no longer create anomalous colour data in the highlights.
The problem with modifying the colour balance before StarTools can analyse the data is that any noise levels will be skewed due to the multiplication (which is what whitebalancing does) of the signal (and thus noise) in the individual channels. Highlights get clipped by the whitebalancing as well, introducing anomalous colour data in the highlights. This is why you'd want to give StarTools data that is as virgin as possible. The Tracking feature will be able to work better and will help the various modules yield better results if it can oversee the full noise evolution.
I have compared final images with using RAW or TIFF (converted first by dcraw) into DSS and the TIFF stack gave a less noisy final image with more dynamic range.
Exporting TIFFs from Canon's Digital Photo Professional will give you, in your TIFF, exactly what the sensor captured.
Using third party software will give you results, but, they will not be precise.
This can be demonstrated by opening a Canon CR2 in any number of RAW decoders (ACR/LR, CaptureOne, blah, blah, blah). None of them will render the image like DPP does. The one true Canon RAW converter.
I suspect that the various products employ their own preferences, which affect the end result. DCRAW is the universal converter for many of these programs. The issues under discussion would apply universally as well, presuming that RAW DSLR data will always present unique non-linear issues.
It might be that dcraw options may differ by camera and model.
Yes it does Barry but it modifies the data. By using dcraw first with the arguments Ivo suggests it gives cleaner data
Paul, interesting - can you confirm that with the latest beta of DSS, which is using an updated version of dcraw. It seems strange that the dcraw conversion it uses would modify anything. I definitely keep everything else 'virgin' when using DSS - or at least as much as is possible!