As part of the RGB workshop 2025 it was proposed to conclude on the correction method to recommend for the normalization of the atmospheric path length for solar channels. Hence, I decided to dig into this and prepare some examples to give an overview. I put the results from my analysis in this issue such that we can discuss also within our community regarding the best approach.

In short we have two corrections available:

• sunz_corrected - standard 1/cos(sza) correction: https://github.com/pytroll/satpy/blob/main/satpy/modifiers/angles.py#L534
• effective_solar_pathlength_corrected - following Li and Shibata (2006): https://github.com/pytroll/satpy/blob/main/satpy/utils.py#L270

Without any modification the "raw" version of the correction formulas look like this:

Setting correction_limit to a high value (120 degrees) where we have no meaningful VIS/NIR data is just a current hack to disable the any reduction/modification of the correction and thus get the "Raw" version.

Looking at the Cloud Phase RGB, this results in the following imagery (no Rayleigh correction)

To tackle the fact that 1/cos(sza) is undefined at SZA=90 and not well defined for the purpose beyond 90 degrees, we have a functionality to reduce the correction starting at a given angle (correction_limit) until it reaches 0.0 at max_sza. This reduction is applied by default in satpy for both sunz_corrected and effective_solar_pathlength_corrected using correction_limit=88 and max_sza=95. However, this results in an unnatural sharp transition at correction_limit (88 degrees) as shown here:

and results in this imagery

Although the left image using sunz_corrected now look much better and retains information beyond 90 degrees, a bright line is introduced parallell to the terminator (commonly visible also in animations). This bright line is also introduced in effective_solar_pathlength_corrected, where also some information at very high angles is lost compared to the raw version of effective_solar_pathlength_corrected above.

The bright line is introduced by the sharp transition at 88 degrees sen above. This can be mitigated by instead applying a constant correction beyond a given SZA. This can be achieved by setting max_sza to None, in which case the correction at correction_limit will be used for all angles beyond correction_limit. Using this approach and some testing, correction_limit=86 turned out to work quite well in the sense of not having bright artefacts close to the terminator:

resulting in this imagery

.

The same imagery but for the True Color RGB (including default Rayleigh correction) looks like this:

So to me the effective_solar_pathlength_corrected correction clearly performs better than sunz_corrected and can also be used as is. This is not in-line with our current implementation where the reduction between 88-95 degrees is applied by default. sunz_corrected can still be used, but I think the best results are achieved by using a constant correction beyond correction_limit.

Based on this I proposed to add the following information in the best practices document that will be one of the outputs from the workshop, which no-one objected to:

Solar channels should be normalized by the atmospheric path length. The Li and Shibata (2006) parameterization is  recommended for this purpose:

correction_factor = 24.35 / (2*cos(SZA) + sqrt(498.5225*cos(sza)^2 +1))

If the alternative normalization using 1/cos(SZA) is used, a constant value should be used beyond ~86 degrees to avoid artefacts and sharp cutoff at 90 degrees.

Talking to other colleagues at the workshop (Meteo-France and CIRA), I also found out that they also use the Li and Shibata parameterization without any reduction/modification.

Hence, I propose the following changes in Satpy:

1. Remove the default reduction applied to effective_solar_pathlength_corrected. We can keep the functionality, but it should not be done by default.
2. Start transitioning from sunz_corrected to effective_solar_pathlength_corrected (without reduction) in the composite yaml recipes.
3. Possibly change the default max_sza for sunz_corrected from 95 to None and possibly reduce the correction_limit to 86 - not sure about this one though. Might need more testing

A while back I proposed refactoring the code for the atmospheric path length corrections (see #2955) so I suggest to tackle the first point together with that one. For the second point, I guess this can be done step-by-step by multiple developers working on the RGB recipes.

Thoughts?