These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
Before, we used to reject profiles where the creation datetime was
invalid per spec. But invalid dates happen in practice (most commonly,
all fields set to 0). They don't affect profile conversion at all,
so be lenient about this, in exchange for slightly more wordy code
in the places that want to show the creation datetime.
Fixes a crash rendering page 2 of
https://fredrikbk.com/publications/copy-and-patch.pdf
Our current CLUT code is pretty slow. A one-element cache can make
it quite a bit faster for images that have long runs of a single
color, such as illustrations.
It also seems to help with photos some (in `0000711.pdf` page 1) --
I suppose even them have enough repeating pixels for it to be worth
it.
Some numbers, with `pdf --render-bench`:
`0000711.pdf --page 1` (high-res photo)
before: 2.9s
after: 2.43s
`0000277.pdf --page 19` (my nemesis PDF, large-ish illustration)
before: 2.17s
after: 0.58s (!)
`0000502.pdf --page 2` (wat hoe dat)
before: 0.66s
after: 0.27s
`0000521.pdf --page 10 ` (japanese)
before: 0.52s
after: 0.29s
`0000364.pdf --page 1` (4 min test case)
before: 0.48s
after: 0.19s
Thanks to that last one, reduces the time for
`time Meta/test_pdf.py ~/Downloads/0000` from 4m22s to 1m28s.
Helps quite a bit with #23157 (but high-res photos are still too
slow).
It converts from a CMYKBitmap to an (rgb) bitmap, using a real
color profile.
The API design here isn't super scalable (what if we want to also
handle grayscale inputs? What if we also want to convert _to_ cmyk
or grayscale?), but we have to start somewhere. Uses of this can
inform future API improvements.
Doesn't matter if both profiles are sRGB since
inv(A) * A == A * inv(A), but when converting e.g. a P3 image to
sRGB, the colors are very off if the matrices are the wrong way round
here.
A bit faster:
```
N Min Max Median Avg Stddev
x 50 0.97179127 1.0031381 0.98313618 0.98407591 0.0092019442
+ 50 0.95996714 0.99507213 0.96965885 0.97242294 0.0095455053
Difference at 95.0% confidence
-0.011653 +/- 0.00372012
-1.18415% +/- 0.378032%
(Student's t, pooled s = 0.0093753)
```
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.
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.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
mft1 and mft2 tags are very similar. The only difference is that
mft1 uses an u8 lookup table, while mft2 uses a u16 lookup table.
This means their PCS lookup encodings are different, and mft2 uses a
PCSLAB encoding that's different from other places in the v4 spec.
If one profile uses PCSXYZ and the other PCSLAB as connection space,
we now do the necessary XYZ/LAB conversion.
With this and the previous commits, we can now convert from profiles
that use PCSLAB with mAB, such as stress.jpeg from
https://littlecms.com/blog/2020/09/09/browser-check/ :
% Build/lagom/icc --name sRGB --reencode-to serenity-sRGB.icc
% Build/lagom/bin/image -o out.png \
--convert-to-color-profile serenity-sRGB.icc \
~/src/jpegfiles/stress.jpeg
ICC profiles work by transforming from the input color space
(one of many: RGB, CMYK, YUV, etc) to a "profile connection space" (PCS)
and then from there to the output color space.
However, there's not one but two possible profile connection spaces,
PCSXYZ and PCSLAB. The matrix/curve tags can only be used with PCSXYZ,
but the mAB, mBA, mft1, mft2 tags can be used with PCSLAB as well.
The PCSLAB encoding has L going from 0 to 100 and ab from -128 to 127,
instead of from 0 to 1. So they need to be scaled up at the end.
That's also the reason for the "mystery conversion factor": PCSXYZ
doesn't go from 0 to 1 either, but from 0 to 65535/32768, per ICC v4
6.3.4.2 General PCS encoding, Table 11 - PCSXYZ X, Y or Z encoding.
Between input and output are various curves (and the CLUT) that
have domain and range of 0..1. For these, the color has to be linearly
scaled to 0..1 before the curve and back to the actual range after
the curve. Doing that back-to-back is a no-op, so scaling back at
the very end is sufficient.
We will need to use ColorSpace in TagTypes.h, and it can't include
Profile.h.
Also makes Profile.cpp a bit smaller.
No behavior change, pure code move.
...as long as the mAB tag doesn't have A curves and a CLUT.
With this, we can convert images that use AToB* tags to the profile
connection space (and then from there to, say, sRGB), if the AToB* tag
uses the mAB format.
We can't yet do this if the mAB tag has A curves or a CLUT.
We can't convert back from PCS to this space yet.
We don't yet handle AToB* tags that use mft1 or mft2 instead of mAB.
There's probably a nicer way of doing this where we don't need to expand
the gray value into a full Vector3, but for now this is good enough.
Makes PDFs written by macOS 13.5.2's "Save as PDF..." feature show up.
This allows converting to a color space that uses a non-parametric
curve, for example:
Build/lagom/image -o foo.png \
--convert-to-color-profile .../profiles/sRGB-v2-micro.icc \
input.jpg
...where profiles/sRGB-v2-micro.icc is from
https://github.com/saucecontrol/Compact-ICC-Profiles/
(Parametric curves are new in ICC v4, which means all v2 profiles
use point curves.)
For now, only for color spaces that are supported by Profile::to_pcs()
and Profile::from_pcs(), which currently means that all matrix profiles
(but not LUT profiles) in the source color space work, and that
matrix profiles with parametric curves in the destination color
space work.
This adds Profile::convert_image(Bitmap, source_profile), and
adds a `--convert-to-color-profile file.icc` flag to `image`.
It only takes a file path, so to use it with the built-in
sRGB profile, you have to write it to a file first:
% Build/lagom/icc -n sRGB --reencode-to serenity-sRGB.icc
`image` by default writes the source image's color profile
to the output image, and most image viewers display images
looking at the profile.
For example, take `Seven_Coloured_Pencils_(rg-switch_sRGB).jpg`
from https://commons.wikimedia.org/wiki/User:Colin/BrowserTest.
It looks normal in image viewers because they apply the unusual
profile embedded in the profile. But if you run
% Build/lagom/image -o huh.png --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
and then look at huh.png, you can see how the image's colors
look like when interpreted as sRGB (which is the color space
PNG data is in if the PNG doesn't store an embedded profile).
If you now run
% Build/lagom/image -o wow.png \
--convert-to-color-profile serenity-sRGB.icc --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
this will convert that image to sRGB, but then not write
the profile to the output image (verify with `Build/lagom/icc wow.png`).
It will look correct in image viewers, since they display PNGs without
an embedded color profile as sRGB.
(This works because 'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
contains a matrix profile, and Serenity's built-in sRGB profile
uses a matrix profile with a parametric curve.)
This implements conversion from profile connection space to the
device-dependent color for matrix-based profiles.
It only does the inverse color transform but does not yet do the
inverse tone reproduction curve transform -- i.e. it doesn't
implement many cases (LUT transforms), and it does the one thing
it does implement incorrectly. But to vindicate the commit a bit,
it also does the incorrect thing very inefficiently.
This can be used to convert a profile-dependent color to the L*a*b*
color space.
(I'd like to use this to implement the DeltaE (CIE 2000) algorithm,
which is a metric for how similar two colors are perceived.
(And I'd like to use that to evaluate color conversion roundtrip
quality, once I've implemented full conversions.)
Only implemented for matrix profiles so far.
This API won't be fast enough to color manage images, but let's
get something working before getting something fast.
