•

# Calculating Sky Background Flux

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

### #1 GeneralT001

GeneralT001

Mercury-Atlas

• topic starter
• Posts: 2,747
• Joined: 06 Feb 2012

Posted 27 December 2016 - 12:37 PM

Have I got this right?

Looking at a Lum sub in PI I get an average K value for the background of 700. I need to subtract 100 from this value for the pedestal, so I now have 600 as a true average of the background flux.

I take this 600 and x by the gain (which is 5e- at 0 gain on the ASI 1600) so, 600 x 5e- = 3000e-

Then,3000e- ÷ exp time (30s) which is = 3000e- ÷ 30s = 100e-/sec of background flux

Is this correct and if so is 100e-/sec a large number for background flux?

Thanks

### #2 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 27 December 2016 - 12:53 PM

Did you configure the PI probe to use 12-bit for the ASI1600? Or is it configured for 16-bit?

### #3 GeneralT001

GeneralT001

Mercury-Atlas

• topic starter
• Posts: 2,747
• Joined: 06 Feb 2012

Posted 27 December 2016 - 01:05 PM

Did you configure the PI probe to use 12-bit for the ASI1600? Or is it configured for 16-bit?

Hi Jon,

I have it set to 16bit.

### #4 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 27 December 2016 - 01:06 PM

A variation on the question.  Could someone describe in detail, how to determine whatever frames are needed, and compute the sky background flux in electrons per second?  Please?  I've looked at a lot of discussions on this, spent hours searching the Net, and I'm still baffled.  Bias surely is important.  Flats?  Darks?

You can assume we set the PI mode (would using zero to one automatically work?) to whatever bits our camera produces.  And know how to determine camera gain in electrons per RN (ADU).  Those things I understand.  Sky flux in electrons per second remains elusive.

Edited by bobzeq25, 27 December 2016 - 01:09 PM.

### #5 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 27 December 2016 - 01:23 PM

Did you configure the PI probe to use 12-bit for the ASI1600? Or is it configured for 16-bit?

Hi Jon,

I have it set to 16bit.

Then your results are very inflated. You need to measure in 12-bit for the ASI1600, to get real camera ADU. Then, once you have a measure in camera ADU, you can convert those to electrons using the gain. Use the proper gain, rather than an estimate. At Gain 0, it is 4.88e-, and as the background levels get higher, the difference will matter more and more.

### #6 GeneralT001

GeneralT001

Mercury-Atlas

• topic starter
• Posts: 2,747
• Joined: 06 Feb 2012

Posted 27 December 2016 - 01:29 PM

Did you configure the PI probe to use 12-bit for the ASI1600? Or is it configured for 16-bit?

Hi Jon,

I have it set to 16bit.

Then your results are very inflated. You need to measure in 12-bit for the ASI1600, to get real camera ADU. Then, once you have a measure in camera ADU, you can convert those to electrons using the gain. Use the proper gain, rather than an estimate. At Gain 0, it is 4.88e-, and as the background levels get higher, the difference will matter more and more.

Thanks.

So I should have 43 x 4.88e- = 209.84 then 209.84 ÷ 30sec = 6.99e-/sec. Definitely seems better!

And PI doesn't use any pedestal value unless you use one, correct?

### #7 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 27 December 2016 - 01:29 PM

A variation on the question.  Could someone describe in detail, how to determine whatever frames are needed, and compute the sky background flux in electrons per second?  Please?  I've looked at a lot of discussions on this, spent hours searching the Net, and I'm still baffled.  Bias surely is important.  Flats?  Darks?

You can assume we set the PI mode (would using zero to one automatically work?) to whatever bits our camera produces.  And know how to determine camera gain in electrons per RN (ADU).  Those things I understand.  Sky flux in electrons per second remains elusive.

It is best to use a calibrated sub for this, however it is not absolutely necessary. If you know generally what your bias offset is, say 21 (i.e. 12-bit, unity gain on ASI1600) or 512 (14-bit, bias offset of all Canon DSLRs), you can simply subtract that from your measurements.

To properly calculate skyfog flux, you need to know the background level in electron counts, as well as the exposure time. The flux would then simply be e-/tsub.

You can figure out what your gain is by using the BasicCCDParameters script.

