Strange ImageViewerAddon MouseEventArgs X-coordinate offset behavior since 2023

Hello, we have noticed a possible bug in the ImageViewerAddon.

If the camera image is cropped on the sides, the whole view width is still considered as the image’s width. This code is needed in 2023 R2 to get the actual X-coordinate of the image:

location.X = e.Location.X - ((imageViewerAddOn.Size.Width - imageViewerAddOn.PaintSize.Width) / 2);

I have screenshot examples of the behavior. Red circle is mouse position, Note the X coordinate:

Old, correct, behavior (2022 R3):

New behavior (2023 R2):

This problem is only for the X-axis. Y-coordinates are correct in both versions tested.

Regards,

Daniel

I was unable to edit my post, but by the image being cropped on the sides I mean when the view has been resized so the view width is wider than the stream image width, and the sides are filled with black bars.

I tried but I cannot reproduce.

It tried to reproduce this using the VideoPreview plugin sample, where you can turn off the “Keep aspect ratio” and turn on the “Draw Line”, then I could see (debugging) that the location variables I got were the same in Smart Client (SC) 2023R2 as in SC 2022R3.

I guess that your code is not the same as the sample. Could you either see if the sample code provides a solution for you or create and share a plugin with minimal code that I can use for reproduction of the issue?

https://doc.developer.milestonesys.com/html/index.html?base=samples/pluginsamples/videopreview/readme.html&tree=tree_1.html

https://github.com/milestonesys

My code is based on the old (2021 R3) VideoPreview sample code which uses WinForms. The newer samples use Wpf, which has a different way of retrieving the relative mouse location. The old sample has the same issue as my code in 2023 R2.

I have small snippets of my code below.

// These events subscribe to handlers that call GetImageCoordinate(MouseEventArgs e)
imageViewerAddOn.MouseMoveEvent += ImageViewerAddOn_MouseMoveEvent;
imageViewerAddOn.MouseClickEvent += ImageViewerAddOn_MouseClickEvent;
private System.Windows.Point GetImageCoordinate(MouseEventArgs e)
{
	var location = e.Location;
	var coordinate = imageViewerAddOn.ConvertUserControlToRelativeImagePosition(location);
	return new System.Windows.Point(coordinate.Item1, coordinate.Item2);
}

The code below, from the latest version of the sample code, seems to do something similar to my code (workaround for 2023 R2) in my original post, except the sample code works in both versions tested, and the margin/offset is applied to the Y-axis as well, whereas only the X-axis is broken with my code:

// Latest sample code
private Point TransformRatio(Point point, Size paintSize, Size renderSize)
{
    var leftMargin = (renderSize.Width - paintSize.Width) / 2;
    point.X -= leftMargin;
    var topMargin = (renderSize.Height - paintSize.Height) / 2;
    point.Y -= topMargin;
    return point;
}
// My 2023 R2 workaround. Only X-axis needs this offset, in fact applying this to the Y-axis breaks it. Doesn't work on 2022 R3.
location.X = e.Location.X - ((imageViewerAddOn.Size.Width - imageViewerAddOn.PaintSize.Width) / 2);

Note that this is a toolbar plugin, where we use the VideoOS.Platform.Client.ImageViewerAddon for mousecoordinates to draw overlays on camera.

Hello, do you have any updates regarding this?

Since the new sample code is in WPF, the logic for retrieving mouse location can’t be applied to our code. The old sample is broken in 2023 R2 as well, so I suspect the ImageviewerAddon, being a WinForms UserControl, is handled differently than its WPF equivalent.

Sorry, I should have come back earlier, I still cannot reproduce the issue. The VideoPreview does not use ImageViewerAddOn, if is use the ImageViewerControl instead I could not reproduce. I am guessing my way of reproducing is flawed, might you be able to suggest how I can reproduce? Perhaps you have a minimal implementation source code I can debug, or a minimal change to a sample (new or old) that you can share?

Hi again,

The sample code from 2021 R1 uses the ImageViewerControl and using that code, without any change, I can reproduce the positioning issues in the 2023 R2 smart client:

I have tested:

  • different DPI scaling, screen resolutions and aspect ratios
  • different camera stream resolutions, aspect ratios
  • different cameras
  • Fresh install of Smart Client 2023 R2

The square position seems to be the relative position of the entire ImageViewerControl, instead of the stream image itself, even when Keep Ascept Ratio is enabled.

I have attached a video to demonstrate using this version of the VideoPreview sample.

Hello, are there any updates on this?

/Daniel

I tried now, and I am confused. You reported there was a different behavior on X and Y coordinates.

I was using the sample plugin from MIP SDK 2021R1, there is no difference in behavior whether I do what you suggest on the X or Y axis. There is no difference when I try with Smart Client 2023R2 or Smart Client 2021R1.

I am either misunderstanding something or getting wrong instructions. If there is an issue, and I must suspect that from what you write about workaround code etc., I am interested and want to reproduce. Please revisit this and see if you can give me better instructions.

Here is an edited version of the SCImageViewerAddOn sample that you can use to reproduce the issue with only the X-axis coordinates being offset in 2023 R2. The plugin adds live coordinates of the cursor location inside a video stream image.

There are videos included that demo working behavior (2022 R3) and buggy behavior (2023 R2) using this edited plugin.

Steps to reproduce are:

  1. Build and install the plugin
  2. Launch Smart Client 2023 R2 and open a camera view.
  3. Crop the window so X-axis gets cropped (black bars left and right)
  4. Drag the cursor along the X-axis.
  5. Notice the coordinates are offset, they start on left view border instead of camera stream left border.
  6. Image example: X starts on viewitem border
  7. Image example: X ends inside video image, offset to left of video stream border

Thank you, I will review the code and use it for a reproduction.. I will update you.

Hello, have you been able to reproduce the issue?

I did promise you an update. Yes, I did reproduce and then reported it to Milestone Development for analysis. We are now awaiting feedback from Development.

Thank you for providing the code to reproduce!

Milestone Development have develop a fix. In first go the issue is fix for future versions of the Smart Client. Next step there will now be made fixes for 2023 versions.

Thank you. Would it be possible for us to get a test version to verify that our plugins will work with this fix?

No, thank you for asking. We will have to wait for the patches for the 2023 versions. I do not believe it will be a long wait, I expect to be able to give you a link to new patches including this fix within a week.

Milestone has now made Smart Client patches available..

Smart Client 2023R1 -

https://supportcommunity.milestonesys.com/KBRedir?art=000051001&lang=en_US

Smart Client 2023R2 -

https://supportcommunity.milestonesys.com/KBRedir?art=000055701&lang=en_US

A patch will also be needed in 2023R3 but that one is not ready yet.

Thank you. The issue seems to be resolved with the patch.

Thank you for the patch.

Issue with X-Axis is resolved.

However, issue with Y-Axis is not fixed.

I am using two screens.

Screen 1: 1920x1080, Scale 125%

Screen 2: 1920x1080, Scale 100%

Screen 1:

  1. 1x1 view - works fine

2) 2x2 view - Issue is open for Y-Axis

  1. 3x3 view - works fine

  2. 4x4 view - works fine

Screen 2:

  1. 1x1 view - works fine

  2. 2x2 view - works fine

3) 3x3 view - Issue is open for Y-Axis

  1. 4x4 view - works fine

@Bo Ellegård Andersen (Milestone Systems)​ could you please verify with different views for Y-axis and confirm the same.

Please provide a screen capture where the issue is seen so that I know what I am looking for.