Pure latency measure

[FrancescoSorrentino]

I'm trying to benchmark multiple cloud detection algorithms, the library uses multiple temp files, so read and write a lot from the disk and the latency for 10m resolution grows up to 20 minutes (and i dubt that it is indeed the real latency since Sen2Cor only for CCSD take around 2 minutes for one .SAFE).

I'm wondering if you have some docs with the latency of the whole algorithm ignoring the processing of writing and reading from the temp files, or it could be added directly in the code, keeping track of the team of each step. It would be awesome.

[gillins]

@FrancescoSorrentino no, sorry we don't have any information on this. We follow the fmask algorithm quite closely with it's various steps all requiring different temporary files. I'm not sure how Sen2Cor works in this regard. Timing would be difficult as it is hard to work out what percentage of each step is calculation vs file I/O. One thing I could suggest (if you have enough memory) is to use GDAL in-memory files. You would need to replace each call to tempfile.mkstemp with a path beginning with /vsimem to save the temporary file to memory. You might also want to use the MEM GDAL format also to speed things up (since they don't need to be the slower HFA format).

[neilflood]

As @gillins says, we don't have that information. However, I can tell you that the main reason why the 10m resolution run takes so much longer is in the section which tries to match clouds to their shadows. This is fairly inefficient, and the time increases very strongly with the number of pixels involved.

It is also worth saying that most cloud/shadow detection methods are not really accurate enough to justify running at 10m resolution anyway. Certainly Fmask is not. If you are trying to get detailed delineation of the edges of the cloud, the spectral problems at cloud edges greatly reduce the accuracy, meaning that the extra resolution is wasted. This is why many methods, including Fmask, will use image dilations or similar to expand the cloud a little, and again, the extra resolution is wasted when this happens.

So, given that 10m does not help, and takes a great deal longer, there is really no point in running Fmask at 10m, and I do not recommend it. Even 20m is a little optimistic, although more commonly used.

[FrancescoSorrentino]

Thank you for all the suggestions and clarifications, i was using the 10m resolution to compare it with DL models that indeed use 10m resolution patches, but i know that most of classical algorithm process masks at 60m or 20m and then upscale the resolution to 10m if needed. I will see if i am able to implement @gillins tweak of code, but, as @neilflood said, the part of cloud shadows is what really slow down the algorithm and at this point i guess is not useful to compare it with other algorithms (for the 10m part). Thank you for the help again! If i manage to do something i will open an issue that can maybe helps other in this matter.