The long rectangular box tends to shift when fine-tuned.

[lhj5426]

Search before asking

• [X] I have searched the X-AnyLabeling issues and found no similar bug report.

X-AnyLabeling Component

No response

Bug

I turned my monitor vertically to use the software. When the rectangular box is very long vertically, there's a chance that it shifts or becomes extremely long when using the arrow keys (up, down, left, right) to fine-tune it, as shown in the video.

https://github.com/user-attachments/assets/66f58707-1b4a-445d-8a27-cb94d0541567

Information

appname = "X-AnyLabeling" appdescription = "Advanced Auto Labeling Solution with Added Features" version = "2.4.1" __preferred_device__ = "GPU" # GPU or CPU

Link to a Reproducible Demonstration Video

https://github.com/user-attachments/assets/66f58707-1b4a-445d-8a27-cb94d0541567

Execution Mode

Source Code

Additional

Here is an image for your convenience to use for testing.

Are you willing to submit a PR?

• [ ] Yes I'd like to help by submitting a PR!

[lhj5426]

After switching pages, there is a high chance of triggering an offset bug the first time you use the arrow keys to fine-tune the rectangle box.

[CVHub520]

Thank you for reporting this issue with the long rectangular box shifting when fine-tuned, especially in vertical monitor orientations.

While we're unable to reproduce this specific behavior at the moment, we appreciate the detailed report. This information is valuable for improving X-AnyLabeling.

In the meantime, here are some general suggestions that might help mitigate the issue:

1. Try resizing the application window: Sometimes, UI rendering issues can be resolved by adjusting the window size or maximizing/restoring the window.
2. Temporary workaround: If possible, try using the software in landscape orientation for critical tasks until we can investigate further.

We'll make a note to test the software in vertical monitor orientations in our development process. Your feedback is crucial for improving X-AnyLabeling for all users.

Thank you for your patience and for bringing this to our attention.

[lhj5426]

Thank you for reporting this issue with the long rectangular box shifting when fine-tuned, especially in vertical monitor orientations.-----------谷歌翻译-----------感谢您报告微调时长矩形框移动的问题，特别是在垂直显示器方向上。

While we're unable to reproduce this specific behavior at the moment, we appreciate the detailed report. This information is valuable for improving X-AnyLabeling.-----------谷歌翻译-----------虽然我们目前无法重现这种特定行为，但我们感谢您提供详细的报告。此信息对于改进 X-AnyLabeling 非常有价值。

In the meantime, here are some general suggestions that might help mitigate the issue:-----------谷歌翻译-----------与此同时，以下是一些可能有助于缓解该问题的一般建议：

1. Try resizing the application window: Sometimes, UI rendering issues can be resolved by adjusting the window size or maximizing/restoring the window.
2. Temporary workaround: If possible, try using the software in landscape orientation for critical tasks until we can investigate further.

We'll make a note to test the software in vertical monitor orientations in our development process. Your feedback is crucial for improving X-AnyLabeling for all users.-----------谷歌翻译-----------我们将在开发过程中记录在垂直显示器方向上测试软件。您的反馈对于改进所有用户的 X-AnyLabeling 至关重要。

Thank you for your patience and for bringing this to our attention.-----------谷歌翻译-----------感谢您的耐心等待并将此事提请我们注意。

https://github.com/user-attachments/assets/50a4a31b-4786-4a9b-a597-47a6ba706414

Even in landscape mode, there are random occurrences of rectangular offset issues. As shown in the video, these issues appear randomly during the adjustment process. I used three images, and from importing to inference to adjusting the rectangles, the rectangular offset occurred randomly 3 to 5 times throughout the complete process

[CVHub520]

Thank you for providing further clarification.

Based on the analysis from the above, it appears that this "Bug" is probably not due to an inherent flaw in the software. Instead, it seems to be associated with the model's provision of incorrect outputs. Specifically, the four coordinate values for the rectangle do not form a "closed loop." A valid output should be structured as follows: points=[[x1, y1], [x2, y1], [x2, y2], [x1, y2]].

Therefore, I recommend that you carefully inspect the label files after the model inference service has been executed.

[lhj5426]

