BGRABitmap and incorrect TRect range

[backprop]

I have basic problem with any method which use TRect.

It seem the range is not calculated well and always is short by 1.

For instance:

Code: [Select]

procedure GetSCR(dst: TBGRABitmap);
var
  r: TRect;
begin
  // It is bug in BGRA, need to be +1
  r := Rect(0, 0, Screen.Width - 1 + 1, Screen.Height - 1 + 1);
  dst.TakeScreenShot(r);

That is. If resolution is 1920x1080, r should be Rect(0, 0, 1919,1079), not Rect(0, 0, 1920 1080).

This is obvious. If I need just one pixel, (0,0) for instance, r should be Rect(0, 0, 0 0), not Rect(0, 0, 1 1) as currently. And this bug is not specific for this, but for any method which use rectangle ranges.

That makes quite a bit of problems with precise image manipulation and require quite a bit of effort of something need to be ported from Delphi.

Circular, can you fix that please?

[KodeZwerg]

Somehow your example looks strange, -1 +1, whats the suppose?
And your second issue, what is the distance from 0 to 0, or 123 to 123? IMHO when distance is 0, there exist no pixel in it.

[backprop]

Try code with  r := Rect(0, 0, Screen.Width - 1 , Screen.Height - 1 ), save the image and see size of it.

This have no sense. If it is required rectangle from (0,0) to (9,9), or  (10,00) to (19,19) size of it is  10x10, not 9x9 as current.

Remember the screen coordinate starts from (0,0), not (1,1). Is it that obvious?
And upper is code I'm using to avoid such problem and point error in it.

Rectangle ranges include values, not exclude it. Thus distance for screen coordinate system is always x2-x1+1 and y2-y1+1, thus final coordinate is always less by 1 from its resolution size. Again, is it that obvious?

BTW. I would contact Circular directly, but for new members is still not allowed to use PM.

[dseligo]

That makes quite a bit of problems with precise image manipulation and require quite a bit of effort of something need to be ported from Delphi.

IMHO it is by design. Bottom and right edges are not included in the rectangle.
I'd say it is same in Delphi, look at this link: https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Types.TRect

[backprop]

If that is by design, not by math logic, then it is disaster.

But I think I have found this problem when I converted some app from Delphi 7 to Lazarus and BGRABitmap when copy part of the picture with rect...

"When a TRect value represents a rectangle on the screen, by convention the top and left edges are considered inside the rectangle and the bottom and right edges are considered outside the rectangle. This convention allows the width of the rectangle to be Right - Left and the height to be Bottom - Top."

The same source said that is by convention. What convention?!? Never heard about that. It simply have no sense and makes big confusion.

[wp]

If that is is in by design, not by math logic, then it is disaster.

Let me say it this way: How many pixels are in Rect(0, 0, 0, 0)? Zero or one? If you answer 1, how should an empty rectangle be defined then? Rect(0,0,-1,-1)? But this violates the convention that Right >= Left... But if you answer 0 you must accept the calculation Width = Right - Left, and this excludes the right edge from the rectangle.

[backprop]

It is classical logical error.

We working with physical pixels and exact points of edges on the screen, not width and height as the second 2 parameters.

As this: rect(x0, y0, x0 + w - 1, y0 + h- 1)
Not this:  rect(x0, y0, w, h)

That why what is said here in the quote have no sense with screen graphics.
In any case, I need precision, not some "convention" have no sense in reality.

[dseligo]

As this: rect(x0, y0, x0 + w - 1, y0 + h- 1)
Not this:  rect(x0, y0, w, h)

Actually it is: rect(x0, y0, x0 + w, y0 + h)

[backprop]

Actually it is: rect(x0, y0, x0 + w, y0 + h)

And the whole point is that this have no sense at all.

[Thaddy]

See:
https://devblogs.microsoft.com/oldnewthing/20040218-00/?p=40563

And this discussion where I got the link from:
https://forum.lazarus.freepascal.org/index.php/topic,64111.msg487239.html#msg487239
So it is not BGRABitmap, but a general programming convention to simplify code.
BGRABitmap simply adheres to that convention.

To me it was also counter-intuitive until I read that article.

[KodeZwerg]

And the whole point is that this have no sense at all.

It is pure logic, how many steps you need to go to count from 0 to 1920?
Feel free to write a RectFix() method that accept your math and returns the correct one, problem solved.

[backprop]

Ah, that is M$ stupidity, I should to assume that.

As a mathematician, this will never have a sense for me. Half included, half excluded - total stupidity only some M$ "expert" could do and explain as a "holy grail". I always looked and used TRect as a simple and logical container for rectangle edges in order to simply code, which basically is. And I will stick to that in the future as well.

It is pure logic, how many steps you need to go to count from 0 to 1920?

You can't ask that question as is illogical. Coordinate system on the screen by convention starts by pixel from position (0,0). And then you falling into logical trap here. If it starts from (1,1), then your question would be logical ("...from 1 to 1920").

Again, total stupidity.

[KodeZwerg]

First you say BGRA is incorrect than you switched to a faulty TRect and now it is the bad bad Microsoft company
For you as a math expert I make it now extra easy.
If you have a box that has exact 50 inch width and you put a ruler on to measure it, where does the ruler begin and where does it end to have the correct width?

Maybe you can just agree that your math is wrong or is now the ruler wrong or the box width cheat or what is going on, who fault is it now, God maybe?

[alpine]

@backprop
As a mathematician, perhaps you are familiar with the notion of the right-open intervals.

[backprop]

You making illogical things logical and follow it and simple thing complicated and then rationalize that?

That is as M$ would define that N divided by zero is zero or one and force entire industry to stick to that as iit will make all things easier. What again question would be to explain/rationalize that?  "How much zeros we have in N?" Dividing by zero is math definition, not convention or suggestion by someone.

You simply can't rationalize irrational things.

KodeZwerg, stop to be sarcastic as that lead nowhere. As a mathematician, I'm not aware of each stupidity is made following irrational things someone made. As I have said, I have always used TRect as a simple and logical container to simplify code.

Canvas.DrawRectangle (0,0,200,200);

or

r:= rect(0,0,200,200);
Canvas.DrawRectangle (r);

What is simpler?

Except rect is not what it should be by "convention" Total stupidity once again.