pytroll/satpy

Extensive NaN Pixels and Ringed Artifacts After Geostationary Satellite Image Projection

Opened this issue · 6 comments

After projecting/resampling a geostationary satellite image from Geostationary projection to Mercator projection, I'm encountering extensive NaN (Not a Number) pixels in between valid pixels. Additionally, there are ringed artifacts present in the resulting image.

I understand that some may attribute this issue to the presence of "space pixels" in the GEO projection system. However, I'm struggling to comprehend the logic behind this explanation. For instance, when considering the 149-degree meridian, why would a latitude of 59 degrees be considered invalid (assuming it's in space) when there are valid points even at higher latitudes, such as 70 degrees?

I'm seeking guidance on potential solutions or approaches to address these issues. Are there any known techniques or methods that can help mitigate the presence of NaN pixels and ringed artifacts after the projection/resampling process?

Environment Info:

  • OS: Windows
  • Satpy Version: 0.43.0
  • PyResample Version: 1.26.1

artifact

It would be helpful if you show your code as it's harder to diagnose the issue without this.

However, in this case I suspect the solution is to change your resample call:

scn2 = scn.resample(some_area, resampler=some_resampler, radius_of_influence=50000)

It's the radius_of_influence argument that's important here. Often it's too small by default for geostationary data.

I was going to suggest the same thing as @simonrp84. @simonrp84 is it always too small by default for geostationary data or only on the edges of the disk?

Tbh I rarely use it as I'm mainly resampling with native.

In any case there's no clear answer, it depends on the satellite. For the modern sats (GOES, Him, GK2A, etc) the default has always been fine for me for areas near the disk center. Beyond about 60 degrees view zenith you start to see these gaps appear though.

(edit) And for the older sats (MSG, Insat, etc) the problem appears at lower angles due to the worse pixel size.

Yeah. It is all based on me (I added the functionality) trying to make an educated guess at what geocentric distance between pixels makes the most sense. On one hand you want it to be large enough to not cause these gaps, but you also don't want it to be too large that you get repeated pixels on the edge of the input data. If we needed/wanted a special case for geostationary projections we could do that. I'm sure my existing guesses could be improved.

Thanks @simonrp84 for your answer. you are right. providing a high value for radius_of_influence would remove those gaps in an acceptable way.

Also thanks to @djhoese. I think if it was possible to have kind of field of view for each sensor (which depicts the valid area), those repeated pixels could be removed by that.

@akasom89 Yes. This could be seen/thought of as an extra masking step. This is not too bad for something like geostationary satellites where this is static, although it is an additional processing step. For polar-orbiting swath-based data this type of masking is not very possible as it would add a lot of time to processing. That said, this radius of influence stuff is only a problem for nearest neighbor resampling as implemented by the "nearest" resampler. Other resamplers don't use this type of searchable radius.