Do you still have the same problem? Was it fixed since then?
Is it also the case with version 4.0?
Please let us know, I inform Julien, Nicolas and Omar about this behaviour, but they surely are already.
Thanks a lot for these elements of observation.
There are still problems with the mosaic tool (and re-projection too).
When trying to select a pre-defined CRS (ESPG:2193), you can find it OK but it is not put into the white space.
Now that the products are in several files, they need to be combined…
I’m trying to mosaic resampled products in .dim files and data folders. I’m curious about the pixel size - how come the default is not the pixel size of the resampled product? The fill in box in the GUI is in degrees and the smallest it accepts if 0.001. My mosaic is very coarse at best and at default value I get huge pixels. Question is: how to get 10m pixels when mosaicing BEAM-DIMAP products that are resampled to 10m?
In the Mosaic is WGS_84 as default projection selected. Its CRS is defined in degree. That’s why the pixel size is given in degree by default.
What’s wrong here is that you can’t define a small pixel size correctly. Below 0.001 it only shows 0.0. But it uses the values you have entered. So it is only a display issue. However this is wrong.
If you change in the upper part the projection, e.g. to UTM, you can enter the pixel size in meter.
It went well untill I clicked run and got an error message about my cloud and cloud shadow condition, when I tried to remove the condition the whole mosaic app froze and I could not select anything. I restarted SNAP and started new mosaic, but the tabs Map Project Definition and Variables & Conditions remained frozen. Maybe I need to restart unity? Or reboot?
Fix: It seems I did not select the source, it was not enough to + it, I needed to select it also… now it seems to work
OK, good that it works now.
Well. It wrote a 104 GB mosaic from two granules in 1h 43 min. The mosaic looks universally grey in SNAP. It seems that something went wrong.
maybe there was a mismatch between the coordinate system of the dataset and the boundary coordinates.
I often see extemely huge files being created when UTM coordinates are applied as boundaries for WGS84 projected files.
Just an idea…
I didn’t give boundary coordinates, maybe that was the problem. I managed to run the mosaic for a small area in the border of the granules just fine. I have subsetted the same area from older products and then the .data folder size was ~266 MB, with this mosaicked product it is ~683 MB. I don’t understand why there is double bands in the band listing … what is in the _count bands?
I have recently explained what’s in the count bands:
I have the same problem to create a mosaic. I get the error of
Product 'sourceProduct2' contains bands of different sizes. Currently it is not possible to use it for mosaicking.
I tried doing the mosaicing operation with the SNAP tutorial, but I cannot achieve to do it.
But when I do the mosaicing operation with one band (for example band 2 from each image) I have not any error and I will get the mosaic.
If I don’t get the multiple reader dialog when opening SENTINEL-2 data . How do I enable it?
Need it as preparation for mosaicing, getting the same resolution for all bands as indicated above.
Running W7 and W8.
The 10/20/60 m resolution readers are no longer available, but you will get the same result if you use the resampling operator after opening the multi-resolution product.
I have problem with mosaicing the sentinel 2 images. I tried resampling and subseting but it is not fixed. Do you find a way to fix mosaicing problem anybody?
I have a problem with mosaic 2 sentinel images . I subset them then make a mosaic. However, it said can not display source product, …" as below. what is a matter?
This is a known issue and it is actually already solved. The fix will be released soon.
Meanwhile you can try to set the mosaic boundary manually. This should help
Please take a look at this video it is already released now
Hi, I followed the video to investigate the blending operation at native resolution for 1 band (8a) at native 20m resolution (tab 2 window below and final results) as the final result screenshot shows, the processing seems to have picked up some aspect of the cloud (mask?) with the rest of the pixel values set to NaN. I am using SNAP v5.0.8 on a 64-bit kubuntu OS.
If I do the same processing but not at 30m resolution instead of the native (20m) resolution then I do get a mosaic but the ‘blend’ option is ignored.
RE the video:
-it does not state the nature of the blend algorithm, is it distance weighted?
-why does the ‘expression’ field in the third control tab seems to have no function, unlike the one in the basic ‘Mosaic’ tool?
To answer to your questions:
- the blending is just a simple pairwise alpha blending (on two images, the first one has weight 1, the second one 0.5);
- the ‘expression’, in the case of multi-size products, has not too much sense. Expressions were designed to work with pixel values. In the case of, let’s say, B8 and B8a, since a pixel in B8a corresponds to 4 pixels in B8, it doesn’t make sense to use these values in an expression (which value from B8 will it use?);
If you do the mosaic at 30m, that means you resample the bands at 30m and the resulting mosaic is no more a multi-size one, but a single size. AFAIK, the blending, in this case, doesn’t work if there are NaN values (it’s a JAI - the image processing library used - limitation).
For the result you’ve obtained for multi-size, could you please specify the products used?
I used S2 tiles S2A_MSIL1C_20170618T105621_N205_R094_T30SVF_20170618T110415 and S2A_MSIL1C_20170628T105651_N205_R094_T30SVF_20170618T110445.
With the blending, if the same blend is applied across the overlap zone, will this not lead to lines (radiometric jumps) along both overlap edges?
For the parameter expression I thought this would allow filtering using flag or classification information to be used (as with band maths). Otherwise, now are bad (invalid, snow, cloud etc.) pixels to be removed?