Support for JPEG XL (JXL) images - #3153
Conversation
Implementation of ac_strategy.h and ac_strategy.c
For now JxlMemoryManager will be a wrapper around MemoryPool<T>.
Implementation of image.h and image.c; AC strategy implementation was slightly adjusted to reduce errors.
This is an implementation of field_encodings.h. Note that I avoided implementing EnumValid() and Values() functions, as we have dedicated methods in .NET to do exactly that (Enum.IsDefined, Enum.GetValues)
Implementation of spline.h
Implemented ANS constants
|
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. |
See ans_common.h
It is too large for a struct.
See ans_common.h
Add JxlAnsEntry and JxlAnsSymbol. See ans_common.h. These correspond to the Entry and Symbol structures within AliasTable.
Currently, there's a VarLenUint8/VarLenUint16 as well as histogram parsing implementation. I will additionally have to implement parsing of ANS codes, uint config and LZ77 parameters.
| /// <summary> | ||
| /// Quantization values | ||
| /// </summary> | ||
| public InlineArray64<int> Values; |
There was a problem hiding this comment.
This struct will be quite big with > 256 bytes in size. Maybe a class is better here (for the JpegQuantizationTable). Depends on the usage though, at least copying the struct should be avoided.
This isn't a decoder or encoder. It's just a parser/writer so the codec can take some quantization parameters from a JPEG file, as JPEG and JPEG XL are very similar.
…ise encoder tools, and complete render pipeline EPF 0 stage Files implemented: - enc_gaborish.cc - enc_gaborish.h - enc_gamma_correct.h - enc_huffman.cc - enc_huffman.h - enc_huffman_tree.cc - enc_huffman_tree.h - enc_noise.cc - enc_noise.h - render_pipeline/stage_epf.cc - render_pipeline/stage_epf.h
1. Reorder the overflow check in JpegData 2. Prefer switch in JpegData instead of multiple if statements 3. Don't explicitly false initialize acOk and dcOk in JpegData (they're already initialized to false). 4. IFjxlFrameInputSource -> FjxlFrameInputSource (it's an abstract class, I prefix is for interfaces) 5. Document that the JxlSqueeze.Average method is specific to the squeeze transform. 6. Prefer RuntimeUtility.Swap over tuple-based swap (micro-optimization)
- Use double for Clamp - Avoid bounds check in while loop
…nder pipeline stages
| public static float RatioOfDerivativesOfCubicRootToSimpleGamma(float v, bool invert = false) | ||
| { | ||
| float epsilon = 1e-2f; | ||
| v = Math.Max(0, v); // cannot be < 0 |
There was a problem hiding this comment.
Instead the comment use a debug guard?
There was a problem hiding this comment.
The Math.Max call limits the v variable so it can't be below 0 (and if it is, it gets set to 0), the comment just explains what that line does.
There was a problem hiding this comment.
Ey shame on me that I didn't read it this way. W/o the comment it would be more obvious (at least for me), so I'd drop the comment here.
| continue; | ||
| } | ||
|
|
||
| Vector256<float> vsm = Vector256.Create((ReadOnlySpan<float>)sadMul[ix..]); |
There was a problem hiding this comment.
What's when Vector256 isn't supported?
When it's guarded / checked at the call-site, then add a debug guard in this method to claim that Vec256 is supported.
There was a problem hiding this comment.
EPF stages operate at a fixed-size lane of 8 floats per iteration (in reference), and I decided to use Vector256 for this.
That being said, if the CPU doesn't support 256-bit vectors, it shouldn't fail - the JIT will just separate it into halves (if 128bit vectors supported), quarters (if 64bit vectors supported), or scalar (when no SIMD support). For example, my CPU (x86-64) supports vector instruction sets up to AVX2 (which is 256-bit), yet I can still use 512-bit vectors just fine.
There was a problem hiding this comment.
Yep, and the JIT may emit software fallback code (which is in it's nature slower).
In order to keep the code clean, your approach is fine.
For tests / CI care has to be taken that these code pathes are also executed when no HW-acceleration is available, etc.
Further an explicit code path for Vec128 (for arm and wasm) can be added later on (if benchmarks show it's necessary).
There was a problem hiding this comment.
I think I can use Vector<T> here actually, with minor changes. I'll just need unit tests to ensure that changing it doesn't break stuff, which we don't have yet (the codec isn't ready for tests at the moment). I'll look into using Vector<T> instead of Vector256 when we have working JPEG XL tests set up.
| ref Vector256<float> B, | ||
| ref Vector256<float> w) | ||
| { | ||
| Vector256<float> cx = Vector256.Create((ReadOnlySpan<float>)rows[0][1 + row][x..].Span); |
| { | ||
| int channels = 3 + extraChannelInfos.Count; | ||
|
|
||
| Span<Memory<float>> rowPtrs = new Memory<float>[channels]; |
There was a problem hiding this comment.
Can the array allocation be avoided?
There was a problem hiding this comment.
Unfortunately I wasn't able to remove the array allocation. Trying to stackalloc a Memory gives error CS0208: Cannot take the address of, get the size of, or declare a pointer to a managed type ('Memory<float>').
That being said, the allocation should be very small - should be < 10 items.
There was a problem hiding this comment.
Actually, I'll consider using an InlineArray10 with a separate length variable once I implement AddOneRow to JxlPatchDictionary. That should remove the allocation. 💡
|
|
||
| namespace SixLabors.ImageSharp.Formats.Jxl.Processing.RenderPipeline; | ||
|
|
||
| internal sealed class WriteToOutputStage |
There was a problem hiding this comment.
Is there something missing?
All the members are private and so unused at the moment.
Maybe this comment is just a reminder 😉.
There was a problem hiding this comment.
Yup, it's incomplete.
The write to output stage in reference had a lot of pointer-heavy code which I found more difficult to port to managed C# compared to other stages. So I implemented a few simple methods and saved this progress for later.
Probably will get back to it today.
Prerequisites
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.
Implementations
The JPEG XL codec lives under
src/ImageSharp/Formats/Jxl.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.