gh2 file sizes

Started Dec 20, 2011 | Discussions thread
kenw
kenw Veteran Member • Posts: 6,308
Re: Raw: why?

Awesome work!

Franksson wrote:

Interestingly all my stuck pixels are at locations where a full 12 bit value is generated. I.e bits 0 or 1 in the group of 14. I would expect stuck pixels to occur anywhere with equal probability, so the chances of 11 all appearing in these locations seems to be rather small - somewhere in the order of 1 in 2 billion. There must be something else going on, but I have no ideas at the moment.

Hmmm... That is a bit weird. On the other hand, looking at the DCRAW code it appears there is something odd going on with those first positions - they aren't necessarily always 12-bits - if they are zero then they are only 8-bits and the 12-bit value is deferred to later in the group (see the conditionals based on the variable nonz ).

If I had to guess what you are seeing is either a bug in the DCRAW algorithm you are deriving from or there is a bug in the Panasonic encoder that is only successfully flagging stuck pixels in those positions (meaning that your sensor likely has around 77 stuck pixels only 11 of which are flagged properly). The RAW converters all find the unflagged stuck pixels on their own just fine so the bug would be hidden in real use. Can you with your code easily search for unflagged stuck pixels somehow (maybe a dark exposure and just check for large valued pixels that make it through)?

Anyway, as you say, strange.

There are 3054 pixels which fit the criteria. Not enough to cause me too much concern, only 0.02% of total pixels and, as far as I can tell (because there's no way I'm going to look at them all), they are all on the dark side of the side lit branches in the trees. With the level of contrast, I doubt anyone could detect the error visually.

Another way to look at it is to assume if they are doing the rounding "intelligently" that the error is best modeled as a uniform distribution from -7 to 8. What would the impact be compared to read noise that is already present? I've got the read noise distribution from my dark frame tests, for ISO160 it is approximately:

1 - 1e6
2 - 4e5
3 - 1e5
4 - 5e4
5 - 1e4
6 - 6e3
7 - 3e3
8 - 1e3

It is presumed to be symmetric based on the encoding (and this is what the histogram looks like as well) so same values for negatives. (First column is read noise in ADC value, second column is number of pixels with that read noise). In the worst case image here the uniform distribution would be about 190 for each of the values -7 to 8. Even out at the read noise tail at position 8 this is a factor of five below the read noise and for the lower values quickly becomes many orders of magnitude below the read noise.

So yeah, I think even in this example it would be impossible to distinguish from the read noise already present and the effective noise power added to the image by the encoder rounding is much, much lower than the read noise.

Also consider, at a count of 80 the shot noise is already about 9 as well and we didn't even consider that above.

So far, I haven't found any instance where I could say that the error would be visible to even the most astute pixel peeper.

I'd agree. That tree image is a great example of a bad case though!

Finally another observation. In some of my images there are a small number of pixels where a value of 15 is generated. So assumptions about

I saw that in my dark frame tests as well.

Thanks for following up. I know that was a lot of effort, and it is really informative.

-- hide signature --

Ken W
See plan in profile for equipment list

 kenw's gear list:kenw's gear list
Panasonic Lumix DMC-GM1 Olympus E-M5 II Nikon Z7 Nikon Z 14-30mm F4 Nikon Z 24-200mm F4-6.3 VR +37 more
Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow