Curve fitting and read noise, FWC, gain

[Jack Hogan]

While I was acting as Jim Kasson's coolie a couple of months ago as he coded up an excellent Photon Transfer matlab application, I came across this interesting tidbit on curve fitting that I would like to submit to the scrutiny of the forum. All data was collected by Jim with his usual professionalism by taking raw capture pairs of a defocused uniform patch from highlights to the deep shadows. Each pair was added to determine mean signal (S) and subtracted to obtain the relative standard deviation (total random noise N). The effect of pattern noise and PRNU is thus effectively minimized, producing data that should depend entirely on the signal, shot noise and read noise only.

SNR** is simply S divided by N and here is Jim's data for the green channel of a D810 at base ISO plotted as a function of Signal on the x-axis (zero stops is clipping/saturation, otherwise known as FWC in some circles):

Jim Kasson's SNR Photon Transfer data from the green channel of a Nikon D810 at base ISO

Note how the data is linear in the highlights because SNR there is virtually all due to the square root of the signal (also equal to shot noise) which plots as a straight line on a log-log scale. The slope is correct (quadrupling the signal doubles the SNR because of the square root) and there is no sign of PRNU, thanks to Jim's excellent technique and pair subtraction. The data deviates from the ideal shot noise SNR straight line in the shadows because Read Noise, always present and adding in quadrature, becomes dominant there. In fact the data appears to fit the incoherent-noise-adds-in-quadrature model so well that if we were able to fit a curve to it built on that model we could extract read noise and other parameters directly from it, more or less like so

Clipping (FWC) can be estimated by checking where the model intersects the y-axis, representing full scale; read noise (RN) by subtracting in quadrature shot noise (obtained from the green line) from total noise (obtained from the red line)

Getting the best curve fit is critical to obtaining accurate estimated parameters, as shifting the curve left or right will clearly result in different read noise and FWC values. Most fitting algorithms choose the best fit based on minimizing the least square error (LSE) between actual data and the model: they simply add up the difference between the actual data point and the relative model prediction squared and find the solution to the quadratic equation that will minimize the sum. Here is the LSE curve fit for our data performed by Excel Solver:

Curve fit resulting from minimizing the least square error (LSE) between the model and actual data

This fit results in a base ISO input-referred read noise for the D810 equal to 5.00e- and FWC equal to 82539e-, which yields an eDR***=14.0 stops. Compare this to DxO/sensorgen.info (RN=5.5e-, FWC=78083e-, eDR=13.8 stops) or Bill Claff's charts (RN=1.076DN or approximately 5.45e-, eDR=13.8 stops). Recall that DxO/Sensorgen averages the four channels while the measured data above refers to the green channel only. I am not sure what channels Bill uses for his estimates.

Pretty good, huh? But if we look closer, while the fit appears good in the highlights and mid-tones it doesn't quite satisfy in the deep shadows:

LSE a good fit? Each dot spans about 0.2 stops.

The reason for this discrepancy is that the absolute error in the shadows is a couple orders of magnitude less than the absolute error in the highlights. Therefore the highlights are (too) heavily weighted in the sum of squared errors overwhelming the errors in the shadows, which end up counting very little in the choice of parameters for the modeled curve. But we know that we do not need all that precision in the highlights: shot noise there is relatively massive, with standard deviation spanning several raw levels; besides, the curve in the highlights is a straight line of known slope. The real test of the accuracy of the fit is in the shadows, exactly the opposite of the weighting resulting from the LSE criterion.

So let's try a different criterion for best fit, one that effectively minimizes the percentage error at every measured point, with equal weighting for data throughout the curve****, from deep shadows to highlights: mathematically, if I've got it right, it is the sum of the absolute log values of the ratio of the measured data to the model = sum(ABS(LOG(measuredSNR/modeledSNR))). Here is the resulting curve fit, also performed by Excel Solver:

Curve fit by minimizing the sum of the absolute log of the ratio of measured to modeled

Zooming in on the deep shadows:

Curve fit by minimizing the sum of the absolute log of the ratio of measured to modeled

Right. With this, imho, better fit the Read Noise is 4.27e- and the FWC 80174e-, for an eDR of 14.2 stops in the green channel*****, down from 5.00e-, 82539e- and 14.2 stops respectively for the original LSE fit.

It appears to me that for this type of analysis LSE curve fitting gives less accurate results than possible with other criteria.

What do you think? And any suggestions for optimal criteria for this application?

Jack



