Cursor And View Difference
Rosella Bowlan
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.
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.
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.
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.
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.
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.
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.
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?
I need a little bit of inspiration. I have two side by side fields in a table, let's call then Addr1 & Addr2. They happen to be the input and result of a geocoding process where Addr1 is the matched address and Addr2 is the input address. This particular table are just matches less than 100%. Some of the reasons for jump right at you, others not so much. But, it's a list of 3100 records and I'd rather have a cursor go through it than stare at the records and not see the difference.
Having read Richard Fairhursts /blogs/richard_fairhurst/2014/11/08/turbo-charging-data-manipulation-with-python-cursors-and-diction..., I'd like to try the dictionary approach, but I'm a little fuzzy as to proper way to construct the dictionary and then cursor through it. Consider the following record where the prefix direction is mismatched:
With the two fields having a standard format, they are easy to parse out (see A better way to parse an address? ) to compare the various elements. It's the cursor/dictionary piece that I need some help with.
You don't need to do anything crazy with dictionaries here since you are directly comparing values within the same row of a cursor. Although I agree with Darren's overall approach, I am not sure if just splitting the address fields based on spaces will be robust enough. You said the addresses are standardized, but we all know there are limits to standards.
Has anyone else had this problem? Basically, I'll be taking a screen recording in Replay and selecting different tabs/options in this video. However, when I view the screen recording in Replay. my cursor in the video is much higher than it should be.
For context, if this was an Excel spreadsheet, my cursor in the video would be 3-4 rows higher than the row that is selected. So I end up with something selected and a cursor that doesn't match the position of the selected item. I want this to be professional and straightforward for the learner, so how do I fix this?
I was recording in 1908 x 1076. and I have a ton of video that I now get to either re-stage and shoot, or process again with Camtasia and 'fake' having mouse tracking enabled.
I am entirely dismayed by the 'aw shucks' attitude regarding this critical issue, at least that's how it reads in the responses above to Brett's concerns. I don't see anything in any release notes or supporting documentation to indicate that a user could have been forewarned about this issue. Users like Brett and I are creating content intended to teach learners how to click and do things in software. That your tool does not do what it is designed to do is a bit more than an 'oops.' I've long been a huge fan of Articulate tools but man this really stings.
I had the same problem and setting the scaling to 100% solved the issue. But please consider this as a workaround and have your dev teams look at it anyway. Depending on the application we're demonstrating and the computer we use, scaling the screen can be unavoidable, making Replay practically unusable in these contexts.
Thank you for reaching out and letting us know! I will be including your comments in our report and be sure to update our team on this. In the meantime, a workflow that I hope will help is to set the scaling to 100% when creating screen recordings.
Having the same issue. I adjusted the scaling which fixed the cursor issue, but now what shows inside the screen frame when I'm recording is NOT what is recorded. Any fix for that? Basically it appears as though I'm recording the whole screen, but when I publish, some is missing
I'm sorry to hear you're running into this issue as well! If adjusting the scaling percentage to 100% in Display settings in Windows isn't working, please connect with our support team for a tailored approach in getting Replay to record as expected.
Changing the scaling percentage to 100% should help in this scenario, but I recognize how frustrating it is to rerecord. From here, I'm going to connect you with our talented engineers to try to find a better way forward.
Hi! I am also getting the issue of the mouse tracking higher than what I am recording. I have set my scaling percentage to 100%; however, now, when I attempt to record full screen, the screen is offset and has black edges on the side and bottom.
The situation Brandon reported has also happened to me. Meaning that the 100% scaling of the screen hasn't solved the mouse tracking issue.
I wonder if there are any developments concerning this bug. My company will start developing video screen tutorials for a client soon and we cannot possibly deliver them if this bug persists.
Disappointing to see that 2 years after this issue was reported it is still a problem - I struggled with it yesterday. I tried the changing my screen dimensions to 100% but it made everything on my screen tiny and then the box around what to record could no longer be stretched wide enough to cover my full screen when I did that!!? I ended up recording without a mouse, touch screened everything, and now am having to go back and manually add in a mouse in editing to every step in the video, adding a full day of work to my timeline. This product/tool did not do what it was advertised to do.
In the meantime, I'll update our bug report to reflect each of your statements. I'll share any updates with you in this discussion. I appreciate each of you for sharing how this bug affects your projects.
But now its making the screencast in a smaller window and is leaving a big black border going around it, i cannot have this as i need the video to take up the entire screen, see screenshot below. Can someone help me out here??
I'm glad to have found this thread since I thought I was going crazy! I was able to switch my Display Settings to 100% and now the mouse cursor movements line up with the video but I find that the quality is not great due to the small size. It's a shame because it severely limits the use of this tool for me. Looking forward to hearing about any updates and fixes to the issue!
Same for me Lena! I can't believe there isn't a published solution given several of us have reported the same issue, adjusted the display settings to 100% now the screen is too small to read, with a large back box around it in the recording.
I use both Splunk and Cloudwatch dashboards on a regular basis. One feature that cloudwatch dashboards have which I really miss in Splunk is a shared time cursor across all charts on the dashboard. So that it's easy to say "What was happening in all these different metrics at time X?"
Now, I recognize that Splunk charts are more diverse and so this is probably a non-trivial feature, but it would be very helpful for my workflows. I often need to correlate phenomena from different systems or sourcetypes by time.
EDIT: To clarify, I mean that when I hover my cursor over a point on chart A which occurs at time X, I see a vertical line though the point. A tooltip shows the value of the point. Simultaneously, on other timecharts a vertical line appears at the same time (horizontal position) and a tooltip shows the value of the point on that chart at that time X.
Hi @akuchta,
Did you get a final solution to do this?
We ware using Splunk 8.1.0 and using metrics.
In the analytics workspace (for metrics) I can create two graphs in which the cursor (time) goes over both graphs at the same time.
However when I save it as a dashboard (with both graphs as a panel) this feature is gone.
How can I get the cursor tracing over both graphs back in the dashboard?