And, as always, remember to do your measurements in the proper bit depth for your camera as it was configured during readout. (i.e. an ASI1600, when using hardware binning mode, is 10-bit...otherwise it is 12-bit. Always use the proper bit depth!)

In formula form:

SkyFlux = ((Background16bit / (216/2ADC) - Offset) * Gain) / ExposureTime

Where:

Background = Measured background level in 16-bit

Offset = The conversion bias offset (configured in the camera driver, if it is configurable at all)

Gain = The conversion gain (measured with BasicCCDParameters script)

ExposureTime = The length of the sub exposure

If you are configuring your measurements for the proper bit depth initially, the formula can be simplified to:

SkyFlux = ((BackgroundADC - Offset) * Gain) / ExposureTime

Edited by Jon Rista, 27 December 2016 - 01:40 PM.

### #8 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 27 December 2016 - 04:39 PM

A variation on the question.  Could someone describe in detail, how to determine whatever frames are needed, and compute the sky background flux in electrons per second?  Please?  I've looked at a lot of discussions on this, spent hours searching the Net, and I'm still baffled.  Bias surely is important.  Flats?  Darks?

You can assume we set the PI mode (would using zero to one automatically work?) to whatever bits our camera produces.  And know how to determine camera gain in electrons per RN (ADU).  Those things I understand.  Sky flux in electrons per second remains elusive.

It is best to use a calibrated sub for this, however it is not absolutely necessary. If you know generally what your bias offset is, say 21 (i.e. 12-bit, unity gain on ASI1600) or 512 (14-bit, bias offset of all Canon DSLRs), you can simply subtract that from your measurements.

To properly calculate skyfog flux, you need to know the background level in electron counts, as well as the exposure time. The flux would then simply be e-/tsub.

You can figure out what your gain is by using the BasicCCDParameters script.

And, as always, remember to do your measurements in the proper bit depth for your camera as it was configured during readout. (i.e. an ASI1600, when using hardware binning mode, is 10-bit...otherwise it is 12-bit. Always use the proper bit depth!)

In formula form:

SkyFlux = ((Background16bit / (216/2ADC) - Offset) * Gain) / ExposureTime

Where:

Background = Measured background level in 16-bit

Offset = The conversion bias offset (configured in the camera driver, if it is configurable at all)

Gain = The conversion gain (measured with BasicCCDParameters script)

ExposureTime = The length of the sub exposure

If you are configuring your measurements for the proper bit depth initially, the formula can be simplified to:

SkyFlux = ((BackgroundADC - Offset) * Gain) / ExposureTime

Ok, now lets talk about being baffled.  If I load a D5500 image of M31 (The exposure was 2 minutes) into IRIS -

I can draw a slice through an obviously saturated star.   I get a flat topped curve with the top at 16,000+ ADU (all numbers here are to two sig figs, which is plenty).  Exactly what you'd expect from a 14 bit camera, like the D5500.  Looking at the histogram, I see a two peak skyfog, centered on 1000 ADU.  About what I was shooting for.

If I do ImageInspection-Statistics in PI, set to 14 bit, I get a mean/median of 250, and a max of 4000?  If I lower things to 12 bit, everything goes down proportionally, ie by a factor of 4.

Bafflement.  Questions.

Is bias an offset?  If so, that's 600, the IRIS value is still 400.

If I raise the PI setting to 16 bits, I get the IRIS result.  Mean/median 1000, max 16000+.  Does PI automatically upscale?  I suppose it's possible that the camera does, but that's news to me.  Note the star is still not saturated, according to PI, since 16 bits has a max RN of 64,000.

Min is now 800, reasonable for 600 bias, I suppose.

Is my skyfog (1000-600) X0.8 (e- per ADU) divided by 240?  1.3 electrons per second?  Seems awfully low for mag per arc sec in the mid 18s.  Not subtracting the bias gives 3.3, a bit better, still maybe low.  I'm pretty clueless about sky fog values.

A two sig fig answer is all I need.

Enlightenment?

Edited by bobzeq25, 27 December 2016 - 05:02 PM.

### #9 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 27 December 2016 - 05:10 PM

