Support for JPEG XL (JXL) images

[winscripter]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

This is a work-in-progress PR whose goal is to introduce decoding and encoding of JPEG XL (*.jxl) images.

Reference software
I use libjxl as reference. See https://github.com/libjxl/libjxl.

Performance
I will begin by applying light optimizations as I implement parts of the JPEG XL codec. Once the codec seems complete enough to handle decoding and encoding of JPEG XL images, I will apply heavier optimizations. Examples include but are not limited to stack allocation, array pooling, and SIMD.

Other components
The JPEG XL codec, additionally, uses the LZ77 and Brotli compression codec. I will also have to implement those eventually.

Implementations
The JPEG XL codec lives under src/ImageSharp/Formats/Jxl.

Brotli and LZ77 implementations will live under src/ImageSharp/Compression.

Testing
I will start adding tests whenever the codec is complete enough to handle decoding of JPEG XL images.

Additionally, JPEG XL reference software, libjxl, contains its own tests too, which I might also implement without modification.

[CLAassistant]

All committers have signed the CLA.

[winscripter]

While I'm working on this, I'd like to note something important.

Libjxl is licensed under the BSD 3-Clause license, and since I'm using libjxl code as reference, that means the license must be included.

I'm not really sure what would be the proper way to include the license. I might place the LICENSE.txt file in the Jxl folder or add a README linking to the libjxl repo.

[JimBobSquarePants]

Just to note. We don't use Debug.Assert in this codebase. We have explicit DebugGuard APIs instead

[winscripter]

In some cases DebugGuard feels too limiting.

For example, in the following condition:

JXL_DASSERT(!extension_states_.IsBegun() || extension_states_.IsEnded());

I'd have to write:

DebugGuard.IsTrue(!this.extensionStates.IsBegun || this.extensionStates.IsEnded);

where it expects a parameter name, which doesn't fit because 1. it's not a parameter (but a property) and 2. there are multiple properties involved in the assertion.

Any ideas?

[winscripter]

Sorry I didn't get it right - the second parameter is a message, not the parameter name.

Would DebugGuard.IsTrue(false, "message") be considered a good replacement for Debug.Fail?

[JimBobSquarePants]

Thanks @winscripter I really appreciate you attempting this.

Examples include but are not limited to stack allocation, array pooling, and SIMD.

On a performance note. I think it would be best if you use these immediately as that can affect design. Any new code should also reuse utility components already available in the library where possible.

In addition, I normally document internal type as well as public types. This stuff is tough and every little helps.

[winscripter]

@JimBobSquarePants The examples I mentioned were the aggressive performance optimizations that I'd apply when the implementation can encode and decode images properly. I'd prefer not to apply them just yet, because in that case, the optimizations may introduce bugs that would later be difficult to diagnose while the implementation isn't fully complete.

I do consider applying light optimizations right now, e.g. using spans, pooling arrays with Configuration.MemoryAllocator.Allocate, inlining attributes, moving checks to debug assertions, etc. These optimizations don't largely differ from the reference implementation, so if things go wrong, I can compare my implementation with the reference implementation and spot the issue easily.

I'd consider documenting the internal stuff, but it might be easier said than done, because not all things in libjxl source are documented.