So here is what may be going on. I found that the off-color gray bars would go to full black and full white. It was only in the gray zones that they looked different. In digging through the datasheet, the following footnote caught my eye:
"PRNU (Pixel response nonuniformity) is the maximum difference between the voltage from any single pixel and the average output voltage from all pixels of the device under test when the array is uniformly illuminated at the white irradiance level. PRNU includes DSNU (Dark signal nonuniformity)."
If I understand this geek-speak correctly, the manufacturer is telling us there may be some pixels lighter or darker than the others. This will vary from device to device, with differing degrees of prominence.
I think that's the right reading. Basically they're saying that there's a variation to each voltage level by +/- 20% from the average of all pixels when the whole sensor is being uniformly illuminated at a level such that the average reading is fully saturated. They don't give a lot of detail on how that translates over the whole exposure range, but I'd assume it's roughly linear - that it's effectively a +/- 20% error bar on each individual reading. What's also not clear is whether the error for a particular pixel is constant over time, or if it's a random fluctuation on each reading. If it's constant over time, it could be compensated for by gathering a bunch of calibration exposures to get a baseline for every pixel, figuring the ratio of that pixel's reading to the average over the whole sensor, and then dividing every reading of every pixel by that ratio. If it's random on every reading, it would have to be handled with a dynamic noise reduction method.
There's also a random noise component from the ADC (the hardware module on the KL25Z that converts the voltage level read from each pixel to a digital value for the software). And then there's the light source itself - our light sources are certainly not even close to perfectly uniform in time or space, and there are all sorts of stray lights and reflections that add further artifacts.
Anyway, the current software doesn't make any attempt to compensate for individual pixel response variation...
@mjr - I did a little spelunking into your code... What I have not found is where you accommodate the varying sensitivity of each pixel.
Well, you haven't missed anything, because it's not there. 
I haven't actually even experimented with that, mostly because all of my empirical testing has seemed to indicate that random noise is the big factor. So the algorithm is just meant to be tolerant of random noise in aggregate, without trying to compensate specifically for any one source.
At some point I have not yet found (maybe in ccdSensor.h) you do a numerical average of dark to light, looking for the edge of the plunger shadow. The first time you encounter a pixel where the luminance dramatically drops, that becomes the shadow.
It actually doesn't do any averaging - it just pulls the pixels at opposite ends of the sensor and uses those as the dark/bright levels. The reasoning is that the plunger shadow edge always has to be somewhere in the sensor window, so the pixels at one end will always be in shadow, and the pixels at the other end will always be bright.
This is part of the noise tolerance strategy, by the way. We don't know what the absolute exposure level is for any one frame - the time can vary, and we want to be tolerant of a wide range of lighting conditions - so we just take the samples of the extremes from each frame get the actual light-to-dark range for that frame.
We really do not care about "shades of gray" in this application. Would it be possible to introduce a deliberate rounding of the pixel luminance values as they are read? The idea is that anything below a certain threshold is considered black. Anything above a second higher threshold is considered white. This is the same approach the venerable TTL devices used. Anything below 1.5 is a zero, anything above 3.5 is a one.
That's actually not far off from the effect of the algorithm, even though it doesn't actually recalculate any pixel values. The algorithm finds the extremes of the exposure levels, then calculates a midpoint between them. (The midpoint isn't quite the halfway point - it seems to work better to weight it a bit more toward the bright side.) Anything brighter than the midpoint is pegged to "fully exposed" in the scan, and anything dimmer than the midpoint is pegged to "fully dark". The edge finder just finds the place where we switch sides. As long as any noise artifacts in the image are on one side or the other of that midpoint, it doesn't matter how "gray" they are.
I actually tried adding some more formal noise reduction when I was working on the new version of the sensor scanner a couple of months ago. I found that a rank selection filter (basically a median cut filter) did a really good job of cleaning up the noise - but unfortunately, the poor little 48 MHz M0+ CPU couldn't execute it fast enough to keep up with the sensor frame rate, so I reluctantly had to remove it. I did, however, tweak the edge finder algorithm slightly to make it a little better at rejecting transient pixel noise locally.
I might experiment a little at some point to see if it's possible to improve things with PRNU calibration - but not until after I get the new release out. My intuition is that it wouldn't do much good given the magnitude of the random noise factors, but I've been around long enough to know that my intuition doesn't always stand up to numerical analysis, so I'll at least spend some time gathering data and see if it would help and could be made fast enough at run-time.
Top
are all trademarks of VPFORUMS.