Pitch Black Skies

1 hour ago, vlaiv said:

62.81ADU

This is quite low though compared to mine.

My camera's default offset is 70, yet my bias ADU is nowhere near that figure, it's 2796 median ADU. Even 2796/16 = 174.75. Still nowhere near 70.

Why is Jon using 50 in his equation but I'm not using 70?

I'm missing something very basic here 🧐

On 20/04/2022 at 09:02, Fegato said:

So with my ASI2400MC Pro at Gain 140 (1.2 e) and Offset 15 (480 ADU),

In the CN thread you shared, Jon Rista uses the ASI1600 default offset of 50 in his equation. He doesn't use the median ADU of his bias sub. I am missing something here?

1 hour ago, vlaiv said:

but one thing is certain - we can't be both right

True 😄 and I'm gonna put my hands up on this one. There's a 99.99% chance that it's me who isn't.

I've repeated the steps from the beginning with the same files. This time I'm getting ~105, ~106.

When I select the centre of the green flat, I get a Mean of 13266.104.

I remove the selection and then divide that flat Green by 13266.104.

Then I'm dividing the light Green by that flat Green, and then dividing the resulting image by 4.

23 hours ago, vlaiv said:

In this particular case we measured background value to be ~77.3 (Mean value is ~78, median is ~77.3)

I've followed all of the steps and selected a few different patches in the final image and measured them. They are all ~131 or ~132 Median. Does that sound right to you? I was expecting to get ~77 or ~78 like yours.

39 minutes ago, vlaiv said:

but due to way my brain is used to working - I instinctively go for these number of subs

Well if you're doing it like that, I am too 😁

5 hours ago, vlaiv said:

I aim for at least 64 darks

I go for 256 flats and flat darks

Any reason for the specific numbers?

I've noticed they are both 2^6 and 2^8 respectively.

7 hours ago, vlaiv said:

What type of stacking did you use for both?

In DSS, I have Intersection Mode, and Kappa-Sigma clipping (Kappa: 2.00 Number of iterations: 5) selected. Alignment is set to Automatic.

27 minutes ago, vlaiv said:

Dark has one (or more) hot pixels that are not showing in flats.

That's interesting, I'll be able to check the DSS settings this evening.

The parameters were all the same. I remember I had to use 10s for the flats to get the ADU around the 20k mark. Not sure if that was a bit too long.

How many would you usually shoot for, 100?

2 hours ago, vlaiv said:

Flat dark has some level of noise, some hot pixels and so does flat.

These are single files not masters so it is not averaged out.

They are a stack of 20 single files each.

Do you think I should increase to get a more averaged out master? I'm going by the reccomendation of 20 in the book 'Every Photon Counts'.

9 hours ago, vlaiv said:

Do the same with master flat and master flat dark - subtract master flat dark from master flat

Something's not right here. The master flat doesn't look right. Also, when I subtract the master flat dark from it I end up with a completely white uniform image with no vignetting 🤔

@vlaiv

Not sure what I am doing wrong on ImageJ.

File

- Open raw sub

Image

- Type, RGB

Image

- Colour, Split Channels

Select square patch similar to yours from yesterday

Analyze

- Measure

I'm getting a Mean of 1,493 ?

15 minutes ago, vlaiv said:

Can you upload just single raw sub as it came from the camera? This one has been debayered, converted to 32bit floating point format and scaled.

This is straight from the camera to my ASIair Pro.

I think it is the same file that I attached yesterday.

Light_M101_300.0s_Bin1_533MC_gain100_20220402-231650_-10.0C_0002.fit

300s raw sub.FTS

MasterDark_Gain100_300s.tif

MasterDarkFlat_Gain100_10s.tif

MasterOffset_Gain100.tif

MasterFlat_Gain100.tif

I hope these are okay. I never calibrate with the Master Offset as I've (read that) Flat Dark/Master Dark contains that signal.

3 hours ago, vlaiv said:

Could you actually put up those files and I'll walk you thru how to do it?

Yes, really appreciate that. I will do it this evening.

I don't recall seeing an option to save as 32bit floating point. I think it is just 32bit integer/32bit rational, fit/tif.

300s sub calibrated.FTS

10 hours ago, vlaiv said:

where flat is normalized to 1

Does it mean just to use 1 flat?

For the M101 sub, I have the master dark, master flat and master flat dark.

Shall I calibrate it, upload it and see what figures you can pull from it?

What program can I use to measure the background like you did?

The software I use are in my signature.

I'm trying to load the file into NINA but having no luck.

On 19/04/2022 at 09:21, vlaiv said:

Select a piece of background without much "stuff" in it (few stars is ok, but try not to have nebulosity or galaxies or such) in one of your subs and measure median ADU value (median is used because of any odd star that ends up in selection - it will "ignore" it).

