Low Cloud Map for MSGs

[akasom89]

Describe the bug
LowCloudCompositor seems to produce wrong results for meteosat satellites.
The result is too much biased over land areas. The same thing does not happen with other satellites(I mean products of other satellites are more reasonable visually, but I am not sure they are correct or not!).
Is this a problem with meteosat?! or LowCloudCompositor?

To Reproduce

    msg_low_cloud= LowCloudCompositor('msg_low_cloud')
    diff= scene[ir] - scene[swir]
    lc = msg_low_cloud([diff, scene[ir], mask])

Expected behavior
It was expected some regions be cloudy. not almost all land pixels. using the same land_range for other satellites did not end to such results.

Screenshots

Additional notes
Also extracting emissive part of swir did not help at all.

[ameraner]

Hi @akasom89 , I'm not an expert for this (@strandgren implemented it in #2557), but two things come to my mind:

• the compositor is supposed to work only during nighttime... maybe this is a daytime scene?
• each sensor needs some tuning to get sensible results, as you've noticed. We didn't do this tuning for SEVIRI yet... if you can, you're welcome to try out some of the parameters (like range_land and range_water) and let us know if you find something that works!

[strandgren]

Hi @akasom89, just to add to @ameraner's reply. I did try to add GeoColor, including this LowCloudLayer, also for SEVIRI in #2557. However, I had the same issue with way too many false alarms. I discussed this with CIRA (who initially developed GeoColor) at the time and they use rolling temporal (monthly I think) average brightness temperature values for the IR3.8 and IR10.8 channels to derive the thresholds for the low cloud detection. Hence, I didn't have the time to look into this in #2557. Can still be that tuning the range_land and range_water as mentioned above can give you good enough results.

[akasom89]

Hi @strandgren , @ameraner .

Thanks for your answers.

As you mentioned, by tuning the ranges we might get something close and reasonable, But I am worried that these tuning be dynamic. I mean same setting which works for images of this week, may or may not work two month later(due to reasons like change in illumination geometry or so!).

Is there any more technical details regarding "rolling temporal (monthly I think) average brightness temperature values for the IR3.8 and IR10.8 channels to derive the thresholds for the low cloud detection."? mainly the thresholds after moving averages.

Thanks a lot.

[strandgren]

Hi @akasom89,

This is the feedback I got from CIRA colleagues at the time:

For SEVIRI, the low-cloud layer thresholds are based on collecting long term statistics(~ 1 month of data) on the brightness temperature difference between the 10.8 um and 3.9 um bands:

meanf = mean brightness temperature difference (band9 - band4) in K at each pixel
minfland = meanf[over_land] + 2. ;K
maxfland = 90th percentile value of meanf[over_land]
minfwater = meanf[over_water] + 1. ;K
maxfwater = 90th percentile value of meanf[over_water]

Seems like I was remembering wrongly about the "rolling" average values, you probably just need to compute the thresholds once, but using ~1 month of data.

Let me know if you give it a try, would be interesting to see and also have it implemented in Satpy if it works well.

[akasom89]

Thanks @strandgren for sharing CIRA's answer.

It seems interesting. I have to give it a try!

As you know better, the only issue with MSGs is not just its night side. Since we miss two visible bands (green and blue), I have a really hard time achieving an acceptable result similar to what we get from GOES. Although it seems CIRA has implemented it well in its slider, I have not been successful in finding out how to do that. Would you please also give me some guidance regarding that if it is possible?

[strandgren]

@akasom89 This is an enhanced version of the natural color RGB using the VIS06, VIS08 and NIR16 channels. However, I don't know how the except recipe of the composite, so I'm afraid I can't help there. But we also have a similar RGB in the EUMETSAT data viewer EUMTVIEW and there have been some discussions on implementing that recipe in satpy, so hopefully that could be available soon :)

In the meantime, you can simply try the natural_color or the natural_enh composites instead of true_color in the SEVIRI geo_color recipe. The first one is the standard composite with turquoise coloured ice clouds whereas the latter was an attempt by @simonrp84 to get rid of the turquoise colour for the ice clouds (I believe).

[akasom89]

Thanks @strandgren

I greatly appreciate your helpful answers.

Exactly. I have never visited the EUMETSAT data viewer, EUMETView, before. You are right; it is very similar to CIRA's slider.

I believe that is more realistic than what we achieve now in satpy. As you mentioned its recipe has been implemented in satpy, Would you mind please helping me find more about the details of the recipe if it is possible? I am interested in this subject and may be able to implement it on my own.

Thanks again!

[strandgren]

The Natural Color Enhanced composite, as seen in the CIRA or EUMETVIEW viewer, is not available in satpy. Hence, I can't give you any further details. I know that some colleagues at EUMETSAT are working on the implementation of the EUMETVIEW one in satpy, but I'm not sure about the status and when it might be available on GitHub.

As mentioned there is the natural_enh composites, which attempts to achieve something similar by applying weights to the three channels. The code for it can be found here: https://github.com/pytroll/satpy/blob/main/satpy/composites/__init__.py#L1509 and you could try to modify the default weights (ch06_w, ch08_w and ch16_w) used in the recipe here: https://github.com/pytroll/satpy/blob/main/satpy/composites/__init__.py#L1509.

[akasom89]

Thanks @strandgren

I found some details about that recipe here. But I am not sure how much it is up-to-date.

Thanks again for your answers.