DSPographer, am actually following what you are saying about putting noise back when rebuilding say an uncompressed TIFF image from a raw file. You've explained painstakingly in this thread that there's inevitably sizable noise in data, and that noise-numerical-error goes up as (perhaps roughly) the square root of the pixel brightness. Therefore, say we're discussing a sensor where the top brightness level the pixel can output is assigned the max value, 4095.
When 3 pixels are all struck with the same really bright light, of actual level 4088, there's so much "square root of 4088-ish" noise that you might have pixel #1 reporting brightness 4089 (1 level too high because of noise), another one reporting 4086 (2 levels too low 'cause of noise), and another pixel reporting the perfect result of 4088.
So there's so much noise in this bright data that there's really no accuracy lost by storing a "4088" for all the pixels.
For all anyone knows, the light hitting all those pixels might indeed have been at level 4088 (and in fact in this example it was, in this example it was just noise that created the other slightly different 4086 and 4089 numbers).
And there's perhaps so much noise that you don't really know if the light is any dimmer on a pixel until you get down to a pixel that reads out at, say 4080. So really, why bother providing unique numbers for the bright pixel values
between 4081 and 4095? Just store a "4095" for every pixel reading out anywhere between 4081 and 4095, store a "4094" for every pixel that read out between 4066 and 4080, etc.
This is what the Sony compression scheme is doing, assigning far fewer different numbers to the brightest values in the raw data off the sensor. And any Sony raw converter must know that sensor-value-to-raw-file-number assignment scheme so that it can undo it. In our example when a raw file value of 4094 is encountered, the raw converter should know that came from a real sensor brightness value of about 4073 (out of 4095 max).
Poster Iliah feels that useful data is being lost by in essence rounding off all those high original sensor data values varying between 4081 and 4095, and representing them in the stored raw file with a single number "4095". But you've pointed out that a knowledgeable raw file converter could for all practical purposes produce a set of uncompressed TIFF pixel values
that is as accurate and full of naturalistic variation as the original pixel data . By simply adding a random number between -7 and +7, to a brightness of 4088, to come up with the uncompressed pixel value, whenever the raw converter ecounters a "4095" in the raw file.
So in our example say the raw converter reads the value "4095" in three different places in the raw file. The converter might write a value into the .TIFF output file of 4088 when it reads the first "4095". But the converter will according to DPSographer add say (a random offset) +3 to the next raw number "4095" it finds, and write that out to the .TIFF as a 4091. Maybe it'll take -2 off the next "4095" and write that out as a 4086. It will do this "random error injection" into the .TIFF values so that there is no
misleading sameness i.e. banding to the output pixel values in the .TIFF file.
So in our example the sensor values of 4089, 4086, and 4088 were all stored in a raw file as number 4095. A stupid raw converter would, upon reading those raw piexls, have written all 3 of them into the output file as a uniform brightness value of 4088. But when those raw values are converted to .TIFF by the
good algorithm with random noise injection described in the previous paragraph, the raw file values might be rebuilt for the .TIFF output file as values 4088, 4091 and 4086.
It
seems at a glance that that good raw converter has "lost something", because its random noise injection has rebuilt the original 4089, 4086 and 4088 values (all stored in the raw file as 4095) as 4088, 4091 and 4086 for the .TIFF output file. But the good converter has, via the noise injection, refrained from writing out the "4095" raw values to the .TIFF as a misleadingly bland block of white space, a "band".
And the error in the reconstituted .TIFF file values, is no greater than the noise-created errors in the original pre-raw-storage sensor values anyway.
Fairly low distortion 28mm enlarger lens, about F8
Or you know the result already, and it is not to your liking?
