ONIKKINEN

I am pretty sure the numbers are arbitrary and are not comparable between different scopes and cameras, and conditions on the night and so on. So the quality estimation mostly works as a tool to tell you the relative difference of your data that night. As for how its calculated the user manual only briefly mentions that it is based on star size and roundness.

Hmm, much more complicated than i thought. Gonna need a cup of coffee to digest all this. This would play well as a processing challenge in that regard and those skilled enough to utilize the best data only, or implement stacking to make the best out of all the data will surely have the best image. The resolution issue could be partially solved by categorizing the stacks to fwhm ranges. Lets say 3" and better, 3"-4", 4"-5" and so on. Most will probably produce not very sharp data but that depends on who participates. Also works as a processing chalenge in the end.

Something like the B.A.T could be interesting as a community challenge of sorts for SGL users. Maybe users would calibrate and stack their own data and upload the stacks here, and then we could all stack the stacks to produce our own images and share them. That would skirt around the terabytes of data issue while also sort of bringing the benefits of very long integrations to play. It would be fairly easy to choose an easy target that most users here can image at certain times of year, like M101 which is fairly large and can be imaged with a wide variety of scopes so no data is truly lost in the end. The soft stacks could go towards a nebulosity image and the sharp stacks could provide detail for the star/galaxy disc layer. Just an idea i had in mind, but seems doable.

Reprocessed some of the same data with a few different and new (to me) methods. Combined 3 recordings in PIPP and stacked from those: Maybe a little bit sharper? Hard to say but i think it is nicer to look at.

That one was 10k frames 1920x1080, OSC camera, not drizzled and double stack reference disabled. The full resolution 3840x2160 captures take considerably longer and completely kill my PC for doing anything else in the meanwhile, so rather not test much on those.

Was a good watch, thanks for the link. Answered many questions about the software, including some of the AP size things. Looks like the multi-scale option partially makes up for incorrect AP size and placement troubles, so maybe not a critical thing to worry about as long as the size is thereabouts correct Just tested different AP sizes for a recording, took 22 minutes for AP size 48 and 3760 points and 15 minutes for AP size 96 and 875 points. So looks like its a little bit faster when there are less alignment points. This was a half resolution recording though so the difference is probably not inconsiderable for very large files.

I have a a TS mirror one, this one: https://www.teleskop-express.de/shop/product_info.php/info/p1771 Might be worth a try with a prism one then? I could use another diagonal to convert an old guide scope to a right angle finder so wouldn't be a waste. I suppose i could also test straight trough without a diagonal, should remove any possible diagonal issues. Ill try that on the next clear night to see if i spot a difference.

Right, i think i will try pre-stabilizing some of the files with PIPP to make the AP size selection a bit easier as i kind of just guessed it when there is a lot of variation from frame to frame. I might be able to squeeze something new off recent lunar shots that were a bit soft.

My PC is a bit aging now, but it was built with good kit in 2016 so its by no means a slow one today. 6700K with a decent overclock, early adopter DDR4 ram and GTX1080 but not sure AS!3 uses GPU acceleration so might not matter. I thought it went the other way with alignment points that smaller sizes and a large number is more intensive than large AP size and lower number of them. Gotta test it now.

Detail on the second one looks much better, and the background looks a bit richer too. More faint stuff in the outer regions of the galaxy in the first one though. Maybe worth trying a blend of the 2 with aggressive stretches for the faint stuff blended to the detailed image of the second one?

Is there a "right" size for alignment points with Lunar and planetary recordings when stacking? I have enormous files with a 678MC and stacking takes forever, so have not experimented much on this. For full resolution 3840x2160 captures i have used a fairly large size, like around 100 or so and there is still thousands of them in the end. With smaller ROIs i have used smaller sizes, like 64 or 48 but not much smaller than that. They still take forever to stack. Is there a rule or a guideline on what should be the AP size? I assume seeing plays a major part in this and the AP size should be big enough to account for the shimmering of the atmosphere, but that is just a guess from my part.

Have not seen a peep of interesting detail on Mars with mine, but it is still just a tiny red blip at max usable magnification. There is a red fuzz at one side of focus that turns into green fuzz at the other, so you are probably right in the red correction department. Yours will be much better, at least would expect it to be. * with fringe killer, otherwise would be purple on the other side of focus

This looks like a bias frame taken with a flat panel, something is wrong with the method of taking the flat. Looks like you took this with a 1/2000s exposure and aperture priority, so your flat panel must be obscenely bright for the camera to go down to 1/2000s in aperture priority mode where the camera takes the wheel and exposes properly. But also the flat just looks plain wrong, with a straight linear gradient top to bottom and no signs of vignetting. I suppose this could be some kind of rolling shutter thing with the extremely fast exposure time? Whatever the cause, this is not a flatframe that can be used. Below are your flat with the 250D and my old flat taken with a 550D, see the difference. They are rendered in false colour rainbow mode in Siril to make the brightness differences pop out visually. Reds are bright, purples are dim (relatively). Yours: My old 550D flat: Looks nothing alike, so something has gone wrong.

Good stuff, like the dramatic shadows of the region.

