10-28-2025 07:59 AM
Hi Omar,
@Omar-Abdelhameed wrote:
The issue I am facing now is when the position of the opject changes, the vi wrongly calculates number of lines!! is there are way to fix that?
Sure: avoid position changes!
More seriously: you could develop an algorithm to crop the image to the interesting part by removing "black borders". This way you only need to analyze very similar images, no matter how large the border area actually is…
10-28-2025 08:17 AM
Thank you Gerdw for your advise. can you please help me applying that! I have never done something similar before.
10-28-2025 08:36 AM - edited 10-28-2025 08:36 AM
Hi Omar,
@Omar-Abdelhameed wrote:
can you please help me applying that! I have never done something similar before.
You never played with GIMP or Photoshop to auto-crop an image?
You never thought about "how did they do that?"?
Building an auto-crop algorithm:
(I will not write the code for you.)
11-06-2025 02:50 PM - edited 11-06-2025 02:50 PM
@Omar-Abdelhameed wrote:
I got that solved. please see attached picture. The issue I am facing now is when the position of the opject changes, the vi wrongly calculates number of lines!! is there are way to fix that?
I appreciate your help and support. Thank you.
I am pretty sure this code is bugged if you look closely (if the input is a rectangle, the output should not be be square!):
To see how to rotate or flip a 2D array, look here.
If you take a horizontal and vertical profile of the brightness, you can tell from the pattern what the correct orientation would be and adjust the code accordingly. You can also tell where the black borders are and only use the inner subset for further processing.