Issues/Observations/Comments of SNAP 6.0 Beta


There is a quiete good anawer on stackoverflow why these values differ.


Interesting link, thanks! Makes sense now.


Thanks! Managed to get terrain flattening incorporated and it looks good. Thank you to everyone who worked on this.

Have noticed that it leaves gaps, presumably where the auto-downloaded SRTM tiles are intentionally “missing” over water. I understand that the purpose of terrain flattening isn’t meant for marine regions, but for consistency, would it be better to just treat these areas as flat (as with the rest of the sea) rather than remove them entirely from the output. This seems to be how Terrain Correction deals with missing tiles.


Dear all,

I have tried to create a stack using Backgeocoding by SNAP 6.0 PREVIEW4 and PREVIEW5.

I used 12 images and it took about 70 mins in PREVIEW4.
But in PREVIEW5, it took more than 10 hours and only processing 15% of this step.

I don’t know why the processing time is so different?

Thank you!


Dear Sharon can you share your graph & product info so we can see whether we see the same behavior. @cwong


Dear @mengdahl,

The products and operator I used were like below figure, I’m not sure that help or not.

I have uninstalled PREVIEW5, and running with PREVIEW4 now.

Thank you!


So running the backgeocoding separately was a lot slower with Preview5?


You mean backgeocoding only for two images?
Sorry, I didn’t try this.


I understood that backgeocoding was slow when you ran in through the GUI as illustrated, instead of running it as a part of a larger graph.


I also tried to processed with graph in Preview5 like below.
It also took much time than Preview4, so I didn’t finish them.


6 posts were split to a new topic: After tiling views one is lost


Dear @ABraun,

are all of them projected and of the same pixel size?


Is it always the same product which is hidden or is it a rather systematic issue?

It’s a systematic issue, the image that is hidden is random.
For example, if i use “tile vertically” with a, b, c, d views, Snap shows: at first attempt a,b,c and hide d; at second attempt a,b,d and hide c; and so on.


@Sharon - you have coregistered a stack in preview 4 and preview 5 and in the first it was one hour and in the latter 10hours, right? We will test it and compare results to see if there is any serious problem with preview5. I will update you soon!



Yes, Preview 5 took a long time to coregister a stack before. I restored preview 5 yesterday to test it again, it seems nothing wrong and finished in 1 hour with 8 images. I don’t know what happened at that time when it ran over 10 hours.

But this time I tried to process by a graph like below:

I have typed RUN before 12 hours from now, but it seems that the software didn’t process it?

Thank you!

Workflow between SNAP and StaMPS

I’m not sure what you intend to do using this graph and why you are trying to "write"all the intermediate products but in general when you have big graphs and additionally a large dataset to read and write it will surely take a long time to finish


I want to process 8-12 images of 6 sets for stamps (the PSInSAR analysis), here are 70 images I need. So, I think I could process some step by graph. And I wrote all the intermediate products just for check this step is success.
I have tried to process the step separated in this graph. In 8 images case, every step (back geocoding, ESD and deburst) spend 60, 52 and 30 mins, respectively. But when processed in graph, it took more than 12 hours.

Thank you for your help!


If you are reading from and writing to a non-local removable disk, then it could be very slow.


But I reading from and writing to a local disk, so I don’t know why.


Hi Federico,

I face the exact same problem with iCOR. The weird thing is that in both SNAP versions (5&6) I cannot run iCOR. Did you maybe found a solution?

Thanks in advance



When you have problems with iCOR you can post it in the iCOR category. Then the iCOR developer will see it.