Device Settings

From ColourWiki

All variable parts of the colour processing chain must be taken into account, to achieve predictable results. As a consequence colour profiles as colour only transformations are not enough to describe completely the path colours has to go. For instance downloading a printer profile and separating an image does not ensure the according driver settings are selected correctly or even the appropriate driver was used. Even the driver and its version is often not included and not standardised to access machine readable. To overcome that information hole for monitors, Apple introduced the vcgt tag to describe the according hardware state in the graphics card gamma table. This is a single step and maybe enough for just this task.

In the following proposal, I will draw sketchy, what I think is needed to make the task complete, and apply to other areas too.

---

Table of contents

1 Informations Incorporated 2 Advantages 3 Scenario 4 Implementation Details 5 Oyranos API suggestion 6 Specification

Informations Incorporated

• device identification
  • device type, manufacturer, model, serial number, country, device options

AB & Co Ltd., printer model CD-1234, EF photo ink, GH gloss paper, #1234-5678

• driver names and their versions to verify integrity

nv/nvidia, Gutenprint/HPIJS, DCraw versions

The driver names used must be unique to later lookup and find the appropriate profile. If one application use Gutenprint and an other gimp-print chances are high to not find the according profile. Of course some kind of registering probably with a enumeration type would help here. With a good maintained database this should work fine.

The driver must be able to tell: down to what driver version he is colour compatible for a certain device.

• device settings (as provided, colour relevant ones should be query able by a device driver API)

expl. PPD, scan parameters, VCGT

• • fixing colour sensible driver settings in a GUI to exclude wrong user interaction is a precondition to form a calibration

PPD with removed choices, VCGT + fixed monitor settings, DCraw called with specified options

• device colour characterisation (a ICC profile belonging to the above outlined calibration)
  • the profile must belong to the device/driver/settings/version mix
  • priority among selected profiles (generic profile - low, self calibrated - high) can be a profile property
• distribute by combining above information
  • packing all informations into one piece

embed into ICC profile, register in a local or remote hardware db, xml configuration

---

---

Advantages

• select an profile and the system/application selects the correct driver and knows about needed settings
• change settings and the system can tell if an profile is available
• email a complete settings file, no further information is needed to setup
• use the same settings in all applications, they are globally available through the profiles themselves

Scenario

(X example, similar to print, scan, digicams):

• obtain monitor settings informations
• set/reset monitor settings from software (xcalib/ddccontrol,...)
• interface to get/set settings from Oyranos to drivers
• extract ICC information easily
• alert for expired configuration

Implementation Details

• easy accessible text format to store and handle driver informations (key/value pairs)
• driver identifier (which every application can either understand or reject the whole profile)
• possibly allow data blobs too, to allow compressed content
• Graeme Gill suggested to use an magic number to identify the blob.
• additional part within this format to store CMM specific thing (expire date, ...)
• combine with ICC profiles
• add device settings information to an existing ICC profile
  • use a internal dedicated ICC profile tag
    • possibly hard to circumvent license issues
    • best to identify, without breaking ICC standards
    • allow profilers do handle themselves (by an small library)
    • need possibility to add that information after profiling, because the device informations may not be available at profiling time or the profiler is simply not aware of our demand
  • check and correct the size tag in ICC profiles and append the device settings text behind. The profile size would be the offset to that data.
    • profile readers and CMMs would handle as usual
    • non standard
    • someone else can use the same approach, which would make such data useless
    • give the modified a proper extension to identify; ?? ICG for instance (InterColorprofileGathering) ??
  • prepend the text and define an offset to the ICC profile data
    • breaks existing CMMs and profile readers
    • clear to handle, to be covered by an specification
    • forces a switch first
• the driver version should be editable (ICC Examin?), so a older drivers can be still used

Oyranos API suggestion

/** The following function includes all information to create and return the device 
    settings tag */
oyProfile_s * oyProfile_AddDeviceSettings     ( const char* device_manufacturer, // used for the 'dmnd' tag
                                                const char* device_name,         // used for the 'dmdd' tag
                                                const char* device_serial,       // 
                                                const char* driver_name,         // just for information
                                                const char* driver_signature,    // to choose the driver
                                                const char* driver_version,      // to choose the driver
                                                struct tm*  calibration_time,    // used for the 'calt' tag
                                                                                 // needs <time.h>
                                                void*       configuration_data_block,
                                                size_t      config_block_size,
                                                oyProfile_s *profile,            // profile to embed into 
                                                size_t*     profile_data_size )
return: the new profile

/** a function to extract the device settings tag from a existing profile */
oyDeviceSettings_s* oyIccDeviceSettingsDataGet( void*       profile,
                                                size_t      profile_size,
                                                size_t*     data_size )
For the oyDeviceSettings_s structure see below.

TODO: proof the available options (ICC, XML...), choose, publish a specification and procedure suggestion, implement in Oyranos

Specification

Device Settings in ICC 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.