Normalize L2A reflectances across tiles (make seamless)

I now spend hours to search for an answer for this question. I keep telling myself that everyone of you has had this problem that I am now asking and that the lack of answers is due to me using the wrong search-terms. This could be the case still, and if so I apologise.

I’ve run the sen2cor successfully on a L1C scene and now the tiles in this scene is really obvious. Since I need to compare reflectance values across a larger area I need to somehow normalize the reflectance values to get them comparable. The tiling is obviously due to sen2cor processing each tile independently of the others but how do I proceed to get a usefull product where values in one scene is comparable to those in another? At a later stage I also need to mosaic together different scenes and also wish reflectance values to be “comparable” across scenes (knowing that this is not really true due to these being recorded at different dates, but still, can I normalize the values somehow?).

You might try MAJA L2A processor :wink: :

Thanks for your suggestion.

I tried to download it and open the manual. It appears to only run in Redhat Linux. Any chance it will work in Ubuntu? Also this piece of software seems to have a really steep learning curve and could be potentially very time consuming. Any other inputs to solve my little problem is very welcome!

Hi again,

All the documentation is either only in English or both English and French.
Depending on your site location, you might directly use products generated by Theia, or install MAJA and use it directly. MAJA is provided as executable code for linux red hat or CentOS. It is possible to broaden that using docker. If you need to use it commercially, you have to ask me for a licence (which is free).

Here are a few other links:

MAJA will not completely solve the tile boundary issue. It shows less artifacts than sen2cor at the tile boundaries, but still has some, especially when our assumption on the aerosol model is wrong. Next month, we should release MAJA V3.1, which improves a lot on that aspect.

Thanks a lot for these details. Your answer also sort of tells me that nobody has really solved this issue? Is that correctly interpreted? What do others do then? Just ignore these edge effects or what? My area of interest is unfortunately not covered by the Theia.
It’s not for commercial use its for a scientific project on plant leaf chemistry.

Also, can you give more insigth into how to get Maja running in Ubuntu using docker? I never tried docker before.

That’s an interesting question !

Atmospheric correction is not easy, aerosol estimates are noisy, which causes the differences between tiles. There are two ways of solving the issues on the boundaries :

  • work on methods to reduce the noise progressively.
  • find some kind of method to homogenise the data from several tiles

I do not favour the second one, because there is always a boundary somewhere. If it’s not at the tile boundary, it will be at the segment boundary. Or there will be loss of time consistency of the products. That’s why we are investing on the first solution. Progresses are made, the multi-temporal algorithms of MAJA are an answer, but the problem is not solved yet.

I am not a docker user either, I just know some users succeeded. With MAVA V3.1, next month, we will also provide an Ubuntu version.

Thanks a lot, I may wish to wait for version 3.1 then. Do you have a newsletter or similar so that I can get notified?

There is a RSS feed on CESBIO’s blog

With help from my Linux guru I managed to get it running in docker now, couldn’t wait…
A few questions:

The folders.txt file seems to be not used during the setup of Docker (, is that correct? It runs without changing the contents of this file at least. Don’t know if it runs correctly though. It seems like the command for running Maja after setting up docker (sudo docker run -v ~/maja/S2_NOMINAL:/data maja /opt/maja/core/1.0/bin/maja -i /data/input_maja1.0 -o /data/output_maja1.0 -m L2NOMINAL -ucs /data/userconf --TileId 36JTT
) does not run it using the and this may be why folders.txt doesn’t matter here? Anyways the usage of folders.txt is not clear to me. Is it supposed to contain info on the locations of the repcode, repwork etc inside the docker or on my actual machine? In the above command it seems like repL1 is given directly in the command (/data/input_maja1.0) together with repL2 (/data/output_maja1.0) etc…

I’ve found the conf folder, containing numerous xml files three of which has to do with Sentinel2. Which one to edit? And can i safely run Maja without editing these settings? Is there a possibility for running Maja using multiple cores like sen2cor? That I guess would speed the process a whole lot?

Is it correct that what matters the most to me is the FRE tiffs? I guess it won’t terrain correct if no DEM is present? What format of DEM will it take and were to put it? I guess I will have to add it to my docker container using ADD?

Good news that you managed with docker. Maybe should you ask the next question on our github repository, not to trust the top rank of Step forum…

As I said, I am not a computer guru, and I do not know docker.

Yes the example provided with docker did not involve The script simplifies a lot your task. It is when you are using that you need the folders.txt. I do not know which folders are visible from within docker, but it seems logical to use visible folderscified folders within folders.txt are visible

Regarding the DEM, the readme file in github explains how to obtain them. MAJA needs a DEM to process the data. FRE data corrects for the terrain effects. It is a “Flattened REflectance”.

Have a nice week-end

Hi, It is not just you. I am facing the same problem to normalise Multitemporal images. Let us know if you made it work.

If you convert all tiles to surface reflectance, it should be good quantitatively. For visual appeal, you could do histogram matching and feathering so that they will look seamless when you mosaic them. You have to pick same image dates or very very close image dates and ideally same imaging time.