[Openicc] meta data in test chart

[Kai-Uwe Behrmann]

Hello Alastair,

I am glad you are interessted in this project :-)
...

Am 21.01.11, 02:24 -0000 schrieb Alastair M. Robinson:
> On 21/01/11 01:07, edmund ronald wrote:
>
>> I think we need to choose between XML and JSON. Robert will have final
>> say, I guess, but we might as well have it out there.
>
> I'm with Graeme in thinking XML is a horrible format to edit by hand (because 
> the tags and the <> delimiters all have the same visual "weight" as the data 
> within, so to my eyes it all just congeals into a mass on screen.)  However, 
> despite my dislike of it, I think XML might be the better fit in this case.
>
> What needs to be able to parse the serialised options, and what can just 
> treat it as a "blob"?
>
> * Gutenprint: Obviously needs to be able to both parse and write.
>
> * Oyranos, colord, etc.: Do they need to parse, or is a test for "equality" 
> (for some yet-to-be-determined definition of "equality") sufficient?

At the level of target generation and reading, a CMS is not much involved.

The CMS needs a way to generically rank a given set of informations, from 
the ICC profiles or an other data base, on a given device. Just inside ICC 
it is already the native format for a CMS. From that installed ICC 
profiles with their properties can be seen as a DB.

We know the selection by the device ID model is not nice, as it is not 
flexible at all and not very transparent. Its easiest to implement, but 
usability is error prone. Change gamma and the CMS is fooled. That model 
is ignorant about the rich device specific informations we could use.

A binary blob model burdens many CMS functionality into the device 
selection module. The devce to ICC comparision would then happen close 
to the device drivers. Obviously the CMS has then less to decide. Thats 
very flexible, but very specialised and needs much more work to become 
functional. I had though of using that approach but stayed away. There 
would be more APIs needed and the code path would require more calls 
into device driver modules which appeard expensive.

A key by key comparsion combined with a ranking map can be managed much 
easier and is flexible enough to handle fuzzy matches, like a set of 
similiar device models. That can happen inside the CMS. It combines the 
many aspects of the above outlined two ICC profile selection models.
The device specific code concentrates just on serialisation and delivers a 
very simple rank map. Thats implemented for four device classes by two 
student from OpenICC GSoC projects and me and it works fantastic. It 
requires on the other side to obtain key/value pairs through the ICC 
profile and the rank map from the device class module to do the search for 
the best match.

I hope to could make the verious models of ICC for device selection a 
bit transparent.

> * ArgyllCMS: I would think profiling tools in general would need no awareness 
> of the contents and would treat the data as a blob to be embedded in the 
> final profile?

CGATS is the input format used by Argyll's profiler. Let me propose a 
scheme, which fits to CGATS.

-------------------------8<--------------------------------
KEYWORD "META_TAG_KEYS"
META_TAG_KEYS "ColorModel StpColorPrecision MediaType Quality Resolution StpColorCorrection StpBrightness StpFineBrightness StpContrast StpFineContrast StpImageType StpDensity StpFineDensity StpDitherAlgorithm StpGamma StpFineGamma StpLinearContrast"
KEYWORD "ColorModel"
KEYWORD "StpColorPrecision"
...
ColorModel "Gray"               # is lower case is allowed in CGATS?
StpColorPrecision "Normal"
...
-------------------------8<--------------------------------

Photoprint can fill and inject the above sequence into the CGATS file.

If Argyll could copy that over into the profiles 'meta' tag, then a 
CMS, like Oyranos, will be able to compare that information with a given 
PPD or whatever from any print application to select the profile.

Thus Photoprint in turn could use a CMS like Oyranos to scan installed ICC 
profiles to select the best fit for a given print queue.

For Argyll that scheme needs no further efforts for other device classes 
or drivers.

>> One argument in favor of JSON is that we can expect to write GUI's to
>> manipulate settings for the user so JSON is a good fit.
>
> From my experience using the Gutenprint options system from within PhotoPrint 
> I'd say the options' limits and their interactions with each other are *way* 
> too complicated to be encoded within a serialised options file, so a GUI tool 
> to edit such a set of options would probably need to be linked with 
> libgutenprint.  Such a tool (at least a Gutenprint-specific tool) would be 
> far better off deserialising an options file into a live stp_vars_t, editing 
> that, then serialising it again than attempting to parse a file itself and 
> implementing its own internal model with option constraints.  Gutenprint 
> already has an XML library, so I don't see much sense in making Gutenprint 
> use a different parsing library just for option serialisation.

If we could agree to the proposed path along the key/value pairs with
the meta tag, then even very generic tools could be leveraged to do tweaks 
on the data set. But I agree a secialised tool can handle contrains, which 
are not visible in a plain key/value view on the data. It would need a 
parser, which combines the key/values to a internal format understood by 
Gutenprint. I roughly remember that Gutenprint had convenient APIs to 
help with that.

> All the best
> --
> Alastair M. Robinson

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org