ImageDecoder itself can check the matrix coefficients and range flag
instead. In the future, ImageDecoder should probably convert its images
into RGB color space using the same solution as for video.
libavif outputs straight (unpremultiplied) alpha by default, but the
AVIF loader was creating bitmaps without specifying an alpha type,
which defaults to premultiplied. This mismatch caused semi-transparent
pixels to render incorrectly.
Pass AlphaType::Unpremultiplied explicitly, matching what the PNG,
WebP, and BMP decoders already do.
Instead of decoding all animation frames at once in decode_webp_image()
and caching them in frame_descriptors, decode frames one at a time
on demand. This avoids holding all decoded frames in memory at once.
The WebPAnimDecoder is kept alive across frame() calls and supports
reset for backward seeks (needed for animation looping).
Add a virtual method to query frame durations without decoding pixel
data. This is needed by the ImageDecoder service to extract timing
metadata upfront for streaming animation decode.
Implement the method for GIF, PNG, WebP, AVIF, and JPEGXL decoders.
For WebP, extract durations from the demuxer during header decode so
they are available before any frames are decoded.
The `Bitmap` type was referring to to its internal pixel format by a
name that represents the order of the color components as they are layed
out in memory. Contrary, the `Color` type was using a naming that where
the name represents the order of the components from most to least
significant byte when viewed as a unsigned 32bit integer. This is
confusing as you have to keep remembering which mental model to use
depending on which code you work with.
To unify the two, the naming of RGBA-like colors in the `Color` type has
been adjusted to match the one from the Bitmap type. This seems to be
generally in line with how web APIs think about these types:
* `ImageData.pixelFormat` can be `rgba-8unorm` backed by a
`Uint8ClamedArray`, but there is no pixel format backed by a 32bit
unsigned type.
* WebGL can use format `RGBA` with type `UNSIGNED_BYTE`, but there is no
such format with type `UNSIGNED_INT`.
Additionally, it appears that other browsers and browser-adjacent
libraries also think similarly about these types:
* Firefox:
https://github.com/mozilla-firefox/firefox/blob/main/gfx/2d/Types.h
* WebKit:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/PixelFormat.h
* Skia:
https://chromium.googlesource.com/skia/+/refs/heads/main/include/core/SkColorType.h
This has the not so nice side effect that APIs that interact with these
types through 32bit unsigned integers now have the component order
inverted due to little-endian byte order. E.g. specifying a color as hex
constant needs to be done as `0xAABBGGRR` if it is to be treated as
RGBA8888.
We could alleviate this by providing endian-independent APIs to callers.
But I suspect long-term we might want to think differently about bitmap
data anyway, e.g. to better support HDR in the future. However, such
changes would be more involved than just unifying the naming as done
here. So I considered that out of scope for now.
From what I can tell BMP files with an alpha channel always store
unpremultiplied alpha. So let's load them as such to avoid rendering
artifacts from using the wrong alpha type.
We should invert CMYK data only if color space is JCS_CMYK and either
there is no Adobe marker, or the Adobe transform is 0. Transform 2
indicates YCCK data, which we should not invert.
The decoder was requiring GIF files to be at least 32 bytes, but the
actual minimum for a valid GIF is only 26 bytes:
- 6 bytes for the header
- 7 bytes for the Logical Screen Descriptor
- 10 bytes for the Image Descriptor
- 2 bytes for the LZW minimum code size and block terminator
- 1 byte for the GIF trailer
This change allows us to load minimal 1x1 GIFs with empty LZW data.
They are commonly used on the web as transparent placeholders with
minimal file size.
As it turns out, SkPath already behaves the way we need for SVG and HTML
canvas elements. Less work for us, yay! This removes a 5% item from the
profile when scrolling on https://imdb.com/
Note that there's a tiny screenshot test expectation change due to
minor antialiasing differences when we no longer do our redundant
subpath modifications.
Gfx::Bitmap only supports a bit depth of 8, therefore we refused to
load AVIF images which didn't have this bit depth.
However, we can tell the libavif decoder to reduce the output depth by
setting avifRGBImage.depth to 8. This allows us to support any input
depth.
Makes images load on https://www.ikea.com/ which uses Cloudflare Images
to re-encode their images to 16-bit AVIF.
In the previous fix, we were still drawing IDAT data to the reference
frame even when no fcTL was present. This would cause rendering issues
when subsequent frames use APNG_BLEND_OP_OVER blending mode, as they
would composite over the incorrect reference frame. This commit adds a
simple check to properly skip any frame without an fcTL chunk.
We now properly handle OS/2 format BMPs that use 3 bytes per color
entry instead of 4. While OS/2 2.x officially specified 4 bytes per
color, some tools still produce files with 3-byte entries. We can
identify such files by checking the available color table space.
This extends ICO loader to support Windows cursor files. There is no
point in creating a separate loader for this, as the ICO format is
very similar to the CUR format. The only differences are bytes used to
identify the file and a presence of a hotspot in the CUR header.
Color masks should only be used when the compression type is either
BITFIELDS or ALPHABITFIELDS. They were always read before and produced
corrupted images when there was random data in the mask fields.
Other browsers don't think that BMP files with more than 1024 colors are
invalid. They clamp the palette instead, and now we do the same. This
allows us to load more BMPs.
Before this change, IDAT data was mistakenly always included in the
animation. Now we only include frames with explicit fcTL chunks.
As per the PNG spec (third edition):
"The static image may be included as the first frame of the animation
by the presence of a single fcTL chunk before IDAT. Otherwise, the
static image is not part of the animation."
We also fall back to the IDAT data when APNG has acTL but no fcTL
chunks. Test image is 062.png from fDAT-inherits-cICP.html from WPT.
GIF loader was completely failing when encountering errors with
frame descriptors or individual frames, even when some frames were
successfully loaded. Now we attempt to decode at least some frames
and fail only when no frames can be decoded at all.
This introduces a new API in ImageDecoderPlugins that allow an image
decoder to return a CICP struct. Also, we use this API in
ImageDecoder::color_space() to create a color space corresponding to
these CICP.
We have to be careful to always destroy the jpeglib decompression struct
before returning from JPEGLoadingContext::decode. We were doing this in
jpeglib error handlers, but we have a couple of paths that bail from the
decoder via TRY. These paths were neither cleaning up memory nor setting
the image decoder to an error state.
So this patch sets up a scope guard to ensure we free the decompressor
upon exit from the function. And it delegates the responsibility of
setting the decoder state to the caller (of which there is only one),
to ensure all error paths result in an error state.
If we have a valid PNG header with geometry info etc, we should still
display it as *something*, even if the image data itself is missing or
corrupted.
This matches the behavior of other browsers, and is something that
Cloudflare Turnstile checks for.
To achieve this, we split the PNG decoder's initialization into two
steps: "everything except reading frame data" and "reading frame data".
If the latter step fails, we yield a transparent bitmap with the
geometry from the PNG's IHDR chunk.
Before, libpng would use its own internal logging mechanism to print
non-fatal errors and warnings to stdout/stderr. This made it confusing
when trying to search the Ladybird codebase for those messages as they
didn't exist.
This commit uses `png_set_error_fn` from libpng to redirect those
messages to our own custom logging functions instead.
This patch introduces the `Gfx::ColorSpace` class, this is basically a
serializable wrapper for skia's SkColorSpace. Creation of the instances
of this class (and thus ICC profiles parsing) is performed in the
ImageDecoder process. Then the object is serialized and sent through
IPC, to finally be handed to skia for rendering.
However, to make sure that we're not making all LibGfx's users dependent
on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no
dependency on objects from Skia. To that end, the only member of the
`ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there
is on issue with that design, the code in `DisplayListPlayer.cpp` needs
access to the underlying `sk_sp<SkColorSpace>`. It is provided by a
template function, that is only specialized for this type.
Doing this work allows us to pass the following WPT tests:
- https://wpt.live/css/css-color/tagged-images-001.html
- https://wpt.live/css/css-color/tagged-images-003.html
- https://wpt.live/css/css-color/tagged-images-004.html
- https://wpt.live/css/css-color/untagged-images-001.html
Other test cases can also be found here:
- https://github.com/svgeesus/PNG-ICC-tests
Note that SkColorSpace support quite a limited amount of color spaces,
so color profiles like the ones in [1] or the v4 profiles in [2] are not
supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with
a linear conversion to XYZ D50.
[1] https://www.color.org/browsertest.xalter
[2] https://www.color.org/version4html.xalter