Multiply that value with e/ADU for your gain - in case you are using unity gain - then it is easy - value is 1e/ADU and you don't have to multiply anything - just use median ADU.

Take square root of that number - that is your LP noise.

For this method my LP noise = 57.58

Mean ADU from your analysis = 3316 829*4=3316

√3316=57.58 LP noise

In the other method you got LP noise = 130

829-699=130 LP noise

What am I doing wrong here?

Edit: I think I could be mixing LP noise up with LP signal in the second calculation.

13 hours ago, Fegato said:

1.5^2 = 2.25 and then multiply by 5 or 10

Is that not for the light pollution swamp?

12 hours ago, vlaiv said:

You can write it down like this 2^(16-camera_bits) for example. That is the notion I would use

2^(16-16) = 2^0 = 1 (for 16bit camera)

2^(16-14) = 2^2 = 4 (for 14bit camera)

2^(16-12) = 2^4 = 16 (for 12bit camera)

Also a much simpler way to calculate.

23 hours ago, Fegato said:

I used

DN = (Nread^2 * Swamp / Gain) * (2^16/2^Bits) + Offset

(otherwise the offset is multiplied by 4 twice)

This is clever, more simple.

3 hours ago, vlaiv said:

Makes sense?

Yes, it's a lot clearer now.

Take a quick look at my latest attempt please to see if I understand it correctly.

I find your method of the RNx5 a bit more straight forward.

On 20/04/2022 at 19:30, vlaiv said:

Yes, but why would you want to go with such large factor?

If you've seen such large factor being used - its probably not the factor for read noise, but rather background level.

Signal and associated noise are related by following equation (for Poisson type noise) - Signal = noise^2 or noise = sqrt(signal)

(by square root / square function)

If you apply factor of 10 to signal - that is the same as applying factor of sqrt(10) to noise - which is ~x3.16

Here is quick calculation in how much "total" difference is made by read noise for different "swamp" factors.

Noise swamped by x3 - there total noise increases by ~5.4%

Noise swamped by x5 - total noise increases by ~1.98%

Noise swamped by x10 - total noise increases by ~0.5%

We can't visually notice increase in noise of less than 5-10%, for this reason it is probably enough to swamp read noise by x3, but I prefer to swamp it by x5.

Swamping it by x10 is really an overkill as you certainly can't perceive increase of less than half of 1% in noise.

What you are probably referring to is "swamping background signal" kind of thing where x10 means signal not noise - and is equivalent to swamping noise by sqrt(10) = ~x3.16 - a bit more than x3 which is on edge of what we are able to detect.

Which ever number you choose in x3-x5 - you'll be fine. Going over x5 really makes no sense as improvement is minimal and can't be perceived by human.

I think I am confusing Jon Rista's reccomendation for swamping read noise squared * 10.

2 hours ago, Pitch Black Skies said:

I think I've read that the default offset for this camera is 70 as per ascom driver?

I can't wrap my head around Jon Riatas formula. What am I doing wrong here?

Btw does DN mean data numbers?

I was writing the gain as 100 rather than 1. The gain is supposed to be expressed as e-/ADU which is 1 for me at Unity Gain. Vlaiv actually explained this to me earlier.

I'm still not getting the end part of the formula (2^16/2^bits). Jon just multiplies by 16 in his equations.

That leads me to another question, should I be multiplying by 14 as my camera is 14bit, or even 13.5 as that's what unity gain brings it down to?

Here's my latest attempt:

44 minutes ago, vlaiv said:

From read noise we saw that you need 1.5 * 5 = 7.5, 7.5^2 = 56.25 background signal value and yours is 130

Awesome, thanks so much.

Does this mean that if I went with a recommendation of 10x swamp factor, I would be underexposing by almost 58%?

1.5 * 10 = 15, 15^2 = 225

130/225 = ~.58

On 20/04/2022 at 16:30, Fegato said:

Yes I didn't understand it for a while. This is quite a good explanation:

https://daleghent.com/2020/08/understanding-camera-offset

You're basically just adding a number to the ADU count to avoid measuring zero in any pixel. There's no right value as such, but I think a value of a few hundred up to a thousand is usually suggested as about right. This will equate to a number that ZWO give, and I don't know what the relationship between the two is I'm afraid! For my ASI2400MC Pro I have offset value of 15 and get a bias ADU median of 480.

As in the linked article, if you take a bias frame with Offset 0, record the median value, and you can then increase the offset and see what you get.  But this isn't going to make a huge difference anyway - it will just give you a little bit more well depth to play with.

 

I think I've read that the default offset for this camera is 70 as per ascom driver?

I can't wrap my head around Jon Rista's formula. What am I doing wrong here?

Btw does DN mean data numbers?