This is a simple container for 2d CMYK data.
This is a new class instead of a new format in Bitmap because:
* Almost all clients of Bitmap will want to deal with RGB data
* It keeps the ARGB32 typedef working
* Bitmap already does a lot of things
The idea is that a few select places will be able to use
CMYKBitmap and a color profile to do a better CMYK -> RGB conversion
than an image decoder could do, and then store the result in a Bitmap
for later display then.
CMYKBitmap misses some of Bitmap's features, such as shared
memory support, high-dpi scaling capability, etc.
Some apps seem to generate malformed images that are accepted
by most readers. We now only throw if malformed data would lead to
a write outside the chunky buffer.
Instead of assuming that the first font in the cascade font list will
have a glyph for space, we need to find it in the list taking into
account unicode ranges.
Some tags have a default value, we should return this value in
Metadata's getters when no value has been read from the input file.
Note that we don't support default values for tags with a count bigger
than one.
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.
When using the BMP encoding, ICO images are expected to contain a 1-bit
mask for transparency. Regardless an alpha channel is already included
in the image, the mask is always required. As stated here[1], the
mask is used to provide shadow around the image.
Unfortunately, it seems that some encoder do not include that second
transparency mask. So let's read that mask only if some data is still
remaining after decoding the image.
The test case has been generated by truncating the 64 last bytes
(originally dedicated to the mask) from the `serenity.ico` file and
changing the declared size of the image in the ICO header. The size
value is stored at the offset 0x0E in the file and I changed the value
from 0x0468 to 0x0428.
[1]: https://devblogs.microsoft.com/oldnewthing/20101021-00/?p=12483
This is enough to make these work:
for f in VideoHD VideoNTSC VideoPAL; do
Build/lagom/bin/icc --debug-roundtrip \
~/Downloads/Adobe\ ICC\ Profiles\ \(end-user\)/RGB/$f.icc
done
It's also possible to convert images to those color spaces:
Build/lagom/bin/image -o image-pal.png \
--convert-to-color-profile path/to/RGB/VideoPAL.icc \
image-srgb.png
(If there's no png file with an embedded sRGB profile at hand, do first:
Build/lagom/bin/icc --reencode-to serenity-sRGB.icc -n sRGB
Build/lagom/bin/image -o image-srgb.png \
--assign-color-profile serenity-sRGB.icc image-no-color-space.png
)
In color-managed viewers, images-srgb.png and image-pal.png should
look identical.
But if you either explicitly assign the sRGB profile to the pal
image, or strip the embedded color space, they'll look different
(since image viewers then assume the image in the VideoPAL space
is in sRGB):
Build/lagom/bin/image -o image-pal-strip.png --strip-color-profile \
image-pal.png
Build/lagom/bin/image -o image-not-actually-srgb.png \
--assign-color-profile serenity-sRGB.icc image-pal.png
We were trying to read exactly 5 pairs for some reason, instead of the
number specified by the format 0 header.
Fixing this makes "OpenSans Condensed" load on my machine.
This fixes an issue where GIF images without a global color table would
have the first segment incorrectly interpreted as color table data.
Makes many more screenshots appear on https://virtuallyfun.com/ :^)
TIFF files are made in a way that make them easily extendable and over
the years people have made sure to exploit that. In other words, it's
easy to find images with non-standard tags. Instead of returning an
error for that, let's skip them.
Note that we need to make sure to realign the reading head in the file.
The test case was originally a 10x10 checkerboard image with required
tags, and also the `DocumentName` tag. Then, I modified this tag in a
hexadecimal editor and replaced its id with 30 000 (0x3075 as a LE u16)
and the type with the same value as well. This is AFAIK, never used as
a custom TIFF tag, so this should remain an invalid tag id and type.
For solid color fills (with alpha = 255), the rasterizer now tracks
spans of solid colors within a scanline and fills the entire span with
a single call to fast_u32_fill().
This gave up to a 1.5x speedup drawing the Ghostscript Tiger within
SerenityOS.
In XYZ space, gray doesn't have three equal values. Instead, it is
a line through the whitepoint.
(Multiplying by the whitepoint has the same effect as multiplying
the sRGB matrix with a (g, g, g) vector, since the numbers on
the matrix's rows add up to the whitepoint.)
Fixes the very slight red tint on all the figures in chapter 4
of the PDF 1.7 spec.
We were previously only checking the first value, this is wrong for tags
that accept multiple values (e.g. ExtraSamples) and can lead to crashes
on malformed images containing tags with a count of 0.
The TIFF spec is constructed in a way that many tags are defined in
multiple places but some of these definitions are partial. If we look
into "Section 8: Baseline Field Reference Guide", we can see that these
tags indeed have an enforced length of 1.
With this change, instead of applying scroll offsets during the
recording of the painting command list, we do the following:
1. Collect all boxes with scrollable overflow into a PaintContext,
each with an id and the total amount of scrolling offset accumulated
from ancestor scrollable boxes.
2. During the recording phase assign a corresponding scroll_frame_id to
each command that paints content within a scrollable box.
3. Before executing the recorded commands, translate each command that
has a scroll_frame_id by the accumulated scroll offset.
This approach has following advantages:
- Implementing nested scrollables becomes much simpler, as the
recording phase only requires the correct assignment of the nearest
scrollable's scroll_frame_id, while the accumulated offset from
ancestors is applied subsequently.
- The recording of painting commands is not tied to a specific offset
within scrollable boxes, which means in the future, it will be
possible to update the scrolling offset and repaint without the need
to re-record painting commands.
The decoder assumes that k's sampling factor matches y's at the moment.
Better to error out than to silently render something broken.
For ycck, covered by ycck-2111.jpg in the tests.
We currently assume that the K (black) channel uses the same sampling
as the Y channel already, so this already works as long as we don't
error out on it.
Before this change, we would only cache and reuse Gfx::ScaledFont
instances for downloaded CSS fonts.
By moving it into Gfx::VectorFont, we get caching for all vector fonts,
including local system TTFs etc.
This avoids a *lot* of style invalidations in LibWeb, since we now vend
the same Gfx::Font pointer for the same font when used repeatedly.
This avoids doing pointless plotting for scanlines that will never be
seen.
Note: This currently can only clip edges vertically. Horizontal clipping
is more tricky, since edges that are not visible can still change how
things accumulate across the scanline.
Fixes#22382
Sadly, this causes a bunch of LibWeb test churn as this change
imperceptibly changes the final rasterized output.
This allows us to reject invalid images before trying to decode them.
The spec requires more tag to be present[1] but as we don't use them for
decoding I don't see the point.
[1] - XResolution, YResolution and ResolutionUnit
