We’ve been using the C2RCC-MSI processor for Sentinel-2 imagery for a few years now. It seems that since the upgrade to processing baseline 04.00 this produces empty results, and nothing in our processing has changed. I suspect it may be related to needing Sen2Cor2.10 - however the C2RCC-MSI processor invokes Sen2Cor itself for L1C imagery. We’ve updated all plugins - and have obtained the Sen2Core2.10 standalone installers - however they do not “slipstream” into SNAP, and I see no way to instruct the C2RCC-MSI processor to use it (if indeed that resolves the issue).
sen2cor is not needed for C2RCC. It does not invoke it.
But if S2TBX, S3TBX and SNAP are all correctly updated it should work.
We use it in operational production, and we get results.
Can you invoke the following command from the bin folder of the SNAP installation?
On Windows: snap64 --list --modules
On Linux: snap --list --modules
This will print the list of installed modules. Can you share the result?
I’ve attached a file contining the output for the modules. I did an update of all plugins on the weekend, so they should be current.
Here’s an example of the output we are (not) getting. C2RCC-MSI is run against the product on the left – which has been resampled to 20m, subsetted to the rough size, and then masked to a specific polygon. This particular image/date is cloud free.
The installed modules look up-to-date. So, this is not the issue.
Have you checked the other bands? Are they empty too?
Can you tell the exact name of the source product? Then I can try to reproduce it.
As a matter of fact, the ONLY band that produces any output (still empty) with the C2RCC-MSI process is the conc_chl - which is the one we’re interested in, however I’ve just found an image from 2022-01-24 for the same location that does produce output, and has all of the other bands in addition to conc_chl
The best answer we’ve been able to come up with is that there is something different with the data from Sentinel-2 after that date. The issue is consistent across all dates and locations that we process post January 19. We’ve actually abandoned C2RCC in general as it fails to provide us consistent results for our purposes, and have built our own models now - which also do not provide proper results after January 19 - which is why we believe the problem is with the Sentinel-2 data.
I can’t comment on the impact on the C2RCC processor, I’m afraid. The intricacies of the processor are unknown to me. All I can say is that the significant changes for L1C in PB04.00 involved changes to the handling of Quality Masks (they are JP2 now, not GML) and the introduction of the Radiometric Offset.