After testing, it seems that the issue of rectangle shifting indeed occurs with the rectangles inferred automatically by the AI. However, manually created rectangles do not show this shifting issue, regardless of how the page is switched.

What causes this issue, and how can it be resolved?

The data used for model training was created using X-AnyLabeling, and the training was done using Ultralytics 8.2. Why does this result in an inability to close the loop?

Is there a solution to this problem?

I really don’t know how this issue is happening. Did some bug occur during the inference process? I used GPU for inference.

[lhj5426]

Do you need me to send you the trained model file for testing? I trained multiple models, but they all have the issue of rectangle shifting when using the arrow keys to adjust.

[lhj5426]

Is it related to this file?

This is the script I used to convert the .PT model to an Xnno model. Did the issue occur during the model conversion? Can the .pt file be loaded directly?

[lhj5426]

https://github.com/user-attachments/assets/b66a1ade-4d63-4c0c-b83c-0eca9dd0618c

This is the new model I trained at 4 a.m. On four pages of images with dozens of rectangles, there were three instances of shifting. I currently don’t know where the problem lies.

[CVHub520]

Hey, @lhj5426, I noticed your message about the stride field in your custom YAML file. You're correct that including the stride field might lead to unexpected results. For your current setup, you don't need to specify the stride in your YAML file. I recommend removing that field and then trying your configuration again. This should help you avoid any unintended issues.

Let me know if you have any further questions or if everything works as expected after making the change. Thanks!

[lhj5426]

Hey, @lhj5426* , I noticed your message about the stride field in your custom YAML file. You're correct that including the stride field might lead to unexpected results. For your current setup, you don't need to specify the stride in your YAML file. I recommend removing that field and then trying your configuration again. This should help you avoid any unintended issues.

Let me know if you have any further questions or if everything works as expected after making the change. Thanks!

Hmm, thanks. I deleted that parameter and will test it again now.

[lhj5426]

Oh, I apologize. The issue still persists even after deleting this parameter.

[CVHub520]

Oh, I apologize. The issue still persists even after deleting this parameter.

Please compress your ONNX model file, YAML configuration file, image file, and JSON file into a single ZIP archive. Once prepared, kindly attach the ZIP file to an email and send it to: cv_hub@163.com. Your prompt assistance is greatly appreciated. Thank you in advance for your cooperation.

[lhj5426]

It's been edited out here

[lhj5426]

Oh, I apologize. The issue still persists even after deleting this parameter.

Please compress your ONNX model file, YAML configuration file, image file, and JSON file into a single ZIP archive. Once prepared, kindly attach the ZIP file to an email and send it to: cv_hub@163.com. Your prompt assistance is greatly appreciated. Thank you in advance for your cooperation.

The attachment is small, so I posted it directly on GitHub. Sorry for the inconvenience. Could you please check it? The model is for recognizing horizontal text. It can handle any images with horizontal text. You can also test it with some images of your own.

[CVHub520]

I have tested the model and found that everything is working normally. Could you please provide some data that can reproduce this issue? This will help us to further investigate the problem.

https://github.com/user-attachments/assets/3d524bbb-389b-461d-9667-9489389dd95f

[lhj5426]

I have tested the model and found that everything is working normally. Could you please provide some data that can reproduce this issue? This will help us to further investigate the problem.

23-21-43.mp4

I will package the software I use, along with the software configuration, a larger model, and the images for testing into a ZIP file. It will be sent to your email with the subject "lhj5426". Please check your email shortly

[lhj5426]

The reproduction steps are as follows:

First, use the model to perform inference. Then, move the mouse over the rectangular block and keep it still. Press any of the arrow keys (up, down, left, right), and random offset will occur. In my case, after the model completes inference, the first rectangular block on each page has a high probability of showing an offset

[CVHub520]

It is recommended that back up the configuration file (.xanylabelingrc) under the user directory and then delete it. Then download the corresponding exe file from the official release page, open it, load the custom model for testing, and see if the problem persists.

[lhj5426]

It is recommended that back up the configuration file (.xanylabelingrc) under the user directory and then delete it. Then_ download _the corresponding exe file from the official release page, open it, load the custom model for testing, 和 see if the problem persists.

This is a topic worth discussing. The official distribution has not provided a version that supports running on GPU since version 2.3.6. The latest version, 2.4.2, only has a version that runs on CPU.

