Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Is M81 M82 really this hard or is it me?

Astrophotography Software
  • Please log in to reply
69 replies to this topic

#51 Mike in Rancho

Mike in Rancho

    Viking 1

  • -----
  • Posts: 925
  • Joined: 15 Oct 2020
  • Loc: Alta Loma, CA

Posted 10 May 2021 - 08:51 PM

We can attach text files?  Well, that makes things easy.

 

(at least, after I changed .log to .txt, that is lol)

 

I was going to copy and paste plus change the font color of my commentary, but instead just set it off with asterisks.  Nearly infinite ways to go about it, this is just what I did on that night.  Pretty good module explanations on the website plus a pdf manual that is mostly up to date with the current release.

 

Attached File  StarTools psugrue m81.txt   8.06KB   17 downloads


  • psugrue likes this

#52 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 10 May 2021 - 10:05 PM

We can attach text files?  Well, that makes things easy.

 

(at least, after I changed .log to .txt, that is lol)

 

I was going to copy and paste plus change the font color of my commentary, but instead just set it off with asterisks.  Nearly infinite ways to go about it, this is just what I did on that night.  Pretty good module explanations on the website plus a pdf manual that is mostly up to date with the current release.

 

attachicon.gifStarTools psugrue m81.txt

Thank you so much. This is so instructive. It makes me happy that even though I have only been playing with startools for a few hours, I am mostly familiar with what you did just from reading the log. What a killer feature! Tomorrow I will get stuck into this and follow along step for step. It's going to be fun.

 

Cheers,

 

Patrick


  • Mike in Rancho likes this

#53 Mike in Rancho

Mike in Rancho

    Viking 1

  • -----
  • Posts: 925
  • Joined: 15 Oct 2020
  • Loc: Alta Loma, CA

Posted 10 May 2021 - 11:09 PM

Thank you so much. This is so instructive. It makes me happy that even though I have only been playing with startools for a few hours, I am mostly familiar with what you did just from reading the log. What a killer feature! Tomorrow I will get stuck into this and follow along step for step. It's going to be fun.

 

Cheers,

 

Patrick

All good, have fun with it!  Post up what you come up with or anything that works particularly well.  The choices are many and I find it interesting to see how others tackle various issues, and to pick up tricks that can be handy on down the line.

 

I think the one correction I'd make is - I think 16bit fits would work just fine.  For whatever reason ST balked at initially opening the files.  I believe they may have been 16 bit tiff, so I just used DSS to make them all 16 bit fits - no reason to up it back to 32 and just take up space I think.  Anyway ST has opened tiffs for me before, but maybe certain ones it just doesn't like.



#54 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 11 May 2021 - 12:22 AM

This is a screen shot of what I came up with following along as best I could. On the second stretch, I did a "Stretch as is" as opposed to "New global stretch" is that right? I did use the 32 bit (integer).fts files.

 

I am pretty happy for a first attempt. I am def going to pay the license for StarTools. I would like to get the sky a bit blacker and filter out the fuzz.

 

 

Respect,

 

Patrickstdone.jpg  


  • brlasy1 and Mike in Rancho like this

#55 Mike in Rancho

Mike in Rancho

    Viking 1

  • -----
  • Posts: 925
  • Joined: 15 Oct 2020
  • Loc: Alta Loma, CA

Posted 11 May 2021 - 01:55 AM

It's a little bit fuzzy. wink.gif 

 

32 bit is fine.  In fact, I think Ivo recommends it.  Typically DSS will output a 32 bit autosave, either tiff or fits depending on which you chose.  Those work for me and Startools likes them, so I just rename the autosave.fits to whatever identification I want to give it and don't bother with any kind of additional saving.  Sometimes I try out different stacking parameters, so it'll be M13-2hrs-k3 or whatever, if I set the kappa sigma to 3.0.

 

I have always used the re-stretch from scratch button, never the as-is.  In fact, I'm not sure what its usefulness would be.  I'll have to go look that up in the manual now. tongue2.gif

 

I stepped through the other posted log from copper280z also.  Some similarities, and some interesting different techniques too - which completely avoided using SS.  I'll have to keep some of those in mind for trying out on different data.



#56 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 11 May 2021 - 02:12 AM

Here's my ST log, anywhere there's a mask set, I just used the recommended mask type.

 

I think if I were to reprocess, I'd do the 2nd autodev a little differently and allow the background to be a little brighter.

 

attachicon.gifM81 ST Log.txt

Thank you so much for the Log. I will give this one a spin tomorrow. I just paid for and installed the license for Startools.



#57 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 11 May 2021 - 03:03 PM

NewComposite75.jpg

 

Getting there. AutoDev does not seem to work very well for me. I am prob doing something wrong but I am having better luck with FilmDev at about 80%


  • Sky King and Mike in Rancho like this

