Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

Padraic M

Members
  • Posts

    514
  • Joined

  • Last visited

Posts posted by Padraic M

  1. 4 minutes ago, teoria_del_big_bang said:

    Also where an automatic rotator becomes very useful is when adding two targets to the nights sequence (maybe 1st target foes out of view at some point in the evening) that really do need a very different rotation to get them in the correct framing as you can use two previous images, or even use two images found on line with correct framing if you do not have previous images) and the software (certainly EKOS and NINA will) will platesolve and rotate to correct framing whilst the rig was left unattended and you are getting some zzzzzz's in.

    Steve

    Do you bother with separate flats for the two rotations? Does it make a difference?

    • Like 1
  2. I wouldn't be inclined to up the gain. Stars are so bright compared to everything else in a DSO image that they're likely to saturate early even at unity gain. I normally use 30 or 60-sec subs @unity for RGB stars. There's a logic for using lower gain for RGB and higher gain for narrowband as the NB filters block a lot of the star light.

    Good discussion on CloudyNights if you search for "Have I understood CMOS camera gain correctly?"

    • Thanks 1
  3. I think most people would view a rotator as a nice-to-have. As @Realtimedoctor says, you can adjust the camera angle in the drawtube. NINA provides a great manual rotator control that prompts you until the angle is within an acceptable range.

    Having said all of that, I'm waiting for a manual rotator aka 'Camera Angle Adjuster' to arrive in the post. My rationale is that my camera is connected by screwed connectors only so there is no way to rotate the image, and I now have a second imaging rig and if I'm going to combine data from both, the camera angles will need to be aligned.

    One big downside is that if you rotate more than a small amount, you will need to shoot new flats. For example, dust bunnies on the camera-side of the rotator will no longer line up with dust marks on the scope side of the rotator.

    If you have a fully automated remote setup, then an automated rotator is a higher priority, although still not essential.

    • Like 1
  4. Hi @BrendanC I know I'm coming late to this discussion and you've made great progress with the issues already, but just to add some thoughts on light leaking through the PDS OTAs. I recently took on a 150PDS and had issues with gradients and LP. I tested the OTA for leaks (similar to what Vlaid suggested earlier), by putting the scope cover in place; looping 1-second or 2-second captures, and shining a bright torch all over the OTA. I found issues with the primary mirror end, obviously, but I also found significant issues around the focuser draw-tube. I know that you've covered the primary end with a shower-cap, but you will also need to cover the focuser draw-tube somehow. I haven't quite found the best way to do this. I use tin-foil when I'm taking flats, but when taking lights there will need to be some flexibility there to allow for autofocus movement of the draw-tube while still blocking the light.

    Bear in mind that there should be very little light-leak at night when taking lights, but a nearby street light, or potentially an LED on some part of your rig, could cause problems over a number of minutes exposure.

    However, when your LED panel is lit up to take flats, you will definitely get lots of light leaking into the focuser, unless you have fully masked the LED panel around the scope aperture. This means that the lights could be fine but your flats are contaminated.

    Finally, any environmental lighting shining obliquely across the OTA opening may illuminate the inside of the tube slightly and cause problems. I now fit a sizeable dew shield the the top of the scope to protect the opening (actually the dew shield for my C8 SCT fits perfectly).

    Environmental light leaks are a pain because they move relative to the OTA/sensor as you track and flip; while sky light pollution and vignetting/reflections in the optical path stay in the same orientation as the image. Consider if you were to track a DSO through a full 90 degrees; your environmental light leak would illuminate your subs on two or even three sides through the duration of the session. No light pollution/gradient removal tool will be able to address this. You may also get LP gradients at different angles in your R, G and B channels when shooting mono as the light ingress angle will change relative to the OTA as the night progresses.

    hth

    • Thanks 1
  5. @Pitch Black Skies re the crop comment - just that in trying to keep both M81 and M82 in frame, you've lost the left-most edge of M81.  It's always a temptation with this pair if your field of view isn't wide enough to fully fit both. My approach at the moment is to do both separately, and see about a mosaic at some stage in the future when I have enough data on both.

    On the dark background - I see from other posts that you're using Startools. I know that others can get great results from Startools but in spite of spending many hours with many images in there I've never managed to get it right. If anyone can guide you through that process, Alacant can. In your other posts I can see the typical 'blotchy' dark background that I get with Startools.

    In the meantime, you could try the basic levels and curves approach in Photoshop or Gimp - it won't give super results, but gives a good understanding of what is happening with dynamic range adjustment. I loaded your jpeg into Gimp below - adjusted the mid point down slightly to stretch the histogram just a tiny bit, and then pulled the black point up slightly to retain the overall contrast level. This reveals more detail in the background - possibly IFN.

    image.png.d2c0f0101a8dee708ae3d57c86a9469c.png

    My workflow is very simple - I stack in AstroPixelProcessor (which is a step up from DSS) and do some basic image processing in APP such as light pollution removal, star colour calibration and a light stretch. Then in Gimp to adjust the levels as above, boost the colour saturation and finalise the image including bit-depth, size and file type.

    • Thanks 1
  6. 2 hours ago, Felias said:

    It looks greenish on my screen, not yellow. I have tried using Siril's photometric calibration, and it seems to get better, though it's rather reddish. But I only had your already calibrated jpeg to start with, so I didn't expect it to work perfectly. Maybe you could try with your stacked tiff/fits file, and remove the green noise if it doesn't completely go after the calibration.

     

    bode.thumb.jpg.1e529d53b4de139cbc77626e6273117b.jpg

    Interesting - thanks for that pointer. I've just had a beginner's play with the latest Siril and it looks very good. Here's a quick version using 100 1-minute lights with corresponding darks, flats and dark-flats. RGB OSC only. I have to figure out how to add Ha. I also need to understand how to manage noise, as it's quite obvious here. Other than that it's a lot better than my first attempt.

    1523194556_M81Siril.thumb.jpg.26e646058b2d4dbb8c33a8316d7e848c.jpg

    • Like 1
  7. 3 hours ago, Pitch Black Skies said:

    Really nice 👍

    Mine seem to end up looking unrealistic.

    Any ideas?

    1209457644_M81M824hr21minfullycalibrated_095343.jpg.22996df8089cb11fba9c412df523bc78.jpg

    I don't think that's unrealistic at all. Lots of great detail in both galaxies, and you've captured the starburst red in M82. Obviously the crop shows some 'artistic license' 😀, and in my opinion the background is too black - I suspect you may have clipped some of the darker detail. I can't really see the star colour or star shape from the final image.

    • Thanks 1
  8. Thanks David - yes, that's 4263 to the bottom-right. Stellarium has pointed out two more smaller galaxies hanging just off the left of M51's 'companion', almost hidden in the tidal dust - IC4277 and IC4278.

    I'm enjoying the 533MC OSC. The plan is to use it in dark skies for filter-less RGB, and capture mono narrowband in the city. The OSC workflow is so much more straightforward! Pleasantly surprised with the results I'm getting even in the city with this camera.

  9. I get the same problem from time to time with NINA. Quite significant star trailing in the platesolve subs after a meridian flip. It's not related to the settle time - I now use 8 seconds as default, and mostly have no issues. My second choice plate solver is astrometry which has as an advantage that the platesolve subs are saved online in your account, so you can see the subs used for platesolving. Astrometry can normally solve even with badly-trailed stars, so as an interim fix, you could try that.

    While it could be a bug in NINA, I suspect that it could alternatively be related to PHD2 settings - if PHD2 can't select a suitable guide star after the flip, guiding will stop. I had that issue earlier this week when I upgraded PHD2 to the latest version, and some of my guiding and camera settings changed (constantly getting "Star Lost" messages). Reverting back to the old version with the old settings fixed the issue. It doesn't explain why the star trails are so long without guiding, as the mount should still be tracking at sidereal rate. Even if the mount wasn't tracking at all it still shouldn't cause trails this long in 8 seconds (my default exposure for platesolving). 

     

    Here's an example of a platesolving sub that Astrometry couldn't solve, and a second example of a trailed sub that Astrometry solved successfully. 

    image.png.68a650cf27acc79aeeafbdb681486e6e.png

    Success:
    image.png.f2f13588a9abd9a8fc3600fc0f4c06ef.png

     

    If I get a chance later tonight, I'll calculate how long those trails are in arc-seconds and compare that to sidereal rate.

  10. This is 444x60s RGB subs from ASI533MC Pro and Esprit 80, no filter, captured over 5 nights in the last week.
    Total integration time is 7hrs 24mins.
    Bortle 8 city skies.

    M51-all_filtered.thumb.jpg.300da32568b57f54230f66d61530a526.jpg

     

    Whenever I get good weather under darker skies, I may revisit to try get more of the tidal tail. I may also try to add some Ha.

    • Like 12
  11. I've had the same problem since updating to 2.6.11. A rig that was happily guiding from 0.5" to 1" on a bad night has gone to 2"+ on good nights.

    Auto-select insists on selecting faint stars really close to my 'Minimum Star HFD' setting, and then can't sustain guiding with that star. I had to go back to manually selecting a single (saturated) star to get any guiding at all.

    I've just reverted to 2.6.10, and with the same rig and the same settings I'm back to auto-select with no issues, and guiding currently at 0.75".

  12. I suspect over-stretching as well. What did you use to process it? Did you capture with the 2600MC? I know that sensor is very sensitive but I'd be surprised if it blows out at 120s. For comparison, I was on M51 last night as well, and this is 3.5 hrs in 60s  subs with a 533MC (unity gain 100, offset 21). I believe Bortle 8 skies respond better to shorter subs. It's noisy, but not saturated.

    Processed in APP with a 10% stretch, and finished with just a levels nudge in Gimp.

    M51-RGB2.thumb.jpg.841b25cea7f1fbacf9cb321650877400.jpg

    • Thanks 1
  13. I've just finished first light with the ASI533MC Pro. I've spent the weekend in Bortle 2 but with a full moon and a breeze so good conditions but not ideal. Bode was a good test subject as it was at a good remove from the moon.

    The 533 is very easy to handle with the SW 150PDS and TS coma corrector - just using the spacers supplied with the camera to give the correct back focus. I could cool to -20c when outside, but couldn't match it the following day to shoot darks, so the image below is shot at -20c and calibrated with -15c darks. I'll shoot at -15c or -10c in future. 

    Stacking RGB in APP is a lot more straightforward than mono too - one workflow rather than three! 

    On the downside, I'm surprised that there wasn't more colour in the final image. The galaxy is a jaundiced yellow straight out of APP, and the stars are also yellow. APP star colour calibration (csc) washed out the galaxy and still didn't add much colour to the stars. I experimented with galaxy-only and star-only frames using Starnet++; also tried Startools; but in the end settled with a lpc-cbg (no star calibration) output from APP with some ASI1600MM Ha added from an earlier session and finished in Gimp.

    Total exposure is 3hrs 20m RGB + 2hrs 45m Ha.

    I've continued to struggle with flats for the 150PDS as it leaks light, but I think I have it sorted now - there is light ingress from the secondary end, and also around the focuser drawtube. There were some remaining circular bands of brightness but thanks to @mackiedlm's recent capture, I've realised that they are actually IFN!

    Any comments on better star colour or size appreciated.

    Bode-HaRGB.thumb.jpg.b15d4bd5d13412b63864837bf13c3327.jpg

    • Like 7
  14. I don't know about the EQ5 but I had similar problems with a HEQ5 - with a generic power brick rated 12V 10A, voltage dropped close to 11V under load and mount behaved erratically. It didn't fail as gracefully as yours - it could stop moving or take a random slew at any stage. It's been perfect since I upgraded the PSU to 13.8V.

    That Nevada Radio PSU will be fine. The cigarette output at 5A will give you plenty of juice so just get a cigarette male connector to 5.5mm x 2.1mm. Forget about the ring connectors.

    • Like 1
×
×
  • 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.