Cleanup of enhancements for composites using `DayNightCompositor` is needed

[pnuu]

Feature Request

Is your feature request related to a problem? Please describe. There are a lot of unnecessary enhancements defined for composites using DayNightCompositor stretching the data from 0 to 1. The compositor it self ensures the data are already in this range by enhancing the sub-composites.

Describe the solution you'd like Remove all the named "from 0 to 1" enhancements created for composites using DayNightCompositor and switch the standard_names with the no-op image_ready.

Describe any changes to existing user workflow None, unless user has defined their own composites using the currently existing enhancements that would be removed.

Additional context

[gerritholl]

Describe any changes to existing user workflow None, unless user has defined their own composites using the currently existing enhancements that would be removed.

Just this week I changed our internal composites which used fci_day_night_blend to use image_ready instead. I think the scenario where someone copied an FCI composite from satpy/etc and then adapted it locally is not so rare, so I think this needs a deprecation warning like the refactoring of module imports has.

[strandgren]

I agree with @gerritholl . I'm quite sure this is the case for EUMETView for example, where we have a local copy of the recipe, but not all the enhancements. So a deprecation warning would be good.

[djhoese]

I've said this before and plan to make a related PR today, but I feel like the default enhancement should detect if it has RGB/A data and if it is already integer type, then do a no-op. That way standard_name can still be something useful/relevant to the actual image and could be used in an output format (ex. CF NetCDF file)...granted I don't know of any RGB CF standard names but still.

[strandgren]

And on that note, I would again be in favour of not using the standard_name to identify the enhancement, but father use something more explicit like enhancement, with a potential fallback on standard_name if enhancement isn't set. That would also allow us to have more useful standard_name

[djhoese]

@strandgren So this is the thing where enhancements could be defined in the composite definition, right? 👍

[strandgren]

@djhoese yes correct. Now that you mention it, I think the argument against using enhancement instead of standard_name was that it doesn't work for datasets created dynamically like toa_brightness_temperature. But allowing to fall back on standard_name if enhancement is not set, would overcome that issue I think?

At least for me the use of standard_name for the enhancement in the yaml-files was very confusing in the beginning. And like you say, it's not optimal for (display) tools that make use of the standard_name

[djhoese]

Yes, in hindsight I should have made the enhancement configuration structure more obvious what parameters were being used as "identifiers" and what was related to the enhancement operations. I think part of the confusion is that people think that standard_name is the only thing you can define an enhancement with. There is no reason that geo_color couldn't be specified with an enhancement with name: geo_color and match to exactly that composite by name (instead of standard_name).

[pnuu]

So if we had the enhancement functionality available we could do this?

  geo_color:
    compositor: !!python/name:satpy.composites.fill.DayNightCompositor
    lim_low: 78
    lim_high: 88
    standard_name: geo_color_day_night_blend
    name: geo_color
    enhancement: noop
    prerequisites:
      - true_color
      - geo_color_night

and the composite would be enhanced using the no-op enhancement

  noop:
    operations: []

Or something else?

All the composites using at least DayNightCompositor and BackGroundCompositor should be doing this. Their data are not integers, but contain pre-enhanced data in the range [0, 1] so are ready for writing to image formats.

StaticImageCompositor in turn contains the original data of the image but converted to float32.

[strandgren]

I created a separate issue for this: https://github.com/pytroll/satpy/issues/3230

[djhoese]

New idea in addition to all of these: an "enhanced" or similar named modifier entry in the DataID to indicate the data is already enhanced and no enhancement is needed anymore. Composite definitions could even request the enhanced version of a dataset to extract that step from the individual composite python code.