Composites combining HRFI and FDHSI channels together

[guidocioni]

Hey guys.
Today we were trying to create some composites using channels both from HRFI and FDHSI. In this case we were focusing on the ash composite.

The first question I have: where is the definition of the ash composite located? I tried to look into
/etc/composites/fci.yaml and /etc/composites/seviri.yaml but couldn't find it. There doesn't seem to be a generic or common composite YAML file, so I'm not sure where they're pulled from (because they are indeed available for both fci and seviri readers). I was interested specifically in knowing which channels are used when composing on FCI, as the channels do not have exactly the same wavelength.

The second question/observation is there may be some error when using channels from the High resolution and Normal resolution together. In this image I'm comparing the ash composite created with channels only from FDHSI (left) and with channels coming from both HRFI and FDHSI. To generate this second image I just provided all files in the scene inputs.

Are these artefacts we're seeing coming from the fact that the data is not yet operational? Or is there some correction to be done when combining data coming from HRFI and FDHSI?
I'm not sure which channels are actually used to produce the right image, but there's definitely something from HRFI used.

[pnuu]

The definition of ash is here: https://github.com/pytroll/satpy/blob/main/satpy/etc/composites/visir.yaml#L125

I'll post you my "resolution-aware" configs after lunch. There I have set the channel differences to use channels that have equal resolution.

[gerritholl]

where is the definition of the ash composite located?

composites/visir.yaml

Are these artefacts we're seeing coming from the fact that the data is not yet operational?

Yes, there are coregistration issues between 10.5 HRFI and other IR channels, so composites that take the difference are affected. Might look better if you use FDHSI only

[guidocioni]

where is the definition of the ash composite located?

composites/visir.yaml

Are these artefacts we're seeing coming from the fact that the data is not yet operational?

Yes, there are coregistration issues between 10.5 HRFI and other IR channels, so composites that take the difference are affected. Might look better if you use FDHSI only

Ok, I was wondering if this was already known.
Well then I guess the only option is to use Normal Resolution data only.

[Reyrem]

Even with the same resolutions, there are sometimes some weird artifacts (here above Bretagne for example) where it seems that the clouds don't exactly overlap in the different channels. Any idea on how to deal with that?

[pnuu]

Even with the same resolutions, there are sometimes some weird artifacts (here above Bretagne for example) where it seems that the clouds don't exactly overlap in the different channels. Any idea on how to deal with that?

That's the co-registration issue Gerrit mentioned.

Here's my ash composite definition, which I've placed in $SATPY_CONFIG_PATH/composites/fci.yaml:

sensor_name: visir/fci

composites:

  ash:
    compositor: !!python/name:satpy.composites.GenericCompositor
    prerequisites:
    - compositor: !!python/name:satpy.composites.DifferenceCompositor
      prerequisites:
      - name: ir_123
        resolution: 2000
      - name: ir_105
        resolution: 2000
    - compositor: !!python/name:satpy.composites.DifferenceCompositor
      prerequisites:
      - name: ir_105
        resolution: 2000
      - name: ir_87
        resolution: 2000
    - name: ir_105
      resolution: 1000
    standard_name: ash

I've done similar changes to other composites that use DifferenceCompositor.

[guidocioni]

Even with the same resolutions, there are sometimes some weird artifacts (here above Bretagne for example) where it seems that the clouds don't exactly overlap in the different channels. Any idea on how to deal with that?

That's the co-registration issue Gerrit mentioned.

Here's my ash composite definition, which I've placed in $SATPY_CONFIG_PATH/composites/fci.yaml:

sensor_name: visir/fci

composites:

  ash:
    compositor: !!python/name:satpy.composites.GenericCompositor
    prerequisites:
    - compositor: !!python/name:satpy.composites.DifferenceCompositor
      prerequisites:
      - name: ir_123
        resolution: 2000
      - name: ir_105
        resolution: 2000
    - compositor: !!python/name:satpy.composites.DifferenceCompositor
      prerequisites:
      - name: ir_105
        resolution: 2000
      - name: ir_87
        resolution: 2000
    - name: ir_105
      resolution: 1000
    standard_name: ash