That's why I attached the configuration I am using, as well as the GPU-supported version I’m running from source, in the email I sent you, so that you can use them for testing and troubleshooting.

[lhj5426]

However, as you suggested, I re-downloaded and extracted the source code, backed up the original configuration file, generated a new configuration file, and ran the program. After the inference was completed, the first rectangle still showed an offset.

[lhj5426]

https://github.com/user-attachments/assets/5070946a-f441-4698-9313-3cd3ba77e203

Here is the translation:

As you suggested, I downloaded the official EXE version 2.4.2 and used CPU inference. After the inference was completed, you can see that an offset also occurred. Since CPU inference is very slow, I only inferred a few images

[lhj5426]

So I have sent you all the models, software, and software configurations that I used. If you can't reproduce this issue, while I can reproduce it every time, that’s quite frustrating. The rectangular offset issue is particularly puzzling. Is this a problem on my end or a software issue? It has become quite a mystery now

However, in any case, I sincerely thank you for taking the time to address this issue. I apologize for wasting your valuable time

[CVHub520]

Hey there! @lhj5426,

Thank you for providing all the necessary models, software, and configurations. I appreciate your thorough approach in trying to reproduce and solve this issue. Given the information you've shared, I have a potential solution that might address the rectangular offset problem you're experiencing:

Considering that your bounding boxes seem to have a high degree of overlap and crowding, the instantaneous offset is likely caused by "confusion" when switching between target boxes. To mitigate this, you could try disabling the automatic switching to edit mode. Specifically, I recommend opening your user configuration file and setting the following two options to False:

auto_highlight_shape: false
auto_switch_to_edit_mode: false

While this adjustment may slightly reduce efficiency, it should theoretically improve stability. This change should help prevent unwanted shifts when interacting with closely packed bounding boxes.

Please try implementing these changes and let me know if they resolve the issue. If you're still experiencing problems or if you need any clarification on how to modify these settings, don't hesitate to ask. Your feedback is valuable in helping us pinpoint and resolve this puzzling behavior.

Lastly, there's no need to apologize - troubleshooting complex issues is an important part of improving software. Your detailed reports and patience are much appreciated.

[lhj5426]

Hey there! @lhj5426* ，

Thank you for providing all the necessary models, software, and configurations. I appreciate your thorough approach in trying to reproduce and solve this issue. Given the information you've shared, I have a potential solution that might address the rectangular offset problem you're experiencing:

Considering that your bounding boxes seem to have a high degree of overlap and crowding, the instantaneous offset is likely caused by "confusion" when switching between target boxes. To mitigate this, you could try disabling the automatic switching to edit mode. Specifically, I recommend opening your user configuration file and setting the following two options to False:

auto_highlight_shape: false
auto_switch_to_edit_mode: false

While this adjustment may slightly reduce efficiency, it should theoretically improve stability. This change should help prevent unwanted shifts when interacting with closely packed bounding boxes.

Please try implementing these changes and let me know if they resolve the issue. If you're still experiencing problems or if you need any clarification on how to modify these settings, don't hesitate to ask. Your feedback is valuable in helping us pinpoint and resolve this puzzling behavior.

Lastly, there's no need to apologize - troubleshooting complex issues is an important part of improving software. Your detailed reports and patience are much appreciated.

According to the two settings mentioned by the developer, I configured them, and there were indeed no issues. Then, I individually disabled one of the options: "Automatically activate the rectangle under the mouse." After that, the offset problem did not occur again.

Thank you! Although turning off this option does reduce efficiency from an operational perspective, it definitely improves stability and solves the problem. Most importantly, we finally pinpointed the source of the issue. I appreciate everything you’ve done!

Then, since we’ve pinpointed the root of the problem, is it possible in the future to fix or improve the rectangle offset issue while still being able to use the "Automatically activate the rectangle under the mouse" feature?

[lhj5426]

Anyway, thank you very much. At least now I can make fine adjustments to the position. From this perspective, it can also be seen as an improvement in efficiency This problem that has been bothering me for a long time has finally been solved with your help thank you

[CVHub520]

Thank you for your feedback. We are continuously working to improve our product and will strive to fix the issue promptly to minimize any inconvenience caused.