#58 copper280z

copper280z

    Vostok 1

  • -----
  • Posts: 186
  • Joined: 01 Mar 2019
  • Loc: Rochester, NY

Posted 11 May 2021 - 03:51 PM

That looks great!

I go back and forth on autodev vs film dev. Tricks I use with autodev are to turn up the "ignore fine detail smaller than X pixels" number, and to turn down the shadow linearity number.

But if film dev is working, and you like it, no reason not to just do that!
  • Mike in Rancho and psugrue like this

#59 dx_ron

dx_ron

    Ranger 4

  • *****
  • Posts: 341
  • Joined: 10 Sep 2020
  • Loc: SW Ohio

Posted 11 May 2021 - 05:24 PM

I guess I should post my M81/M82 - everyone else is :)  I won't derail your thread with it, though.

 

I have played around a lot with autodev on my image. Where I think I am happiest is when I select a small ROI mostly along the long axis of M82 (so a pretty small ROI), avoiding including any background. Small changes in the M82 ROI have fairly large effects of how M81 ends up. The version I've settled on right now has some of the fainter M81 outer regions pushed back into the background, but I don't have enough overall signal yet from my light polluted inner suburb to show real detail in those outermost regions anyway.


  • Mike in Rancho and psugrue like this

#60 Mike in Rancho

Mike in Rancho

    Viking 1

  • -----
  • Posts: 925
  • Joined: 15 Oct 2020
  • Loc: Alta Loma, CA

Posted 11 May 2021 - 10:32 PM

 

Getting there. AutoDev does not seem to work very well for me. I am prob doing something wrong but I am having better luck with FilmDev at about 80%

It takes some getting used to.  Using FilmDev, especially when starting out, is rather common, and some people stick with it and I guess become pretty good.

 

I imagine it's that the development slider seems similar to a levels stretch that everyone probably has some experience with.  Still, the likelihood is that a better detailed stretch will occur with AutoDev.  Last night reading around I stumbled across this relevant discussion on Startools that was pretty interesting: https://forum.starto...opic.php?t=1743

 

When I first got started I was drawing repeated ROI boxes, in vary shapes, all over the place and getting a little frustrated.  Now I kind of have a feel for where a box should go and I just throw it up there.  Then instead of redrawing it, I start clicking or sliding the X and Y controls to squeeze or expand the box.  After first dialing in the ignore fine, of course, usually at the point where it balances out with the darkness and contrast.  Then if necessary I can fiddle with the shadow linearity control.  I usually don't need to mess with the outside influence, and anyway if you zero it there's a chance of clipping.

 

One thing about the AutoDev showing those nice details in a ROI box though, is that you can kind of be tricked into overstretching beyond what the overall image data can handle.  That section might look nice, but in the end you can have a bunch of muck that can't be eliminated.

 

Finally as with any software I think, the better the data the better Startools works.  Try some tutorial or other excellent data and you'll be amazed at how little you need to use Wipe and how good the Autodev makes it.

 

Remember too that this data here is a little off perhaps.  With your telescope I really don't think you should have had those blue halos to deal with.

 

Anyway, from the logs you should be able to replicate the ROI used by me or copper280z, and then tweak other settings to just watch what happens.  Pretty big jump already though from your first try to the latest!  waytogo.gif


  • psugrue likes this

#61 idclimber

idclimber

    Apollo

  • -----
  • Posts: 1,359
  • Joined: 08 Apr 2016
  • Loc: McCall Idaho

Posted 11 May 2021 - 11:44 PM

I am only a few miles north of you up in McCall. What gain are you using with the 1600? and do you have a target average ADU that you are aiming for?

 

I will also add that I did not get good results on this target until I got over 10 hours of data. Some of my images are over 40hrs using the 1600mm. And my skies up in the mountains are a lot better than down in the valley. 


  • psugrue likes this

#62 BQ Octantis

BQ Octantis

    Aurora

  • *****
  • Posts: 4,810
  • Joined: 29 Apr 2017
  • Loc: Red Centre, Oz

Posted 12 May 2021 - 02:24 AM

I don't know…I think your M81 has a lot more detail to give up. Here it is at 40% scale:

 

(Click for 100% scale.)

gallery_273658_12412_57124.jpg

 

BQ


  • brlasy1 and psugrue like this

#63 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 12 May 2021 - 08:41 PM

I am only a few miles north of you up in McCall. What gain are you using with the 1600? and do you have a target average ADU that you are aiming for?

 

I will also add that I did not get good results on this target until I got over 10 hours of data. Some of my images are over 40hrs using the 1600mm. And my skies up in the mountains are a lot better than down in the valley. 

139 gain I think. Does that sound right? I have heard of ADU and if I ever figure out what it is, I might have a target for it.

 

Respect,

 

Patrick



#64 idclimber

