I have found that the DoasFOV.plot() method doesn't work if there are NaNs in the correlation image. This seems to be because the definitions of vmin and vmax on line 489 of doascalib.py are retrieved from min()/max() methods which return NaN if any NaNs are present in the array. I'm not sure if this is desired behavior or not. NaNs are present in the correlation image if any pixels have exactly the same value throughout the entire image stack, as the NaN is returned from scipy.stats.stats.pearsonr(), line 3506:
# If an input is constant, the correlation coefficient is not defined.
if (x == x[0]).all() or (y == y[0]).all():
warnings.warn(PearsonRConstantInputWarning())
return np.nan, np.nan
A scenario where this is quite likely in SO2 camera work is following image registration - parts of the off-band image that do not overlap the on-band image are defined as NaN (to keep the dimensions of the two images the same and on the same grid), or they can be set to 0 to avoid NaNs. Either way, this constant value in these pixels throughout the image stack will causes the error described above when working with DoasFOV.plot().
There may be other issues caused by this behavior which I haven't found yet. In general, it may be best to make the package accept NaNs in images by using np.nanmax()/np.nanmin() etc, rather than methods that return NaN if any NaNs are present in an array. Although this would probably be a lot of work... and perhaps there is a good reason to not accept NaNs which I am missing?
I have found that the
DoasFOV.plot()method doesn't work if there are NaNs in the correlation image. This seems to be because the definitions ofvminandvmaxonline 489ofdoascalib.pyare retrieved from min()/max() methods which return NaN if any NaNs are present in the array. I'm not sure if this is desired behavior or not. NaNs are present in the correlation image if any pixels have exactly the same value throughout the entire image stack, as the NaN is returned fromscipy.stats.stats.pearsonr(), line 3506:A scenario where this is quite likely in SO2 camera work is following image registration - parts of the off-band image that do not overlap the on-band image are defined as NaN (to keep the dimensions of the two images the same and on the same grid), or they can be set to 0 to avoid NaNs. Either way, this constant value in these pixels throughout the image stack will causes the error described above when working with
DoasFOV.plot().There may be other issues caused by this behavior which I haven't found yet. In general, it may be best to make the package accept NaNs in images by using
np.nanmax()/np.nanmin()etc, rather than methods that return NaN if any NaNs are present in an array. Although this would probably be a lot of work... and perhaps there is a good reason to not accept NaNs which I am missing?