According to ministat, a bit faster to render page 3 of 0000849.pdf:
```
N Min Max Median Avg Stddev
x 50 1.000875 1.0427601 1.0208509 1.0201902 0.01066116
+ 50 0.99707389 1.03614 1.0084391 1.0107864 0.010002724
Difference at 95.0% confidence
-0.00940384 +/- 0.0041018
-0.921773% +/- 0.402062%
(Student's t, pooled s = 0.0103372)
```
Reduces time spent rendering page 3 of 0000849.pdf from 1.45s to 1.32s
on my machine.
Also reduces the time to run Meta/test_pdf.py on 0000.zip
(without 0000849.pdf) from 58s to 55s.
Reduces time spent rendering page 3 of 0000849.pdf from 1.85s to 1.45s
on my machine.
As determined by running
time Build/lagom/bin/pdf --page 3 --render out.png \
~/Downloads/0000/0000849.pdf
a few times and eyeballing the min time.
Also reduces the time to run Meta/test_pdf.py on 0000.zip
(without 0000849.pdf) from 1m7s to 58s.
We refuse any image with a sample depth greater than 32, storing these
value as `u64` prevent any overflows. This is probably overkill as no
one in their right mind will use a 32 bits color table.
frame() still returns a regular RGB Bitmap (now lazily converted
from internal CMYK data), but JPEGImageDecoderPlugin now also
implements cmyk_frame().
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.
