[Bug]: ScreenGear's options wrong names

[xiety]

Description

I need to capture an exact rectangle starting from x, y and with size of width and height

I've came up with following working code, but it looks strange:

options = {"top": x, "left": y, "width": x + width, "height": y + height}

Why top should be x and not y?
Why width must be calculated like it is right?

I think it should be

options = {"left": x, "top": y, "width": width, "height": height}

or

options = {"left": x, "top": y, "right": x + width, "bottom": y + height}

Issue Checklist

• I have searched open or closed issues for my problem and found nothing related or helpful.
• I have read the Documentation and found nothing related to my problem.
• I've read the Issue Guidelines and wholeheartedly agree.

Expected behaviour

Correct bounding box

(left, top, left+width, top+height)

Actual behaviour

Incorrect bounding box

(top, left, width, height)

Steps to reproduce

irrelevant

Terminal log output

No response

Python Code(Optional)

from vidgear.gears import ScreenGear
    options = {"top": x, "left": y, "width": x + width, "height": y + height}
    stream = ScreenGear(**options).start()
    frame = stream.read()

VidGear Version

0.3.1

Python version

3.10.7

OpenCV version

4.8.0

Operating System version

Windows 10

Any other Relevant Information?

No response

[welcome]

Thanks for opening this issue, a maintainer will get back to you shortly!

In the meantime:

• Read our Issue Guidelines, and update your issue accordingly. Please note that your issue will be fixed much faster if you spend about half an hour preparing it, including the exact reproduction steps and a demo.
• Go comprehensively through our dedicated FAQ & Troubleshooting section.
• For any quick questions and typos, please refrain from opening an issue, as you can reach us on Gitter community channel.

[abhiTronix]

@xiety This is not a bug. VidGear follows pillow's Coordinate System which states as follows:

The Python Imaging Library uses a Cartesian pixel coordinate system, with (0,0) in the upper left corner. Note that the coordinates refer to the implied pixel corners; the centre of a pixel addressed as (0, 0) actually lies at (0.5, 0.5).

Coordinates are usually passed to the library as 2-tuples (x, y). Rectangles are represented as 4-tuples, (x1, y1, x2, y2), with the upper left corner given first.

That would look like this:

Pillow's XY coordinate system, which is different from what you're targeting for. Kindly make changes according to it.

[xiety]

@abhiTronix, I'm sorry, but I can't understand why I need to put x coordinate into the top property and not into the left

[abhiTronix]

Hope this image helps you.

[abhiTronix]

I never said it should x or y, it is distance from top.

[xiety]

But the fact of the matter is that now in the top property you need to put the distance from the left edge of the screen.

[xiety]

This is how it is working now, which is kinda strange

[abhiTronix]

@xiety let me check.

[abhiTronix]

@xiety Yes "top" and "left" were swapped for dxcam backend. But your diagram is incorrect, height and is not from the initial(0,0) but from the top+height and left+width respectively, you can confirm this by setting top and left zero and then increasing both the values simultaneously and you could see region moving diagonally, but the dimensions(area) of region not changing.

[xiety]

I'm doing a simple test:

from vidgear.gears import ScreenGear
capture_options = {"top": 100, "left": 100, "width": 700, "height": 700}
screen = ScreenGear(**capture_options).start()
image = screen.read()
print(image.shape)

The result is (600, 600, 3) instead of (700, 700, 3). The same with mss backend.

[abhiTronix]

@xiety Apologies, visually this is really hard to see. Yeah you're correct, since all those backend libraries are following PIL.ImageGrab.grab bbox left,upper,right,lower conventions as explained in depth here: http://chayanvinayak.blogspot.com/2013/03/bounding-box-in-pilpython-image-library.html

[abhiTronix]

@xiety I'll add this to ScreenGear documentation.

[abhiTronix]

Successfully resolved and merged in commit 3c0dd5d