•

# ASI1600mm-c Cheat Sheet - No math

This topic has been archived. This means that you cannot reply to this topic.
95 replies to this topic

### #51 calan

calan

Viking 1

• Posts: 806
• Joined: 16 Jun 2007

Posted 01 May 2017 - 05:26 PM

`MinDN16 = (((ReadNoise * 20) / Gain) + BiasOffset) * 2^16/2^Bits`

WHERE:

Gain is the gain in e-/ADU
Bits is the bit depth of the camera

So, for the ASI1600 @ Gain 0 with 3.5e- read noise and 4.88e-/ADU at 12-bit:

`MinDN16 = (((3.5 * 20) / 4.88) + 10) * 16 = ((70 / 4.88) + 10) * 16 = (14.4 + 10) * 16 = 25 * 16 = 400`

Jon...

Where does the "at 12-bit" figure into this equation? I thought the 1600 was a 12-bit camera, but it looks like you used 16 bit in the equation. What am I missing?

I'm gonna figure this stuff out if it kills me.

### #52 Thirteen

Thirteen

Gemini

• Posts: 3,192
• Joined: 12 Jul 2013

Posted 01 May 2017 - 05:31 PM

The 16 in that last equation is the result of converting 12-bit to 16-bit....

2^16 / 2^12 = 16

Hope that makes sense, but holler if not.

Edited by Thirteen, 01 May 2017 - 05:31 PM.

### #53 calan

calan

Viking 1

• Posts: 806
• Joined: 16 Jun 2007

Posted 01 May 2017 - 05:43 PM

The 16 in that last equation is the result of converting 12-bit to 16-bit....

2^16 / 2^12 = 16

Hope that makes sense, but holler if not.

Got it. I was seeing 2^16 / 2^16 and coming up with 1 for some reason.

If anyone can help, I'm looking for numbers that I can plug into an excel sheet I made for the ASI224MC.

Thanks Jason

Edited by calan, 01 May 2017 - 05:45 PM.

### #54 calan

calan

Viking 1

• Posts: 806
• Joined: 16 Jun 2007

Posted 01 May 2017 - 05:46 PM

On a semi related note, I use SharpCap (never used SGP). Is there a way to convert something that SC gives us into an equivalent of SGP's median ADU readout?

