Processing VIMS cubes, An attempt at "true" color Options

[ugordan]

Right, a suggestion I made here in another topic made me wonder why not try that myself. A bunch of data was sitting on the PDS, after all. After a hassle figuring out just how the image cubes are organized and trying to read them, finally I was able to produce some results. This is all very rough work, can be considered first-iteration only and not particularly accurate.
Basically, I used the cubes to extract the visible spectrum in the 380-780 nanometer range which was then input to color matching code I found here by Andrew T. Young.
The code integrates over 40 10-nm steps to produce CIE XYZ color components. I then converted these to RGB values.

I'm aware of at least three inaccuracies in my code as of yet: one is the above sampled code apparently uses Illuminant C as the light source, not true solar spectra so the color turns out bluish (has a temp. of 9300 K instead of 6500 K, AFAIK). I tried to compensate at the moment by changing the final RGB white balance, but this is probably an inaccurate way to go. Another inaccuracy is I don't do bias removal from the cubes. This likely affects the outcome. Also, I don't use the precise wavelengths the code requires, but use the closest one in the cube. I intend to fix this by interpolating between nearest wavelengths.

All images are enlarged 4x.


The leftmost image is a 4-cube mosaic. The colors in all four frames turned out identical which gives me at least some confidence. The image in the middle shows Dione's disc creeping in front of Saturn. Dione's disc appears elongated probably because as the lines were readout, it moved considerably in its orbit. The rightmost image shows a very overexposed Saturn image, the part below the ring shadows got overexposed. From what I've seen browsing through the PDS, a lot of the cubes are badly overexposed at some wavelengths.

Here's a couple of Jupiter images. I'm not very satisfied with them as they seem to look somewhat greenish, but overall the color looks believeable:



Lastly, two Titan composites. They turned out way more reddish than I thought they would.


It'll be interesting to see how much the results will change once I do a more proper processing pipeline working.

[Guest_DonPMitchell_*]

Very good. Gamma 2.2 is technically what should be done, to get the image we see on the monitor to be proportional to actual scene radiance. What is the camera's radometric response function like? Are the pixel values in the VIMS file logarithmic?

As for dark current, making the background be 0 black should be right. But check the camera response. Subtracting background before or after linearization of the pixel values gives a totally different result if the camera response is nonlinear (and it probably is).

I'm not sure about the Illuminant C business. I'm not sure I understand what you did. The sRGB matrix assumes a white point of D65, which all new monitors are supposed to do. Don't think about correcting the color on the camera end, just concentrate on linearizing its response. Just plug those spectral radiance values into the XYZ integrals, convert to RGB by matrix multiple, and do gamma of 2.2. And you should see what the camera saw then!

[Malmer]

Very good. Gamma 2.2 is technically what should be done, to get the image we see on the monitor to be proportional to actual scene radiance. What is the camera's radometric response function like? Are the pixel values in the VIMS file logarithmic?

correct me if im wrong but: sRGB does not use a 2.2 gamma. it uses its own custom crve that is reasonably close to gamma 2.2...




the red curve is gamma 2.2
the green is sRGB:s "gamma" curve
the blue is just linear.

The difference is mostly visible in the dark regions.

/M

[Guest_DonPMitchell_*]

correct me if im wrong but: sRGB does not use a 2.2 gamma. it uses its own custom crve that is reasonably close to gamma 2.2...




the red curve is gamma 2.2
the green is sRGB:s "gamma" curve
the blue is just linear.

The difference is mostly visible in the dark regions.

/M

I asked Gary Starkweather about this a few years ago, because the documentation talks about gamma of 2.2, and then also describes a piece-wise function. He told me the piecewise function was just introduced because there is some way to calculate it that is much faster than pow(x, 2.2). He claimed that gamma of 2.2 is what is intended. Just now, I found this page which seems to say the same thing.

[Malmer]

I think the strange piecewise funktion has its benefits. it gives slightly better coverage in the black regions... when handling 8bit images...