MRF: JPEG-XL (brunsli) support

[lucianpls]

What does this PR do?

brunsli (part of JPEG-XL) is an open source licensed lossless packer for JFIF files from Google.
The brunsli blobs are usually 22% smaller than the source JFIF JPEG on the average, while increasing the compression and decompression time. The source JFIF form is fully restored, thus brunsli requires only minor changes to the existing code and does not affect the image quality or any other JPEG features. It can only handle the most common 8bit JFIF format, but it does pass-through all JFIF chunk, brotli compressed.
This PR includes the changes to make the MRF driver capable of encoding and decoding tiles in the brunsli format, when the brunsli support is enabled. Since brunsli/brotli libraries are not usually available as packages, support for this feature has to be enabled manually at this point.

I intend to add a standalone JPEG-XL (brunsli for starters) driver shortly, with read/write capabilities.
I would appreciate any help or advice on adding brunsli/brotli libraries to the CI workflow so these changes can be fully tested.

What are related issues/pull requests?

Tasklist

• ADD YOUR TASKS HERE
• Add test case(s)
• Add documentation
• Review
• Adjust for comments
• All CI builds and checks have passed

Environment

Provide environment details, if relevant:

• OS:
• Compiler:

[rouault]

CC'ing @tbonfort

@lucianpls I wasn't aware of https://github.com/google/brunsli, but in https://github.com/rouault/gdal/commits/jxl I have preliminary work to use JPEG-XL as a TIFF codec, based on the https://gitlab.com/wg1/jpeg-xl implementation. I'm not completely clear if a google/brunsli blob is a valid JPEG-XL one ? It would be best to converge on a single JPEG-XL implementation for GDAL.

[lucianpls]

@rouault

Brunsli is a subset of JPEG-XL. JPEG-XL lite if you want.
From what I've read, brunsli output is a fully compliant JPEG-XL file, so at least there should not be format issues.
The brunsli has the advantage that it can be seen as a JPEG add-on, while the other features of JPEG XL are much more far reaching. It is very simple to change existing code that uses JPEG to accept brunsli, it is a pre-processing filter. That is not the case if the full JPEG XL is expected.

There is also the issue of dependencies. libbrunsli only depends on brotli, and even that dependency is non-essential and could be removed, although I'm not sure that it can be considered JPEG-XL in that case. The full JPEG XL code is much more complex AFAICT.

In general, I prefer the simplicity and clarity of brunsli over the full JPEG-XL. It does one thing and it does it well.

[tbonfort]

@lucianpls from a user's point of view, supporting brunsli requires bumping the gdal version and adding some new dependencies, whereas adding full jxl support requires bumping the gdal version and adding a different set of dependencies. Not very different in my book. The full jxl suite has some very attractive support for n>3 bands along with more than 8bit and lossless which rivals j2k, and should see mainstream support in distros, it would seem to be a pity to only support brunsli, even though it would mean more effort to implement in the mrf driver.

[lucianpls]

@tbonfort
Sure, both full JXL and the brunsli subset make sense.
Brunsli is an incremental JPEG optimization, easy to implement and very attractive by itself, especially for tile services. As you say, full JXL is a different compression, with it's own set of options.

[rouault]

@lucianpls What I would wish to avoid is to have both Brunsli and libjxl as dependencies of GDAL. Would it be possible to leverage libjxl to deal with the Brunsli payload for MRF ?

[lucianpls]

@rouault
I'm sure JXL includes brunsli as a dependency. So there should be no problem. In the worst case, these bits of code would only need a bit of tweaking to use the brunsli that comes with JXL instead of the stand alone, without any change in the user observable behavior. I need this capability now, no reason to wait as far as I can tell! I already have an apache httpd on-the-fly brunsli transcoder for tile serving.

[rouault]

I'm sure JXL includes brunsli as a dependency.

yes, seeing https://github.com/libjxl/libjxl/tree/main/third_party . But as far as I remember, the install of the JXL library doesn't make brunsli headers available. They're likely considered as an implementation detail

[rouault]

doc/source/drivers/raster/marfa.rst would probably need some updates too

[lucianpls]

doc/source/drivers/raster/marfa.rst would probably need some updates too

The MRF detailed documentation is in the MUG, the rst is just a pointer to that document. I will update the MUG to discuss the brunsli implications.

[SpaceIm]

BRUNSLI_LIB is super fragile:

• lib ordering is wrong: brotlicommon is a dependency of brotlienc and brotlidec, same for brunsli.

• Lib names of brunsli seem wrong: https://github.com/google/brunsli/blob/v0.1/brunsli.cmake#L50-L85. Installation of brunsli is not neat, but CMakeLists suggests it's always shared and lib names are brunslidec-c and brunslienc-c.

• brotli lib names are different if static (-static suffix)

[rouault]

we'll probably not put too much effort in autoconf support for Brunsli, but I've filed #5068 to add support for it to CMake builds

[lucianpls]

@SpaceIm

* Lib names of brunsli seem wrong: https://github.com/google/brunsli/blob/v0.1/brunsli.cmake#L50-L85. Installation of brunsli is not neat, but CMakeLists suggests it's always shared and lib names are `brunslidec-c` and `brunslienc-c`.

Those are for the C API, which is much more limited than the C++ one if I recall.

[SpaceIm]

I see, but it's worth noting that the very few package managers having this lib don't even package the static libs (C++), only the shared C lib. I don't know whether C++ headers are intended to be used by consumers (there is no install target nor API documentation so it's unclear, but at least the folder of C/C++ files is called c).
Anyway, static lib names have -static suffix as you can see in CMakeLists.