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.