Some OLCI results show strange invalid patterns

Post Reply
Posts: 3
Joined: Thu Oct 10, 2019 3:04 pm
company / institution: Brockmann Consult GmbH
Location: Hamburg, Germany

Some OLCI results show strange invalid patterns

Post by martin.boettcher.bc » Sat Nov 30, 2019 8:48 pm

Dear Francois,

some OLCI products (e.g. S3A_OL_1_EFR____20180509T083238_20180509T083538_20180510T131627_0179_031_064_1980_MAR_O_NT_002.SEN3) processed with v4.12 show something like in the right image, in comparison to e.g. the same product processed with v4.0 (left).
Both are processed with NCEP auxiliary data. Do you know why this happens? What can I do to avoid it?

Best regards,

Dr. Martin Boettcher
Brockmann Consult GmbH
phone: +49(0)40 696389-315
skype-id: martin.boettcher.bc
Brockmann Consult GmbH
Chrysanderstr. 1
D-21029 Hamburg, Germany
Amtsgericht Hamburg HRB 157689
Geschäftsführer Dr. Carsten Brockmann
Twitter: @BrockmannCon
You do not have the required permissions to view the files attached to this post.
User avatar
Site Admin
Posts: 51
Joined: Fri Sep 07, 2018 1:34 pm
company / institution: Hygeos
Location: Lille, France

Re: Some OLCI results show strange invalid patterns

Post by fsteinmetz » Tue Dec 03, 2019 1:12 pm

Hi Martin,

Thanks for your feedback.
This kind of patterns is typically due to un unstability of the algorithm. Polymer uses the result of previous pixel to initialize the minimization of current pixel, which can lead to successive (vertically) bad pixels within a processing block (which is a horizontal stripe of 100 pixels for OLCI) in case of unstability of the minimization scheme.
Between v4.0 and v4.12, most changes that could be related to this kind of patterns are the changes in vicarious calibration coefficients, and the fact that band 412 is not used for atmospheric correction since v4.11. I would expect this last change to avoid unstable situations, but apparently the opposite is happening here.
I will have a look at this case because some updates of Polymer are underway (not in the short term). In the meantime, you should be able to reproduce the behaviour of v4.0 by providing the following options to run_atm_corr: calib=None, bands_corr = [412,443,490,510,560,620,665, 754,779,865], bands_oc=[412,443,490,510,560,620,665, 754,779,865].

Post Reply