A large difference in reflectance values ​​on the same pixel - Prisma after co-registration or georeferencing in QGIS??

[tazrart]

Dear users Enmap-box,

I wanted to study the spectral signature of a lake. Indeed, I correctly imported the Prisma L2D product under enmap-box v 3.10 (he5 to tif format conversion). The values ​​vary between 0 and 1 (it's perfect!).

However, even with this new version (3.10), prisma images are still shift with reality (compared to google earth image). That's a shame ! there is no improvement at this level!

Gooogle earth image :

‌

Prisma image :

‌

‌

So I applied the correction via the QGIS Co-registration module (plugin) and I also tested the QGIS core "Georeferencing" module. In both cases it gives a good result (good correction) :

‌

Prisma image after correction :

‌

‌

‌

‌

‌

‌

However, the values ​​of the pixels before and after correction are not identical: see the stats of band 1 of each image:

Stats Prisma image :

‌

‌

Stats Prisma image after correction :

‌

Note : We already notice the values ​​of the initial image in the property tab of the image (see Stats Prisma image ), they are multiplied again by the factor 10^4 even if the values ​​of a pixel are between 0 and 1 and after correction the values ​​are multiplied directly by 10^4 for each pixel (see values below). . I don't understand why!!!.

The problem is not the question of multiplied by a factor of 10^4, the big problem that the values ​​of the same pixels have been changed too much. Se below, I folllow the same pixel (blue outline pixel) and the reflectance vary from 1155 to 7509 after the correction.

‌

Values on one pixel after correction :

‌

‌

‌

‌

Values on same pixel before correction ;

‌

‌

‌

‌

‌

‌

I have tested all resampling methods of correcgistration module (cubic, bilinear, nearest neighbour,…) and the results are almost the same and the values ​​are too far from the initial image.

‌

‌

In my opinion, I cannot work with the reflectances of the corrected image. They are too far from reality.

Have you noticed this difference?
Frankly, what is the method you use to correct the shift of the intial images? Do you work directly on the initial images even if their location have a shift to the reality?

Thank you,

[Andreas Rabe]

We already notice the values ​​of the initial image in the property tab of the image (see Stats Prisma image ), they are multiplied again by the factor 10^4 even if the values ​​of a pixel are between 0 and 1 and after correction the values ​​are multiplied directly by 10^4 for each pixel (see values below). . I don't understand why!!!.

The imported PRISMA raster is stored in it’s original integer values with proper data scaling defined. You can check this in the console:

‌

Note that QGIS is using the scaling factors properly, when reading data.

I would guess that the arosics software (by @Daniel Scheffler , and therefore also the Coregistration plugin) is reading the data with GDAL API without applying data scaling.

[Andreas Rabe]

Regarding all the other questions, I can’t really help you.

[Daniel Scheffler]

That´s right, AROSICS reads the original pixel values as stored in the file and does not apply any scale factors from the metadata. I don´t know from which metadata key the EnMAP-Box reads the scale factor but it might be that AROSICS does not propagate the image metadata completely to the output. In that case, you have to set the scale factor again manually.

I don´t have an explanation for the differing pixel values but without any sample data, I have no chance to reproduce it.

However, even with this new version (3.10), prisma images are still shift with reality (compared to google earth image). That's a shame ! there is no improvement at this level!

First, neither PRISMA, nor Google Earth is reality. Both can have errors in their registration accuracy. My guess is that PRISMA just uses another geospatial reference. However, this has nothing to do with the version of the EnMAP box but is related to the preprocessing on the provider side.

[Andreas Rabe]

I don´t know from which metadata key the EnMAP-Box reads the scale factor

Data offset and scale information is part of the GDAL data model. Offset and scale aren’t metadata items, but can be accessed via gdal.Band.GetScale and gdal.Band.GetOffset methods via the GDAL API:

‌

‌

[Daniel Scheffler]

I created an issue about the scale factor here and will look into this as soon as I have some time.

[tazrart]

@Daniel Scheffler Thank you for your answer. Is the test you did for your Co-registration plugin, the pixel values of the output raster are identical (or close) to the input raster. Thank you!