Improve calibration for M20 ECAM

[sschmaus]

I noticed several issues with the current calibration data and workflow for the M20 engineering cameras. I will show comparisons between MRU v7.0 and my own calibration process written in python. The images in these examples are all from Sol 795.

1. mru calibrate crops the image by two pixels at every edge. This crop is not reflected in the .json metadata and should preferably not happen anyway as there are no telemetry pixels to crop away with these images.

2. JPG compression of flatfield images severely decreases quality by introducing blocky artefacts I derived my flat from the official PDS flat, but extrapolated the masked edges so they are not automatically removed by the calibration. Masking should happen optionally in a different step in my opinion. Another thing I changed from the original flat is that I added noise reduction to it because the flat (contrary to good practices I know from astrophotography) seems like only a single frame and is therefore quite noisy which will add unnecessary noise to the calibrated image.

3. Bias (sensor readout noise) should be subtracted after decompanding and before flatfielding the image. The bias values are specified in the M20_rad_cal.params file: https://pds-geosciences.wustl.edu/m2020/urn-nasa-pds-mars2020_mission/calibration_camera/param_files/M20_rad_cal.parms The flatfield images already have this bias removed (hence bias in their name) and applying them to a non bias-subtracted image will result in uneven calibration (edges will appear less contrasted and too bright). For this comparison I adjusted the whitebalanceing and brightness to make it more obvious.

4. There is a residual color cast after flat fielding the image with MRU. It especially shows up after color calibration because this process increases the saturation of the image. I believe this is also an issue with the missing bias subtraction. I applied some black clipping to the MRU image in this example after flatfielding to make both images look comparable, otherwise it would look a lot less contrasted.

Some of these issues can be fixed with better calibration files, I would recommend 16bit png/tiff images, but 8bit png might also just be sufficient. I understand you want to keep the file size low for your Debian packages, so I would suggest either an alternative calibration data repository that the user has to download themselves or a calibration data fetch routine that can download a larger repository after installing the program. I would be happy to supply my own derived flatfield images to the original repository or make a fork of your calibration data repo with higher quality calibration files.

As far as I know MRU doesn't support bias subtraction yet, so I think that should a) be implemented in the code and b) the bias values should be added to the calibration data repo.

[kmgill]

• Yes, I do need to update the JSON to reflect cropping. Most instruments are effected by this. As it is, the whole json metadata structure needs a revamp as it's too rigid and a pain to update from the calibrators.
• The main reason I used JPEG for the flats as they needed to fit into a 30MB max size for the .deb packages created by cargo deb (I believe that max is a bug on their part as I supply an option that should remove the limit). Now that I've implemented cal-data-update, I can remove the calibration data from the install packages and switch to PNGs.

[kmgill]

Also, what additional calibration are you applying post-MRU?

[sschmaus]

I tried to use MRU with the bias and flat changes at 5e07165e759d66a8b48af18844eb38e972049b2a but ran into several issues, it seems like the scale factor is not being considered at the moment, so the flat will be applied at full scale even on a downsampled image. The current calibration gives me this:

Also, the images seem to get stretched differently after calibration, which makes it impossible to assemble them afterwards, I don't know if that's intented behaviour to maximize the brightness space... (now that I think about it, it may be connected to the scale factor issue)

Regardless, if all of this was working at the moment, I'd convert the decompanded, bias subtracted and flatfielded image to a DNG with LinearRaw interpretation and the necessary color calibration matrix, exif metadata, etc.

Then I typically load these images into Lightroom which applies the color calibration on the fly, I like to set the white balance on a white reference in the scene. Lightroom also applies an s-shaped tone curve (this is default behavior and gets applied to any normal DSLR RAW photo you load into LR/PS, however this isn't really well documented...) In Lightroom I typically apply color noise reduction which can help with the blocky artefacts from the JPG compression.

So much for the "calibration part" of my workflow. On some images I apply a little dehaze and contrast adjustments to increase the clarity of the image because dust on the lens reduces clarity somewhat. It goes without saying that I'm never really trying to preserve the science quality, but to make an image that's nice to look at.

[sschmaus]

I figured out why the flatfielding wasn't working for me above. I was using the wrong calibration data directory which was not updated with the new downscaled flats, so MRU just used the full scale flat without telling me it was missing the downscaled files.

The calibration is now working correctly for me and the bias subtraction works as expected, so I'm getting nearly identical results as with my own calibration routine. Here is the above image precalibrated with MRU, then color calibrated with my own process. The color cast that was previously there is now completely gone.

There is a slight issue with the masked off regions becoming white instead of black. Not sure what causes this.