(I've already mentioned this to Robin)

### #55 rockstarbill

rockstarbill

Voyager 1

• Posts: 11,480
• Joined: 16 Jul 2013

Posted 02 May 2017 - 12:22 AM

I am writing a simple command line program that can calculate this and spit out the right value, as long as the user knows the right numbers to plug in. Problem is, I am coming up with different results than this thread claims. I have no intention of spreading the code around - I am more concerned with why the numbers are not matching up.

### #56 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 02 May 2017 - 12:58 AM

Bill, I padded and rounded to nice numbers. My 400 in the quoted post above is just that, rounded from 389 to 400. It doesn't have to be dead-on precise. The difference between the two back-calculates to about 3e-, so 73e- vs. 70e-. Not a difference that really matters in the end.

### #57 rockstarbill

rockstarbill

Voyager 1

• Posts: 11,480
• Joined: 16 Jul 2013

Posted 02 May 2017 - 01:02 AM

Good to know. I like to make small little programs to calculate useful things so I dont have to search for bookmarks in my browser.

### #58 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 02 May 2017 - 01:04 AM

I do too. I write most of my stuff with javascript for node. Very simple, very handy.

### #59 rockstarbill

rockstarbill

Voyager 1

• Posts: 11,480
• Joined: 16 Jul 2013

Posted 02 May 2017 - 01:06 AM

I like me some old school C. Makes me feel like I worked for it.

### #60 calan

calan

Viking 1

• Posts: 806
• Joined: 16 Jun 2007

Posted 02 May 2017 - 01:12 AM

Excel.

I'm an Excel junkie.

### #61 rockstarbill

rockstarbill

Voyager 1

• Posts: 11,480
• Joined: 16 Jul 2013

Posted 02 May 2017 - 01:23 AM

Excel has its limits though. I like C because its easy to write, and really easy to port and compile anywhere. For complex stuff you'd want to look elsewhere, but for the basics, c is pretty nice. Especially on Linux since you have the man pages built into the OS.

### #62 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 02 May 2017 - 01:35 AM

I like node.js for the same reason. Highly portable, basically no limitations, easily installable with package managers (and has it's own package manager, NPM.)

### #63 calan

calan

Viking 1

• Posts: 806
• Joined: 16 Jun 2007

Posted 02 May 2017 - 05:46 AM

Excel has its limits though.

I've hit very few with it, given that it's a Windoze environment of course.

I wrote a full-blown data aquisition and logging/analysis package with it a few years ago. That one kicked my arse...but was a lot of fun.

Now I need to figure out how to adapt that ^ to Jon's math and knowledge of astro-imaging.

Edited by calan, 02 May 2017 - 05:47 AM.

### #64 vagrom

vagrom

Vostok 1

• Posts: 191
• Joined: 05 Sep 2016

Posted 02 May 2017 - 07:39 AM

I like Python and have started to use the astropy.org library. I have a juptyer notebook for this thread actually! Although I am more proficient in Java.

### #65 Midnight Dan

Midnight Dan

James Webb Space Telescope

• Posts: 15,788
• Joined: 23 Jan 2008

Posted 02 May 2017 - 08:45 AM

I am writing a simple command line program that can calculate this and spit out the right value, as long as the user knows the right numbers to plug in. Problem is, I am coming up with different results than this thread claims. I have no intention of spreading the code around - I am more concerned with why the numbers are not matching up.

Not sure why you'd need to write software to handle this.  It's a one-time calculation for each gain setting for your camera.  And you generally don't need more than 2 or 3 different gain settings for normal use.  With my ASI071, I settled on 3 gain setting: 0.5 e-/ADU, 1 e-/ADU, and 2 e-/ADU (gain settings of 30, 90, and 150).  I did the 3 calculations for 20xRN and wrote the results on a piece of paper for reference.

-Dan

### #66 rockstarbill

rockstarbill

Voyager 1

• Posts: 11,480
• Joined: 16 Jul 2013

Posted 02 May 2017 - 10:07 AM

I am writing a simple command line program that can calculate this and spit out the right value, as long as the user knows the right numbers to plug in. Problem is, I am coming up with different results than this thread claims. I have no intention of spreading the code around - I am more concerned with why the numbers are not matching up.

Not sure why you'd need to write software to handle this. It's a one-time calculation for each gain setting for your camera. And you generally don't need more than 2 or 3 different gain settings for normal use. With my ASI071, I settled on 3 gain setting: 0.5 e-/ADU, 1 e-/ADU, and 2 e-/ADU (gain settings of 30, 90, and 150). I did the 3 calculations for 20xRN and wrote the results on a piece of paper for reference.

-Dan

It's a tiny command line tool that calculates this for me. No paper needed, and eliminates the need for me to do anything but run it and feed it values. Useful to me.

### #67 ecorm

ecorm

Viking 1

• Posts: 580
• Joined: 21 Nov 2015

Posted 03 May 2017 - 03:53 PM

Last winter, I tried the suggested 20xRN rule of thumb for the Orion Nebula at unity gain (using ASI1600 + LRGB). The brighter stars ended up being badly blown and bloated. I have green zone light pollution.

Is this an instance where I'd go with a "compromise" 10xRN? Or should I be looking into capturing a second set at shorter exposure and doing an HDR composite in post-processing?

### #68 ecorm

ecorm

Viking 1

• Posts: 580
• Joined: 21 Nov 2015

Posted 03 May 2017 - 04:22 PM

I guess what I'm saying is that we have this nifty rule of thumb for what the left side of the histogram should look like. But what about the right side? How should one deal with clipping?

### #69 Midnight Dan

Midnight Dan

James Webb Space Telescope

• Posts: 15,788
• Joined: 23 Jan 2008

Posted 03 May 2017 - 05:03 PM

ecorm:

Just my 2 cents, but with my camera and my skies, I'm finding the 20xRN impossible to achieve on dark nights.  I have the ASI071, which is a color OSC camera and will have very different behavior from the 1600 and LRGB.

But I'm finding that when I expose around 5 minutes, at unity gain, I end up with a handful of the brightest stars saturated, and the mean value is only around 10xRN.  If I try to expose longer, I'll just end up saturating way too many stars.  I could go for lower gain to get more dynamic range, but then I'll need even longer exposures.  And for my mount, I don't like to go much beyond about 5 minutes.

I'm in a yellow-orange border light pollution area.  I've imaged when the moon is out, and then I can achieve a mean of 20xRN because there is so much skyglow.  But in my normal skies, no can do.  So I think for those of us with at least moderately dark skies, getting to 20xRN is going to be a problem.

-Dan

### #70 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 03 May 2017 - 06:48 PM

You can certainly scale it back to 10x. You could also use the 3*RN^2 rule, which would be even lower than the 10x rule. The 3*RN^2 rule will scale relative to the square of the read noise. So if you follow that rule, then there is effectively no real advantage to having lower read noise vs. a camera that has higher read noise...not once you get the same total integration time. Additionally, you will likely find that with this rule that your exposures are extremely short, and that you need more of them than you can handle, unless you are at a really nice dark site.

For RGB imaging, using a lower gain is usually more viable than a higher gain, since you get more DR at lower gain. For the ASI071, it's a 14-bit sensor with very high DR (over 13 stops at minimum gain, IIRC). That is a lot more than even most of the best CCD cameras. So you should not have any problem with DR at a lower gain setting with the ASI071. It's peak read noise is about 3.3e-, which is still quite low. So you shouldn't have problems getting good exposure lengths and minimal if any clipping issues at a lower gain settings. You might need to tweak and fiddle a bit with different rules to find the sweet spot. But there is a sweet spot.

Also, keep in mind that star saturation rate is primarily determined by the aperture of the scope (and secondarily the Q.E. of the sensor and image scale). A larger aperture that is still relatively fast (moderate to faster f-ratio) will have an image scale that allows stars to saturate very quickly. I have this problem with a 150mm aperture at f/4 (1.3"/px). Now, an 80mm f/4, or f/5, or f/6, would have much less problem saturating stars so quickly, since the smaller aperture just isn't going to gather as much light per unit time for each star.

Edited by Jon Rista, 03 May 2017 - 06:51 PM.

### #71 ecorm

ecorm

Viking 1

• Posts: 580
• Joined: 21 Nov 2015

Posted 03 May 2017 - 07:46 PM

For RGB imaging, using a lower gain is usually more viable than a higher gain, since you get more DR at lower gain.

On a high dynamic range target, such as M42, let's say that I lower the gain to get more DR and avoid blowing up the bright stars. Also assume that I keep my exposure and total integration time the same. Won't I end up with worse SNR in the dark regions, and will therefore not be able to stretch the faint nebulous details as much?

If I want a win-win of being able to stretch out faint details, while avoiding overexposure, is my only option to capture at two different exposure/gain levels and produce a composite HDR image in post-processing?

I'm curious to know what you think of the "synthetic 16-bit" idea I proposed in this other thread.

### #72 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 03 May 2017 - 07:50 PM

For RGB imaging, using a lower gain is usually more viable than a higher gain, since you get more DR at lower gain.

On a high dynamic range target, such as M42, let's say that I lower the gain to get more DR and avoid blowing up the bright stars. Also assume that I keep my exposure and total integration time the same. Won't I end up with worse SNR in the dark regions, and will therefore not be able to stretch the faint nebulous details as much?

If I want a win-win of being able to stretch out faint details, while avoiding overexposure, is my only option to capture at two different exposure/gain levels and produce a composite HDR image in post-processing?

I'm curious to know what you think of the "synthetic 16-bit" idea I proposed in this other thread.

If you don't change your exposure, there would be a chance in SNR of faint details, yes. However, the difference between say 2e- read noise and 3.3e- read noise is not that large. You might need to increase exposure a little bit, however, it's highly unlikely you would need to increase exposure so much that you still blew out details with over 12 stops of dynamic range. You would need a really huge aperture and a really fast f-ratio (i.e. say a Hyperstar) to still have an issue.

### #73 ecorm

ecorm

Viking 1

• Posts: 580
• Joined: 21 Nov 2015

Posted 03 May 2017 - 09:56 PM

You could also use the 3*RN^2 rule, which would be even lower than the 10x rule. The 3*RN^2 rule will scale relative to the square of the read noise. So if you follow that rule, then there is effectively no real advantage to having lower read noise vs. a camera that has higher read noise...not once you get the same total integration time. Additionally, you will likely find that with this rule that your exposures are extremely short, and that you need more of them than you can handle, unless you are at a really nice dark site.

Thanks for all your help, Jon. Can you me point towards a post or thread that discusses this 3*RN^2 rule? I can't search for it because of all the non-alphabet symbols.

### #74 Jon Rista

Jon Rista

ISS

• Posts: 25,616
• Joined: 10 Jan 2014

Posted 03 May 2017 - 10:01 PM

It's just that, three times the read noise squared. If you read noise is 3.3e-, then it's:

3.3e-2 x 3 = 10.89e- x 3 = 32.67e-

For the rest, you can check out this thread:

https://www.cloudyni...-sheet-no-math/

### #75 ecorm

ecorm

Viking 1

• Posts: 580
• Joined: 21 Nov 2015

Posted 03 May 2017 - 11:07 PM

It's just that, three times the read noise squared. If you read noise is 3.3e-, then it's:

3.3e-2 x 3 = 10.89e- x 3 = 32.67e-

For the rest, you can check out this thread:

https://www.cloudyni...-sheet-no-math/

I understand the arithmetic. What I don't understand is why the square of the read noise and why times 3? I had assumed you already covered this in some other thread and was hoping to read up on it.

I guessing the 3*RN^2 formula has something to do with putting the median DN 3 standard deviations to the right of the RN? My stats math is very rusty.

## Recent Topics

 Cloudy Nights LLC Cloudy Nights Sponsor: Astronomics