I've done similar changes to other composites that use DifferenceCompositor.

As far as I can see this produces exactly the same image as just using the normal resolution channels without any custom composite.
It kind of makes sense, as the resolution for the first 2 bands is forced to be 2km, which is the same as the normal resolution channel.
However I would expect to see some differences as the last band is taken at the original 1 km resolution. Probably that's not enough to see a difference in the image....
If the result is the same I would argue it doesn't make sense to get into the trouble of custom defining a composite as just producing the composite with just normal resolution data would give the same product.

[ameraner]

There are two effects overlapping here causing the artefacts:

1. there is indeed an issue in the data that affects the coregistration (overlap) of different IR channels, in this specific case the ir_105-ir_85 pair most predominantly. This is causing most of the colorful "shadow effects" in the images, both when using FDHSI only as well as FDHSI+HRFI. A fix/clear improvement is on the way in upcoming processing facility updates.
2. there is a further intrinsic problem related to using channels of different resolutions in the same composite, which is particularly evident when doing channel differences (as in the dust/ash RGBs for example). The fact that the HRFI channels contain finer spatial structures that are missing in the FDHSI channels will inevitably lead to artefacts in the images, particularly when doing channel differences, particularly around edgy features. I created a simplified example below trying to explain this in a schematic way - hope it's somewhat clear :D
   

[guidocioni]

Probably dumb question...would using a different resampling algorithm that adopts more smoothing (linear, bicubic...) alleviate this issue but still keep some spatial features of the high resolution channel?

[ameraner]

Ah yes, I forgot to mention that - indeed, a different resampling would likely improve the results a bit, but iirc we tried in the past and it wasn't so much better in the end, still worth investigating though. I guess a very smart resampling algorithm, maybe a machine learning model that uses the HRFI spatial features to enhance the upsampled FDHSI channels, would deliver better results...

[guidocioni]

Ah yes, I forgot to mention that - indeed, a different resampling would likely improve the results a bit, but iirc we tried in the past and it wasn't so much better in the end, still worth investigating though. I guess a very smart resampling algorithm, maybe a machine learning model that uses the HRFI spatial features to enhance the upsampled FDHSI channels, would deliver better results...

You heard @Reyrem , now you're next :P

[pnuu]

However I would expect to see some differences as the last band is taken at the original 1 km resolution. Probably that's not enough to see a difference in the image....

Yeah, I was also kinda suprised not to see any change between "all 2 km" and "non-difference data at high-res" versions.

If the result is the same I would argue it doesn't make sense to get into the trouble of custom defining a composite as just producing the composite with just normal resolution data would give the same product.

If you want to create any high-res images and include the HRFI files, you do need to have the resolutions defined for at least the channel differences. It might need some more investigation and trials to see whether the single HRFI channel has an effect or not. The effect isn't big, based on what we've seen so far.

Probably dumb question...would using a different resampling algorithm that adopts more smoothing (linear, bicubic...) alleviate this issue but still keep some spatial features of the high resolution channel?

I'm processing the data using bilinear resampling (gradient search) and the results are not any better compared to nearest resampling.

[simonrp84]

Ah yes, I forgot to mention that - indeed, a different resampling would likely improve the results a bit, but iirc we tried in the past and it wasn't so much better in the end, still worth investigating though. I guess a very smart resampling algorithm, maybe a machine learning model that uses the HRFI spatial features to enhance the upsampled FDHSI channels, would deliver better results...

This is pretty much what pan sharpening does, isn't it? Technique has been around for a long time and would probably work even better in this case as the spectral band is identical.

[BENR0]

That (pan sharpening) is something I have also been thinking about from time to time and would be a nice addition I think.