Add warning to default enhancement

[djhoese]

Reviewers, I don't remember who was interested in this topic so forgive me if I missed anyone or added someone who doesn't care.

This PR changes the behavior of the default enhancement in Satpy. That is, the enhancement used when no other enhancement is configured. This PR adds a warning informing the user that there was no other enhancement configured. I should probably add more info about what the user should do about that.

I am also adding a no-op before falling back to the linear stretch if the data is integer type already as that it likely more useful (I think) than a dynamic stretch for data that is likely already image ready.

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] Fully documented
• [ ] Add your name to AUTHORS.md if not there already

[djhoese]

This should be merged after a default BT enhancement is defined.

[djhoese]

I mean I could put them in one function but then I kept thinking someone might find them useful.

[pnuu]

Agreed.

CI doesn't seem to be happy about ninjogeotiff tags.

[djhoese]

No it's that some test data doesn't have "name" defined and the warning message uses it.

[djhoese]

@pnuu @gerritholl What if in Satpy <1.0 I keep the existing warning, but don't stop scaling non-float data. I can also add an additional warning telling people of the change upcoming in Satpy 1.0. That change would be no longer scaling non-float data.

[pnuu]

I'm fine with that.

[djhoese]

Ok I've started updating this PR again hoping to point @mraspaud at it. My last commit implements what I mentioned in my previous comment. That is, in Satpy <1.0 the behavior is the same but you get a warning about:

1. You should define your own explicit enhancement.
2. Satpy 1.0+ will no longer dynamically scale non-floating data as it is likely unexpected/unintended.

However, now I'm debating whether this change where non-floating point data is not going to be scaled. If we're warning people to make an explicit enhancement, then what's the point of careful/data-type-specific scaling anyway?

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 96.30%. Comparing base (92df937) to head (2b643fc). :warning: Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3237   +/-   ##
=======================================
  Coverage   96.30%   96.30%           
=======================================
  Files         463      463           
  Lines       58179    58194   +15     
=======================================
+ Hits        56027    56042   +15     
  Misses       2152     2152           

Flag	Coverage Δ
behaviourtests	3.65% <20.00%> (+0.01%)	:arrow_up:
unittests	96.39% <100.00%> (+<0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coveralls]

Pull Request Test Coverage Report for Build 18761561777

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.001%) to 96.384%

---

Files with Coverage Reduction	New Missed Lines	%
enhancements/contrast.py	1	98.84%
<!--	Total:	1

Totals
Change from base Build 18560792710:	0.001%
Covered Lines:	55923
Relevant Lines:	58021

---

💛 - Coveralls

[djhoese]

Talked about this in the meeting today. We decided to always warn about not using the default enhancement but we'll keep scaling the same as it is now.

[djhoese]

~TODO: Make sure warning references Satpy documentation on how to create a custom enhancement.~ Looks like this was already done.

[djhoese]

As discussed at the end of the meeting, it would be good if this warning message functionality could be moved outside of the individual enhancement operation functions and into the enhancement handling itself (if possible). This way @mraspaud could use it for his WMO RGB recipe work to deprecate certain enhancements.