Offset Tracking - Manually change the oversampling parameter

Dear people,

If you are familiar with offset tracking methods, you know that to achieve finer results, it is highly recommended to oversample your data, sometimes up to a factor of 64!

In SNAP, the offset tracking module in the SAR applications enables us to tune a lot of parameters. however, the oversampling parameter cannot be changed and is even unknown. Reading the documentation, this parameter isn’t mentioned.

Studying relatively slow displacement (ranging from 50-350 m/year), it’s important to be sure that the oversampling factor is big enough.

Digging into SNAP codes, we notice that in the file (lines 868-893), an oversampling parameter is used.

It is actually defined in the first lines of codes (as 16), but contrary to other parameters, headers of the oversampling factor are commented.

By uncommenting these lines and modifying a bit the SNAP user interface, we can “unlock” this for the user.

If I make this topic, it’s because this parameter does change final results, as you can see below. I’m thus wondering why locking and hiding this parameter from the user?



I’m not sure about the history on why those parameters get hidden but, I can enable and expose the oversampling parameters.
Thanks Quentin


Yes it would be great. Thank you

Just as an example, here-below we have the comparison between default oversampling (16) and an oversampling of 64, in a slow-moving area (~100m/year).

In glaciology, a key parameter is velocity divergence. In the first case, we can see that the estimated ice-flow is noisy. Derived velocity divergence will be erroneous and won’t be usable in ice-sheet models. A solution is to filter the results, but then it means that we lose resolution, and our ability to capture small topographic features that disturb the ice-flow. In the second case, the ice-flow is much cleaner. We won’t need a lot of post-processing. So you know the reason :slight_smile:

Here are the modified codes : (14.4 KB) (47.7 KB)

One more question : is there any reason that using a stride of 1x1 pixel is not allowed?


Thanks a lot Quentin!!

@lveci Maybe my question was a bit hidden in my long post, but Is there any reason that using an exhaustive pixel offset search is not allowed in the module? (pixel spacing of 1x1)

Thanks in advance

I’m very interesting in this topic as the glaciers I am working with are rather slow compared to Greenlandic glaciers, however I’m struggling to work out how to enable the option of changing the oversampling option. Is there a way of doing this in Windows? I tried delving into doing it in Linux but got utterly lost.


I’m sorry I can’t help you. I built SNAP from sources thanks to this :
but not sure if a similar procedure exists on Windows.

However, from what I understood from @lveci, this parameter will be “re-activated” in future release.

I’m not an experienced user in offset tracking and in image processing. Could you please specify a little bit deeper what is oversampling factor. And what is it used for? To lower pixel size and improve image resolution?

In offset tracking, you are working with two coregistered images and you want to find the local displacements that occurred between the two acquisition dates. To do so, you define a grid i.e. a systematic sampling every x/y pixels. For each sample, offset tracking tries to find a translation in azimuth/range that maximizes local correlation of small patches around the sample. That’s classical image matching algorithm.

To get a finer estimation of the translation in azimuth range, it is common to oversample the patch. Instead of using a patch of 5x5 for example, you can use a patch of 40x40 (oversampling factor = 8). So yes the goal is lower the pixel size.

1 Like