idclimber

    Apollo

  • -----
  • Posts: 1,359
  • Joined: 08 Apr 2016
  • Loc: McCall Idaho

Posted 12 May 2021 - 10:18 PM

139 gain I think. Does that sound right? I have heard of ADU and if I ever figure out what it is, I might have a target for it.

 

Respect,

 

Patrick

Yes, 139 is what I used for RGB with my 1600mm. That is what is called unity gain where there is a one to one relationship between the an ADU unit and a single electron. The other gain I used was 200 for my narrow band filters. I mostly imaged at f/5.25 but can also setup my refractor at f/7. I also have an 12" SCT at f/7.

 

ADU is an acronym for Analog Digital Unit. Each pixel on the camera measures an amount of light that is detected during an exposure. The 1600 like a lot of cameras is 12 bit, this is usually displayed by your imaging program as a 16 bit file (at least it does with mine). If so it will scale the levels from 1 to a little over 65500. To verify this just look at the maximum ADU level of the image. 

 

Looking at ADU values will allow you to evaluate the exposures of your images. This is especially helpful with the linear files that these cameras save. We want to make sure that we have exposed long enough that the background is above the noise of the sensor so when we stack them they look their best. We also want to minimize any clipping of the central cores of our stats if possible. My software allows me to place a crosshair and measure the actual recored values of my test images when I am trying to determine my exposure for a given target. 

 

With this camera this is the targets for average ADU that I determined using a formula posted here by Jon Rista. 

 

Gain 139, Offset 40 = Target average ADU of 467 to 810

Gain 200, Offset 40 = Target average ADU of 856 to1360

 

If you have a location that you can upload a singe light frame, I can evaluate it for you and tell you what it measures. 


  • psugrue likes this

#65 psugrue

psugrue

    Vostok 1

  • -----
  • topic starter
  • Posts: 158
  • Joined: 11 Nov 2020
  • Loc: Boise Idaho

Posted 13 May 2021 - 12:40 PM

Yes, 139 is what I used for RGB with my 1600mm. That is what is called unity gain where there is a one to one relationship between the an ADU unit and a single electron. The other gain I used was 200 for my narrow band filters. I mostly imaged at f/5.25 but can also setup my refractor at f/7. I also have an 12" SCT at f/7.

 

ADU is an acronym for Analog Digital Unit. Each pixel on the camera measures an amount of light that is detected during an exposure. The 1600 like a lot of cameras is 12 bit, this is usually displayed by your imaging program as a 16 bit file (at least it does with mine). If so it will scale the levels from 1 to a little over 65500. To verify this just look at the maximum ADU level of the image. 

 

Looking at ADU values will allow you to evaluate the exposures of your images. This is especially helpful with the linear files that these cameras save. We want to make sure that we have exposed long enough that the background is above the noise of the sensor so when we stack them they look their best. We also want to minimize any clipping of the central cores of our stats if possible. My software allows me to place a crosshair and measure the actual recored values of my test images when I am trying to determine my exposure for a given target. 

 

With this camera this is the targets for average ADU that I determined using a formula posted here by Jon Rista. 

 

Gain 139, Offset 40 = Target average ADU of 467 to 810

Gain 200, Offset 40 = Target average ADU of 856 to1360

 

If you have a location that you can upload a singe light frame, I can evaluate it for you and tell you what it measures. 

OK this is very interesting. I think I am starting to get ADU maybe? So ADU is a metric that we can use to verify that a Light frame is not over or under exposed? It looks like I can see the ADU in NINA under "Image History" It lists the mean value for ADU for all my images. I was thinking that I needed to lower my exposure on Lum because 360s looked over exposed relative to RGB so I did a session at 120s for Lum. But I think what you are teaching me here is that I can keep my Lum at 360s the same as my 360s RGB and just lower the gain for Lum to keep in the same ADU range. Is that right or am I still confused?



#66 Mike in Rancho

Mike in Rancho

    Viking 1

  • -----
  • Posts: 925
  • Joined: 15 Oct 2020
  • Loc: Alta Loma, CA

Posted 13 May 2021 - 05:04 PM

OK this is very interesting. I think I am starting to get ADU maybe? So ADU is a metric that we can use to verify that a Light frame is not over or under exposed? It looks like I can see the ADU in NINA under "Image History" It lists the mean value for ADU for all my images. I was thinking that I needed to lower my exposure on Lum because 360s looked over exposed relative to RGB so I did a session at 120s for Lum. But I think what you are teaching me here is that I can keep my Lum at 360s the same as my 360s RGB and just lower the gain for Lum to keep in the same ADU range. Is that right or am I still confused?

Probably?  I think the reason for targeting ADUs is to stay off the left, but retain dynamic range to the right, so it would seem logical to be the same.

 