Well, first off...a dark site (~21-21.5mag/sq") is going to be around 10-20e-/min, depending on image scale, IIRC from my old measurements. So if your skyfog level is 1.3e-/s, that is 78e-/min. That is pretty high, definitely in the realm of pretty darn light polluted.

Regarding your other questions. I am not sure exactly what PI does. It used to be in the past that PI simply loaded DSLR data directly into the 16-bit space without scaling. I am not sure that is still the case with Canon CR2 files anymore...sometimes I measure values a lot higher than 2^14. Given that you are measuring values from 1000 to 16000+ when measuring in 16-bit, and 250-4000 in 14-bit...it sounds like PI is still doing that for NEF files at least. I guess it depends on whether you believe that you do indeed have maximum values in the 16k DN range. If so, then I'd keep your data in 16-bit, as it sounds like it's being loaded unscaled.

Regarding bias. Have you measured it for yourself? You can figure out what your offset is in camera ADU by loading up a bias and measuring the median. What bit depth you measure in would depend in the answer to the above question.

SkyFlux = (1000-600)*0.8/240 = 1.3

So 1.3e-/s or 78e-/min skyfog flux sounds about right to me. That is a high flux...you have to realize that some object flux is less than 0.5e-/MIN! So, 78e-/MIN skyfog would make it pretty difficult to get useful signal on faint objects, and is most likely red zone flux. It is important to keep in mind that flux levels are very dependent on image scale. What you measure with a large image scale at the same site would differ from what you measure with a small image scale. It is possible to convert flux into a common unit...say per square micron of sensor area. You can even use your quantum efficiency and scope transmission levels to figure out what the true flux is through the atmosphere per unit area (say square millimeter of aperture), if that is more helpful to you.

### #10 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 27 December 2016 - 05:19 PM

Thanks.

So, with a read noise of about 4, I'm just about at 40X with a 2 minute exposure?  I really don't want to go below 1000 ADU, (which is about 25% on the stretched histogram).  I have difficulty processing that data (maybe because one channel is low), and the gain in dynamic range is insignificant.

Here's something interesting.  I see exactly the same thing with my ATIK460EXM.  Clearly a 16 bit camera, if I load a light in, and set PI at 16 bits, I get 1000 mean/medium, max 16000.  When 16 bits is 64000.

Is there some internal setting in PI that I'm messing up?

EDIT: IRIS now is crazy too.  The peak of a saturated star is 32000.   The histogram is at 13000 (!)  300 second exposure, gain is 0.4.

The image looks weird in PI, like it was stretched.  Ditto IRIS.

Bafflement continues.

EDIT2.  Looking at an earlier 460 image at 120 seconds gives more expected results in PI statistics.  Max of 64000, center of 3300.  So, maybe the later image is something I did.  Bias is 300, electrons per second (conversion is 0.4) is now 10?  The image is still suspiciously bright in PI, but not as ridiculous.

Sigh.  I need to see if the capture program (Artemis) is stretching things.  Can't understand why it would.

It certainly looks like 60 seconds would be fine for the 460, or 120 with a filter.

At least you understand why I'm baffled.  Things are going on that I do not understand.

Edited by bobzeq25, 27 December 2016 - 05:43 PM.

### #11 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 27 December 2016 - 07:53 PM

The only real harm in swamping the read noise by more than 20x is a loss of dynamic range. That may matter a lot for a DSLR at moderate ISO (800-1600+) or variable gain CMOS camera, it may not matter as much for a CCD/CMOS camera with fixed gain and maximum DR. For a DSLR, the 1/4 histogram rule exists because it's simple, easy to see on the back of the camera, the BOC histogram is NON-linear (so, a 25% histogram is actually a FAR smaller signal in linear terms...not sure if you knew that), and it's handy for beginners.

The key thing here is that the BOC histogram is non-linear. A 25% BOC histogram (and FTR, a 25% BYE/BYN histogram), and a 25% linear histogram are radically different things. The latter is a SIGNIFICANTLY more exposed signal. You don't need to expose a DSLR linear histogram to 25%. If your FWC is say 10ke-, then a 25% histogram would be 2500e-!! That is a huge signal, would swamp your read noise by a massive 625x, and would definitely be burning up dynamic range your stars could use. In contrast, a 25% BOC histogram might only be 250e-, if that. Depends on the exact tone curves used to display the histogram (and, even worse, those curves are applied when generating a JPEG, and the histogram is rendered from the JPEG, not the RAW.)

So if you are swamping the read noise by 40x with a 120s exposure, then you are doing fine, IMO.

Edited by Jon Rista, 27 December 2016 - 07:54 PM.

### #12 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 28 December 2016 - 01:58 AM

Sure I knew the relative differences between BOC and linear.  I often look at both on the same image.  "BOC" is usually Fastone, linear was IRIS, I'm starting to use PI, although IRIS' "slice" feature for looking at a localized histogram is valuable, for a few reasons.

But the results for max level seem baffling.

First, the histograms.  I generally shoot for 25% BOC (DSLR) or 1000 ADU linear (both DSLR and CCD, 1000 ADU is about 6% of linear full scale with the 14 bit DSLR, about 2% with the 64 bit CCD.  Dynamic range should be decent in either case.).  My theory is, in light polluted skies, just have a decent separation between bias and skyfog peak, to give myself a bit of room in processing, and to be sure all the channels in the DSLR have separation.  A "Samir" kind of approach.  My comment about 40X was mostly confirming that it also made sense in the "20X" methodology.

Now, max level.  Any ideas about why the max level in PixInsight is often wrong (the max level in most any image should be full scale for the bit level, a saturated star), even if I set the bit level in Statistics correctly?  Is there some other setting in PI?  Something global?  Is something scaling?

Since my subframe exposures seem reasonable, and I'm increasing total imaging time, I think I'm on the right path in this regard.  But this max level being wrong thing is a concern, if only an intellectual one.  I have no confidence that my sky level number is good, unless I simply correct manually for the max level thing.

Edited by bobzeq25, 28 December 2016 - 02:03 AM.

### #13 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 28 December 2016 - 03:17 AM

Are you sure the values in PI are wrong? If you measure in 16-bit, your values range from ~1000 ADU mean to ~16000 ADU max? That is within the 14-bit range. IIRC, PI loads DSLR RAW data into a 16-bit numeric space without scaling. So, it will basically just drop the 14 bits of each pixel from the NEF file into the first 14 of the available 16 bits. It will not multiply the NEF pixels by 4 first, in other words.

Regarding ADU levels. Keep in mind one camera is 1000 14-bit ADU, while the other is 1000 16-bit ADU. Scale the 16-bit level to 14-bit, and it's effectively 250 ADU. Conversely, scale the 14-bit level to 16-bit, and it's effectively 4000 ADU. There is a factor of four difference in ADU there. I don't think you will be underexposed with either camera in any case, however my guess is the Atik 460 could be underexposed a good deal relative to the DSLR if you are using it at a low ISO.

### #14 pfile

pfile

Fly Me to the Moon

• Posts: 5,682
• Joined: 14 Jun 2009

Posted 28 December 2016 - 03:28 AM

Jon is right, PI always loads DSLR data into a 16-bit space by leaving the uppermost bits set to 0. to be fair i think this is what DCRAW is doing - the way PI calls DCRAW it hands the data to PI with only the n LSBs populated (where n=12 for some older cameras and n=14 for newer cameras).

so, a fully saturated flat from a 14-bit canon DSLR will read out 16383 everwhere in all 3 channels when the readout is set to 16 bits.

rob

Edited by pfile, 28 December 2016 - 03:28 AM.

### #15 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 28 December 2016 - 09:53 AM

Thanks everyone.

OK, that explains the DSLR.  I still have one anomalous issue with how it did statistics on the ATIK, I'm quite prepared to say that somehow I did something strange, the light even looks strange.

The bottom line is that setting the statistics readout to 16 bits (on my 14 bit camera) harmonizes my PI results with my IRIS results, and I think that gives me the right mean/median number (1000 RN (ADU)) to compute sky flux.  Bias is an "offset", 600 ADU.  1.3 electrons per second, on that night.  So, with a read noise of about 4, I'd meet the 20X criteria at 60 seconds.  Seems plausible for my skies.  I think I'll try 60 (I could maybe do that unguided by simply using PEC), and 90, but won't be surprised if I stick with 120.  The results seem pretty good.

Confirmation is that if I measure statistics on a calibrated light, selecting 16 bit, I get 480 mean/median.  About right, I think.  If I use 14 bit, I wind up with a result of 120, which would say I'd need a 240 second exposure to get to 20X.  Not plausible, I think, in my backyard, with my low read noise camera.

So, the real numbers for RN in PI are obtained by setting the readout to 16 bits, when you're inputting RAW images from a DSLR.   That was my problem, I was setting it to 14, because it was a 14 bit camera.  And I'd never seen anything to suggest using 16, just advice to match the camera.

Jon.  From the appearance of my lights, I think the problem is that I'm overexposing with the CCD.  Not too surprising, I generally shoot longer exposures with it than with the DSLR at 200 ISO, which just can't be correct.  Read noise with the two cameras are comparable, gain on the CCD is more.  I'll work on the numbers, probably run some experiments.  Your backyard skies seem pretty similar to mine.  Mid 18s.  What is an example of your backyard sky flux, in electrons per second (or minute), and do you have a mag per arc second squared number to go along with that?

Edited by bobzeq25, 28 December 2016 - 10:09 AM.

### #16 *Axel*

*Axel*

Mariner 2

• Posts: 228
• Joined: 01 Mar 2016

Posted 10 January 2017 - 02:58 PM

Well, first off...a dark site (~21-21.5mag/sq") is going to be around 10-20e-/min, depending on image scale, IIRC from my old measurements. So if your skyfog level is 1.3e-/s, that is 78e-/min. That is pretty high, definitely in the realm of pretty darn light polluted.

Regarding your other questions. I am not sure exactly what PI does. It used to be in the past that PI simply loaded DSLR data directly into the 16-bit space without scaling. I am not sure that is still the case with Canon CR2 files anymore...sometimes I measure values a lot higher than 2^14. Given that you are measuring values from 1000 to 16000+ when measuring in 16-bit, and 250-4000 in 14-bit...it sounds like PI is still doing that for NEF files at least. I guess it depends on whether you believe that you do indeed have maximum values in the 16k DN range. If so, then I'd keep your data in 16-bit, as it sounds like it's being loaded unscaled.

Regarding bias. Have you measured it for yourself? You can figure out what your offset is in camera ADU by loading up a bias and measuring the median. What bit depth you measure in would depend in the answer to the above question.

SkyFlux = (1000-600)*0.8/240 = 1.3

So 1.3e-/s or 78e-/min skyfog flux sounds about right to me. That is a high flux...you have to realize that some object flux is less than 0.5e-/MIN! So, 78e-/MIN skyfog would make it pretty difficult to get useful signal on faint objects, and is most likely red zone flux. It is important to keep in mind that flux levels are very dependent on image scale. What you measure with a large image scale at the same site would differ from what you measure with a small image scale. It is possible to convert flux into a common unit...say per square micron of sensor area. You can even use your quantum efficiency and scope transmission levels to figure out what the true flux is through the atmosphere per unit area (say square millimeter of aperture), if that is more helpful to you.

Hi guys

sorry to unearth this post but I tried to apply Jon´s recommendation here but I bumped in a wall [ ]

I use a Canon T6 (1300D in Europe)

Running basic CCD parameters in PI using Kayron guidance (format explorer = pure raw, cfa checked, readout 14bits, A/D bits=14)

I get the following measures

To continue I took a raw Light and measured the background value

From here I get a lower background value(14bits mean of 464) than my bias value (511) so that I can´t apply SkyFlux = (background - bias )*gain/time.

If you guys have an idea about where I got it wrong?

Thanks

Axel

### #17 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 10 January 2017 - 03:38 PM

This may be the small quirk with PI, where it (or rather, DCRAW) loads DSLR raw files directly into 16-bit space without scaling. So while technically your data is 14-bit, it is being represented as 16-bit due to the way DCRAW handles the files. Try measuring in 16-bit, and see what your values are.

### #18 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 10 January 2017 - 03:41 PM

Well, first off...a dark site (~21-21.5mag/sq") is going to be around 10-20e-/min, depending on image scale, IIRC from my old measurements. So if your skyfog level is 1.3e-/s, that is 78e-/min. That is pretty high, definitely in the realm of pretty darn light polluted.

Regarding your other questions. I am not sure exactly what PI does. It used to be in the past that PI simply loaded DSLR data directly into the 16-bit space without scaling. I am not sure that is still the case with Canon CR2 files anymore...sometimes I measure values a lot higher than 2^14. Given that you are measuring values from 1000 to 16000+ when measuring in 16-bit, and 250-4000 in 14-bit...it sounds like PI is still doing that for NEF files at least. I guess it depends on whether you believe that you do indeed have maximum values in the 16k DN range. If so, then I'd keep your data in 16-bit, as it sounds like it's being loaded unscaled.

Regarding bias. Have you measured it for yourself? You can figure out what your offset is in camera ADU by loading up a bias and measuring the median. What bit depth you measure in would depend in the answer to the above question.

SkyFlux = (1000-600)*0.8/240 = 1.3

So 1.3e-/s or 78e-/min skyfog flux sounds about right to me. That is a high flux...you have to realize that some object flux is less than 0.5e-/MIN! So, 78e-/MIN skyfog would make it pretty difficult to get useful signal on faint objects, and is most likely red zone flux. It is important to keep in mind that flux levels are very dependent on image scale. What you measure with a large image scale at the same site would differ from what you measure with a small image scale. It is possible to convert flux into a common unit...say per square micron of sensor area. You can even use your quantum efficiency and scope transmission levels to figure out what the true flux is through the atmosphere per unit area (say square millimeter of aperture), if that is more helpful to you.

Hi guys

sorry to unearth this post but I tried to apply Jon´s recommendation here but I bumped in a wall [ ]

I use a Canon T6 (1300D in Europe)

Running basic CCD parameters in PI using Kayron guidance (format explorer = pure raw, cfa checked, readout 14bits, A/D bits=14)

I get the following measures

To continue I took a raw Light and measured the background value

From here I get a lower background value(14bits mean of 464) than my bias value (511) so that I can´t apply SkyFlux = (background - bias )*gain/time.

If you guys have an idea about where I got it wrong?

Thanks

Axel

One possibility is my post just above yours.  Read it carefully.  I only got reasonable results when I set PI to 16 bits, even with a 14 bit camera.  Not sure exactly what's going on.

With the Pleadies, I don't see how you would not have some saturated stars, some pixels with a max value equal to your full well capacity.

### #19 *Axel*

*Axel*

Mariner 2

• Posts: 228
• Joined: 01 Mar 2016

Posted 10 January 2017 - 06:08 PM

Jon, Bobzeq25,

I followed you advice reading my lightframe in 16bit and I get the following results

Under my sky condition I swamp x20RN  (RN of 2.488e) in about 8sec. >>> less tracking / guiding issues . At around 10sec/frame I less concerned about clipping stars because I always found that the 1/3 or 1/4 BOC was clipping to much.

I hope to be able to image in dark locations in April and August (in the french Alps at around 2000m )

Clear Skies

Edited by *Axel*, 10 January 2017 - 06:09 PM.

### #20 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 10 January 2017 - 07:27 PM

Your e/s and e/min fluxes there have to be wrong. At those levels, you would have to be imaging something ludicrously bright...the sun, for example.

If those are 45 second subs, and you acquired a background signal of 1055ADU, then your flux would be (1055/0.533)/45, which comes out to 44e-/s, which is 2640e-/min. Those values still seem ridiculously high, but I guess not outside of the realm of possibility if you live smack in the middle of downtown New York City or something like that.

### #21 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 10 January 2017 - 08:47 PM

Your e/s and e/min fluxes there have to be wrong. At those levels, you would have to be imaging something ludicrously bright...the sun, for example.

If those are 45 second subs, and you acquired a background signal of 1055ADU, then your flux would be (1055/0.533)/45, which comes out to 44e-/s, which is 2640e-/min. Those values still seem ridiculously high, but I guess not outside of the realm of possibility if you live smack in the middle of downtown New York City or something like that.

By me, those numbers are not too far out of line.

Bias 544.  Mine is 600, close enough.

45 sec exposure, ISO 1600, background 1055 (light, so it includes bias).

I got about that background with 120 seconds at ISO 200.  Which would be 15 sec at ISO 1600, yes?  Does F number change things?  Mine was 4.8.

@Jon.  You didn't subtract the bias.

I don't know that it's correct, but it's hardly the Sun.  <grin>

Edited by bobzeq25, 10 January 2017 - 08:58 PM.

### #22 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 10 January 2017 - 09:11 PM

I was referring to the 386603e-/min value. However I now see that comma is the decimal place, so it actually does look correct.

You are correct, I forgot to subtract the bias level. I also apparently divided the gain, but it should be multiplied. That would give 6.44e-/s, or 386.6e-/min. That does seem more reasonable, definitely a very bright LP zone. (For reference, some of my measurements at green zone dark sites range from around 20e-/m to 40e-/m, and a blue or gray zone dark site may be a good 2-3x better than that.)

As for whether F-number matters. It certainly does, however when you are calculating flux from a measured ADU value, that is already accounted for. You have the signal level in ADU, so just subtract the bias, multiply by the gain, then divide by the exposure length to get the flux.

You could keep going. Divide the calculated flux by the quantum efficiency to get the photon flux incident on the sensor. Divide by the scope's transmission rate to get the flux incident at the aperture. You could take it even farther, divide that flux by the aperture area to get flux per square millimeter of aperture, etc.

Edited by Jon Rista, 10 January 2017 - 09:27 PM.

### #23 *Axel*

*Axel*

Mariner 2

• Posts: 228
• Joined: 01 Mar 2016

Posted 11 January 2017 - 02:37 AM

cool my numbers are correct.

For what it is worth I once measured the sky darkness at the imaging location using Dark Sky Meter app and the reading were in the 19.5x - 19.7x SQM range (bortle 5). This said I don´t know if the app figures are reliable.

For the record the scope is a 80mm / 510 FL >>>Fratio 6.375

The camera QE is est. 37% (I refer to the APT website where the EOS are listed with I guess a rather hypothetical QE).

Anyway my initial intent was to find the minimum required time to swamp RN (from x20 to x40).

Enjoy your darker skies guys and thanks for the support!

Edited by *Axel*, 11 January 2017 - 02:37 AM.

### #24 bobzeq25

bobzeq25

ISS

• Posts: 23,914
• Joined: 27 Oct 2014

Posted 11 January 2017 - 11:07 AM

cool my numbers are correct.

For what it is worth I once measured the sky darkness at the imaging location using Dark Sky Meter app and the reading were in the 19.5x - 19.7x SQM range (bortle 5). This said I don´t know if the app figures are reliable.

For the record the scope is a 80mm / 510 FL >>>Fratio 6.375

The camera QE is est. 37% (I refer to the APT website where the EOS are listed with I guess a rather hypothetical QE).

Anyway my initial intent was to find the minimum required time to swamp RN (from x20 to x40).

Enjoy your darker skies guys and thanks for the support!

Hmmm.  Darkers skies I have not.  <smile> My skies are mid 18s.  I calculated my sky flux as 4 electrons/sec.  20X read noise gives me 14 seconds.  There is no earthly way I could use exposures that short, it would have my (stretched) histogram as less than 10% over from the left.

I'm still not seeing how F number, quantum efficiency, etc.  play into this.  I used a 70mm, F4.8 (reduced), scope, my Nikon D5500 has a QE about 55%.

I think the histogram is a more reliable way of determining subexposure than 20X read noise.  Something around 1000 RN (ADU) on the linear histogram seems about right to me (not corrected for the 600 bias).   ie, your 45 sec exposure looks good.  With a max of 16,000 RN, I'm surely not giving up much dynamic range.   When I shot something at 850, it seemed distinctly underexposed, and hard to process.

Edited by bobzeq25, 11 January 2017 - 11:37 AM.

### #25 Jon Rista

Jon Rista

ISS

• Posts: 24,803
• Joined: 10 Jan 2014

Posted 11 January 2017 - 12:51 PM

The problem I have with just saying that XYZ DN (digital number)/ADU is sufficient is that it ignores the arbitrary nature of ADU. What a single ADU means is entirely dependent on the gain. A camera operating at unity gain would have a true signal of say 200e- when the background sky (histogram peak) is at 200 ADU. A camera operating at a high gain of say 0.15e-/ADU would have a much smaller signal of 30e-. A camera operating at a low gain of say 5e-/ADU would have a much larger signal of 1000e-.

ADU are arbitrary. This is a fact that cannot be ignored when recommending acceptable exposure levels. This is why I try to avoid recommending signal values to anyone in ADU, and always prefer to recommend true signal values in electrons. If you feel the 20x rule is insufficient, you can always increase the multiplier...30x, 40x, whatever tickles your fancy. However, it is best to avoid telling someone to expose to some given ADU level without any other context (i.e. the gain used in e-/ADU) since any given ADU level for them could mean something significantly different than that ADU level means for you.

## Recent Topics

 Cloudy Nights LLC Cloudy Nights Sponsor: Astronomics