Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by derrickf

  1. It's been a few years since I processed an image but I've recently started to re-learn what little I used to know about astro image processing. Big thank you to the team for making this high quality dataset available to us, the high SNR of the data makes a big difference to the processing choices available. The image was processed in PI then saved as a 32 bit TIF which was then saved as a JPG from Affinity Photo (no other processing was undertaken in Affinity). The main processing steps in PI were: RGB channel combination Photometric colour calibration Noise reduction (TGV denoise & MMT) Stretch to non-linear Noise reduction of L channel (TGV Denoise & MMT) Mild Sharpening with LMT Stretch to non Linear Sharpening with HDMRT LRGB Combination Star reduction (using Adam Block method) Colour saturation and Intensity tweaking using Curves Transformation Save as 32 bit TIF for transport to Affinity Photo from which it was saved in JPG format for submission here. I'll probably take another shot at it to see if I can recover more of the star colour
  2. I would really appreciate the link to the .STP files too. You have done a fantastic job with this design Derrick
  3. Autodesk Fusion 3D is free for personal use and use by small businesses. It is a fully featured 3D modelling system with integrated complex surfacing, FEA, CAM, sheet metal design and development, rendering etc. It is ideal for designing the kind of widgets we need from time to time in pursuit of this hobby. It is very well supported on Youtube by Autodesk and many third parties. HTH Derrick
  4. You don't need the hand controller to be plugged in if you are controlling the mount through sitch.exe. My hand controller has been dodgy since day 1 and now lives in a box far away from the mount. HTH Derrick
  5. I like the choices you have made in working on this data - it's good to see an image that is processed just far enough to exploit the available data; as others have said you can process more aggressively to minimise noise when you have more data. Derrick
  6. I noticed this in a thread on the PI forum about a different topic here. About halfway down the first page Vicent Pieris indicates that PI will have a process for correcting amp glow; this may be of use to owners of the ASI 1600 : Quote from: IanL on 2017 January 09 10:17:16 - If your CMOS camera suffers from repeatable banding, amp glow or fixed pattern noise, then you should turn off PI's dark frame optimisation and use a time and temperature matched master dark. Otherwise it will likely over or under-correct and those artifacts will only be partially corrected (or indeed made more visible). This is certainly the case for my CMOS-based ZWO ASI1600MM-cool. A temperature and time-matched master dark without optimisation works very well and deals with the amp-glow that becomes visible and increases after about 60 seconds of exposure. With optimisation turned on, PI under-corrects by applying a scaling factor of about 0.45 despite a matched dark frame. This is unsurprising since the optimisation process is global and I expect it is being thrown by the significant variation across the frame. Hi, We're designing an amp glow correction right now, so in the future you'll be able to optimize the amp glow subtraction. HTH Derrick
  7. Is this with no PC connection whatsoever to the mount? If so it would point to this being either a mechanical problem with the mount (faulty encoder?) or a firmware problem. Maybe Lucas can shed some light on possible solutions now that the mount control software is demonstrably not the culprit. One step closer to a solution ... BTW there is no reason to assume that this is the cause of the aberrant behaviour of the mounts owned by other people.
  8. I would share your trepidation but, as Ray D suggests, no need to be quite that radical - just hook up a camera without connecting Sitech.exe to the mount
  9. I certainly wasn't suggesting that running it as a "dumb mount" should be anything other than a diagnostic exercise. You have been rigorous in your diagnosis to date with this one exception; again I'm not advocating that you do this - I was just asking if you had.
  10. I almost agree with your conclusion: if I understand your setup correctly, the problem, based on your observation, would seem to be in either the mount (including the Sitech controller) or in Sitech.exe. Have you tried doing an animation run using just the handset (a PITA I know - the handset is the weakest part of the whole mount hardware IMHO and I dislike it intensely). Clearly if the behaviour persists then it is the mount at fault; if it doesn't then that would be pretty incontrovertible proof that the issue lies with Sitech.exe. FWIW when I first got my mount, I had some seemingly random RA jumps but I chased that down to a PXP model gone bad after making some (what I thought were) minor changes to the mechanical configuration. I built a new PXP model and the jumps went away - probably un-related to the current problems people are seeing but I thought I would mention it.
  11. I have great respect for Dan and he may well be right - however he appears in this case to have based his solution on reviewing logs from only 1 or possibly 2 systems that exhibit this issue. Anyhow it looks like those users who are suffering with this are content that a fix is on the way so there's little point in further conjecture; I'll keep quiet
  12. Has anybody considered whether the guiding software used has any bearing on this - I use MaximDL and I recall Steve indicating that he also does - neither of us has (yet) been afflicted by jumps in RA. It seems that some others who use PHD do experience the RA jumps.
  13. I agree, it is unlikely to be an OS related issue per se (it could though conceivably be related to some combination of OS settings). ISTR from another thread that you are using win 10 pro as am I. I have not had any issues with jumps in RA, indeed imaging at around 0.5 arcseconds / pixel RA jumps of the magnitude others have observed would be a huge issue for me.
  14. Narrow band filters enable you to capture detail which is difficult to perceive in a wide band image but there is still quite a detailed structure that can be captured in LRGB. See my LRGB image from last year I think you are on the right path - refining your focus and guiding before leaping into the added challenges presented by narrow band imaging is IMHO your best option. Regards Derrick
  15. Magnus, you might want to read about sampling theory: a system that can sample at roughly 0.33 arcseconds is indeed required to properly reconstruct 2D features separated by 1 arcsecond - it is not resolving features at 0.33 arcseconds. Clearly one cannot capture more detail than permitted by local environmental and atmospheric effects otherwise NASA would not have invested billions of dollars sending telescopes into space. Earth based imaging will always be limited by the seeing which we often evaluate using the FWHM of star images. So if a star is blurred by atmospheric conditions into a disk with a FWHM of 1 arcsecond , we need a system capable of collecting 3.3 samples across the disc at full width half maximum intensity.
  16. It depends on your imaging preferences - if widefield nebulae, galaxy fields etc. are what float your boat you probably don't care much about critical sampling - FOV is king. OTOH if your interest is in imaging PNebs, galaxies and other small objects and extracting the maximum detail for seeing conditions (as mine primarily is) than critical sampling is ... well, critical :-)
  17. I know you are quoting the often-touted conventional wisdom but this is a mis-application of the Nyquist sampling criterion. More correctly, for a 2 dimensional signal you need more like 3 - some (including me) would argue that for critical sampling you need 3.3 pixels to sample correctly. Derrick
  18. Ray, I have owned an EQ-8 and currently have a Mesu200; I usually image at medium to long focal length (1700 - 2500mm) - as you know it is image scale that is important but focal length serves as a reasonable analogue in this case. The EQ-8 was a very sturdy mount with low PE and was easy to use via EQ-ASCOM. Mechanically the mount was adequate but even after less than a year there was some cosmetic tarnishing of fasteners etc. that indicated where low cost materials had been used. Imaging performance at 1500 - 1700mm was IMO just about acceptable - I didn't need to be constantly fiddling with mount balance etc and would typically lose about 15-20% of subs due to mount aberrations (small transient jumps, slips, unexpected drift etc.) - at a shorter focal length (more generous image scale) these may not have been noticeable but imaging at < 1 arcsecond pp is pretty unforgiving. I found imaging at longer focal length (>2000mm) was frustrating and I found myself losing significant amounts of imaging time trying to fine tune the mount to overcome the effects of the mechanical compromises made in the mount design and manufacture. Typically I was lucky not to lose more than 50% of images from a session. Remember though that this is fairly extreme imaging at around 0.5 arcseconds pp which not many people engage in. The net result was that I spent far too much precious imaging time nursing the mount and far too little of the available clear sky time actually collecting usable photons. I replaced the EQ-8 with a Mesu200 about 2 years ago and after the initial setup have lost very few images to mount issues. On the odd clear night I open up the observatory, fire up all the equipment and image without any concerns at all about whether the Mesu200 carrying my qpprox. 50kg imaging setup will perform as expected - it just does. Typically I see guide errors at around 0.25 arcseconds rms with no unexpected glitches, farts or transients. I can think of no better endorsement of a mount for imaging - the Mesu just works as it should. HTH Derrick
  19. Thanks Adriano, the weather here has reverted to normal for this time of year in the UK - clouds, mist and fog :-( I hope it is better where you are
  20. Thanks Steve, this was my first attempt at using the colormask script in PI to modify the SHO image - pretty much following BoB Francke's procedure for colour mapping to the Hubble palette. Derrick
  21. Thanks Barry, it was so nice to have a run of clear nights to collect sufficient data for a half decent image :-) Derrick
  • 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.