The Lazy Astronomer

Where's the fun in that - wouldn't want to make it too easy now, would we?! 😁

Music to my ears! 😁 I did notice some stars looked like they were a slightly diamond-like shape - perhaps I need to play with the clamping threshold a bit. Assuming it'd be possible to work out the guiding problem, is this potentially where we could get to in the near future if the re-emergence of dual sensor cameras takes off, do you think?

There's something I find very amusing about this statement 😆

Thanks @vlaiv - I think I've done this process correctly: 1. Used the bin1 data 2. Wasn't sure how to do this in Siril (or if it can do it all), so used Pixinsight's SplitCFA process on the calibrated subs - this gave me 4x as many images of 4144 x 2822 px (native bin1 is 8188 x 5644 px), so I think that's done what you suggest. 3. Aligned using lanczos-4 and stacked At the end of that I have one integrated image of 4144 x 2822 px, with a measured FWHM of 1.639 px or 2.85". Overall, an additional 9% improvement on Lanczos-4 registration with native bin2 data, and a 21% improvement when compared to native bin2 data registered using Siril's default method! Before I commit to capturing all my future data using the "unlocked" bin1 mode and stacking as above (and probably also having to purchase a few more TB of storage for the 89MB subs!) - are there any downsides you can think of when handling the data this way, in terms of the SNR of the stack, when compared to capturing with "normal" bin2 mode and aligning/stacking without the split binning? Thanks in advance!

