Lazarus
Programming => Graphics => Graphics and Multimedia => BGRABitmap and LazPaint => Topic started by: Boleeman on February 08, 2025, 04:12:43 am
-
Made possible by Tomxe, from Poland. Horray !
I came across the FLIF lossless image format here:
http://flif.info/
and
https://github.com/dlemstra/FLIF
Does stationary pictures as well as animated ones.
Perhaps try the animations at https://uprootlabs.github.io/poly-flif/ by selecting Images, Animations, Train or Pyani
It outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio.
FLIF is a lossless image format based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is a variant of CABAC (context-adaptive binary arithmetic coding), where the contexts are nodes of decision trees which are dynamically learned at encode time.
FLIF supports a form of progressive interlacing (essentially a generalization/improvement of PNG's Adam7) which means that any prefix (e.g. partial download) of a compressed file can be used as a reasonable lossy encoding of the entire image.
A GUI can be downloaded here:
http://flif.info/UGUI_FLIF/
An online FLIF and PNG comparison can be found here:
https://uprootlabs.github.io/poly-flif/
Depending on the Truncation slider value, the file size of the compressed file can be made smaller.
Mentioned:
FLIF development has stopped since FLIF is superseded by FUIF
https://github.com/cloudinary/fuif
FUIF stores pixels and the metadata needed to render the image
FUIF can do more than just what JPEG can (for example you can add an alpha channel to an existing JPEG)
FUIF does support simple 'filmstrip' animation, so it can be used to recompress GIF and APNG.
FUIF is optimized for delivery, not storage. It is progressive / "responsive by design". One single file can be used instead of having to downscale a high-resolution original to various target resolutions. The bitstream does not require seeking and a meaningful placeholder/preview can be shown from the first few hundred bytes.
Wondered if this image format (FLIF or FUIF) could possibly be added to Bgrabmp?
I used https://github.com/FLIF-hub/UGUI_FLIF/releases/download/v0.3.5/UGUI_FLIF_0.3.5-win.zip
I also tried the FileMill version at https://github.com/FileMill/FLIF-GUI/releases/download/0.3/FLIF-GUI.0.3.Setup.exe
(This FLIF-GUI.0.3 64-Bit Binary has different settings for the compression so I got a smaller 240kB filesize)
The original test compression of a 1100 px x 800 px fractal tree png picture.
Here are the results:
Preview and Convert FLIF files.
testmepng.png selected
Output Comparison
Input testmepng.png 309244 bytes
Output testmepng.flif 260280 bytes
84.16% of original 48964 bytes saved
-
The first sentence on the website says "FLIF development has stopped since FLIF is superseded by FUIF and then again by JPEG XL" and I've never come across a FLIF image file, so I can't see a good reason for taking the trouble. That's not to say the image format isn't without merit, but we seem to still be stuck with early-'90s image formats largely. PNG is more recent, but I've been using that for 20+ years already.
I do wish we could get further with modernizing our image formats, but the nature of the modern Internet makes it all but impossible by now. The current situation is a mess.
-
https://forum.lazarus.freepascal.org/index.php/topic,70167.0.html
-
Tomxe from Poland, just amazing.
Thank you for helping out and making it possible to use the Flif format in Lazarus.
I made a sample test program to load Flif, png, bmp, jpg
and
then save to Flif with compression loss amount.
Copy all the files from the https://github.com/Xelitan/FLIF-for-Delphi-Lazarus into the Project folder and then compile.
I used the 32-Bit version.
I see that the Transparency is not implemented, but the main part is working well.
procedure TFlifImage.SetTransparent(Value: Boolean);
begin
//
end;
Once again Tomxe, thanks for your great help in making FLIF possible in Lazarus.
I also went to your http://xelitan.com/ website and saw that you have made some really nice software.
Especially like the raster to vector image converters.
-
I am glad you like it!
-
It is generally ok to add suport for a new format. However, it relies on an external library, here compiled on Windows. BGRABitmap is supposed to work at least on Windows, Linux and MacOS. So if someone desires so, they could provide units for readers/writers, as it has been done for AVIF and Webp. It would need to:
- handle the dependencies and various versions of the library on Linux and MacOS
- provide the binaries for 32 and 64 bit for Windows
So that's not trivial and as it has been integrated into JPEG XL, it would be worth considering this option instead. What has been demonstrated here with FLIF shows us the wonderful potential of this new technologie. Adding support for JPEG XL would help make it more widespread.
Currently, WebP is widely used in websites. While AVIF has a tiny usage (stats (https://w3techs.com/technologies/overview/image_format) of 2022). However JPEG XL looks promising with amazing speed and compression so it may become more widespread.
-
The advantage of using FLIF and FUIF Formats was that the file could be viewed even if the full file has not been fully downloaded. I was pleasantly surprised by the quality of the FLIF image (storing the same png image but with less size and lossless compression). Sort of reminds me of the old RLE lossless compression, but more high tech.
With TBgrabmp, I agree with Circular that it is really advantageous to have it working for multiple platforms (Windows, Mac, Linux) without the need for extra dlls. Perhaps maybe those dlls might become standard dll's for future Windows/MacOS platforms?
I went to the Githib site for the JPEG XL Image Coding at https://github.com/libjxl/libjxl for the releases.
Also the blurb at https://jpeg.org/jpegxl/ says:
Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. Existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size. These can be restored into the exact same JPEG file, ensuring backward compatibility with existing JPEG-based applications. It supports wide colour gamut as well as high dynamic range and high bit depth images. JPEG XL further includes features such as animation, alpha channels, layers, thumbnails, lossless and progressive coding.
Sounds quite amazing (Jpeg with alpha and getting losslessly transcoding with a significant reduction in file size).
I wonder if Tomxe is possibly able to make a read/write Windows port of JPEG XL to Lazarus/Delphi?
-
With TBgrabmp, I agree with Circular that it is really advantageous to have it working for multiple platforms (Windows, Mac, Linux) without the need for extra dlls. Perhaps maybe those dlls might become standard dll's for future Windows/MacOS platforms?
Bgrabitmap also needs DLLS/SO files to read/write WEBP and AVIF.
But there is a way to hide DLL in an EXE's resources and use without unpacking to disk, at least on Windows.
I wonder if Tomxe is possibly able to make a read/write Windows port of JPEG XL to Lazarus/Delphi?
I'll look into it :)
-
I am really impressed Tomxe with your skills, as you are great in binding c++ coded programs to Lazarus.
I was going to "play around with your Github codes" to see how you did your porting and try to get some more experience with binding C++ codes with Lazarus.
I have played around with a few CSharp codes but my knowledge of C and C++ is a bit limited.
The old Codeproject site had some great graphics C++ codes, which I downloaded but never got to play around with.
Perhaps i need to start playing with C++ a bit more to learn to integrate it with Lazarus.
Thanks Tomxe for helping out and providing your excellent codes.
-
Thank you for kind words.
Here's a reader of JPEG XL files:
https://github.com/Xelitan/JPEG-XL-reader-for-Delphi-Free-Pascal-Lazarus/
Tested on 64 bit Lazarus. I uploaded 32 bit DLLs but didn't test them yet.
-
As always Tomxe, many thanks for the reader of JPEG XL files.
Noticed that JPEG-XL-reader-for-Delphi-Free-Pascal-Lazarus has jxl_jni.dll in 64bit dll folder but this is not in 32bit dll folder.
Is this also needed for 32bit compiling?
I have been busy chopping down trees where I live in the Aussie heat, so sorry for replying a bit late.
With the "FLIF-for-Delphi-Lazarus" I tested out the 32bit version with your original version and it worked well at loading and saving. So on the Github page "Needs tests under 32 bit Lazarus" = works well for saving and loading to stationary FLIF pictures.
Not sure if you included saving to animated pictures ?
Thank you once again Tomxe.
-
I don't think jxl_jni.dll is needed in either 64 or 32 bit mode.
Animations are not supported yet. I don't know how to approach them. There doesn't seem to be any standard way to handle animations in Delphi or Lazarus.
Thanks, I'll update FLIF page.
-
Thanks Tomxe for that info.
Found a github page with test JPEG XL images at https://github.com/alistair7/jxl-community.github.io/tree/main
(file is 348 Mb)
Also found:
JPEG XL Image Loader for imlib2
This is a loader for imlib2 that adds support for reading and writing JPEG XL files.
Windows/Linux releases here: https://github.com/libjxl/libjxl/releases/
from the page https://github.com/alistair7/libjxl
To encode a source image to JPEG XL with default settings:
cjxl input.png output.jxl
To decode a JPEG XL file run:
djxl input.jxl output.png
That Github page says:
When possible, cjxl/djxl are able to read/write the following image formats: OpenEXR (.exr), GIF (.gif), JPEG (.jpg/.jpeg), NetPBM (.pam/.pgm/.ppm), Portable FloatMap (.pfm), PGX Test Format (.pgx), Portable Network Graphics (.png), Animated PNG (.png/.apng), and JPEG XL itself (.jxl).
Also found:
Jpegli: an improved JPEG encoder and decoder implementation
The development of jpegli, the improved JPEG encoder and decoder, will continue at https://github.com/google/jpegli
This repository contains a JPEG encoder and decoder implementation that is API and ABI compatible with libjpeg62.
https://github.com/google/jpegli
Info from the page: https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html
Jpegli is a new JPEG coding library that is designed to be faster, more efficient, and more visually pleasing than traditional JPEG. It uses a number of new techniques to achieve these goals, including:
It provides both a fully interoperable encoder and decoder complying with the original JPEG standard and its most conventional 8-bit formalism, and API/ABI compatibility with libjpeg-turbo and MozJPEG.
High quality results. When images are compressed or decompressed through Jpegli, more precise and psychovisually effective computations are performed and images will look clearer and have fewer observable artifacts.
Fast. While improving on image quality/compression density ratio, Jpegli's coding speed is comparable to traditional approaches, such as libjpeg-turbo and MozJPEG. This means that web developers can effortlessly integrate Jpegli into their existing workflows without sacrificing coding speed performance or memory use.
10+ bits. Jpegli can be encoded with 10+ bits per component. Traditional JPEG coding solutions offer only 8 bit per component dynamics causing visible banding artifacts in slow gradients. Jpegli's 10+ bits coding happens in the original 8-bit formalism and the resulting images are fully interoperable with 8-bit viewers. 10+ bit dynamics are available as an API extension and application code changes are needed to benefit from it.
More dense: Jpegli compresses images more efficiently than traditional JPEG codecs, which can save bandwidth and storage space, and speed up web pages.
Looks like they are always making changes and updating.
-
Jpeg li is just improved jpeg encoder/decoder.
I think more interesting is Lepton. It's on my Github and there's a post here, on the forum.
-
Yes Tomxe, I downloaded all your new additions from Github. Can't wait to try them all out. I will also try your Lepton version.
Not sure why .... but:
I tried making a test program for reading JPeg XL under Win64bit, but just get endless debugging with no form shown.
Not sure why? I am using Lazarus 64 bit V2.2.6 on Windows 10.
It seems to happen when I add JxlImage.pas to the project using Project Inspector and when I add JxlImage to uses.
I have all the 64bit dll files in the compile folder as well as the test image.
Source is attached below.
Would you possibly have a working Lazarus Reading JPeg XL under Win 64bit test program?
-
Actually, when I click and run the compiled 64bit windows exe it shows the test Jpg XL Image, but I still get an endless debug when compiling without the Form showing.
I needed to reset the debugger to get out of compilation mode in Lazarus.
With the previous V1 attachment JPeg XL 64Bit read test.zip there was also a invalid buffer load error.
Not sure, but there maybe some variation in the format of the JPeg XL test images.
-
Tomxe, I think the compiling problem in Windows 10 Lazarus 64bit was with the dll files from your Github page.
I replaced them with the dll files from
https://github.com/libjxl/libjxl/releases/download/v0.11.1/jxl-x64-windows.zip
and added the libjxl.dll from your github page
and now the test code compiles well in the Lazarus IDE and shows the test form and loads the test image.
-
That's weird. Those DLLs work just fine for me under 64 bit Windows 10. Can you send your JPEG XL file?
-
Attached is the Jpeg XL picture file that gives an invalid buffer size error when loading.
I am using 64 bit Windows 10 and Lazarus 64bit compile on a Dell AMD A9 cpu laptop.
I got the image file from the Github example files located at
https://github.com/alistair7/jxl-community.github.io/tree/main
Also noticed looking at the releases from https://github.com/libjxl/libjxl/releases/
it seems there have been quite a few Huffman lookup table size fixes.
Perhaps these continual fixes have changed the file format slightly to cause the invalid buffer size error?
I also attached a Lazarus test program for that buffer size error.
Also found that the original dlls from your github repo is for some reason now compiling and showing the form
yet yesterday it was stuck in continual debug mode, without the form popping up. Go figure. I don't know why?
-
Maybe that's an antivirus problem, interfering with debugging.
-
Not sure if antivirus is the source of the problem Tomxe so I will try out JPeg XL on a few other laptops to see if it works correctly on them.
Also thought that perhaps some component or driver may have not been installed correctly.
Seemed strange that after I replaced the dlls that both Lazarus sources of JPeg XL worked to compile and load "test.jxl".
I still get that "invalid buffer size error" when trying to load the picture file "Background-hologram.jxl"