-
Notifications
You must be signed in to change notification settings - Fork 1
Device Settings in ICC 0.2
| Revision History | |||
|---|---|---|---|
| v0.1 | 2006-08-28 - 09-04 | Kai-Uwe Behrmann © 2006 | |
| v0.2 | 2006-09-06 | Kai-Uwe Behrmann © 2006 | Thanks for suggestions and revisions to Graeme Gill, Hal V. Engel, Robert L Krawitz and Gerhard Fuernkranz. |
ICC profiles can contain informations about the calibration measurements, sometimes profiling information and the colour transformation description. What is missed are the driver settings used for the calibration process. The settings of a RIP or scanner driver are barely left out. The purpose of this specification is to provide driver specific configuration information additional to the ICC specification. The described tag follows the ICC sheme in constructing tags. The tag allows applications to select and check the correct driver and to configure him properly to match calibration conditions.
The herein suggested new tag to an ICC profile must be of type 'DevS' (device settings type) and be called 'DevS' (device settings tag).
The device settings tag starts as any other tag in a ICC profile with the bytes 0-3 for the type signature 'DevS' and bytes 4-7 set to zero as of ICCv4.2.
A static block of 76 follows the standard 8-byte tag header as described in table 0.
| 0...3 | 4 | 'DevS' () type signature |
| 4...7 | 4 | reserved, must be set to 0 |
| 8 | 1 | version of tag, must be set to 1 as of this specification version |
| 9...20 | 12 | device serial (12 byte field, null terminated, unused bytes must be set to zero) |
| 21...32 | 12 | driver name (12 byte field, null terminated, unused bytes must be set to zero) |
| 33...44 | 12 | driver version (12 byte field, null terminated, unused bytes must be set to zero) |
| 45...56 | 12 | drivers signature/encoding (12 byte field, null terminated, unused bytes must be set to zero) |
| 57 | 1 | priority of appliance (low - 0 ... high - 255) |
| 58...79 | 22 | reserved, must be set to 0 |
| 80...83 | 4 | data size as follows starting from byte 84 |
| 84...84+n | n | driver specific configuration data (as devined in drivers signature/encoding) |
After byte 83 the driver specific configuration data follows until the size specified with the blob size at position 80.
The tag type requires certain other tags to be present too. Namely the 'dmnd', the 'dmdd' and 'calt' tags are required for the device settings tag to work.
Hint: It is recommended that a API to handle the device settings tag should at the same time handle the mentioned tags.
The device names are used to check if the profile would match to a given device.
The 'dmnd' and 'dmdd' tags are general tags, which contain the device name and the device manufacturer name. They are required for the device settings tag. These tags indicate the device for which the profile is intented.
Hint: If a the profile is a generic profile and valid for a group of devices, all devices and manufacturers can be listed separated by colon in the device manufacturer description tag ('dmnd') and the device model description tag 'dmdd'. The first entry should be the one with the most match, e.g. the device, which was used for calibration.
The device serial name allows a very individual calibration and profiling. This field is intended for the most exact matching - in opposite to generic profiles.
The driver names are used to check for the presence of the appropriate device driver. If the driver names does not match, the tag should eighter be rejected for exact matching, or the application tries a clever approach by searching for the nearest match (not exact).
The field driver version should be filled with a device specific colour compatibility version of the driver.
The driver should provide a query function for the colour compatibility version for a particular device. The colour compatibility version is the lowest driver version since the last significant colour relevant changes happened in the driver for that particular device. This colour compatibility version would then been used in the 12-byte driver version field.
If the application requests exact version match, or the driver has no colour compatibility version query function, the real driver version number can be used instead.
The driver signature/encoding tells the driver about what kind of data is stored in the tag.
In some cases this information can be enough for the driver to identify the correct setting. In such a case the variable sized settings block may remain empty. This is suitable for a driver, which provides one or more fixed internal colour setting presets.
For a driver specific linearisation, the driver specific settings data might be of more interest.
The priority number is used to wighten different profiles for the same device and driver. By default a generic profile should be set to value 63. A device specific measured profile should get 225. The application or user can lower or increase this value as needed. For the same degree of harmony of two profiles this number may help to identify a prefered one. The measurement time ('calt' - calibrationDateTimeTag) should play a good role in this comparision and is therefore to include in the profile.
The driver specific settings data is usually the colour relevant part of the configuration, which would normally be editable. The driver should accept to gray out these settings in his dialogs, as they are marked as froozen by the colour management system. The colour management system handles here blindly and relies on the driver to provide the correct configuration subset and only passes it on. Possibly the configuration data is in a transparent form (e.g. PPD), known by the application, then the application can take over more control if needed.
Hint: The driver specific settings data can contain any kind of data. Anyway you are strongly encouraged to use standard formats, like xml, ascii or document the format used. This will lower supporting costs and improve portability.
Hint: For monitor calibrations, the 'vcgt' tag might be present and must be taken into account.
A profiler should ideally write the tag and the required ones into the profile itself to minimise error prone interactions.
Hint: A workflow, how to do in detail, is to be given elsewhere.
This specification is not part of the official ICC profile specification. The described tag is only valid for systems, which understands and supports him. Oyranos will obtain a implementation to support the tag.
Specification ICC.1:2004-10 (Profile version 4.2.0.0)
ISO/IEC 9899:1999(E) Programming languages - C
Chemnitz
06. September 2006