Thank you for your reply. After further analysis, it seems that this kind of histogram is to be expected. I think part of the confusion for me was because I initially assumed that the values coming from the camera will occupy the first 14 bits of the 16-bit range. They are instead spread over 16 bits. I recreated an histogram but this time without any debayering, so directly on the sensor data. In this case we can see that the values are always even numbers (at least most of them) and are spaced evenly on 16-bit range (between 0 and 65533). The gap between each value is 4 which is logical since only 16384 values are possible with 14-bit. I also went back to the histogram that I produced using the PhaseOne SDK and gaps were present too (but less obvious). In this case, they seems to use some kind of contrast correction which I don't have control over. So that's it, I suppose I just need now to divide the pixel values by 4 so all the data will be concentrated on the first 16384 values. Thanks again.
Hi Alex,
Thank you for your reply. After further analysis, it seems that this kind of histogram is to be expected. I think part of the confusion for me was because I initially assumed that the values coming from the camera will occupy the first 14 bits of the 16-bit range. They are instead spread over 16 bits. I recreated an histogram but this time without any debayering, so directly on the sensor data. In this case we can see that the values are always even numbers (at least most of them) and are spaced evenly on 16-bit range (between 0 and 65533). The gap between each value is 4 which is logical since only 16384 values are possible with 14-bit. I also went back to the histogram that I produced using the PhaseOne SDK and gaps were present too (but less obvious). In this case, they seems to use some kind of contrast correction which I don't have control over. So that's it, I suppose I just need now to divide the pixel values by 4 so all the data will be concentrated on the first 16384 values. Thanks again.