The method was only used in `load_from_file(StringView path)` and
replacing it with `load_from_file(NonnullOwnPtr<Core::File>)` is very
straightforward.
I had missed this in 21cc0c0cb2 because this tag is missing in
"Table 32 — Tag list" in the v2 ICC spec O_o. But it's in
"6.4.26 namedColorTag".
Also add a comment pointing to a page saying that all these tags
are very deprecated and not even recommended for new v2 profiles.
(That's how I noticed that namedColorTag was missing.)
The curve data in lutAToBType and lutBToAType can store 'para' data, but
other than in the main ICC tag table, the size of the tag data isn't
explicitly stored. So it must be computed from the data contents.
Extract the function body into a helper can call that from both
variants.
The curve data in lutAToBType and lutBToAType can store 'curv' data, but
other than in the main ICC tag table, the size of the tag data isn't
explicitly stored. So it must be computed from the data contents.
Extract the function body into a helper can call that from both
variants.
The new Painter::set_clip_rect(IntRect) API was able to make the clip
rect larger than the underlying target bitmap. This was not good, as it
could make it possible to draw outside the bitmap memory.
Fixes a crash when viewing https://twinings.co.uk/ in the browser. :^)
This isn't terribly useful. But some profiles, for example the ones at
https://vpifg.com/help/icc-profiles/, do contain this tag and it seems
nice to be able to dump it, just for completeness.
I haven't seen any files that contain a phosphor or colorant type
different from "Unknown", even for the Rec2020 profile on that page.
(It has x,y coordinates that match the values required for Rec2020,
but it doesn't set the phosphor or colorant type to that.)
Not terribly useful in practice either and also mostly for
completionism. But with this, we can dump all types present
in Lightroom Classic-exported jpegs :^)
Previously checkerboard patterns were anchored to the top left of the
bitmap they were being drawn into.
This makes the transparency grid in PixelPaint static relative to the
canvas when panning.
These are among the permitted tag types of ATo0Tag and BToA0Tag,
which are among the required tags of most profiles. They are the
last permitted tag types for those profiles (the other are
lut8Type or lut16Type, which are already implemented).
They are pretty chonky types though, so this only implements
support for the E matrix and the CLUT. Support for the various
curves will be in a future PR.
We essentially just end up moving `release_value_but_fixme_...` one
layer down, but it makes adding more fallible operations in the
serialization function more comfortable.
This is useful in general (I'd imagine), but in particular having this
will allow us to implement accented PDF Type1 Font glyphs, which consist
of two separate glyphs that are composed into a single one.
Functionality for checking image size in advance has been removed, as
this would require a SeekableStream and we now check for read errors
everywhere anyways.
This is a very new tag used for HDR content. The only files I know that
use it are the jpegs on https://ccameron-chromium.github.io/hdr-jpeg/
But they have an invalid ICC creation date, so `icc` can't process them.
(Commenting out the check for that does allow to print them.)
If the CIPC tag is present, it takes precedence about the actual data
in the profile and from what I understand, the ICC profile is
basically ignored. See https://www.color.org/events/HDR_experts.xalter
for background, in particular
https://www.color.org/hdr/02-Luke_Wallis.pdf (but the other talks
are very interesting too).
(PNG also has a cICP chunk that's supposed to take precedence over
iCCP.)
This isn't used by any mandatory tags, and it's not terribly useful.
But jpegs exported by Lightroom Classic write the 'tech' tag, and
it seems nice to be able to dump its contents.
signatureType stores a single u32 which for different tags with this
type means different things.
In each case, the value is one from a short table of valid values,
suggesting this should be a per-tag enum class instead of a
per-tag DistinctFourCC, per the comment at the top of DistincFourCC.h.
On the other hand, 3 of the 4 tables have an explicit "It is possible
that the ICC will define other signature values in the future" note,
which suggests the FourCC might actually be the way to go.
For now, just punt on that and manually dump the u32 in fourcc style
in icc.cpp and don't add any to_string() methods that return a readable
string based on the contents of these tables.
This is the type of namedColor2Tag, which is a required tag in
NamedColor profiles.
The implementation is pretty basic for now and only exposes the
numbers stored in the file directly (after endian conversion).
