Solved BGRABitmapTypes.BGRA() needs parameters reordered on Linux vs Windows

[Coxy]

As part of moving from Windows to Linux I'm porting my applications across. When porting a graphics application that takes pen input (mouse movement) I'm finding the RGBA parameters passed to BGRABitmapTypes.BGRA() need to have their Red and Blue parameters swapped to get correct colors.

I don't want to have my code festooned with,

Code: Pascal  [Select][+][-]

1. procedure SetBackgroundColor(pBackgroundColor:TBGRAPixel);
2. begin
3.   {$IFDEF UNIX}
4.     FBackgroundColor:=BGRA(pBackgroundColor.blue,pBackgroundColor.green,pBackgroundColor.red);
5.   {$ELSE}
6.     FBackgroundColor:=pBackgroundColor;
7.   {$ENDIF}
8. end;
9.  

Noticed in BGRABitmapTypes,

Code: Pascal  [Select][+][-]

1. const
2.   {$IFDEF BGRABITMAP_RGBAPIXEL}
3.   TBGRAPixel_RGBAOrder = True;
4.   TBGRAPixel_RedByteOffset = 0;
5.   TBGRAPixel_GreenByteOffset = 1;
6.   TBGRAPixel_BlueByteOffset = 2;
7.   {$ELSE}
8.   {** Order of the channels (when BGRA) }
9.   TBGRAPixel_RGBAOrder = False;
10.   {** Offset of the blue channel (when BGRA) }
11.   TBGRAPixel_BlueByteOffset = 0;
12.   {** Offset of the green channel (when BGRA) }
13.   TBGRAPixel_GreenByteOffset = 1;
14.   {** Offset of the blue channel (when BGRA) }
15.   TBGRAPixel_RedByteOffset = 2;
16.   {$ENDIF}
17.  

The correct byte offset for Linux is greyed out i.e. BGRABITMAP_RGBAPIXEL set.

BGRABitmap package was downloaded using Online Package Mangaer and IDE rebuilt with Normal profile.

Have I got my environment setup incorrectly or am I missing something? Everything worked on my computer when I had Windows installed.

My environment,

Computer: Lenovo Laptop
CPU: AMD Ryzen 7 5800H
GPU: RTX 3070

OS: Linux Mint 22.2 Zara

Lazarus IDE: 4.2
FPC: 3.2.2

bglcontrols.lpk: 1.2.0.0
bgrbitmappack.lpk: 11.6.6.0
bgracontrols.lpk: 9.0.2.0
bgrapascalscriptcomponent.lpk: 9.0.2.0

[Fred vS]

Hello.

From /bgrabitmap/bgrabitmap.inc:

Code: Pascal  [Select][+][-]

1. { You can define the following compiler directives in the package options,
2.   in tab Compiler options, in section Other. Directives must be prefixed with
3.   "-d". So for example:
4.  
5.   - to always have RGBA pixel format, write "-dBGRABITMAP_RGBAPIXEL"
6.   - to always have BGRA pixel format, write "-dBGRABITMAP_BGRAPIXEL"
7.   - to use fpGUI toolkit, write "-dBGRABITMAP_USE_FPGUI" }

So in your case, if you want to always have BGRA pixel format, add the parameter -dBGRABITMAP_BGRAPIXEL for compilation.

[Coxy]

Hi Fred,

This allows me to set/define BGRABITMAP_RGBAPIXEL but not unset it. It being set/defined is my problem.

Windows uses RGB while the Linux I'm using is BGR. Was hoping there was some code something like,

Code: Pascal  [Select][+][-]

1. {$IF DEFINED(UNIX)}
2.   {$DEFINE BGRABITMAP_BGRAPIXEL}
3. {$ELSEIF DEFINED(WINDOWS)}
4.   {$DEFINE BGRABITMAP_RGBAPIXEL}
5. {$ELSE}
6.     Not supported!
7. {$ENDIF}
8.  

Which would make it transparent to the programmer.

[Fred vS]

