## Description of the .cal format

Device calibration information. This is ASCII text, CGATS, Argyll specific format, used to hold a description of device setup information that brings it to a desired calibration state. Calibration files are created by synthcal, dispcal and printcal.
While fully compatible with the CGATS.5 Data Exchange Format, the particular required keywords and fields are unique to Argyll, hence an Argyll specific file identifier CAL is used to avoid confusion with standard ANSI or CGATS files.
The .cal format changes from time to time with new releases, to add new functionality, but generally retains backwards compatibility. Note that in the description below, the word "may" indicates an optional component, while the word "shall" indicates a necessary component.
Generally a .cal file contains only one table, the table containing the setup information.
The table contains the following:
The file identifier (First 7 characters) shall be CAL.
A # character introduces a comment.
There may be DESCRIPTOR, ORIGINATOR, or CREATED keywords and values (as per CGATS).
There shall be a DEVICE_CLASS keyword that has a value of "OUTPUT", "DISPLAY" or "INPUT".
This indicates what type of device the calibration information is suitable for.
A "DISPLAY" type device may have a VIDEO_LUT_CALIBRATION_POSSIBLE keyword that must have a value of "NO" or "YES", to indicate whether the display has the ability to be calibrated by loading VideoLUT values.
A "DISPLAY" type device may have a TV_OUTPUT_ENCODING keyword that must have a value of "NO" or "YES", to indicate whether the calibration was created withing the video (16-235)/255 compressed range of device value. This is used to signal to a VideoLUT loader whether calibration values should be converted to video encoded range when loaded into hardware. The calibration values stored in the .cal file are never video encoded themselves, i.e. 0.0 is always device minimum, and 1.0 is always device maximum.
There shall be a keyword COLOR_REP that has a value that indicates what colorspaces of the device values. The colorspaces shall be encoded with one or two letters per component. The device spaces shall use the following letter encoding:
Cyan C
Magenta M
Yellow Y
Black K
Orange O
Red R
Green G
Blue B
White W
Light Cyan c
Light Magenta m
Light Yellow y
Light Black k
Medium Cyan 2c
Medium Magenta 2m
Medium Yellow 2y
Medium Black 2k
Light Light Black 1k
There may be an a prefix i preceding the device space letter encoding, indicating that although the space appears to be an additive space, it is in fact a subtractive device.
Typical values might be: "RGB" for an RGB display, "iRGB" for an RGB printer, "CMYK" for a printer, "RGB" for an RGB scanner.
The NUMBER_OF_FIELDS keyword shall have a value that indicates the number of fields in each data set, e.g. 4 (as per CGATS).
The start of the declaration of the fields shall be marked by the BEGIN_DATA_FORMAT keyword (as per CGATS).
The fields shall use the standard CGATS pattern of the full colorspace identified followed by the individual colorant identifier. There shall be an initial input index value identified by the letter I.
For an RGB device, the following fields would be used:
RGB_I The device value input value between 0.0 and 1.0.
RGB_R The Red device value input value between 0.0 and 1.0.
RGB_G The Green device value input value between 0.0 and 1.0.
RGB_B The Blue device value input value between 0.0 and 1.0.
The corresponding field names for a CMYK device would be CMYK_I, CMYK_C, CMYK_M, CMYK_Y and CMYK_K, etc.
The definition of the fields shall be terminated by the END_DATA_FORMAT keyword (as per CGATS).
The NUMBER_OF_SETS keyword shall have a value that indicates the number of sets of data, e.g. 256 (as per CGATS).
The start of the values of the data sets shall be marked by the BEGIN_DATA keyword (as per CGATS).
Each set of data shall be on one line, and shall be separated by white space. All values shall be normalized to lie between 0.0 and 1.0.
The end of the values of the data sets shall be marked by the END_DATA keyword (as per CGATS).
There may then be device type specific extra tables that hold target or device behavior information. These will be specific to the tool that creates that particular type of calibration.
Generally any other keywords and values will be ignored.