Hi all, I was trying out some different camera settings the other night, mainly a test to see if using the "unlocked" bin 1 mode on my 294 would be worth it (I've previously avoided because I figured my local seeing would not support a resolution higher than what I can achieve using the "standard" bin2, and 47MP files take up quite a bit more storage space). My thoughts are below, I'd invite anyone to share their thoughts on this too. Acquisition & analysis info The target, for no particular reason other than it was visible, was M13 Bin 1: gain 108 (unity), offset 30, -10C, 60s subs, image scale = 0.87"/pixel Bin 2: gain 120 (unity), offset 30, -10C, 60s subs, image scale = 1.74"/pixel 100mm triplet refractor, 550mm focal length Astronomik L3 filter Guiding was nice and consistent, around 0.5 - 0.6" RMS throughout capture, fairly equal in RA and DEC bin1 frames taken first, immediately followed by bin2 frames Each stack calibrated with its own set of darks, flats, and flat darks Calibration, registration, and stacking done in Siril Image analysis done in Pixinsight using FWHMEccentricity script on default settings - reported figures are median FWHMs expressed in pixels, not arcseconds Results For all images, the measured FWHM (in pixels) is stated in the top right hand corner. Also note that the text says "slight midtones stretch", but this was done using STF and data was linear Comparison of stacks The bin1 stack gave a reported FWHM of 3.210 pixels, which equals 2.793". Following the advice I've seen from @vlaiv on here (shameless tagging to get your attention 😃) of an optimal sampling rate of FWHM/1.6, that would infer an optimal sampling rate of 1.75"/pixel. This seemed to confirm my first thought (i.e. my conditions/equipment don't support a higher resolution than can be achieved using bin2, and in fact my sampling rate at bin2 is pretty much perfect (for the conditions that night, at least)). However, the bin2 stack gave a reported FWHM of 2.071 pixels (3.604"); somewhat higher than the bin1 data suggests should have been possible. I then decided to bin the bin1 image x2 using IntegerResample in PI so both images were at the same scale for direct comparison (all the bin1 images below have been binned x2 in that way). Now, the x2 binned bin1 image gives a FWHM of 1.780 pixels (3.097") - when converted to arcseconds, it's a little higher than the native bin1 image*, but it shows ~9% improvement in measured FWHM compared to the native bin2 image (ok, not massive, but it's a free resolution improvement - the words "free" and "astrophotography" don't often cross paths 🤣). The bin1 image also appears visually sharper (again, not massively, but I think it is noticeable when viewed at 100%). *I'm sure this is probably expected, but I don't know why - perhaps someone can explain that to to me. Comparison of raw subs I thought maybe the seeing had suddenly worsened during bin2 exposures, so I looked at 2 subs taken right after one another (the last bin1 sub, and the first bin2 sub). These gave very similar FWHMs, with bin1 still taking the lead. Comparison of calibrated subs Just to check the calibration wasn't doing something weird (you never know with a 294!! 😆), I compared those same subs. Very slight changes, but they're still quite similar. Comparison of calibrated and registered subs Same two frames again, this time registered with Siril's default method (pixel area relation). A-ha! A 6% increase in FWHM for bin1, but a 12% increase for bin2. The issue with the bin2 images must therefore stem from the interpolation method used during image registration! Comparison of stacks using different registration methods (Bin2) It is clear that different interpolation algorithms lead to different FWHMs in the stack. For this dataset, it seems that Lanczos-4 gives the best result and bilinear the worst (bilinear has also given the same result as Siril's default of pixel area relation), but it's still not quite as good as the x2 binned bin1 stack from above. Comparison of stacks using different registration methods (bin1, stacks binned x2) Same exercise using the bin1 data. This time bicubic has given the best result and bilinear again the worst (and also again, the bilinear result is the same as Siril's default pixel area relation algorithm). In each of these cases, the x2 binned bin1 stacks have between 5 - 9% improvement over the equivalent native bin2 stack, and even the worst bin1 stack still shows a lower FWHM than the best bin2 stack. Conclusion Based on this (admittedly very limited) data, my preliminary conclusion is that capturing data using the "unlocked" bin1 mode of the 294MM followed by binning the stack x2 in software, does have the potential to net a slight resolution increase in a stacked image, compared to capturing data using the "standard" bin2 mode. The difference between individual subs captured using the two modes is virtually non-existent, so the improvement seems to stem solely from better registration with the bin1 data. As to why this appears to be the case, I am assuming it is due to the finer sampling of the bin1 data allowing the registration algorithms to do their job with a bit more precision. Happy to hear any thoughts on this, including any completely tearing apart the conclusion I've come to and/or pointing out any obvious or stupid mistakes I've made!! Thanks

I love it! Star size and colours seem perfect for the composition.

I'll start by saying devices such as these don't really appeal to me, and I can't see myself ever buying one, personally. But I guess the difference between them and looking at pics on the internet is the image you see is what is above you in that moment, so there's more of a direct connection to the object. Yes, it removes the challenge, but undoubtedly, some people are put off astrophotography because of the difficulty (not to mention the cost!!). It that sense, I can understand why these things would appeal to someone who just wants to sit back and appreciate the things that are up above them.

I dread to think of the insurance value of that warehouse contents 😬

It looks it might simply be, as you say, overexposed. The 16-bit mean ADU of your red image is ~14K (which I would say is quite high already), and obviously a luminance filter will let more light through, so you'd expect a higher ADU for a given exposure time compared to the red filter. It seems as though you've just exposed too long for your conditions. Side note: 600s is quite a long exposure time for broadband with a CMOS - you've got some elongation of the stars across the frame, which may be due to tracking/guiding errors across the exposure time. That said, the stars near the bottom right corner look pretty round, so it may just be a spacing or tilt issue.

Woah, having a bad day?

Yes - I have to admit I found this quite strange when I was looking for info on how they got to the final image. I wouldn't expect post processing details, but I would've thought (for a scientific paper) details of the pixelmath operations performed to the Oiii image should be included.

Unrelated (but sort of related): I went to visit the Greenwich observatory in the summer last year, and my take away memory from it was overhearing a boy, maybe about 12 or so, saying to his dad "why is at all clocks? I thought this about space!" I probably laughed about that for about 20 minutes. To be fair to him though, there were a lot of clocks...

Yeah, sigma clipping will deal with that easy. I don't even pay attention to satellite trails for precisely that reason.

As the others have suggested, the mount has moved a relatively large distance suddenly. If you figure out your camera orientation relative to the mount, then you work out which axis is causing the problem. As to why, the fact it affects several lights would imply it's probably more likely to be a tracking issue, rather than the mount being knocked.

Well, the article says that they plan to use them to collect data from the mesosphere, so they would be doing something useful, at least.

Has anyone considered the possibility that "they" are cows?!

Sorry, couldn't resist. I'll get my coat...

As you say, maybe a bit much with the Ha contribution, but very punchy. I like it

The more l look at it, the more I think that's my one too! Good to know I'm not alone

Thanks all for the feedback - pretty unanimous! 😃 It's interesting that's the preference, that one was the first version and I thought it looked a bit bland, although I have to admit it looks a bit more vibrant on my phone than it did on my monitor. Still haven't quite found my 'style' for narrowband colours yet I think.

Shot mostly over late autumn/winter 2022, around 18hrs integration time with approx 7 hrs each Sii and Oiii, and about 3.5 hrs Ha. Given other images I've seen on here with much shorter integrations, I'm not necessarily sure I've benefited from the extra hours, but oh well. 2 versions: one where I've gone fairly aggressive with the Ha/Sii dust colour, and one much more toned down, but more Oiii coming thtough. Not sure which I prefer - let me know your thoughts!

Same as the other guy, only ever done it once, so don't necessarily take my advice!! I used Starnet2 to remove stars from each sub - it's actually quite simple: just create a process container with a stretch, Starnet2, and an inverse stretch*. Then create an image container, load your subs into it and then apply your process container to your image container. *you could forgo the stretches and use the linear mode of Starnet2, but I find better results are achieved on stretched images. This, along with some rejection stacking, removed pretty much all of the star trails. There were still some ghostly residuals on the larger stars, which were largely removed using masks and MMT (aka the Adam Block "special sauce" - he actually recommended MLT, but I found MMT worked better for me).

There's upselling and then there's UPSELLING. Salesman level: pro

Woops! That's unconscious bias happening right there - I see what I want to see 😁 Edited original post

Edited to correct an error pointed out by vlaiv If I'm reading the order of the images correctly, then it looks to me, on this selection of images at least, that Starnet is removing less non stellar detail than StarX, but StarX has dealt with Alnitak better, in that it has been completely removed (albeit with artifacts, but completely removed nonetheless).