LutAToBTagData::from_bytes() and LutBToATagData::from_bytes() already
reject curves for which this isn't true with an error.
Ensure potential future callers of the constructors get it right too.
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.
No behavior change.
(Well, technically mix() uses the other simple implementation of lerp
and the two have slightly different behavior if the arguments are of
very different magnitude and in various corner cases. But in practice,
for ICC profiles, it shouldn't matter. For a few profiles I tested, it
didn't have a measurable effect.)
The values aren't 100% self-consistent, but it probably doesn't make
a difference for u8 color data. Good enough for now. See all the links
on #17714 for some more background.
This might be useful for converting data from arbitrary profiles to
sRGB.
For now, this only encodes the transfer function and puts in zero values
for chromaticities, whitepoint, and chromatic adaptation matrix.
This makes the profile unusable for now. But I've spent a very long time
reading things and need to check in some code, and it's some progress.
The encoded transfer function exactly matches the one in GIMP's built-in
sRGB ICC profile (but not the Compact-ICC-Profiles v4 one or the
RawTherapee v4 one -- I'll add a comment about why later.)
We could make UnknownTagData hold on to undecoded, raw input data and
write that back out when serializing. But for now, we don't.
On the flipside, this _does_ write unknown tags that have known types.
We could have a mode where we drop unknown tags with known types.
But for now, we don't have that either.
With this, we can for example reencode
/Library/ColorSync/Profiles/WebSafeColors.icc and icc (and other
tools) can dump the output icc file. The 'ncpi' tag with type 'ncpi'
is dropped while writing it, while the unknown tag 'dscm' with
known type 'mluc' is written to the output. (That file is a v2 file,
so 'desc' has to have type 'desc' instead of type 'mluc' which
it would have in v4 files -- 'dscm' emulates an 'mluc' description
in v2 files.)
It only implements serialization of the 7-bit ASCII string, not yet
serialization of the UCS-2 and Macintosh ScriptCode strings.
With this, matrix-based v2 profiles can be reencoded :^)
With this, common v4 profiles, such as embedded into jpgs by iPhones
(when configured to write jpegs) or Pixel phones, are identical to
the input when reexported :^)
