FLIF and now JPeg XL Done by Tomxe

[Boleeman]

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

[hukka]

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.

[Tomxe]

https://forum.lazarus.freepascal.org/index.php/topic,70167.0.html

[Boleeman]

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.

[Tomxe]

I am glad you like it!

[circular]

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 of 2022). However JPEG XL looks promising with amazing speed and compression so it may become more widespread.

[Boleeman]

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?

[Tomxe]

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

[Boleeman]

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.

[Tomxe]

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.

[Boleeman]

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.

[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.

[Boleeman]

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.

[Tomxe]

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.

[Boleeman]

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?