search

remicres / sr4rs

Super resolution for remote sensing
MIT License
167 stars 19 forks source link

Bullet-proof tutorial, with easy-to-follow steps #19

Open remicres opened 3 years ago

remicres commented 3 years ago

It could be great to have this somewhere.

Basically it could consist in the following steps:

If a kind soul is able to make a PR :pray:

quizz0n commented 3 years ago

I can help with the tutorial once I go through the entire process. Can you tell me why is this step necessary?

  • a combination of OTB orthorectification (or gdalwarp), to prepare:

    • one LR image with physical spacing spc
    • one HR image with physical spacing spc / 4

And here:

  • patches centers seeding (e.g. using QGis > Vector > Search > Create grid then QGis > Vector > Geometry > Centroïds)

what value did you use for grid spacing? Also from the blog post, the grid looks to have an alternating pattern. It's just a selection over it to illustrate or it's the way it was generated?

image

remicres commented 3 years ago

Hi,

Can you tell me why is this step necessary?

That is because your images (HR and LR) must me in the same geometry, aligned (some pixels top left corners matching), and LR must have 4x the pixel spacing of HR.

what value did you use for grid spacing?

I did use some 256x256 pixels for HR (hence 64x64 pixels for LR). For Sentinel-2 as LR, that make a grid with 640m sized cells.

Also from the blog post, the grid looks to have an alternating pattern. It's just a selection over it to illustrate or it's the way it was generated?

I did that to split my dataset in two: one for training, and the other to control how PSNR and some other stuff evolved during the training. But of course you can use all patches of the area :)

quizz0n commented 3 years ago

Started on this just now, so thanks for details @remicres. Fallowing the instructions, I aligned the images, but somehow the patches generated with PatchesExtraction application for HR and LR, don't have the same origin (Upper Left Corner). I used the OTB OrthoRectification application to resample and align the SPOT image to the Sentinel-2 image.

$ gdalinfo S2_10m.tif 
Driver: GTiff/GeoTIFF
Files: S2_10m.tif
Size is 1377, 1076
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 34N"
...
Origin = (693790.000000000000000,5111010.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
$ gdalinfo SPOT6_2.5m.tif 
Driver: GTiff/GeoTIFF
Files: SPOT6_2.5m.tif
Size is 9173, 7170
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 34N"
...
Origin = (693790.000000000000000,5111010.000000000000000)
Pixel Size = (2.500000000000000,-2.500000000000000)

Still the patches don't share the same origin.

$ gdalinfo lr_patches.tif 
Driver: GTiff/GeoTIFF
Files: lr_patches.tif
Size is 32, 40672
Origin = (-5.000000000000000,5.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
$ gdalinfo hr_patches.tif 
Driver: GTiff/GeoTIFF
Files: hr_patches.tif
Size is 128, 162688
Origin = (-1.250000000000000,1.250000000000000)
Pixel Size = (2.500000000000000,-2.500000000000000)

I thought to align the patches but the files generated don't seem to contain geometric metadata. Do you have any suggestions?

remicres commented 3 years ago

Hi @quizz0n ,

The extracted "patches images" have no spatial metadata, it's fine (They are just basically patches stacked in rows).

The important thing is to have the original images aligned, which is the case in your example because gdal uses pixel corner as origin.

We have to be careful that unlike GDAL, OTB uses the pixel center as origin:

image

quizz0n commented 3 years ago

That is a very interesting aspect. Thanks for pointing that out. So because the patches images have their origin in pixel center origin of the original images, it is not possible to visualize the "overlap" even they are actually "overlapping". Is this correct?

remicres commented 3 years ago

The patches images origin is such as the first pixel center coordinates is (0, 0). I don't recall where this convention comes... I agree that it is not very convenient: because we cannot visualize properly overlapping patches images of patches having the same physical extent but not the same pixel spacing (which is the case in super-resolution, but also in many multi-scale approaches). Indeed patches images do not share the top-left corner when you open them in QGIS, even if the actual patches do overlap in real life

Maybe it could be useful to change that in future releases...