This allows me to set/define BGRABITMAP_RGBAPIXEL but not unset it. It being set/defined is my problem.

I'm not sure I understand, does your program sometimes use RGB and other times BGR in the same OS?

[Fred vS]

Also RGB or BGR does not depends on the OS but on the hardware, driver, and specific application.

[Coxy]

Hi Fred,

I have the same code running on Windows and Linux. On windows I make a call like,

Code: Pascal  [Select][+][-]

1.    FColor:=BGRABitmapTypes.BGRA(FRed,FGreen,FBlue);
2.  

Which does what I expect. If I compile and run it on Linux then color is incorrect and I have to change parameters to

Code: Pascal  [Select][+][-]

1.    FColor:=BGRABitmapTypes.BGRA(FBlue,FGreen,FRed);
2.  

To get same color as on Windows.

Now BGRABitmapTypes has code to handle this automatically using the color ByteOffet but its part of compilation of BGRABitmap package. BGRABitmap should be independent of RGB vs BGR environment, programmers just use RGB . But compilation is defining BGRABITMAP_RGBAPIXEL in my Linux BGR environment. Hence the problem.

I just want to know if I'm doing something stupid or if there is something needs changing.

[Thausand]

Was hoping there was some code something like,

Have read wiki:
- https://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options
- https://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_project_and_all_packages
- https://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Custom_Options
- https://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_one_package_without_altering_the_lpk_itself
etc.

[Thausand]

BGRABitmap should be independent of RGB vs BGR environment, programmers just use RGB.

Please have tell hardware/driver manufactor and OS developer, they make decide how is store pixels. BRABitmap now fast when make your wish then make slow(er) 

[Fred vS]

I did a try here on Linux Ubuntu 24.2 but all is ok with RGB for my system, so maybe you have a hardware/driver who prefers BGR.

What if you use a TBGRAPixel and compilation parameter "-dBGRABITMAP_BGRAPIXEL" on Linux for this:

Code: Pascal  [Select][+][-]

1. FBackgroundColor:=pBackgroundColor;

But yes, in this case, you need to remove the "-dBGRABITMAP_BGRAPIXEL" compilation parameter on Windows.

I'm not familiar with Lazarus, but perhaps it's possible to add conditional parameters.

[Coxy]

Hi Thausand,

Please have tell hardware/driver manufactor and OS developer, they make decide how is store pixels. BRABitmap now fast when make your wish then make slow(er)

I'm not saying that. I'm saying the abstraction layer BGRABitmap that's above hardware/driver manufacture and OS should hide implementation details. Exactly what Free Pascal does for CPU's and OS's.

The method signature for BGRABitmapTypes.BGRA() is,

Code: Pascal  [Select][+][-]

1.   function BGRA(red, green, blue: byte): TBGRAPixel; overload; inline;
2.  

Why would I have to, depending on environment, enter a blue value for the parameter named "red" and a red value for parameter named "blue"?

[Coxy]

Hi Fred,

I did a try here on Linux Ubuntu 24.2 but all is ok with RGB for my system, so maybe you have a hardware/driver who prefers BGR.

This may be the case, if this is so I would prefer BGRABitmap to have a soft switch to change between RGB and BGR rather than it being backed in at compile time.

[Fred vS]

Hi Fred,

I did a try here on Linux Ubuntu 24.2 but all is ok with RGB for my system, so maybe you have a hardware/driver who prefers BGR.

This may be the case, if this is so I would prefer BGRABitmap to have a soft switch to change between RGB and BGR rather than it being backed in at compile time.

Please create a issue (feature request) at https://github.com/bgrabitmap/bgrabitmap/issues, with the link of this forum topic.

[Coxy]

Hi Fred,

Please create a issue (feature request) at https://github.com/bgrabitmap/bgrabitmap/issues, with the link of this forum topic.

I'll wait for "circular"'s view on this before raising a feature/request. As I said earlier, I might be doing something stupid, not understanding how BGRABitmap works, it being a configuration problem or something needs changing.

A little more background may shed light on the problem.

1) I've created PNG files on windows using BGRABitmap that display colors correctly via OpenGL textures on Windows and Linux.

Code: Pascal  [Select][+][-]

1. { TTexture }
2.  
3. constructor TTexture.Create(pBitmap: TBGRABitmap;
4.   pTexMagFilter: TTexFilterType; pTexMinFilter: TTexFilterType;
5.   pTexWrapS: TTexWrapType; pTexWrapT: TTexWrapType);
6. begin
7.   Create(pBitmap.Width,pBitmap.Height,pTexMagFilter,pTexMinFilter,pTexWrapS,pTexWrapT);
8.  
9.   glActiveTexture(GL_TEXTURE0);
10.  
11.   glBindTexture(GL_TEXTURE_2D,Texture);
12.  
13. {$IF Defined(UNIX)}
14.   glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA8, pBitmap.Width,pBitmap.Height, 0, GL_BGRA, GL_UNSIGNED_BYTE, pBitmap.DataByte);
15. GL_UNSIGNED_BYTE, PInteger(pBitmap.DataByte));
16. {$ELSEIF Defined(Windows)}
17.   glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA8, pBitmap.Width,pBitmap.Height, 0, GL_BGRA, GL_UNSIGNED_BYTE, pBitmap.DataByte);
18. {$ELSE}
19.   Platform not supported!
20. {$ENDIF}
21. end;

2) PNG's created on Linux using BGRABitmap and displayed via OpenGL have red and blue channels swapped.

I'm just trying to identify what causes this behaviour and find possible solutions.

[Coxy]

Hi Fred,

My mistake in presenting this incomplete information.

As part of my debugging I pasted in the Windows code into Linux section and then tried this to see if it fixed the problem. Used code is,

Code: Pascal  [Select][+][-]

1. {$IF Defined(UNIX)}
2.   glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA8, pBitmap.Width,pBitmap.Height, 0, GL_BGRA, GL_UNSIGNED_BYTE, pBitmap.DataByte);
3.   //glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA8, pBitmap.Width, pBitmap.Height, 0, GL_BGRA, GL_UNSIGNED_BYTE, PInteger(pBitmap.DataByte));
4. {$ELSEIF Defined(Windows)}
5.   glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA8, pBitmap.Width,pBitmap.Height, 0, GL_BGRA, GL_UNSIGNED_BYTE, pBitmap.DataByte);
6. {$ELSE}
7.   Platform not supported!
8. {$ENDIF}
9.  

I removed the commented code in reply for brevity. But both Linux and Windows code sections have same effect.

As I said, I'm just looking for a solution to this problem.

Having changed GL_BGRA parameter to GL_RGBA, to glTexImage2D() call, in initial tests it's having corrective effect, but I need to do more testing, and will get back with results.

[Thausand]

The method signature for BGRABitmapTypes.BGRA() is,

Code: Pascal  [Select][+][-]

1.   function BGRA(red, green, blue: byte): TBGRAPixel; overload; inline;
2.  

Why would I have to, depending on environment, enter a blue value for the parameter named "red" and a red value for parameter named "blue"?

Quetzal 

Code: Pascal  [Select][+][-]

1. function BGRA(red, green, blue: byte): TBGRAPixel; overload;
2. begin
3.   LongWord(result) := (red shl TBGRAPixel_RedShift) or
4.                    (green shl TBGRAPixel_GreenShift) or
5.                    (blue shl TBGRAPixel_BlueShift) or
6.                    (255 shl TBGRAPixel_AlphaShift);
7. end;
8.  

If want change internal format runtime then is manual else depend how hardware/driver/os store bitmap internal. I write before so is repeat.

I think may be you have bgrabitmap install error. Choice type widget automake correct pixelformat when build bgrabitmap. When change type widget is need rebuild for package. I no write you have no issue, I write something gone wrong. Normal is work out of box as write you (build correct).

PS: I make wonder: This problem inline some time generate wrong code ?