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.)
