ok.... - let's sort this out a little bit.
First of all, what you are up to is probably not really related to this forum - I highly doubt that Raspberry Pi hardware or software components are actually used in space probes (save of a few cube sats maybe).
Nevertheless, here are some further comments.
Usually, the color filters on a space probe's scientific or engineering cameras are quite different from the filters employed by, say, an Alexa or Red movie camera. I know this for sure for the Viking cameras as well as the Opportunity and Spirit rovers. The reason is quite simple: in a scientific context, you want to increase signal-noise ratio of the data you are concerned with. In a photographic or movie setting, you want to capture colors as close as possible to the colors a human observer would observe. Two very different task.
This difference is actually noticeable if you look at the filter curves of both types of sensors. Scientific cameras tend to have quite narrow filter curves whereas a normal image sensor is equipped with quite broad ones.
For the rest of this post let's talk only about normal (photographic/cinema) image sensors with broadly tuned color filters.
The pipeline from the raw image data to an image viewable by humans features several steps, and the compromise color matrix (ccm) is just one of these steps. As already indicated, it is possible to derive the ccms for different color temperatures or even different illuminations by simulating imaging a virtual color checker.
Now, a ccm is a compromise. And it depends on quite a variety of things, most notably the spectrum of the illumination chosen. I would assume that the spectral illumination curve on Mars is not quite exactly matching D65 (approx. the mid-day spectrum on Earth). A ccm also depends heavily on the number of samples chosen. You will obtain a different matrix if you chose a standard 24 patch color checker or one with a higher number of samples.
The white balance (wb) is another step in the camera's processing pipeline, and it basically tries to mimic the ability of our human eyes to see a grey card as grey, whatever the current illumination is (sun, fluorescent light, tungsten, etc.), within limits. Normally, the wb is estimated for us by automatic processes - from my own experiences, libcamera (the software stack used with Raspberry Pi sensors) does not do a very good job in estimating the correct wb values.
Note that there is a hierarchy for precise colors (on Earth):
In fact, you might want to have a look at the work done within the context of ACES (Academy Color Encoding System) (https://acescentral.com/. It's a way to work with scene referred color instead of the old display referred way.
On this topic: the Bayer color filters of a sensor come from the sensor manufacturer (in case of the IMX477 from Sony), the IR-block filter is usually selected by camera manufacturer (in this case the RP guys). To do the "virtual color checker" trick, you absolutely need the correct filter curve of the IR-block filter, otherwise your results are not correct at all. The IR-block filter usually affects the red response curve dramatically.
First of all, what you are up to is probably not really related to this forum - I highly doubt that Raspberry Pi hardware or software components are actually used in space probes (save of a few cube sats maybe).
Nevertheless, here are some further comments.
Usually, the color filters on a space probe's scientific or engineering cameras are quite different from the filters employed by, say, an Alexa or Red movie camera. I know this for sure for the Viking cameras as well as the Opportunity and Spirit rovers. The reason is quite simple: in a scientific context, you want to increase signal-noise ratio of the data you are concerned with. In a photographic or movie setting, you want to capture colors as close as possible to the colors a human observer would observe. Two very different task.
This difference is actually noticeable if you look at the filter curves of both types of sensors. Scientific cameras tend to have quite narrow filter curves whereas a normal image sensor is equipped with quite broad ones.
For the rest of this post let's talk only about normal (photographic/cinema) image sensors with broadly tuned color filters.
The pipeline from the raw image data to an image viewable by humans features several steps, and the compromise color matrix (ccm) is just one of these steps. As already indicated, it is possible to derive the ccms for different color temperatures or even different illuminations by simulating imaging a virtual color checker.
Now, a ccm is a compromise. And it depends on quite a variety of things, most notably the spectrum of the illumination chosen. I would assume that the spectral illumination curve on Mars is not quite exactly matching D65 (approx. the mid-day spectrum on Earth). A ccm also depends heavily on the number of samples chosen. You will obtain a different matrix if you chose a standard 24 patch color checker or one with a higher number of samples.
The white balance (wb) is another step in the camera's processing pipeline, and it basically tries to mimic the ability of our human eyes to see a grey card as grey, whatever the current illumination is (sun, fluorescent light, tungsten, etc.), within limits. Normally, the wb is estimated for us by automatic processes - from my own experiences, libcamera (the software stack used with Raspberry Pi sensors) does not do a very good job in estimating the correct wb values.
Note that there is a hierarchy for precise colors (on Earth):
- white balance + compromise color matrix (ccm)
- white balance from grey card + compromise color matrix (ccm)
- color checker with reference colors and grey patches
In fact, you might want to have a look at the work done within the context of ACES (Academy Color Encoding System) (https://acescentral.com/. It's a way to work with scene referred color instead of the old display referred way.
Well, can be found here (viewtopic.php?t=306224). I simply ripped out the blueish filter and measured it with a spectrometer. Only to discover that the RP guys actually published the filter curve already (see cited thread). Note also that newer HQ sensors (IMX477) feature a slightly different IR-block filter - it has however only minor effects on the ccm's of the sensor.Your measurement of the UV/IR filter would be interesting to see as graph as I had to guess that part for the imx214 helicopter camera which is actually most likely one of the standard raspi modules as the helicopter runs Linux. I used a hypothetical 400-700nm transmission.
On this topic: the Bayer color filters of a sensor come from the sensor manufacturer (in case of the IMX477 from Sony), the IR-block filter is usually selected by camera manufacturer (in this case the RP guys). To do the "virtual color checker" trick, you absolutely need the correct filter curve of the IR-block filter, otherwise your results are not correct at all. The IR-block filter usually affects the red response curve dramatically.
Statistics: Posted by cpixip — Thu Jul 04, 2024 6:14 am