Regardless of the individual exposures though, for sure you want to increase that total integration time on the L, though I don't know what the rule of thumb ratio might be.


Edited by Mike in Rancho, 13 May 2021 - 05:04 PM.

  • psugrue likes this

#67 dx_ron

dx_ron

    Ranger 4

  • *****
  • Posts: 341
  • Joined: 10 Sep 2020
  • Loc: SW Ohio

Posted 13 May 2021 - 07:04 PM

If you want to calculate exposure time based on sky brightness and telescope characteristics, this spreadsheet is an awesome resource.


  • psugrue likes this

#68 jonnybravo0311

jonnybravo0311

    Surveyor 1

  • *****
  • Posts: 1,749
  • Joined: 05 Nov 2020
  • Loc: NJ, US

Posted 13 May 2021 - 07:20 PM

OK this is very interesting. I think I am starting to get ADU maybe? So ADU is a metric that we can use to verify that a Light frame is not over or under exposed? It looks like I can see the ADU in NINA under "Image History" It lists the mean value for ADU for all my images. I was thinking that I needed to lower my exposure on Lum because 360s looked over exposed relative to RGB so I did a session at 120s for Lum. But I think what you are teaching me here is that I can keep my Lum at 360s the same as my 360s RGB and just lower the gain for Lum to keep in the same ADU range. Is that right or am I still confused?

If you're using NINA, take a look at the image stats. You'll see min, median, mean, max. Next to min and max you'll see something like (###x). For example, you might see min 1000 (1x) max 65535 (152x). That means the lowest recorded ADU value for this image is 1000, and 1 pixel has this value. The highest recorded ADU value for this image is 65535 and there are 152 pixels at that value.

 

Since NINA reports your image in 16 bit, any time you see the max equal (or near to) that 65535 value, all of the ###x pixels are clipped (i.e. pure white - no color will be recoverable). It is inevitable some of your pixels (especially in bright star cores) are going to clip. The object is to keep that number relatively low. However, you also have to consider the other end of the spectrum. Sure, I can prevent (or drastically reduce) the number of star cores I clip by taking a silly short exposure. The problem with that approach is now all I've got is sensor noise, and I'll never be able to recover any of the faint details because they're all lost in the noise. This is where the term "swamp the sensor" comes into play. You want to ensure your exposures are long enough that the signal (i.e. the light from the night sky) overwhelms the sensor noise, but not so long that you're clipping all the highlights (stars and other extremely bright regions).

 

The classic example is M42. Absurdly easy target to find and frame. Extremely difficult target to get right because it has such a giant dynamic range: Extremely bright in the core and trapezium. Extremely faint dust and nebulosity the further you get from that core. Now you're getting into advanced capture and editing techniques (long and short exposures, HDR combinations, etc).


  • psugrue likes this

#69 idclimber

idclimber

    Apollo

  • -----
  • Posts: 1,359
  • Joined: 08 Apr 2016
  • Loc: McCall Idaho

Posted 13 May 2021 - 10:22 PM

OK this is very interesting. I think I am starting to get ADU maybe? So ADU is a metric that we can use to verify that a Light frame is not over or under exposed? It looks like I can see the ADU in NINA under "Image History" It lists the mean value for ADU for all my images. I was thinking that I needed to lower my exposure on Lum because 360s looked over exposed relative to RGB so I did a session at 120s for Lum. But I think what you are teaching me here is that I can keep my Lum at 360s the same as my 360s RGB and just lower the gain for Lum to keep in the same ADU range. Is that right or am I still confused?

ADU is simply the standard measure of how dark or bright a pixel is in our image. The average allows us a good idea how much we have raised the detail in our image above the background noise. This is often referred to "swamping the read noise". If we raise this too high we start to clip the stars to solid white and loose the color data and overall the image suffers. 

 

I shoot all my lum with shorter exposures than RGB. The last couple nights lum has been 150 seconds while RGB were at 300. This is with my newer ASI2600mm though so don't use those numbers as direct comparisons. I did the same with my 1600mm last year. 

 

To answer another question about how many exposures with each filter. I have my imaging script set to take three lum for every set of RGB. The detail comes from lum once you know how to process it. I image over multiple nights for each target. My longest integration is over 40 hours. Once I have what I consider enough RGB I often switch to just gathering more lum and perhaps a set of Ha if the target has that data. 


  • psugrue likes this

#70 idclimber

idclimber

    Apollo

  • -----
  • Posts: 1,359
  • Joined: 08 Apr 2016
  • Loc: McCall Idaho

Posted 13 May 2021 - 10:26 PM

I recommend the following books to help you better understand the technical aspects of imaging. 

 

 

https://www.amazon.c...,aps,251&sr=8-1

 

https://www.amazon.c...,aps,272&sr=8-1

 


  • psugrue likes this


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: Astrophotography, Software



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics