A color seems complex to understand because sometimes we use CMYK values to talk about it or RGB or even Lab, XYZ, Lch, ... All those color spaces could define the same color depending of the use.
In fact the purest way to speak about a color is through its spectral data. Those data are measured directly through a spectrophotometer. Though we can have different spectral data for the same color depending of the measurement condition : without illuminant every color is black, so let's use an illuminant but which one ? Do we use the D50 normalized illuminant or the D65 normalized illuminant, should we use a filter or a polarizer (to prevent gloss interfering)? It does not seems to have one unique way to save colors.
There is a long way before a true digitalization of a color in the real world...
There are two main goals of the color digitalization: saving and sharing.
As a picture would, by saving a color you can create a fixed point in the time of your color's perception (because the measured subject can change through the time by growing old, burning at the sun, ...). You can use it as a reference like Pantone does with its inks or keeping it to create a history and check the evolution over time.
You might have laboratories that measure and work with the color within the same building but colors workflow often have many places all around the world. In this last case the manufacturer may never see the color reference he is about to reproduce, so he does need a way to know what he is supposed to do and what does it looks like.
There are others cases but let's keep it simple for today.
There are many way to save color information, indeed some well known companies such as X-Rite or Data Color though about it and made their own formats.
But all of them are very different from each other and make complicated the compatibility between software. This issue was a starting point of the Coraye software : creating a bridge between software by implementing import and export of any kind of files (e.g.: allowing to transform a QTX file to a CxF one). To achieve this, we needed to create a way to become compliant to any kind of file format and keeping data untouched (no rounding or transformation process) by structuring data.
Our first though was to choose one existing file format as a reference for all other one but we did not found the perfect one because our requirement for the Coraye Software are too specifics. Moreover we choose to work with web technologies and encoding such as JSON format whereas standardized files are often proprietary oriented and complicated to parse.
The QTX format
Created by DataColor, the QTX file store data in a way that each color is independent from each other. So you will find informations such as the spectrophotometer used or the measured date for each sample.
You do have the possibility to insert batches colors. Those are repeated measure in different conditions (e.g.: with a different spectrophotometer).
You can even set different custom keys with custom value without worry. This would allow the file system to grow without requiring a v2 format that would not be compatible with previous versions.
- You can mix colors in a same file
- You can customize the content
- Human readable
- Not standards format (Require custom interpreter)
- Repetitive content
- Custom key mean specific code to interpret (data is lost if the software that import the file is not able to work with it because it doesn't understand what PRG_DATE_REVIEW=XXXXX means)
- Full of unused empty keys (more difficult to read even for humans) that make file heavier that it should be
- Difficulties to use with basic tools such as XCEL
The Cxf format
Created by XRite, the Cxf file is a complexe format that allow you to store various information from Lab to spectral, with metadata. It's a complete format that allow a full customization. But what seems to be a key functionality could also be a dangerous one : the over-customization tend to make difficult to read what's essential.
More over the XML format also have a lot of repetitive content. You can escape this by settings common parameter but it does only make the file even more complicated to read.
- Certified file
- Standardized way to communicate color
- Possibility of customization
- Does have a versioning that require a program to be up to date with the latest rules
- Chaotic over-customization
- The data's path is not always intuitive (where should I write spectral data, Resources>ObjectCollection>Object>ColorValues>ColorCIELab to get Lab values)
The CGATS format
This format is not used as a color table format, it's mainly a file used for printing targets but it can be considered as it (since strictly speaking it does contain similar information than you can find in a QTX or a Cxf format).
The format is quite convenient for a list of color patches that share the same condition (same support, same spectrophotometer info, same color index value). It is easy to read for a human or a computer and is even adapted for a copy paste in an excel sheet. You can add custom keys and there aren't that much repetitive content.
Unfortunately it isn't convenient for color table saving since all colors must share a common context and color values (XYZ & LAB & SPECTRAL), if one were missing, the full file would collapse.
- Easily readable
- No repetitive content
- Can store spectral data with custom wavelength index
- Easy to export to tool such as XCEL
- Colors must share a common context
- Each color have the same data structure
- Text format is not convenient for machine parsing
There are also other file formats that are made for color saving but those aren't efficient because they unfortunately do not support spectral data. It can mainly be explained by the fact that those file format are made to save spot colors only and are more focused on graphic art than printing.
Examples of other formats : Ase, Acb, Aco, Csv, Coreldraw, ...
Now that we've seen other formats and understand what are expectation among all of them, let's build a way to save our colors.
Has previously said, we will use the JSON format, in that way it will be easier to parse for an online program or an online database.
Here is the start of our color file :
If we want to ensure compatibility with QTX files, we need equivalent for following keys :
If we want to add the CxF compatibility let's add equivalent for:
From this we do support QTX, CxF and CGATS format. They would work but we would still loss any other kind of information. The way we store spectral data give us every information we need : we could eventually store spectral data with irregular step.
ArgyllCMS does provide spectral curve with a 3-3-4 steps such as 380, 383, 386, 390, 393, 396, 400, ...
Adding color spaces
Every software does not include a spectral converter to get Lab values, so it would be nice to save them as well BUT to get Lab values (or XYZ ones) we require a white reference and an observer angle value. The perfect thing would be to include full white reference object but that's a little overkill for a true use of the color. But let at least give the possibility to it by specifying the white reference with a reserved name (among standards).
Or with a detailed white reference (tip: that is the exact same structure than a color but with a light type):
Let's merge the white reference with our main color object to get a more specific way to save it
From this point we do have a color with enough information for a RIP or many other softwares but you might want to get more color space values of your measured color. Let's add them inside a colorspace field.
How should we encode our color values ? This is a complicated question since RGB is from 0 to 255, XYZ is from 0 to 1, Lab is 0 to 100 for L value, -125 to 125 for a and b values but every thing else is from 0 to 100. We may even need to encode a CMYKOG (O: Orange, G: Green) values.
The best is still to keep the data untouched and so saving data colors "as it": no rounding or mathematical formula required.
Basically, everything that is not RGB (or Lab, XYZ, Lch ...) is CMYK so it should be encoded from 0 to 100.
Where is the profile info used for conversion ?
Since the profile has already been used to get the RGB, CMYK or NCLR (N -> 1, 2, 3, ... color channel) color value, we do not need it anymore so it is not require to specify it again. But we can still add the information if you want into a metadata field. This field is made to store whatever information you may use to include context.
The spectral data is the best way to communicate color without data loss, because you get Lab, XYZ and every other color space value from it. But the same color could have different spectral data (and so another Lab, XYZ, etc values) if you change your spectrophotometer configuration (Filter and specular component mode). That's what batches field is for : saving measurements of the same color but in another configuration mode.
The batch data should follow the same structure than the main color but should not include another batches field into it, only the main color should have one. Everything included into the batch data should be impacted data by the filter change, every thing else is inherited from the main color.
If we include every thing that has been explained until here, we should have a file that looks like this:
This file structure might not be perfect but tend to be as complete as possible. It mixe the use that can be made of data and takes into account colorimetric issues of the printing and graphic world. It is web focused and the JSON format is among one of the most used in the world because it is easily readable for both humans and computers.