Sen2Corr messes up georeference

Hi everyone.

I installed Sen2Corr on Ubuntu 14.04, and processed one S2 granule. Everything seemed to work fine, but when I opened the generated images I realised that all georeference was lost, even the pixel size is changed to 1. Has anyone had simmilar problems?

Thank you,

1 Like

Yes, everbdody has the problem.

Use (comes with the GDAL installation) to copy the projection from the unprocessed to processed data. Or wait for an update of sen2cor.

Nice solution, thank you!

So this is meant to be fixed in 2.2? Is this confirmed?

I can confirm that it is NOT fixed… Geographic projection missing in output

I don’t understand how such a crucial problem like this was overlooked.

I have exactly similar problem as “Ognjen” has mentioned above, and there is a solution suggested by “Unnic” using . My problem is I have no idea on how and where to use this command. I don’t have a programming knowledge on Python. I wanted to use the sen2cor atmospherically corrected images but I couldn’t because of the missing georeference. Can anyone give me more information on how to proceed with this please.

You probably figured it out by now, but anyway…maybe someone will need it :slight_smile:

You download the script from (or copy the source code into a file you made - you can name it or some other name).

You open the command line and type :
“python /path/to/your/ path_to_inputfile.tiff path_to_outputfile.tiff”
Input file should be the downloaded L1C image with projection intact, and output is your file which doesn’t have projection. Keep in mind that you should be careful to copy projection from exactly same tile and date.


1 Like

Hello all,

I have had the exact same issue with missing projections after a sen2cor 20m transformation and I was hoping to get some expert opinion on my current work around.

Due to the known issues with sen2cor and anaconda’s version of GDAL not supporting .jp2/JPEG2000 files I have converted the sen2cor files (.jp2) to Geotiff format using SNAP and similar for a reference
file from the L1C product. I have then used gdalcopyproj to georeference the geo-tif files for use.

The issue is that the BoA DN range displayed when a load this into a GIS are different between the .jp2 product (non-referenced) are between 0 & ~20,000 and the .tif (geo-referenced file) are ~200 to ~10,000. I understand that the method that the two product types use to store the numbers is different, but should I be concerned with this difference when using these ‘corrected’ L2a products to create EVI, NDVI, etc with this work around?

Thank you for any help!


regarding the BoA DN range: Which band?
Unfortunatly I can’t calculate any band statistics of the .jp2 image because the corresponding driver got botched by sen2cor. For .tif NIR (B8) for a scene in middle europe, the data ranges from 0 to 16000. checking individual targets the B08 values are the same in .jp2 and .tif.

I opened a question on stackoverflow regarding the jp2 driver issue

Thanks for the stackoverflow link, I hope
someone can find a method to over come this jp2 driver issue, very frustrating.

R.e. DN range, for example.
The corrected (BoA) B8 band in the jp2 format ranges from 0 to 10075,
but it ranges from 0 to 9033 in the .tif format. At the moment I am not too
concerned as the NDVI values are looking comparable compared to other products
I.e. LandSat and I believe the work around (I.e. converting raster formats) is
valid, but I couldn’t find any other methods to use the sen2cor
output, so thought I would see if there was an explanation for the different

That is strange, the range should not be dependent of the format.

Are you sure you used the right data type when converting to tiff (parametar -ot UInt16 for example)?

As for .jp2 files, unnic is right - you have to convert to tiff and then copy the georeference. Because the jp2 driver that gdal is using (if there is any, I’m not sure there is a JP2000 driver by default ) does not support writing georeference to files, so JP2OpenJPEG driver is needed >
(see this paragraph: Starting with GDAL 2.0, the driver supports creating files with transparency,
arbitrary band count, and adding/reading metadata. Update of georeferencing or
metadata of existing file is also supported. Optional intellectual property
metdata can be read/written in the xml:IPR box. )

So you can manually compile gdal with this driver , or add it after. Instructions:

I have tried both, but I gave up quickly…


JP2OpenJPEG is the jp2 driver that comes with gdal by default. The thing is, it get’s removed by installing sen2cor 2.2.1 (2.0.6 didn’t have that problem) and is not acessible for python after reinstallation (see stackoverflow post)

It’s not the default driver, the site you are using in your installation (Gis Internals), contains already compiled packages to make it easier for people to use gdal so they included it in their build (see this table - column Compiled by default).

Anyway, I’m not working on Windows so I’m not sure if your problem can be fixed easier than here, but I think it shouldn’t be too hard to make python use your other gdal installation (with the JP2OPenJPEG driver). Because Anaconda installs it’s own gdal and everything (at least that’s the case in Ubuntu). Try searching for all gdalinfo files on your system and see which one has the neccesary drivers, than use python that contains that gdal bindings for running or other scripts you need.


thanks for the clarification.

can you elaborate on this? I have gdalinfo.exe files but I’m not sure how to verify which one has the neccesary drivers or how to acess the relevant python.

Open the command line terminal and try running each one of them by typing >/path/to/gdalinfo.exe --formats

See which one gives the correct output. Then when you know, that gdalinfo file with the correct drivers should be connected to some python (Maybe C:/Python27/some/directories/gdalinfo? is the file).
I think you should try executing (or some other python script which uses import gdal with this python ( type in the command line > C:/Python27/…/python arguments)

It confirms that the Anaconda gdal is missing the jp2 driver whereas the other (QGIS, GRASS, own installation) include it. BTW: in the cmd directly calling gdalinfo --formats (without any direct path) lists the .jp2 driver

unfortunatly acessing the desired python directly did not work in reading .jp2 files.

import gdal

>ERROR 4: `Z:/unproj.jp2' not recognized as a supported file format.

or (QGIS 2.16\bin\python.exe)

import gdal
ERROR 1: Can't load requested DLL: C:\Program Files\QGIS 2.16\bin\gdalplugins\gdal_ECW_JP2ECW.dll
ERROR 1: Can't load requested DLL: C:\Program Files\QGIS 2.16\bin\gdalplugins\gdal_MrSID.dll

I do not get any errors using gdal on another computer running sen2cor 2.0.6. or before installing 2.2.1. I tried removing os.system('conda install --yes gdal') from sen2cor (line 214) to avoid the problem but wasn’t successfull.


Hi Unic,

Yes this is true, the Anaconda drivers do not support the jp2. This (among others) was one of the reasons why we switched to glymur in the past. The second one had been incompatibilities between the openJPEG library used by the Toolbox and the gdal generated images on sen2Cor, which used the (very old) GDAL Jasper JPEG 2000 drivers in the past. So the compatibility to the Toolbox was the cardinal driver for switching to the Glymur / openJPEG combination. Now the good news: we are in the final state of releasing a bugfix for Sen2Cor which will support the geodata info inside of the JP2 image headers in the same way as gdal does, using a new version of glymur. This fix will be available very soon.


I’m trying sen2cor 2.2.3. In this version the L2A output does not lose georeferencing

it’s fixed now.