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).
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 trims the input bytes to the profile size stored in the file.
Alternatively, we could reject files where the stored size doesn't
match the handed in size. But ICC profiles can be embedded in other
files, and those could conceivably pad the ICC profile data some.
There's a small, old-timey list of platforms in the spec, but as far
as I can tell nobody is using additional platforms on Linux or Android
or what. So let's try going with an enum class instead of the FourCC
machinery for now.
Namely:
- preferred CMM type
- device manufacturer
- device model
- profile creator
These all have in common that they can take arbitrary values, so I added
a FourCC class to deal with them, instead of using an enum class.
I made distinct types for each of them, so that they aren't accidentally
mixed up.
These flags are always 0 in practice in all profiles I've seen so far,
but hey, probably nice to dump them anyways.
And hey, it's just 86 lines to print 4 bits.
Always computing computing the md5 takes some time, but most
icc profiles are small. So that's probably fine.
If this ends up being a perf problem in the future, or if it ends up
rejecting tons of embedded proiles from images, we can row it back.
But let's see if we can get away with this first.
I checked that they are zero for all profiles in Compact-ICC-Profiles
and for all .icc files in /Library/ColorSync and
/System/Library/ColorSync on my Mac (running macOS 12.6.2).
This is a bit messy: The spec says that PCSXYZ and PCSLAB are the only
valid profile connection spaces -- except for DeviceLink profles, where
all data color spaces are valid.
So this uses the existing ColorSpace enum for profile connection spaces
instead of adding a dedicated enum, to not duplicate all the color space
parsing and printing code. That matches what the spec does, too.
This saves about 100 lines of code, at the expense of less type
safety -- but further down the line we probably want to be able to
compare data color spaces and profile connection spaces, so the type
safety would likely get in the way then. (But if not, we can change
things around once we get to that point.)
