gh2 file sizes

Started Dec 20, 2011 | Discussions thread
Franksson Forum Member • Posts: 93
Re: Raw: why?

As I promised in my earlier post, I have been looking for examples of small pixel values impacted by a high shift value. To achieve this I have written my own version of a RW2 decoder, based upon knowledge gained from DCRaw. It found it easier to modify my own code to get at the data I am looking for. In the process, I discovered a few interesting things.

To test my decoder accuracy, I compared my output with that obtained from DCRaw with the options -v -D -r 1 1 1 1 -o0 -4 -T -H 1. This generates a Tiff file with no Bayer interpolation and no tone curves. I.e containing just the raw data. Well almost just the raw data. I noticed some differences. There were a number of pixels where I have zero, and DCRaw has other values. I now know that I have 11 stuck pixels, and where they are. I also know that they have been there since the camera was new. DCRaw is interpolating stuck pixels even with the above options. 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.

I have looked in a number of images for cases where there is a shift value of 4 and the result of applying the difference value is less than 96 (I will use decimal values throughout this post). I chose 96 because there appeared to be a consensus elsewhere in this forum that RW2 raw data is modified to start from 16. (This seemed to make sense. Given that zero mean stuck and the lossy compression means it is not possible to guarantee to generate a zero value in all pixel locations, it seemed to me that a pixel value

For many images, there are no instances at all. Images with high ISOs, and hence lots of noise, have many instances. This is no surprise. Here is an image that did surprise me a little.

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.

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 am not sure if the 4 bit error that I assumed is necessarily correct. If you look at the range of possible errors for a 4 bit shift value, (I.e all possible combinations of generated LSBs and true LSBs at the sensor) then it would be possible for the encoder to reduce the range of the error. If the error is greater than + or - 8 then the encoder can reduce it to be less than 8 by adding or subtracting 16 to/from the calculated difference. I have no way of knowing if the Panasonic engineers have implemented this in the encoder. It would halve the potential errors, so I hope so. If not, maybe they could add it in the next firmware release.

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

Any thoughts?

 Franksson's gear list:Franksson's gear list
Panasonic Lumix DMC-GH2 Panasonic G85 Panasonic Lumix G Vario 7-14mm F4 ASPH Panasonic Lumix G Vario HD 14-140mm F4-5.8 OIS Panasonic Lumix G Vario 100-300mm F4-5.6 OIS +1 more
Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow