WEBP, no DLLs

[Tomxe]

https://github.com/Xelitan/Pure-Pascal-Webp-for-Delphi-Lazarus-Free-Pascal/

No encoding for now, sorry.

Add WebpImageX to your uses, then:

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

1. Image1.Picture.LoadFromFile('test.webp');

[AlexTP]

Thanks, it is useful, I asked for it in github and later I closed my request because some Pascal lib for WebP already exists. AI told me about it.

[Tomxe]

There are a few Pascal libs for Webp but they require DLLs

[AlexTP]

webpimageX.pas says:
> Target:   Win64, Free Pascal, Delphi       

Is it only Win64, or also other OS / bitness?

[Tomxe]

Should work on other OSes and on 32 bit, but it wasn't tested.

[CM630]

This is how it look like in Linux Mint mate in a VM:
In KUbuntu it looks the same.

[Tomxe]

This is how it look like in Linux Mint mate in a VM:
In KUbuntu it looks the same.

I added a switch to support Linux. Can you test?

[Thaddy]

Your decoder outputs BGRA but your Linux widget interprets it as RGBA. BGRA is correct.

[CM630]

...I added a switch to support Linux. Can you test?...

Linux Mint Mate on real and virtual HW, see the screenshot.

Also, I had to edit in WebpImageX.pas:

uses ...
     WebpDec,

to

uses ...
     WebPDec,

[Thaddy]

read my reply: on linux the deciding is wrong color order. That is all and needs fixing at the widget side.

Your decoder outputs BGRA but your Linux widget interprets it as RGBA. BGRA is correct.

Not a joke: the decoding is otherwise OK. He did a straight, correct, translation but the issue is Lazarus/Linux.

The correct order is taken from the image itself. That's why everybody else shows it ok, just not Lazarus/Linux. Any other main software recognizes the encoding correct on all platforms.

Just file a bug report. This is not his fault. On Windows it is fine, because it respects the specified order..

[dsiders]

Just file a bug report. This is not his fault. On Windows it is fine, because it respects the specified order..

Actually, it's a feature request... since WebP is not one of the image formats supported in LCL/TImage.

[Thaddy]

Fine with me. I just debugged it (and was "easy", but not for an hour of looking...)
BTW: the FPC decoding itself - also on Linux - is fine, the display error appears only higher up in the chain at the display level, so that is to me a bug...and not a feature. Otherwise Windows display would also fail.
I can't spend more time on it, but you can use that - I am sure it is correct - conclusion.

[Marc]

Just file a bug report. This is not his fault. On Windows it is fine, because it respects the specified order..

Actually, it's a feature request... since WebP is not one of the image formats supported in LCL/TImage.

Not really IMO. When using a "3rd party" decoder, a TImage should be able to display the data. However the decoded color bytes should be provided in the correct order. You can use TRawImage & co  to feed this to TImage.

[Tomxe]

There are thousands of programs written for Delphi that use Scanline. FPC/Lazarus tries to emulate Delphi. So I believe there should be an easy way to use Scanline for all platforms just like on Windows.
There could be a function TBitmap.FixScanlines that converts from Windows to whatever platform.

Anyway, I will try to make Webp work on other platforms.

[Thaddy]

scanline is not the issue. the order that the emulation of scanline under Linux does IS the issue.
I would not spend time on that since YOUR code is correct. Unless you want to debug scanline on linux....