ExifOrientedBitmap was implemented before the introduction of the TIFF
decoder. So we had to provide a definition of the Orientation enum. Now
that we have a TIFF implementation that comes with some enum
definitions, we should prefer this source.
Due to the way JPEG XL encodes its lossless images, it is sometimes
interesting to embed a large image and crop the result at the end. This
patch adds the functionality to crop a frame.
Note that JPEG XL supports image composition (almost like layers in
image editing software programs) and I tried to make these changes be
a step toward image composing. It's a small step as we are still unable
to read multiple frames, and we only support the `kReplace` blending
mode.
The image was previously managed as an output parameter of the
`read_frame` function. This reorganisation also brings us closer to the
spec. As it is specified that each frame have its own image that will
later on compose a greater bitmap.
While being way less frequent than for classical JPEG images, JPEG XL
images can use the YCbCr color space. Supporting it makes us properly
decode the "The Smoke Machine" image on https://jpegxl.info/jxl-art.html
On top of the Brotli/ANS compression, the entropy stream can have
another compression layer, this time using LZ77. This patch adds support
for this last layer, which makes us decode the `lz77_flower` test. This
double-compression is also often used for ICC profiles.
Since the introduction of the JPEG XL decoder, we always read the
`orientation` field in the `ImageMetadata` bundle. This patch allows us
to render the bitmap accordingly to this transformation.
We don't do anything particular with images that contain a custom
ColourEncoding yet, but at least it allows us to know how to decode the
metadata of such images.
Complex distribution - distributions that are encoded using an internal
symbol decoder with a single distribution, are very often used for lz77
compressed images. This is a requirement for the lz77_flower test case.
This type of cluster is an exception and has specific rules (but
simpler) to be read. This is a requirement to support complex
distributions as they use a symbol decoder initialized with a single
distribution.
This allows us to read many more images. This decoder is one of the two
possibilities (along Brotli) that can be used for modular images. All
the logic is directly taken from the spec.
One of the image that can now be decoded is "Lucifer's Dominion:
Synthesis" that can be found on `https://jpegxl.info/art/`, it also
makes us pass one more test of the conformance test suite, namely
"alpha_triangles".
JPEG XL supports two types of entropy encoding: the first one is
Huffman-based (Brotli) and the second one is based on ANS. To introduce
the latter, we start by storing the `Vector` of distributions in a
`Variant`. This will allow us to choose which entropy decoder we use
during execution.
This predictor is much more complicated than the others. Indeed, to be
computed, it needs its own value but for other pixels. As you can guess,
implementing it involved the introduction of a structure to hold that
data.
Fundamentally, this predictor uses the value of the error between the
predicted value and the true value (aka decoded value) of pixels around.
One of this computed error (namely max_error) is used as a property, so
this patch also solves a FIXME in `get_properties`.
To ease the access to value that are close in the channel and moving
their values around, this patch adds a `Neighborhood` struct which holds
this data. It has been used in `prediction()` and it allowed to simplify
the signature and to remove the explicit retrieval of the underlying
data.
All this work allows us to decode the default image that appears when
loading `https://jxl-art.surma.technology`. However, we still render it
incorrectly due to the lack of support for orientation values different
from 1.
The first implementation of this property was just plain wrong. Looks
like this property isn't used a lot as I found the issue by reviewing
the code and not because of a specific image.
The test image is a 32x32 mosaic of alternating black and yellow pixels,
it was generated using this code:
Bitdepth 8
RCT 1
Width 32
Height 32
if W-WW-NW+NWW > -300
- Set -1000
- Set 900
Now that we are able to read extra channels, it's time to include them
in the final bitmap. They are usually at a smaller resolution than the
final bitmap and the first step to render them is upscaling. Luckily,
this is not necessary for rendering the `alpha_nonpremultiplied` case of
the conformance test suite, so, as usual, I implemented this rendering
function as a check + no-op.
Then, we simply test if an alpha channel is present and emit the
corresponding data when creating the bitmap.
Finally, it means that we are now capable of rendering images with a
full size alpha channel, like `alpha_nonpremultiplied`. In other words,
we now successfully decode one of the image of the official test suite!
As a quick and dirty implementation, we used to assume that the final
image was always composed of three channels of the same size. However,
JPEG XL has support for more than three channels and extra channels can
have a smaller size. With this patch, we now create the image with the
correct number of channel and with their respective sizes.
Thanks to previous patches, everything used in `read_frame_header`
supports extra channels. The last element to achieve the read of headers
of frame with extra channels is to add support in the function itself
and the `FrameHeader` struct, which that patch does.
This implementation is not feature complete yet as it only supports
channels with a type different of `ExtraChannelType::kAlpha`.
This patch also introduces the `read_enum` function.
There is always a section for HfGlobal, even if it's empty like with
Modular images.
I also removed the outdated (and misinterpreted) spec comment and
replace it with the name of the section.
The computation was copied from the spec, but I forgot that they mention
that every "/" should be performed without truncation or rounding. Let's
use `double`s instead of integers.
I recently discovered a bug when we count the number of LfGroups, and it
turns out that this number can't be null. So that means that we need to
support reading them. The trick is that we only have support for images
that contains an empty LfGroup, so this patch implement a dummy reader
that just check that we are indeed facing an empty one and `TODO()`
otherwise.
During the original implementation, I mixed the condition for
`save_before_ct` and the one for `save_before_ct`, resulting in a bogus
code. That's fixed now!
There was a confusion between both `BitmapDecoded` and `FrameDecoded`
states. Removing one of them, solves the issue.
This patch removes the crash caused by requesting the same frame twice.
The original image this decoder was written for has a single PassGroup,
so applying transformations after each PassGroup or after all of them
was equivalent. This patch fix the behavior for images with 0 or more
than one PassGroup.
All the logic is exactly the same as for x2 upsampling, so this commit
essentially boils down to adding arrays for default weights and the
logic to select the correct array.
This is something I missed when I ported the JPEG XL decoder to the new
plugin interface (decoding the header at creation). First sorry because
that's entirely my fault, second sorry because a test should have caught
that.
Instead of rejecting them, we truncate each value to 8 bits. This is
clearly a hack, but given the lack of support of variable bit-depth in
`Bitmap` this is the only sensible change.
This allows us to display "Iceberg" on https://jpegxl.info/art/.
JPEG-XL is a new image format standardized by the same committee as the
original JPEG image format. It has all the nice feature of recent
formats, and great compression ratios. For more details, look at:
https://jpegxl.info/
This decoder is far from being feature-complete, as it features a grand
total of 60 FIXMEs and TODOs but anyway, it's still a good start.
I developed this decoder in the Serenity way, I just try to decode a
specific image while staying as close as possible to the specification.
Considering that the format supports a lot of options, and that we
basically support only one possibility for each of them, I'm pretty sure
that we can only decode the image I've developed this decoder for.
Which is:
0aff 3ffa 9101 0688 0001 004c 384b bc41
5ced 86e5 2a19 0696 03e5 4920 8038 000b
