Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sharkmelley

Pages: 1 2 [3] 4 5 ... 16
31
Announcements / Re: New RAW Module - Ready for Testing
« on: 2018 December 15 09:28:15 »
Nikon Z6? Very unlikely.

The author of LibRaw added Z6 support only a few days ago: https://www.dpreview.com/forums/post/62005403

Mark

32
General / Re: asi1600mm Bright Star Reflections
« on: 2018 November 30 16:58:28 »
There was some analysis done on these diffraction patterns here:
https://www.cloudynights.com/topic/635937-microlens-diffraction-effect-explained/?p=8967693

It doesn't help with removing them though!

Mark

33
Of course! The BN upper limit can be set within the PCC.  I hadn't spotted that!

Also it is always the case that one of the channels (the weakest one) will also be assigned a white balance multiplier of  exactly 1.0
This prevents the white balance operation clipping any bright highlights and therefore gives full control to the user.

Mark

34
I don't understand your statement that "red is obviously very wrong".

I downloaded your file (which is massive by the way) and more or less duplicated your first run.  Here are my results:

* Color transformation functions:
R-G = +9.740677e-01 + 8.713659e-01*(Sr-JV) ± 4.845947e-02
B-G = +2.728715e-01 + 4.308724e-01*(JB-JV) ± 4.088340e-02
* White balance factors:
W_R : 1.0000e+00
W_G : 4.8952e-01
W_B : 8.3431e-01
Applying white balance: done
Evaluating background reference: done
* Background reference:
B_R : 9.16751e-05
B_G : 5.58179e-02
B_B : 9.52719e-02
Applying background neutralization: done
02:57.58

I think your problem is that the background level is so high that the background neutralisation step fails with the default parameters but that's only a guess.  I see the same problem as you - the white balance has been applied but the background neutralisation has not.

So after running PCC try running BN manually and set the upper limit to 0.25 instead of the default of 0.1.
Now run HistogramTransformation setting highlights to 0.4 to deal with the pink in the core of the bright stars.
ArcsinhStretch (in the real time preview I did "Estimate black point" and I used a stretch factor of 140) then gives the attached result.  ArcsinhStretch was used in this instance because it faithfully reproduces the colours during the stretching.
The star colours and nebulosity colours look pretty much OK to me.

Mark

35
General / Re: How many dark frames?
« on: 2018 November 08 13:27:52 »

Would you think the modified equation shown in the first attachment properly accounts for the Dark Frame Noise when dithering is present? In the equation nD is the number of Dark Frames stacked to make the Master Dark Frame.

The second attachment shows the Stacked SNR graph without the randomizing effects of Dithering (or frame-to-frame drift) included. 

The third attachment shows the Stacked SNR graph with the complete randomizing effects of Dithering included (per the equation in the first attachment). The dithering makes a huge difference for the better.


Your new equation look correct to me and the new graphs are much more in line with what I expect to see.  I think most of us take dithering for granted because it makes such a big difference.  Because of that, your initial results (without dithering)were quite counterintuitive.

Mark

36
General / Re: How many dark frames?
« on: 2018 November 08 07:57:33 »
Mark - Here are the equations.


Thanks - I've worked through the equations and I can now see exactly what you are doing.  You'll be pleased to know I can't fault your logic!

Just as you said, the key issue is that the master dark is being subtracted from all light frames and hence the noise in the master dark appears in exactly the same place in each light frame and exactly the same place in the final stack.  Your equations and graphs correctly reflect this.

However, there is one important assumption you are implicitly making - you are assuming that no registration of light frames is required i.e. the star field lines up precisely in all the light frames taken over the 6 hour period.

In practice this simple case is unlikely because dithering is performed during acquisition or there is an accidental frame to frame drift.  In either case, registration of the images will be required before stacking and this will have the effect of randomising the position of the dark master noise across the stacked images and so noise reduction does take place because it is random.

So although your analysis is entirely correct, you are actually analysing a pathological case that almost never happens in practice.

Mark

37
General / Re: How many dark frames?
« on: 2018 November 07 14:09:32 »
I'm sorry to be the one who tells you that those graphs make no sense at all.

For 180sec exposures, you have stated that the standard deviations for skyglow, dark current and bias are 115.9, 30.1, 22.3 respectively.  I have no reason to doubt those figures.

It is therefore quite clear that skyglow is the main source of noise by quite a large margin.  If you could remove the dark noise completely then skyglow noise remains and you would obtain a marginal reduction in overall noise.  But the graph indicates a reduction in noise a factor of 4 for infinite darks at 180sec.   It's completely impossible.

Mark

Hi Mark - Let me clear up the confusion.

For a single frame the skyglow noise is much greater than the Dark Noise from the Master Dark. However, as more and more frames are stacked the skyglow noise (along with dark noise and Read noise in the Light images) are reduced by sqrt(number of stacked frames). Because the Master Dark Frame noise isn't reduced by the stacking of the Light frames, this noise can be significant when compared to the reduced noise in the stacked images.

As explained in the text, the vertical axis of the graph shows the Stacked SNR (SNR for the stacked images). Unfortunately I omitted "Stacked" in the vertical axis label which may have led to the confusion.

