Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

The Lazy Astronomer

Members
  • Posts

    952
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by The Lazy Astronomer

  1. Oh sorry, I just realised what you meant! By defects, l mean can you see any residual dust mote shadows, or vignetting that hasn't been fully corrected, or a brightening of the edges caused by over correction (inverse vignetting).
  2. Clipped pixels (value of 0 or 1), as mentioned above, and ideally a histogram peak that sits in the linear response range of the sensor - generally speaking, somewhere in 30 - 60% range.
  3. To simplify things, pick a temperature and stick to it. Dark current is insignificant compared to other sources of noise, so don't worry too much about it. I went with -10C, purely because l feel like its extremely unlikely the ambient temperature at night will ever be lower than that, or more than 35C above that. Regardless of which temperature you settle on, as has been mentioned above, you should take darks with settings to match the lights you have used (or will use). Whatever capture software you use will have the ability to set a sequence for dark frame capture so you can set it up and let it run - I use NINA and take 20 subs. Folder structure is pretty simple: dark library/[camera model]/[gain, offset and binning]/[exposure time]/[individual subs]. I also copy the master calibration frames into each folder with the lights for each project, for simplicity should I ever feel the need to go back and restack.
  4. I'm of the belief that the only meaningful test of calibration frames is to use them to calibrate lights (any clear defects like clipped pixels notwithstanding) Stretch the calibrated stack to oblivion and see if you can see defects.
  5. Put the darks in the 'main group' tab - these will be applied to all lights in all other groups. If you can share the flats between all the nights (ie. you left the camera on the scope), then the flats, associated flat darks and all the lights can also go in the main group tab. If you have different flats for different nights, then put the lights with their associated flats and flat darks in their own groups. You can also stack the calibration frames separately and just add the masters into the relevant group(s) when stacking the lights if you wish. When adding new data, I would always restack all the lights from scratch (using prestacked master calibration frames, wherever possible).
  6. Should be, provided the lighting is even. In fact, daylight wall flats is the only way I've managed so far to get passable (but not quite perfect) Oiii flats.
  7. I've read that the 294 cameras don't do so well with flats under 1s, so l stick to flats above 3s for my 294MM, but thinking about it, ultra short flats are about the only thing I haven't tried to try and fix my Oiii calibration woes, so maybe I'll give it go tomorrow.
  8. I don't really know what the generally accepted convention is, mine are between 6 - 12 months old currently, and I'll probably just keep using them until I encounter some kind of calibration issue. I suppose if it was cloudy for a prolonged period and I was bored one evening, I may take some new ones.
  9. Nice. I was doing some test shots of this region at the end of last night's imaging session and was quite surprised at how little apparent Oiii there is. You've got it showing through quite nicely there though 👍
  10. Hmm.. A similar thing happens to me sometimes (though never that extreme - it's only slightly off centre). It doesn't seem to have any appreciable effect on guiding, so I've never really thought anything of it. Not very helpful, I know, sorry!
  11. That advice is for DSLRs or other cameras where you don't have control over the sensor temperature. If you can't temperature matched darks, they may end up introducing more problems than they solve. Obviously you have set point cooling, so the full suite of calibration frames should net you the best result. Edit: but do still dither!
  12. You're quite right - I'll edit my original post, and my apologies to Dave! I think my impression it was not being actively developed is because the information on the DSS website is not being updated anymore it appears.
  13. I'm not that clued up on the specifics of the algorithms used, so can't comment on that. There's nothing fundamentally wrong with DSS, it's easy to use, but it is essentially adandonware, having not been updated in I-don't-know-how-long. Siril certainly offers more flexibility, and is more comparable to Pixinsight in terms of stacking. I used DSS exclusively for a year or so (because it's so easy to use), but what made me switch to Siril was an issue l had with a faint, almost checkerboard/grid-like pattern on an image l was trying to stack - I thought it was an issue with my camera or calibration frames, but after some research, I discovered it was actually due to the subframe alignment process in DSS (image was shot over multiple nights, and there was some slight rotational difference between the nights). I tried all the different options I could see in DSS, but to no avail, then I tried out Siril, and sure enough the pattern did not appear in the stacked image (exactly the same raw data). I've stacked using Siril exclusively ever since.
  14. Ah well, at least you had plans to move anyway, so it's irritating but at least only a temporary problem.
  15. Believe it or not, plate solving is much easier than messing around with star alignment. I'd recommend you look into it for phase 1.
  16. Assume this was with the c9.25 in your signature? If so (and if you don't have a corrector), then coma's your issue - DSS won't recognise the stars due to the distorted shape. Difficult to be certain from the screenshot image, but I'm reasonably confident.
  17. Astrophotography is nothing like point and shoot daytime photography, and some degree of processing of the image is required. You don't need anything fancy, but at least some form of basic image processing software is recommended. GIMP is a good starting point - it's free and quite similar to photoshop, plus plenty of online tutorials for some basic processing of astro images. Do you have the RAW file still? If you post to here, I can quickly run it processing software to see what's in there.
  18. Imaging scale ("/px) = pixel size (μm) / scope focal length (mm) * 206.3
  19. I started off with DSS and GIMP, but I got the feeling I wasn't really getting the most out of my images, and I found it quite faffy to do things in it. Then I moved to Startools; I liked it generally - it has a relatively simple and (to me anyway) a pretty intuitive interface, and you can knock out a completed image in minutes, but I was never really 100% happy with the way the autodev module stretched the data, particularly the way it stretched the stellar profiles - I tried many different things and just couldn't quite get them to look how l wanted them, which meant I then had to do a fair amount of star reduction, which in turn left them looking slightly artificial within the context of the image. At the same time, I also switched to Siril for stacking (never really used it for post processing though). Siril has DSS beat for stacking, so I'd recommend you check it out. Then I moved to Pixinsight, and got on with it a lot better than I expected. I find the sheer vastness of it's available processes gives so much fine control over every facet of the image and l really like that, but it is a slow procedure to complete an image - I can spend hours playing with settings and different processes!! I would say Startools gets me to an image that is 90% as good as what I can get out of PI, in a fraction of the time, but if you asked me which image l preferred, it would be the PI one, every time (not sure how much the IKEA effect comes in to play here though...).
  20. Aha - another 294MM user! I'll put the same question to you that I asked to geeklee: how do you take your narrowband flats? Oiii gives me real issues, and I'm trying to understand if there's a better way l can do them.
  21. Typical, you wait all day for a response then 2 come along at once 😁
  22. Checking the logarithmic box just a different way of displaying the histogram information graphically. Check it if you want, it makes no difference to the capture. There seems to be different approaches to exposure for lunar and planetary imaging, but the best results I've had is by following advice to ignore the histogram, set a high gain and short exposures (around 5ms, but maybe even shorter for the very bright moon). Don't worry if it looks bad on the capture screen, stacking and sharpening will work their magic later!
  23. I wouldn't say those images were too noisy - overly smoothed and noise reduced images tend to have a plasticy 'fake' type look. This is actually something I really struggle with, I have a tendency to go too far with noise reduction, due to an aversion to noise. I'm trying to get over that and embrace the grain! What you do appear to have there though, is some blue bloat on the stars. This can be relatively easily remedied with a uv/ir cut filter, such as the Astronomik L3. Could also be processed out to some degree, but I prefer to prevent problems rather than fix them later. Re: the mount, have you tried running the guiding assistant?
  24. Your calculated time for broadband seems a little long (it's in high read noise ccd territory), but if that is indeed correct, then yes, you'll likely benefit from exposing for longer in Ha.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.