QE, Full Well, Gain and Filtering

[JimKasson]

It was hypothesized in this thread that making a hot pixel map and replacing each hot pixel with the median value of its immediate neighbors would be undetectable by the DSPographer frequency analysis.

I set out to test that. I ran my simulation with randomly distributed hot pixels. I was brutal with those pixels; I set them to full scale.





With a hot pixel density of 0.1%, we get this:





In order to get repeatable results, I upped the image size to 8192x8192, and set the FFT averaging bucket size to 8.

My interpretation of the above. The correction is undetectable.

With a 1% hot pixel density:





You can just barely begin to see the droop. Since I don't use 8192x8192 raw planes in my camera testing (that would imply a 16Kx16K sensor), this wouldn't be detectable, either.



If the hot pixel suppression algorithm is to replace each mapped hot pixel with the average of it's 8 immediate neighbors, that is detectable with 0.1% hot pixels:





Comments?

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

 

[sharkmelley]

Hi Jim,

I really wouldn't expect to see any difference between using the median and the mean.

Your results using the median make complete sense to me - 1% of pixels is hardly detectable. I could only just detect it at 2% of pixels using the mean: https://www.dpreview.com/forums/post/59074597

I think something somewhere must be going wrong when you use the mean.

I also think it would help detectability if you stretch the vertical scale on the plots.

Mark

 

[JimKasson]

Hi Jim,

I really wouldn't expect to see any difference between using the median and the mean.

Your results using the median make complete sense to me - 1% of pixels is hardly detectable. I could only just detect it at 2% of pixels using the mean: https://www.dpreview.com/forums/post/59074597

I think something somewhere must be going wrong when you use the mean.

OK. I'll go back and take a look.

I also think it would help detectability if you stretch the vertical scale on the plots.

Sure. But that's the most expanded scale I use with real cameras.

Jim

 

[JimKasson]

Hi Jim,

I really wouldn't expect to see any difference between using the median and the mean.

Your results using the median make complete sense to me - 1% of pixels is hardly detectable. I could only just detect it at 2% of pixels using the mean: https://www.dpreview.com/forums/post/59074597

I think something somewhere must be going wrong when you use the mean.

I can't find an error. Maybe you can. Here are the methods for both mean and median:

I also think it would help detectability if you stretch the vertical scale on the plots.

Here you go:





I screwed up the titles. Both are for the mean, not the median.

This next one really is for the median:







Jim

--
http://blog.kasson.com

 

[sharkmelley]

Hi Jim,

I really wouldn't expect to see any difference between using the median and the mean.

Your results using the median make complete sense to me - 1% of pixels is hardly detectable. I could only just detect it at 2% of pixels using the mean: https://www.dpreview.com/forums/post/59074597

I think something somewhere must be going wrong when you use the mean.

I can't find an error. Maybe you can. Here are the methods for both mean and median:

At first sight I can't see anything obviously wrong in your suppressHotPixelsAverage function. So I can't see why it should behave so differently to the median.

Maybe calculating the standard deviation of the resulting data in both cases might help to understand what is going on.

Mark

 

[Jack Hogan]

Hi Jim,

I really wouldn't expect to see any difference between using the median and the mean.

Your results using the median make complete sense to me - 1% of pixels is hardly detectable. I could only just detect it at 2% of pixels using the mean: https://www.dpreview.com/forums/post/59074597

I think something somewhere must be going wrong when you use the mean.

I can't find an error. Maybe you can. Here are the methods for both mean and median:

Jim, if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter. I wonder if it has something to do with the fact that the mean is more correlated to its surroundings than a median or min/max function.

Jack

 

[Joofa]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

--
Dj Joofa
http://www.djjoofa.com

 

[sharkmelley]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

But we are replacing isolated pixel values by either the average of the 8 immediate neighbours or the median of the pixel and its 8 immediate neighbours. The difference ought to be incredibly subtle. I'll run some tests tonight just to confirm what I see.

Mark

 

[Joofa]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

But we are replacing isolated pixel values by either the average of the 8 immediate neighbours or the median of the pixel and its 8 immediate neighbours. The difference ought to be incredibly subtle. I'll run some tests tonight just to confirm what I see.

Yes, you are right. I looked at Jim's code snippet again. It appears he is limiting filtering to hot pixels. Lets look forward to seeing what you get?

--
Dj Joofa
http://www.djjoofa.com

 

[JimKasson]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

But we are replacing isolated pixel values by either the average of the 8 immediate neighbours or the median of the pixel and its 8 immediate neighbours. The difference ought to be incredibly subtle. I'll run some tests tonight just to confirm what I see.

Yes, you are right. I looked at Jim's code snippet again. It appears he is limiting filtering to hot pixels. Lets look forward to seeing what you get?

The sigma is higher for hot pixel suppression with averaging than with median. I suspect that is because two neighboring hot pixels can infrequently occur, and only the contribution of the center one is mapped out of the averaging for each iteration of the convolution filtering.

I know how to fix this with a for loop, but a vectorized fix is not immediately apparent to me.

Jim

--
http://blog.kasson.com

 

[sharkmelley]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

But we are replacing isolated pixel values by either the average of the 8 immediate neighbours or the median of the pixel and its 8 immediate neighbours. The difference ought to be incredibly subtle. I'll run some tests tonight just to confirm what I see.

Yes, you are right. I looked at Jim's code snippet again. It appears he is limiting filtering to hot pixels. Lets look forward to seeing what you get?

The sigma is higher for hot pixel suppression with averaging than with median. I suspect that is because two neighboring hot pixels can infrequently occur, and only the contribution of the center one is mapped out of the averaging for each iteration of the convolution filtering.