** I prefer to use SNR for Photon Transfer analysis, as opposed to alternatives based on variance for instance, because the parameters we are interested in (read noise and FWC) can be determined directly without having to estimate a third unknown: gain/sensitivity.

*** I am using the simplified definition of engineering Dynamic Range in this post, with the denominator equal to the read noise.

**** Yes, in this case data points are denser in the shadows than in the highlights and ideally we would maintain equal spacing in the measurements. As mentioned, however, the highlight fit is just a straight line: in theory two points would be enough, in practice the more the better to average errors out. Here we have data at every 1/3 stop, plenty.

***** Note that if we wanted to use the formal definition of engineering DR (with the denominator equal to the signal at which SNR =1), we could simply read it off the x-axis intercept in the graph, or approximately 14.0 stops.

 

[JimKasson]

Good work, Jack. This makes me want to go back and add a new squared-error criterion to the Matlab code.

Jim

PS. Coolie? No way. I couldn't have done it without you.

 

[JimKasson]

I made the change in the Matlab code, as an option. For example:

I used the square of the log error instead of the absolute value to penalize outliers.

It does produce visually better fits.

I made squared log error the default.

Jim

--

the last word the last word - Photography meets digital computer technology. Photography wins -- most of the time.

Photography meets digital computer technology. Photography wins -- most of the time.

blog.kasson.com

 

[bclaff]

Jack Hogan wrote:
...
Bill Claff's charts (RN=1.076DN or approximately 5.45e-, eDR=13.8 stops). Recall that DxO/Sensorgen averages the four channels while the measured data above refers to the green channel only. I am not sure what channels Bill uses for his estimates.
...

Jack,

My data is measured from single frames as opposed to subtracted pairs.
The channels are "averaged" (average of variance) as opposed to only reporting green.
I noticed and fixed a gross error with my D810 input-inferred chart.
Yes, my current published values are 1.076DN or 5.084e- for ISO 64

I recently completed a review of all my read noise data but haven't quite found the time to republish all the Read Noise in DNs and Input-referred Read Noise charts. I hope to get to it soon as I do have more and improved data.

My analysis process requires fits at various points and you definitely have shown a clear example of the fact that when performing fits we must not ignore weighting.
I too have sometimes struggled with tweaking this.

