This probably won't be the final API for getting color spaces
from images, since some formats just store an "is sRGB?" flag
instead of a full profile. Instead, once everything works,
we probably want to give every Bitmap a pointer to some
color space abstraction.
But we can always change this later, once things are further along
and better understood.
As the different Cmap encoding records are guaranteed to be sorted by
their platform ID, we would previously prefer the Macintosh platform
because of its lower ID value. However, this platform is split up into
a lot of encoding formats for different languages, and usually only
English is included. This meant that we could not handle most unicode
characters anymore.
The Windows platform now takes precedence again, as it can handle
arbitrary code points in its supported encodings.
This solution is still far from perfect, but it makes this regression
disappear for now.
Add a targeted quirk for the one known file where this is violated.
Adding that quirk is a bit of a bummer, since that means all client
code of this class now needs to deal with the possibility that
'cprt' and 'desc' aren't 'mluc' for v4 files. But if that code wants
to handle v2 files, it needs to deal with that anyways, so it's
really just a bit of a bummer and not more.
This adds checking for all tags where ICCProfile can parse the type.
Over time, more of this needs implementing -- at least lut8Type,
lut16Type, lutAToBType, and lutBToAType, since these are used by
required tags.
What _is_ checked for the most part matches the spec, but it's possible
that the spec text is aspirational and that profiles in the wild don't
fully match it.
I've run the current checks against these profiles:
find \
~/src/Compact-ICC-Profiles \
/{System/,}Library/ColorSync \
-name '*.icc' \
-exec echo {} \; \
-exec Build/lagom/icc {} \;
...and against 3 hand-selected icc files I locally extracted from jpegs.
This identified 3 cases where the spec text is too strict for reality.
I added comments for these for now. Eventually, I'd like to try to still
enforce these types, and have a profile-id-based quirks list for which
they aren't enforced. It's possible that that won't be feasible, but
it's probably better to start out to strict and then relax over time
than the other way round.
This patch adds the following some convenience functions:
- Lines do now support rotated(), scaled() and translated()
- AntiAliasingPainter has now a draw_line function that takes a
FloatLine as argument
The spec names are still a bit cryptic ("deviceMfgDescTag"
for "device manufacturer description"), but less cryptic than
just the fourcc.
There's a private tag area, so this will only print the spec name
of tags in the current spec. Private tags are in active use, e.g.:
$ icc /Library/ColorSync/Profiles/WebSafeColors.icc
...
Unknown tag ('dscm'): type 'mluc', offset 312, size 1490
(That's a v2 file. In v2, 'desc' has that strange textDescriptionType.
In v4, 'desc' has type 'mluc' -- but in v2, it didn't yet, so Apple
invented the private 'dscm' tag which has the description as an 'mluc'.)
Also add a function to map each tag signature to its name,
that is a function that maps e.g. measurementTag to "measurementTag"sv.
To implement this without too much repetition, use an x-macro.
I used pdftotext on the icc v4 spec to extract the list of tags,
and then manually cleaned it up a bit:
https://github.com/nico/hack/blob/main/icc-tags.txt
I then converted that to an x-macro using vim macros.
There is a problem with current approach where overflow clip rectange is
calculated by aggregating intersection of absolute padding boxes of
boxes in containing block chain that resulting rectangle doesn't
respect transform properties.
To solve this problem `PaintableBox` is changed to store clip rectangle
saved from painter because it does respect transform properties of all
previously applied clip rectangles.
Several tags can refer to the same TagData. In particular, the
rTRC, gTRC, bTRC tags usually all three refer to the same curve.
Curve objects can be large, so allocate only a single TagData
object in that case and make all tags point to it.
(If we end up storing some cache in the curve object later on,
this will also increase the effectiveness of that cache.)
This reduces reliance on the peek operation, which the generic stream
implementation does not support.
This also corrects the naming, since "tag" wasn't entirely correct for
some of the operations, where the tag takes up only part of a byte, with
the rest being reserved for data.
This is used in v2 profiles for the required 'desc' tag. In v2
profiles, it's also used by the 'dmnd', 'dmdd', 'scrd', 'vued' tags.
In v4 profiles, these all use 'mluc' instead (except for 'scrd', which
is no longer part of the spec in v4).
This fixes a few rendering bugs especially where the first or last
color stop had a zero alpha value. Note we can't just set the first
and last values on the gradient line to the first/last colors since
that might not be correct (e.g. have a transition hint).
This implements the gradients for:
- CanvasRenderingContext2D.createLinearGradient()
- CanvasRenderingContext2D.createConicGradient()
- CanvasRenderingContext2D.createRadialGradient()
As loosely defined in: https://html.spec.whatwg.org/multipage/canvas.html#fill-and-stroke-styles
(It's really not very well defined for radial gradients)
Actual implementation (for radial gradients) was done with a lot
of trial and error, then visually comparing to other browsers.
This means fill_path() now paints the scanlines its self rather than
calling draw_line() which easily allows each pixel along the scanline
to have a different color.
The idea is that we'll have one type for each tag type.
For now, this treats all tag types as unknown, but it puts most
of the infrastructure for reading tags in place.
This happened because the reader was incrementing the byte index of it
after each read of a byte from the Span, so by the end of the frame
method, we could be at the end of the mapped file, so the next call
on the same decoder will just resume from that point and will be quickly
out of boundary.
To ensure this doesn't happen we only set the bitmap to m_context member
at the end of the method, and call to that method again will just give
the already-generated bitmap.
In case of setting the bitmap as volatile, we test for that case and
re-generate a reader to read the frame again correctly.
When trying to figure out the correct implementation, we now have a very
strong distinction on plugins that are well suited for sniffing, and
plugins that need a MIME type to be chosen.
Instead of having multiple calls to non-static virtual sniff methods for
each Image decoding plugin, we have 2 static methods for each
implementation:
1. The sniff method, which in contrast to the old method, gets a
ReadonlyBytes parameter and ensures we can figure out the result
with zero heap allocations for most implementations.
2. The create method, which just creates a new instance so we don't
expose the constructor to everyone anymore.
In addition to that, we have a new virtual method called initialize,
which has a per-implementation initialization pattern to actually ensure
each implementation can construct a decoder object, and then have a
correct context being applied to it for the actual decoding.
Originally I simply thought that passing file paths is quite OK, but as
Linus pointed to, it turned out that passing file paths to ensure some
files are able to be decoded is awkward because it does not work with
images being served over HTTP.
Therefore, ideally we should just use the MIME type as an optional
argument to ensure that we can always fallback to use that in case
sniffing for the correct image type has failed so we can still detect
files like with the TGA format, which has no magic bytes.
These are currently being implicitly including by FixedPoint.h by way of
Format.h. The former will soon be removed from the latter, which would
otherwise cause a compile error in these files.