I know how to fix this with a for loop, but a vectorized fix is not immediately apparent to me.

Jim

 

[JimKasson]

if the hotPixelMap is the same percentage of total pixels I am surprised that an Average would be more noticeable than a median or min/max filter.

It would appear to me that hot pixels appear like an impulsive noise. And, median filter would typically remove the impulses without smearing a signal like the mean or averaging filter.

But we are replacing isolated pixel values by either the average of the 8 immediate neighbours or the median of the pixel and its 8 immediate neighbours. The difference ought to be incredibly subtle. I'll run some tests tonight just to confirm what I see.

Yes, you are right. I looked at Jim's code snippet again. It appears he is limiting filtering to hot pixels. Lets look forward to seeing what you get?

The sigma is higher for hot pixel suppression with averaging than with median. I suspect that is because two neighboring hot pixels can infrequently occur, and only the contribution of the center one is mapped out of the averaging for each iteration of the convolution filtering.

I know how to fix this with a for loop, but a vectorized fix is not immediately apparent to me.

I think that neighbouring hot pixels is very likely the explanation of the anomaly you are seeing. My methodology avoided the inclusion of another hot pixel in the average of neighbours. I find no discernible difference between median and mean.

I have tried to come up with an estimate of the number of hot pixels mapped by my Sony A7S. I make the assumption that a mapped hot pixel will never have a value higher/lower than the max/min of the 8 immediate neighbours from the same colour channel. So I can take a flat frame and any pixels that break the condition can be eliminated. After churning through 100 flat frames I was left with only 25 remaining candidates in one colour channel. Multiply this by 4 colour channels and that gives an upper limit of 100 mapped hot pixels out of a total of 12Mpixels.

Thanks, Mark. About one in 100,000, or 0.001%. I think it's fair to say that the DSPographer method won't see anything with that few hot pixels. And the neighborhood of each hot pixel is exceedingly likely to be hot-pixel-free.

But to circle back around to what we were trying to get at, I don't think that mapping a tiny number of known hot pixels counts as material raw file "cooking" through digital filtering.

Can anyone think of an algorithm that doesn't depend on knowing the hot pixel map that the DSPographer frequency analysis wouldn't find?

Jim

 

[sharkmelley]

Thanks, Mark. About one in 100,000, or 0.001%. I think it's fair to say that the DSPographer method won't see anything with that few hot pixels. And the neighborhood of each hot pixel is exceedingly likely to be hot-pixel-free.

But to circle back around to what we were trying to get at, I don't think that mapping a tiny number of known hot pixels counts as material raw file "cooking" through digital filtering.

Can anyone think of an algorithm that doesn't depend on knowing the hot pixel map that the DSPographer frequency analysis wouldn't find?

We've shown that DSPographer frequency analysis can detect an algorithm that affects just 1 in 100 pixels. But an algorithm that affects just 1 in 100 pixels does not have any material impact on estimates of gain, full well or QE.

I would dare to say that if frequency analysis cannot detect the raw "cooking" then the raw "cooking" is not sufficient to materially affect the estimates of gain, full well or QE.

On the other hand, it is certainly possible to misinterpret "features" in the frequency analysis as being due to raw cooking.

Mark

 

[JimKasson]

Thanks, Mark. About one in 100,000, or 0.001%. I think it's fair to say that the DSPographer method won't see anything with that few hot pixels. And the neighborhood of each hot pixel is exceedingly likely to be hot-pixel-free.

But to circle back around to what we were trying to get at, I don't think that mapping a tiny number of known hot pixels counts as material raw file "cooking" through digital filtering.

Can anyone think of an algorithm that doesn't depend on knowing the hot pixel map that the DSPographer frequency analysis wouldn't find?

We've shown that DSPographer frequency analysis can detect an algorithm that affects just 1 in 100 pixels. But an algorithm that affects just 1 in 100 pixels does not have any material impact on estimates of gain, full well or QE.

I would dare to say that if frequency analysis cannot detect the raw "cooking" then the raw "cooking" is not sufficient to materially affect the estimates of gain, full well or QE.

So, unless some one can come up with such an algorithm, I think the ball is in Roger's court.

On the other hand, it is certainly possible to misinterpret "features" in the frequency analysis as being due to raw cooking.

Yes. I found that I got results like that from time to time until I increased the sample size a lot.

Jim

 

[Jack Hogan]

Thanks, Mark. About one in 100,000, or 0.001%. I think it's fair to say that the DSPographer method won't see anything with that few hot pixels. And the neighborhood of each hot pixel is exceedingly likely to be hot-pixel-free.

But to circle back around to what we were trying to get at, I don't think that mapping a tiny number of known hot pixels counts as material raw file "cooking" through digital filtering.

Can anyone think of an algorithm that doesn't depend on knowing the hot pixel map that the DSPographer frequency analysis wouldn't find?

We've shown that DSPographer frequency analysis can detect an algorithm that affects just 1 in 100 pixels. But an algorithm that affects just 1 in 100 pixels does not have any material impact on estimates of gain, full well or QE.

I would dare to say that if frequency analysis cannot detect the raw "cooking" then the raw "cooking" is not sufficient to materially affect the estimates of gain, full well or QE.

So, unless some one can come up with such an algorithm, I think the ball is in Roger's court.

On the other hand, it is certainly possible to misinterpret "features" in the frequency analysis as being due to raw cooking.

Yes. I found that I got results like that from time to time until I increased the sample size a lot.

Good work Jim and Mark. Roger?