Steve

I'm afraid your response really doesn't clear up the confusion at all.  I stand by my comments above because you haven't addressed them. 

I would be interested if you can explain (preferably with a calculation) why you think that for a sub frame exposure of 180sec the top blue line has 4x the (Stacked) SNR of the red line i.e approx. 45 vs approx. 12 because I think you are making a fundamental error somewhere.  The skyglow is the main source of noise in that 180sec sub and even if you could magically eliminate the dark noise and bias noise from the sub you simply cannot get a 4x improvement keeping the sub length at 180sec.

Mark

38
General / Re: How many dark frames?
« on: 2018 November 07 12:27:10 »
I'm sorry to be the one who tells you that those graphs make no sense at all.

For 180sec exposures, you have stated that the standard deviations for skyglow, dark current and bias are 115.9, 30.1, 22.3 respectively.  I have no reason to doubt those figures.

It is therefore quite clear that skyglow is the main source of noise by quite a large margin.  If you could remove the dark noise completely then skyglow noise remains and you would obtain a marginal reduction in overall noise.  But the graph indicates a reduction in noise a factor of 4 for infinite darks at 180sec.   It's completely impossible, given your original standard deviation figures.

Mark

39
General / Re: How many dark frames?
« on: 2018 November 06 22:44:47 »
In your charts, what is your signal?  In other words, what are you graphing the SNR of?  A star, a faint nebula, the skyglow or what?

Mark

40
The first step I perform after stacking my DSLR images is to open the master flat and measure the RGB values at the centre.  I then scale RGB channels of stacked image using PixelMath to undo the colour mangling before I apply the camera's daylight white balance.

Definitely don't try to use a debayered master flat for image calibration of all your light frames.

The other thing that sometimes alters the colour balance of a DSLR image is Normalization in ImageIntegration.  I always switch this to "No normalization".   This option is in the "Image Integration" section.   The normalization in the "Pixel Rejection" section should be left switched on.

Mark

41
General / Re: Flat frames not subtracting properly from lights
« on: 2018 November 01 01:04:15 »
Are you are really subtracting flat frames from the lights?

That will cause all sorts of problems.  Light frame calibration by a flat is a divide operation, not a subtract operation.

Mark

42
General / Re: DSLR Noise Calculations using PixInsight: Part 2
« on: 2018 October 28 15:33:29 »
I agree with you.

However, for the benefit of other readers, a formula like the following is often used to calculate SNR of an exposure:
SNR = S*t/sqrt(S*t + DC*t + SG*t +RN^2)
where
t is the exposure length
S, DC, SG are signal, dark current and sky glow, all in electrons/sec
RN is read noise in electrons

Plugging in some example numbers:
SNR = 1*100/sqrt(1*100 + .1*100 + .2*100 + 5^2) =8.03

If the gain is a factor of 2 and we mistakenly feed in ADU counts instead of electrons we get:
SNR = 2*100/sqrt(2*100 + .2*100 + .4*100 + 10^2) =10.54 which is the incorrect answer

If the gain is a factor of 4 and we mistakenly use ADU counts we get:
SNR = 4*100/sqrt(4*100 + .4*100 + .8*100 + 20^2) =13.19 which is a different incorrect answer

So when using formulae similar to this always make sure you have converted all the input parameters to electrons.

Mark

43
General / Re: DSLR Noise Calculations using PixInsight: Part 2
« on: 2018 October 28 00:49:22 »

The parts of the methodology you have described here are fine.

But in step 4 you say you calculate SNR for any length exposure from Read Noise, Dark Current and SkyGlow current.  How are you doing this?  The formula you used last time needed the figures to be in electrons.

Here's a simple example of a Photon Shot Noise calculation.  Suppose your recorded light level is 10000 electrons.  Then the noise will be the square root of this i.e. 100 and SNR will be 100.

But if those 10000 electrons give you an ADU count of 20000 then its wrong to perform the same steps using ADU.  Taking its square root gives 141 and an incorrect SNR of 70.

Mark

44
General / Re: DSLR Noise Calculations using PixInsight: Part 2
« on: 2018 October 27 16:24:45 »
I agree with you that if your starting point is a measurement of signal and a measurement of noise then we obtain the same SNR whether those measurements are in electrons or in ADU counts.

But in your previous thread you were calculating SNR from read noise, dark current and rate of sky glow.  Then it does matter whether your read noise, dark current and sky glow rate is in electrons or in ADU counts.

Mark

45
General / Re: Calculating DSLR Noise Sources Including LP
« on: 2018 October 18 22:31:13 »
Quote from: STEVE333
If I calculate the SNR for both spectral bands and then take the ratio of the two SNR values, all calculated using counts, and then repeat the same calculations using e- values in place of the counts, I believe the ratio of the two SNR values will be identical. It is only because I'm interested in the ratio that the conversion to e- isn't necessary.

Sorry - your belief is incorrect and you can actually prove it to yourself by actually scaling your numbers.
   
It might make a small difference or it might make a big difference - it depends on how close to unity gain your existing data is.

Mark

Pages: 1 2 [3] 4 5 ... 16