Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensive NaN Pixels and Ringed Artifacts After Geostationary Satellite Image Projection #2756

Open
akasom89 opened this issue Mar 9, 2024 · 6 comments

Comments

@akasom89
Copy link

akasom89 commented Mar 9, 2024

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

@simonrp84
Copy link
Member

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.

@djhoese
Copy link
Member

djhoese commented Mar 9, 2024

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?

@simonrp84
Copy link
Member

simonrp84 commented Mar 9, 2024

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.

@djhoese
Copy link
Member

djhoese commented Mar 10, 2024

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.

@akasom89
Copy link
Author

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.

@djhoese
Copy link
Member

djhoese commented Mar 11, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants