My point of view here is to prefer the simpler code instead of better performance. LIS is fast enough in any case. If memory and performances are enhanced in the next OTB versions, I would say it's better to keep the code as it is.
Thanks @raillece, few modifications!
Céline Raillé (83db2fa4) at 28 Mar 15:54
Make let-it-snow compatible with OTB 8.x versions.
Not a hard requirement for a deployment on Trex new CNES cluster, but nonetheless it's important to follow OTB developements.
Closes #120
Guillaume Eynard-Bontemps (51ee3e43) at 28 Mar 15:54
Merge branch '120-otb8' into 'develop'
... and 1 more commit
Closes #120
Closes #120
Céline Raillé (83db2fa4) at 25 Mar 14:45
Update hillshade.py
Memory usage : no improvement with OTB 8, but better performances with OTB 9 (7G for max memory instead of 17G).
Execution time : no major differences between OTB 7, OTB 8 and OTB 9 (always between 25 and 30min). But I realized I only used 1 CPU. I did some tests with 4 CPU and we have better results : 14min for OTB 7 and OTB 8, 8min for OTB 9 (it takes only 5 min if we simplify the equation for the bandmathx).
So finally, keeping the BandMathX seems interesting if we can use many CPU.
Moreover, I will verify that we correctly use the BandMathX function.
Just to be fare, even if the shaded snow mask generated by rastertools generaly miss a pixel line on the ridges, most of the time (in all of other images I analyzed), it doesn't show up on the Snow cover result, probably because this snow is already classified as snow without the shado pass.
So based on my really small experience on analyzing and comparing results on just 10 images or so, this case is rare.
But anyway, the algorithm should be improved.
Todo :
Discussion today: try to look at rastertools algorithm to see if these effect can somehow be improved: it seems we're missing often just one pixel of shadow.
If not, maybe combine rastertools for casted shadow (for which it is really good), and a classical hillshading algorithm with a proper threshold.
From our discussion today:
So the goal here is to try to ensure the case where a radius > 512 or 1024 is an exception, and be able to give an option to rastertools to use a maximum radius, even if we lose a few shadow information.
Céline Raillé (9705452e) at 20 Mar 08:10
Merge branch 'develop' into 120-otb8
... and 13 more commits
While comparing results of LIS blue in #21, I observed some shadow detection problem with the new rastetools algorithm used in 1.11.0 version.
The overall observation is that:
The following images illustrate these results and problems near Goulier area in France on the S2 image taken on 19 Nov 2019.
The hillshade mask is green is issued from saga-gis, wherease the one in blue on the top is from rastertools:
On the left, rastertools mask is missing shadow near the mountain ridges. On the top, we can see that saga-gis mask detects also slopes with lower illumination. On the right, rastertools mask is better on casted shadow.
It is hard to argue on some areas which one of the mask is the best, a choice between over estimation and conservative one. But the problem of the ridges of rastertools mask is clearly visible on the final result (LIS 1.11 in blue, LIS 1.10 in green):
Céline Raillé (3f58b753) at 15 Mar 10:00
Update CMakeLists.txt
Céline Raillé (3f70012f) at 15 Mar 09:59
Update snow_synthesis_test.py
Céline Raillé (152daf1c) at 15 Mar 09:46
Update snow_synthesis_test.py