- that is actually a quite bad performance for the RP5. Rules out the RP5 for any serious scientific work.
In fact, the fct "raw digit" vs "exposure" should be a perfect linear one, as exemplified by your RP3 result. Basic sensor physics...
One major deviation the RP5 features is that it's processing defaults to a "compressed raw" format - which is not identical to the raw data values your sensor had actually recorded.
At least if you request a ".dng"-file, the "compressed raw" is converted back to the standard 16bit/channel, normal raw format. Of course, some image information is lost along that way. Since there is currently no documentation about the compression algorithm - except reference C/Python-implementation without any comment line available - it is hard to judge what reduction in image quality this design decision has.
It seems that you can force the RP5 to use the good old normal raw formats by explicitly requesting them. I see in your code that you are actually doing this ('format': 'SGBRG10'[ should trigger that), but since these configuration options were broken in picamera2 some time ago, I would check whether the RP5 is actually using the requested old format.
From a logical point of view: since your setup as well as your picamera2 script do not change between your experiments, only the RP3 is swapped with a RP5, the differences you see in your experiment clearly point to a difference in the processing of raw sensor data in the new RP5, compared to the RP3. Whatever that is...
In fact, the fct "raw digit" vs "exposure" should be a perfect linear one, as exemplified by your RP3 result. Basic sensor physics...
One major deviation the RP5 features is that it's processing defaults to a "compressed raw" format - which is not identical to the raw data values your sensor had actually recorded.
At least if you request a ".dng"-file, the "compressed raw" is converted back to the standard 16bit/channel, normal raw format. Of course, some image information is lost along that way. Since there is currently no documentation about the compression algorithm - except reference C/Python-implementation without any comment line available - it is hard to judge what reduction in image quality this design decision has.
It seems that you can force the RP5 to use the good old normal raw formats by explicitly requesting them. I see in your code that you are actually doing this ('format': 'SGBRG10'[ should trigger that), but since these configuration options were broken in picamera2 some time ago, I would check whether the RP5 is actually using the requested old format.
From a logical point of view: since your setup as well as your picamera2 script do not change between your experiments, only the RP3 is swapped with a RP5, the differences you see in your experiment clearly point to a difference in the processing of raw sensor data in the new RP5, compared to the RP3. Whatever that is...
Statistics: Posted by cpixip — Fri Feb 09, 2024 7:53 am