Regards,
--
Bill (visit me at http://home.comcast.net/~NikonD70/ )

 

[Jack Hogan]

I made the change in the Matlab code, as an option. For example:

I used the square of the log error instead of the absolute value to penalize outliers.

It does produce visually better fits.

I made squared log error the default.

Jim

--
http://blog.kasson.com

Excellent. Thinking aloud here Jim, the log error difference is mostly a very small number, less than one. Squaring it will will make it even smaller. Will the squaring then penalize potentially bigger outlier errors, in the overall sum? What about a square root?

 

[JimKasson]

Thinking aloud here Jim, the log error difference is mostly a very small number, less than one. Squaring it will will make it even smaller. Will the squaring then penalize potentially bigger outlier errors, in the overall sum? What about a square root?

Jack, I don't think the world turns upside down when the numbers get below 1. Let's compare log errors of say, 0.1 and 0.01. Their squares are 0.01 and 0.0001. The larger error contributes 100 times as much to the sum as the smaller one. Now consider errors of 100 and 10. Their squares are 10000 and 100. The larger error contributes 100 times as much to the sum as the smaller one.

Jim

 

[Jack Hogan]

Thinking aloud here Jim, the log error difference is mostly a very small number, less than one. Squaring it will will make it even smaller. Will the squaring then penalize potentially bigger outlier errors, in the overall sum? What about a square root?

Jack, I don't think the world turns upside down when the numbers get below 1. Let's compare log errors of say, 0.1 and 0.01. Their squares are 0.01 and 0.0001. The larger error contributes 100 times as much to the sum as the smaller one. Now consider errors of 100 and 10. Their squares are 10000 and 100. The larger error contributes 100 times as much to the sum as the smaller one.

Jim

--
http://blog.kasson.com

Got it. Do we want the outliers to contribute so much more to the error sum than better fitting data?

 

[Jack Hogan]

Jack Hogan wrote:
...
Bill Claff's charts (RN=1.076DN or approximately 5.45e-, eDR=13.8 stops). Recall that DxO/Sensorgen averages the four channels while the measured data above refers to the green channel only. I am not sure what channels Bill uses for his estimates.
...

Jack,

My data is measured from single frames as opposed to subtracted pairs.
The channels are "averaged" (average of variance) as opposed to only reporting green.

Right. Using all four channels from Jim's data at base ISO the read noise averages out to around 4.1e-.

I noticed and fixed a gross error with my D810 input-inferred chart.
Yes, my current published values are 1.076DN or 5.084e- for ISO 64

Ok, so an average FWC of around 74573e-, a number very very similar to the one I get averaging the four channels from Jim's data. However a bigger question is whether it makes sense to average the four channels at ISO 64 for the D810, especially given the fact that the red and blue data in the deep shadows appear to suffer from quantization somewhere along the chain to DN, putting some unwanted play into the fit, hence into RN and FWC estimates.

I wonder whether at base ISO the green channel should be it, period.

 

[JimKasson]

Thinking aloud here Jim, the log error difference is mostly a very small number, less than one. Squaring it will will make it even smaller. Will the squaring then penalize potentially bigger outlier errors, in the overall sum? What about a square root?

Jack, I don't think the world turns upside down when the numbers get below 1. Let's compare log errors of say, 0.1 and 0.01. Their squares are 0.01 and 0.0001. The larger error contributes 100 times as much to the sum as the smaller one. Now consider errors of 100 and 10. Their squares are 10000 and 100. The larger error contributes 100 times as much to the sum as the smaller one.

Jim

 

[J A C S]

First, which curve are you fitting to the data? The one I have seen depends on 3 parameters? Or more? Where is the formula?

To my eyes, it looks like the second fit is also better in terms of least squares as well?

The reason least squares (L^2 norm) is commonly used is mostly because it is simple. Minimizing a quadratic functional leads to a linear system that can be solved in a fast and accurate way. Another reason, sometimes, is that the quadratic functional may have some physical meaning, like energy, for example.

You are minimizing the so called L^1 norm of the error, on a log scale. That leads to a non-linear system. Is it better - depends on what you want to do. In some applications, I think tomography is one of them, it is considered better. But that really depends on what that error signifies, and what we know about the statistical nature of the error.

Another option is to put some weight there. That weight should not depend on what we think is more important but on where we think the error of the measurements might be different. Say - we have a reason to believe that highlight measurements are more accurate - put more weight there then.

--
Formerly known as Just Another Canon Shooter

 

[JimKasson]

Got it. Do we want the outliers to contribute so much more to the error sum than better fitting data?

Here you go:

Not tested yet.

Jim

--

the last word the last word - Photography meets digital computer technology. Photography wins -- most of the time.

Photography meets digital computer technology. Photography wins -- most of the time.

blog.kasson.com

 

[JimKasson]

I hesitate to bring this up because I don't feel like ripping all the code apart right now, but we could use the high mu values to compute FWC, and the low mu values to compute RN, and do one-dimensional optimization for both in single ISO mode instead of two-dimensional optimization. In all-ISO mode, we could do one dimensional optimization for FWC and two dimensional optimization for preAmp RN and postAmp Rn, instead of three-dimensional optimization.

Please say you hate this idea.

Jim

 

[JimKasson]

First, which curve are you fitting to the data? The one I have seen depends on 3 parameters? Or more? Where is the formula?

I'll let Jack answer, but here's a little background:

http://www.dpreview.com/forums/post/54965474

By the way, what Jack is reporting here is a large simplification over what the camera modeling program does; it actually performs a camera simulation inside an optimum seeking loop.

Jim

--
http://blog.kasson.com

 

[bclaff]

Yes, my current published values are 1.076DN or 5.084e- for ISO 64

Ok, so an average FWC of around 74573e-, a number very very similar to the one I get averaging the four channels from Jim's data.

FWIW, I currently publish 78083e- on my site.

However a bigger question is whether it makes sense to average the four channels at ISO 64 for the D810, especially given the fact that the red and blue data in the deep shadows appear to suffer from quantization somewhere along the chain to DN, putting some unwanted play into the fit, hence into RN and FWC estimates.

I wonder whether at base ISO the green channel should be it, period.

For your purposes (you and Jim) that probably makes sense, and it's your decision.

For my purposes I'm satisfied with combining the channels.


I'm less interested in an exact value as in how the read noise affects a normal image.
That's why I don't subtract pairs.
And that's why, for my purposes, combining channels makes sense.

FWIW, because DSNU tends to be pretty low (I have numbers but haven't gotten around to publishing yet) my technique seems to produce pretty good results.
I judge my results as better than the DxOMark derived data but not quite up to your (you and Jim's) standards. (As they say, "good enough for government work" )

Regards,

 

[Jack Hogan]

Yes, my current published values are 1.076DN or 5.084e- for ISO 64

Ok, so an average FWC of around 74573e-, a number very very similar to the one I get averaging the four channels from Jim's data.

FWIW, I currently publish 78083e- on my site.

Right, I believe that's the number from DxO data as it is identical to sensorgen.info's. I estimated average FWC from your average read noise figure above = 15783/1.076*5.084

However a bigger question is whether it makes sense to average the four channels at ISO 64 for the D810, especially given the fact that the red and blue data in the deep shadows appear to suffer from quantization somewhere along the chain to DN, putting some unwanted play into the fit, hence into RN and FWC estimates.

I wonder whether at base ISO the green channel should be it, period.

For your purposes (you and Jim) that probably makes sense, and it's your decision.

For my purposes I'm satisfied with combining the channels.

I'm less interested in an exact value as in how the read noise affects a normal image.
That's why I don't subtract pairs.
And that's why, for my purposes, combining channels makes sense.

I understand. But (honest question) does it though? Shouldn't random read noise be the same for all four channels at base ISO? Is it at higher ISOs? I did a quick check of the D810 at ISO400 and it appears to be (sort of). And shouldn't FWC be the same for all four channels?

My guess is that the curves are not being properly fit near base. But that's just the fit. Pixels in real life behave according to physics not according to a squiggly fit. So FWC is FWC. Read noise I need to think about a bit more, especially because I still have not fully understood why the curve(s) start deviating so early from the ideal.

D810 Blue Channel fit at base ISO. Obviously wrong.

 

[Jack Hogan]

I hesitate to bring this up because I don't feel like ripping all the code apart right now, but we could use the high mu values to compute FWC, and the low mu values to compute RN, and do one-dimensional optimization for both in single ISO mode instead of two-dimensional optimization. In all-ISO mode, we could do one dimensional optimization for FWC and two dimensional optimization for preAmp RN and postAmp Rn, instead of three-dimensional optimization.

Please say you hate this idea.

Jim

 

[bclaff]

However a bigger question is whether it makes sense to average the four channels at ISO 64 for the D810, especially given the fact that the red and blue data in the deep shadows appear to suffer from quantization somewhere along the chain to DN, putting some unwanted play into the fit, hence into RN and FWC estimates.

I wonder whether at base ISO the green channel should be it, period.

For your purposes (you and Jim) that probably makes sense, and it's your decision.

For my purposes I'm satisfied with combining the channels.

I'm less interested in an exact value as in how the read noise affects a normal image.
That's why I don't subtract pairs.
And that's why, for my purposes, combining channels makes sense.

I understand. But (honest question) does it though? Shouldn't random read noise be the same for all four channels at base ISO? Is it at higher ISOs? I did a quick check of the D810 at ISO400 and it appears to be (sort of). And shouldn't FWC be the same for all four channels?

For the D810 I get read noise in DN at ISO 400 of 5.396, 4.625, 4.672, 5.210 for R, Gr, Gb, and B respectively.
(Across all ISO settings I get higher R and B than Gr and Gb)
This isn't specific to the D810. I can't remember any camera I have tested that doesn't have this pattern.
Remember, many things differ depending on wavelength; QE, energy, cross-talk, etc.
Everything downstream can be identical but noise originating at the pixel could be a function of dominant wavelength (and appears to be, to me).

FWIW, remember that I'm much more interested in DN since that's what the sensor measures than in electrons (that's "interesting" but not as interesting.)

My guess is that the curves are not being properly fit near base. But that's just the fit. Pixels in real life behave according to physics not according to a squiggly fit. So FWC is FWC. Read noise I need to think about a bit more, especially because I still have not fully understood why the curve(s) start deviating so early from the ideal.

I'm not curve fitting to get the read noise values that I report.
FWIW, for the same reasons state above I don't think FWC is FWC; I think it's a function of wavelength.

 

[JimKasson]

For the D810 I get read noise in DN at ISO 400 of 5.396, 4.625, 4.672, 5.210 for R, Gr, Gb, and B respectively.
(Across all ISO settings I get higher R and B than Gr and Gb)

I'm glad to hear that, Bill. I see it in all Nikons.

This isn't specific to the D810. I can't remember any camera I have tested that doesn't have this pattern.

Now I'm going to have to go back and look. Thanks.

Remember, many things differ depending on wavelength; QE, energy, cross-talk, etc.
Everything downstream can be identical but noise originating at the pixel could be a function of dominant wavelength (and appears to be, to me).

Oh, my. Just when I thought I was getting a handle on it. But that would mean that dark-field noise would be the same across channels, since there isn't any dominant wavelength, or any way for the pixel in the sensor to know what filter is over it, right?

Another thing for me to check.

FWIW, remember that I'm much more interested in DN since that's what the sensor measures than in electrons (that's "interesting" but not as interesting.)

I consider them to be two ways of lookng at the same thing, if amplifier gain is properly handled.

My guess is that the curves are not being properly fit near base. But that's just the fit. Pixels in real life behave according to physics not according to a squiggly fit. So FWC is FWC. Read noise I need to think about a bit more, especially because I still have not fully understood why the curve(s) start deviating so early from the ideal.

I'm not curve fitting to get the read noise values that I report.

How are you doing it, Bill?

FWIW, for the same reasons state above I don't think FWC is FWC; I think it's a function of wavelength.

Oh, my (again).

Jim

 

[bclaff]

For the D810 I get read noise in DN at ISO 400 of 5.396, 4.625, 4.672, 5.210 for R, Gr, Gb, and B respectively.
(Across all ISO settings I get higher R and B than Gr and Gb)

I'm glad to hear that, Bill. I see it in all Nikons.

This isn't specific to the D810. I can't remember any camera I have tested that doesn't have this pattern.

Now I'm going to have to go back and look. Thanks.

Remember, many things differ depending on wavelength; QE, energy, cross-talk, etc.
Everything downstream can be identical but noise originating at the pixel could be a function of dominant wavelength (and appears to be, to me).

Oh, my. Just when I thought I was getting a handle on it. But that would mean that dark-field noise would be the same across channels, since there isn't any dominant wavelength, or any way for the pixel in the sensor to know what filter is over it, right?

Another thing for me to check

The DN distributions for R and B are stretched with respect to Gr and Gb.
I've heard this called "white balance preconditioning".
But I'm arguing it's more like "QE compensation".

The conversion gain for the R and B channels must be higher.
It follows that the FWC for R and B must be lower.
I would think this would affect how white level is set since R and B would saturate ahead of Gr and Gb.

.

FWIW, remember that I'm much more interested in DN since that's what the sensor measures than in electrons (that's "interesting" but not as interesting.)

I consider them to be two ways of lookng at the same thing, if amplifier gain is properly handled.

If conversion gain varies across the channels then I don't think measured DN and input-referred electrons are equivalent.
In any case, the photographer has raw data in DN, not electrons.

My guess is that the curves are not being properly fit near base. But that's just the fit. Pixels in real life behave according to physics not according to a squiggly fit. So FWC is FWC. Read noise I need to think about a bit more, especially because I still have not fully understood why the curve(s) start deviating so early from the ideal.

I'm not curve fitting to get the read noise values that I report.

How are you doing it, Bill?

You caught me in a half-truth.
Depending on the camera there may or may not be Optical Black (OB) data.
Depending on the camera the data in the image area and/or OB may or may not be clipped.
(Sadly, even data with a non-zero Blacklevel can be clipped).
For clipped data I do fit the histogram to a normal distribution.

As a "sanity check" I try to compare measurements from different techniques.
(Such as image area read noise versus OB read noise).

FWIW, for the same reasons state above I don't think FWC is FWC; I think it's a function of wavelength.

Oh, my (again).

Do let me know if I'm dragging the thread Off-Topic (OT)

Regards,

 

[JimKasson]

The DN distributions for R and B are stretched with respect to Gr and Gb.
I've heard this called "white balance preconditioning".
But I'm arguing it's more like "QE compensation".

The conversion gain for the R and B channels must be higher.
It follows that the FWC for R and B must be lower.
I would think this would affect how white level is set since R and B would saturate ahead of Gr and Gb.

I've modeled this behavior in the Nikons, and it doesn't explain all of the discrepancy across channels. I should probably look at it again.

How are you doing it, Bill?

You caught me in a half-truth.
Depending on the camera there may or may not be Optical Black (OB) data.
Depending on the camera the data in the image area and/or OB may or may not be clipped.
(Sadly, even data with a non-zero Blacklevel can be clipped).
For clipped data I do fit the histogram to a normal distribution.

That makes sense to me, and fits my experience.

As a "sanity check" I try to compare measurements from different techniques.
(Such as image area read noise versus OB read noise).

Sounds wise.

Jim