I have thoroughly enjoyed the cheaper version of this as an RFT type scope. Interested to hear how well your better one handles the targets the scope really isn't suited for: Jupiter and Lunar for example. Mechanically the included 2'' to 1.25'' clamp ended up being of poor quality in mine. Same story as the recent thumbscrew thread pointed out. Its made of some kind of mystery metal and the threads are difficult to tighten all the way, i replaced mine with a clicklock and life has been good with the scope ever since. The thought of upgrading to the better version did cross my mind several times, especially with Lunar and Jupiter stuff, so your experiences with the scope may have expensive collateral damage if it ends up being great 😆.

I have this one, bought from a local military supply store: https://www.amazon.co.uk/fenix-HM61R-Rechargeable-Magnetic-Headlamp/dp/B082DGTZVG/ref=sr_1_4?keywords=fenix+head+torch&qid=1665930113&qu=eyJxc2MiOiI0LjA1IiwicXNhIjoiMy45MCIsInFzcCI6IjMuNzkifQ%3D%3D&sr=8-4 It is weatherproof and drop proof, hell i think it might be bomb proof, you cant destroy it even if you try. The rechargeable battery lasts forever, and you charge it with an included USB cable so sounds more or less what you had in mind? The lamp will also force itself on the lowest brightness mode when batteries are getting low, but at this point you can still run the red light for several nights. So no accidental battery losses either. 1 gripe with it however, when you turn it on it will always start as the last white LED mode it had on, even if you had it in the red light mode. I have just manage this by blocking the light with my other hand when turning it on so that i dont get blinded. But if i was less lazy i would MacGyver some kind of red filter on the light itself to make sure i dont accidentally lose dark adaptation when turning it on.

Yes, this is what happens. If you set the slew speed to 9 and then did the alignment, it will have gone down to a low number, i think 3 when it asks you to center the target in the crosshairs. Change the rate after the go-to when it asks you to center the target.

Okay thats pretty weird. Try factory reset from hand controller? The motors clearly work if it slewed, and the hand controller also must work since you could slew manually before the GO-TO. Might be worth looking into firmware updates too, if something is wrong with the firmware that is.

Agree with the above, the mount goes into a very slow slewspeed mode by default after the GO-TO. You can press the rate button on the keypad and put it back into 9 to move the mount at full speed. Probably will need to since the initial go-to is often many degrees off target.

The 678MC with the small 2 micron pixels would be a killer low effort lunar RGB camera with your longer focus 10'' at prime focus. Not that its a huge difference to the 2.9 micron ones, but still a little bit closer. A bit painful to work with the large files though, so no free lunch there.

It always pops out as the most prominent colour feature in these saturated shots. Gotta try and get a closer image one day under good seeing!

Gorgeous image!

And forgot to mention, the output files are named CFA_0, CFA_1, CFA_2, and CFA_3. You need to figure out yourself which of these 2 are green and which is red and blue. For my camera CFA_0 and CFA_3 are green, CFA_1 is red and CFA_2 is blue. Your mileage may vary depending on the bayer pattern of your camera. Easiest way to test is to take an image of something that has strong reds, greens, and blues and inspect the images afterwards.

Best way is to have the image be mono in the first place, and here i dont mean use a mono camera. I mean split debayering to separate each subexposure to their 4 constituent monochrome parts = 1 red, 1 blue, and 2 green monochrome subs. In fact this is how all colour cameras work anyway and the colours are the result of interpolation between the 4 pixels. In Siril you can use the split_cfa console command in Siril to split a single frame. I recommend using the seqsplit_cfa (sequence-name here) command to run it on the entire opened sequence, for example after calibration of your files. You could easily modify the existing OSC_Preprocessing script and remove the debayering part from the lightframe portion of the script and remove the lines that stack the image in the end. This leaves you with a pp_light sequence that you can run the seqsplit_cfa pp_light command on and the result is 4 mono subs for each input sub. Scripts are found in your Siril installation folder in the scripts folder. I have attached 2 modified scripts in .txt format below if you dont want to do it yourself. Open with any text editor and save it as .SSF and put it in the folder and it will show up in the scripts menu in Siril. The scripts require you to have folders named "lights", "flats", "biases", and "darks" with their own files. If you dont have darks or biases you could modify the script to not have those. Since you have some chromatic aberration you want to hide/get rid of you could choose to only use the colour channels that are not bloated. May be only green, or green+red/green+blue, depends on which side of focus you were in. If you are working with an already debayered (so not a raw) RGB file, you can use the Extraction - Split Channels function in the Image Processing menu to split the image into mono R G and B files. You could then just stack them with average and result in a mono synthetic luminance file afterwards. You can also choose to use only the green channel for example since that will have the highest SNR due to twice the amount of pixels and generally because the green channel is strongest in both daylight and broadband astrophotography images. But if you have the raw files for whatever image you want to convert to mono i recommend the bayer split method above. Another note from split debayering: It will half your resolution as the raw data is actually 4x half resolution mono images anyway. The typical OSC processed image with debayering is in fact just resampled by 200% and carries no real detail of its own, but will introduce interpolation errors and noise. If you must have the original resolution you can resample by 200% and get the same result as with "normal" processing. No difference in actual captured resolution because it was not there anyway. OSC_Preprocessing - bayer split no stacking.txt OSC_Preprocessing - no stacking.txt

If its the same focuser that my VX8 had, its a strong recommendation from me to get rid of it. If the CT8 has the same secondary spider that the VX8 has (looks like it in photos), same story. Not sturdy.