[Openicc] [Fwd: icm profiles in debian]

[Chris Murphy]

On Feb 11, 2013, at 11:25 AM, James Cloos <cloos at jhcloos.com> wrote:

>>>>>> "KB" == Kai-Uwe Behrmann <ku.b at gmx.de> writes:
> 
> KB> Can you please switch on the light for us all and elaborate, why
> KB> you think algorithmically profile generation is essentially right?
> 
> The weight of continuing evidence has convinced me that stuffing a
> mathematically defined space into a file format designed for sampled
> data fails miserably.

I don't know what this means. What evidence? Fails how, with what manifestation? At the moment, the only profile classes affected by this packaging are mntr and spac.

And mntr and spac are expressly designed formats for describing mathematically defined spaces. So they work quite well for RGB additive color spaces; and even work quite well for actual devices if they're reasonably well behaved.

The method of package profiles in colord is advantageous for significantly improving the changes of squashing buggy profiles. The profile data is packaged in non-ICC format, but then they are produced at install time as ICC profiles. So in practice the transforms are still limited to whatever the file format limitations are.

But what it does help with, is getting all delivered profiles of a certain class (spac and mntr at least) created exactly the same way. If that method is wrong, all profiles conceivably will inherit the bug in baked-in form, but identifying this and getting it fixed means fixing all subsequent profiles rather than having to push out a pile of pre-encoded ones. Eventually, if not already, the bugs for making mntr and spac profiles are squashed, and now you don't end up with this 15 year legacy b.s. of some profiles containing unadapted primaries. Or some that use XYZ scaling with others using Bradford, etc.

When the devices aren't reasonably well behaved, then all we have is sampled data so of course we need a sampled data profile format.

Chris Murphy