I keep seeing this problem where the synchronised cursors are not in the same image location. To reproduce it, I opened multiple images in tiled windows and selected ‘Synchronises cursor positions across multiple image windows’ in the ‘Navigation’ pane in the bottom left.
Specifically, the actual cursor is always further left than all the crosshairs in the other image windows:
In my test (pictured above), the offset was always about 10 image pixels, regardless of zoom level. I tested with 3 TDX images from the same relative orbit, in ground range (not terrain corrected).
I was curious and restarted SNAP to see what that would do. Now with geocoded Sentinel-1 images there was no offset. However, when I opened the same 3 TDX images again, now the cursor was offset 20 image pixels to the RIGHT from the crosshairs.
Does anybody else experience funny behaviour like this?
I might be wrong but I think this is caused by the lack of precise geolocation of the TDX producs. They might be acquired at different angles or slightly shifted orbits so you can only compare the location of pixels after terrain correction.
Oh, I didn’t make this clear. The images are perfectly aligned – a colour composite works just fine, for instance. The top and bottom screens are the same, except for the cursor position. If you click on the screenshot to blow it up, you can clearly see that the difference is not between images but between cursor and crosshairs.
Although in the screenshot it looks like the difference could be between active (yellow frame) and inactive subwindow, this is not the cause. I tested that. It doesn’t make a difference which subwindow is active.
And from playing around with the time series tool, it looks a lot like the cursor is displayed in the wrong position (i. e. different from the one SNAP uses for calculations) and the crosshairs in the right place. Even when I had just one subwindow open, the cursor was offset, making the cursor pretty useless.
Have you compared the lat/lon values of the three scenes? The cursor synchronisation uses the geo-position of the scenes. Maybe there is something wrong.
have a look at the same pixel and and compare the lat/lon values. If they differ, than this is the explanation for the shift.
@marpet, take another look at the screenshots I uploaded in the first post and the cursor and crosshair positions. The offset isn’t tied to the displayed scene, it’s a constant offset between cursor and crosshairs, no matter which scene each is on. It looks like some sort of display glitch. To answer your question directly: For positions in the image that look the same and at which the crosshairs are displayed at the same time, the XY and LatLon positions are equal. In the case I’m looking at (same as first post), the XY are equal because I’m looking at repeat acquisitions of the same TDX scene.
Additional bit of info: When I hover over the top left corner bit with the cursor, it shows X=0 and Y=0. Hence things are not totally out of whack. However the values displayed in the Time Series window appear to not correspond to the cursor position, but to the crosshair position.
@mengdahl, I’m on 64-bit Windows 10 Enterprise and SNAP 6.0
I looked at coregistered images (See below).
The red dot is at image location (x,y) = (18249,9894) and (lat/long)=(70°09’53"S,25°58’15"E). The corresponding cursor on the right pane is at location (x,y) = (18271,9896) and (lat/long)=(70°09’50"S,25°58’21"E). We have an offset of 22 in x direction and 2 in y.
The offset is the same if I put the cursor on (x,y) = (18249,9894) on the left image, i.e. that the corresponding cursor on the left image is (x,y) = (18271,9896)
After having a look at this I can say that the main reason for the displacement is the sparsely populated tie-point grid of the S1 data.
Just a short review of how the cursor-sync works:
It pixel location is used to retrieve the geo-location in the one image view and the other view the geo-location is used to find the pixel location.
While the first step (retrieving the geo-location) is pretty accurate (bi-linear interpolation), the inverse operation is not.
Polynomial approximations are used in order to retrieve the pixel-position.
The root cause for the poor quality is that for a S1 scene of 24000x16000 pixels only 21x10 tie-points are provided. Less then every thousands pixel one tie-point. Doing an approximation on this sparse grid will not perform well.
I guess after a terrain-correction the cursor sync will perform better. The inverse look up is not used for the terrain-correction and the tie-points are not used anymore.
While looking at the code I found some places where SNAP could do things better. So we can improve in the future, but without a better tie-point grid the cursor-sync will remain poor.
There are some tools in SNAP which gives you an indicator how good this performance.
There is the Geocoding Information Window (). There the RMSE and the max error is shown for the approximation.
And you can compute the displacement bands (Raster / Geo-Coding Displacements Bands). But better do it on a subset. This can consume some memory.
This issue is still not resolved
I have a coregistered (cross-correlated and warped) stack of TSX images
col.1 - master; col.2 - slave1; col3 - slave2
rows - clicked images (master/slave1/slave2).
I’m getting same pixel coordinates of clicked pixel, but all synchronised cursors have 5px horizontal offset
The synchronisation is done by the geo-location. And this is the same for all 3 pixels.
So, the synchronisation is working. And in all three scenes the same pixel is highlighted. The one in the middle.
That the image coordinates (X,Y) are not the same might be caused by the co-registration step before.
You say they have 5 pixel horizontal offset, but in the image only a vertical offset by one is visible.
You mean the block of 9 pixels should be located else where? 5 pixels to the right?
Maybe. I can’t judge it. But this is not a problem of the synchronisation but of the coregistration step.
So the image with the red marking is always where you have your mouse pointer, right.
However, issue with synchronisation usually indicate issues with the data products.
I have no idea how such a shift could be introduced.
Is the shift the same over the whole image or does it change depending on the position in the image?
The shift is not the same, it varies a bit across the image.
Further step. Very easy test, no need to create stack. I’ve added a virtual band duplicate of stored band to open it twice. Cursor behavior is still the same, the issue is definetly not data related.
Then syncronized cursors is showed on different (same size!) bands of same coregistered product, there is no need to recalculate XY position.
). There the RMSE and the max error is shown for the approximation.
Thanks