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!
The conversion to AK::Stream makes everything much more straightforward
and understandable now, because we remove the custom reader we had.
Because AK::Stream is more tested, it means that the code should be now
more robust against bugs as well.
Currently, the `isobmff` utility will only print the media file type
info from the FileTypeBox (major brand and compatible brands), as well
as the names and sizes of top-level boxes.
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
