Cover for Numérisation de la couleur et sauvegarde des données article

Introduction

Une couleur apparait comme quelque chose de complexe à comprendre car nous utilisons à la fois du CMJN pour en parler, voir du RGB, du Lab, XYZ, Lch, ... Tous ces espaces de couleurs peuvent décrire une seule et même couleur en fonction de l'usage que l'on en fait.

De ce fait, la meilleure manière de parler d'une couleur est au travers de ses données spectrales. Ces données sont mesurées directement depuis un spectrophotomètre. Cependant nous pouvons avoir différentes données spectrales pour une même couleur suivant les conditions de mesure de votre spectrophotomètre : sans lumière toutes les couleurs apparaissent noires, donc utilisons une source lumineuse mais laquelle ? Devons nous utiliser une lumière normalisée de type D50 ou D65 ? Devons nous utiliser un filtre UV? Un filtre polarisant ? Il semblerait qu'il n'y ai pas une manière unique de sauvegarder les données d'une couleur.

Il y a encore une long chemin avant d'atteindre une réelle numérisation de la couleur du monde réel...

Voici à quoi ressemble les données spectrales d'une couleur

Pourquoi avons nous besoin d'une numérisation précise de la couleur ?

Il y a deux objectifs principaux concernant la numérisation de la couleur : figer et partager.

Figer

De la même manière qu'une photo le ferait, en figeant une couleur vous créez un point fixe dans le temps en ce qui concerne la perception de votre couleur (car la perception d'une couleur varie suivant le temps : en vieillissant, en brulant à cause du soleil, ...). Vous pourrez l'utiliser comme une référence au même titre que Pantone le fait avec ses encres ou en créant un historique pour vérifiez l'évolution de votre couleur au travers le temps.

Partager

Il y a des laboratoires qui mesurent et travaillent la couleur au sein d'un même bâtiment mais le cadre de travail que peut avoir une couleur dépasse bien souvent les quatre murs du lieu où elle a été mesurée. Dans ce dernier cas, le fabricant en ayant reçu la commande pourrait ne jamais voir la couleur qui a servi de référence et qu'il est sur le point de reproduire, il a donc besoin de savoir précisément ce qu'il est sensé faire et à quoi cela devrait ressembler.

Il y a bien d'autres raisons de numériser les couleurs mais faisons simple pour aujourd'hui.

Méthodes de sauvegardes actuelles

Il existe de nombreuses manières de sauvegarder de l'information autour d'une couleur, en effet plusieurs entreprises très connues dans le secteur comme X-Rite ou DataColor y ont pensé et conçus leur propres formats.

Le problème est que chaque format est très différent l'un de l'autre et cela rend la compatibilité avec les logiciels assez complexe. Ce problème était un point de départ du logiciel Coraye : créer un pont entre les différents logiciels en développant l'import et l'export de n'importe quel type de fichier (ex : permettant de transformer un fichier QTX en fichier CxF). Pour atteindre cet objectif, nous avons eu besoin de penser à une façon de structurer les données autour de la couleur afin de devenir compatible avec n'importe quel jeu de donnée tout en gardant la donnée intacte (pas d'arrondis ou de transformation).

Notre première pensée fût de partir d'une structure de fichier déjà existante et déjà utilisée pour ensuite l'appliquer à tous les autres fichiers, mais nous n'avons pas trouvé la structure parfaite du fait des exigences trop spécifiques du logiciel Coraye. Ajoutons à cela que nous avons choisi de travaillez avec les technologies du web et l'encodage JSON alors que les fichiers standardisés sont souvent propriétaires et compliqués à décoder.

Le format QTX

Créé par DataColor, le fichier QTX stock les données de manière à ce que chaque couleur soit indépendante l'une de l'autre. Vous trouverez donc des informations relative au spectrophotomètre utilisé pour la mesure ou la date de mesure pour chacun des échantillons.

Il y a également la possibilité d'y insérer des "batches" (= "lots" en français). Il s'agit de mesure répétées mais dans des conditions différentes (ex: avec un spectro différent).

Il est aussi possible d'y ajouter des clés avec des valeurs personnalisées sans problème. Cela permets au fichier de grandir en terme d'architecture sans avoir besoin de passer à un format V2 qui ne serait plus compatible avec les versions précédentes.

[STANDARD_DATA 0]
STD_NAME=11-0605 TCX
STD_GUID=3B5F4330-4B43-715F-4146-BB2B4146BB2B
STD_DATETIME=1304360181,
STD_REFLPOINTS=36,
STD_REFLINTERVAL=10,
STD_REFLLOW=400,
STD_VIEWING=%R LAV  SCI UV 400
STD_X=76.039398,
STD_Y=79.696068,
STD_Z=79.106171,
STD_R=68.957001,71.864998,72.008003,72.107002,72.460999,73.196999,74.137001,75.147003,75.987000,76.930000,77.723000,78.228996,78.500999,78.888000,79.075996,78.955002,78.995003,79.988998,81.500000,82.607002,83.119003,83.142998,83.023003,83.170998,83.910004,85.121002,86.570999,87.936996,89.249001,90.633003,91.738998,92.385002,92.737000,92.898003,92.920998,92.829002,
STD_MEASDLL_PARAMS=Manufacture:unknown,Model:CE7000A,Serial number:unknown,FirmwareVersion:unknown,Geometry:d/8,Specular component:I,MeasSpot:N/A,MeasArea:LAV ,UV-Filter%:UVEXC ,UV-Cutoff:None,MeasurementType:R,MeasurementSource:Instrument,Number of bands:36,Start band:400,Bandwidth:10,Correlation:Off,
STD_INST_TYPE=CE7000A
DCC_JOB_COMMENT=
Vendor Name=
Vendor Number=
Mill=
Dyehouse=
Vendor Email=
Retailer Name=
Brand=
Division=
Department=
Season=
Delivery Number=
Retailer Email=
Color Name=
Color Number=
Fiber=
Fabric Style=
PID=
Submit Number=
Labdip_Number=
Date Submitted=
User Name=
PRG_PALETTE_PROGRAM=
PRG_COLOR_PROGRAM=
PRG_COORD_PROGRAM=
PRG_DATE_DUE=
PRG_DATE_SUBMIT=
PRG_DATE_REVIEW=
PRG_ITEM_STATUS=
PRG_ITEM_TYPE=
PRG_JOB_IDENTIFIER=
PRG_FORMAT_FILE=
Sauvegarde d'une seule couleur au format QTX
Pour:
- Il est possible d'ajouter plusieurs couleurs différentes dans un même fichier
- Il est possible de personnaliser le contenu associé à une couleur
- Lisible pour les humains
Contre:
- Format non standard (Nécessite un algorithme spécifique pour l'interpréter)
- Contenu répétitif
- L'ajout de clés personnalisés au même niveau que les autres requiert un algorithme particulier pour les traiter (la donnée peut éventuellement être perdu si le logiciel qui interprète le fichier ne comprend pas ce que PRG_DATE_REVIEW=XXXXX signifie)
- Rempli de clés inutilisées (rend la lecture du fichier pour un humains plus compliquée) qui rend le fichier plus lourd que ce qu'il ne devrait être
- Compliqué à utiliser avec de simples outils tel qu'XCEL

Le format CxF

Créé par X-Rite, le fichier CxF est un format complexe qui permet le stockage de nombreuses informations, du Lab aux valeurs spectrales incluant les métadonnées. C'est un format complet qui permet une personnalisation complète de la donnée. Mais ce qui semble être une fonctionnalité clé peut également s'avérer être un piège : la sur-personnalisation rend la lecture difficile de ce qui est vraiment essentiel.

Ajoutons à cela que le format XML contient beaucoup de contenus répétitif. Il est possible d'y remédier en parti en définissant des métadonnées communes à plusieurs couleurs mais cela ne fait qu'amplifier la difficulté de lecture.

<?xml version="1.0" encoding="utf-8"?>
<cc:CxF xmlns:cc="http://colorexchangeformat.com/CxF3-core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <cc:FileInformation>
    <cc:Creator>Coraye</cc:Creator>
    <cc:CreationDate>2018-07-16T19:30:53.225Z</cc:CreationDate>
    <cc:Description/>
  </cc:FileInformation>
  <cc:Resources>
    <cc:ObjectCollection>
      <cc:Object ObjectType="Standard" Name="Orange" Id="C0">
        <cc:ColorValues>
          <cc:ColorCIELab ColorSpecification="S0">
            <cc:L>90</cc:L>
            <cc:A>78</cc:A>
            <cc:B>125</cc:B>
          </cc:ColorCIELab>
          <cc:ColorSRGB ColorSpecification="S0">
            <cc:R>255</cc:R>
            <cc:G>151</cc:G>
            <cc:B>0</cc:B>
          </cc:ColorSRGB>
        </cc:ColorValues>
        <cc:PhysicalAttributes>
          <cc:Quantity Units="TINT PERCENT">100</cc:Quantity>
          <cc:Opacity>100</cc:Opacity>
        </cc:PhysicalAttributes>
      </cc:Object>
    </cc:ObjectCollection>
    <cc:ColorSpecificationCollection>
      <cc:ColorSpecification Id="S0">
        <cc:MeasurementSpec>
          <cc:MeasurementType>Colorimetric_Reflectance</cc:MeasurementType>
          <cc:GeometryChoice>
            <cc:SingleAngle>
              <cc:SingleAngleConfiguration>Annular</cc:SingleAngleConfiguration>
              <cc:IlluminationAngle>45</cc:IlluminationAngle>
              <cc:MeasurementAngle>0.0</cc:MeasurementAngle>
            </cc:SingleAngle>
          </cc:GeometryChoice>
        </cc:MeasurementSpec>
      </cc:ColorSpecification>
    </cc:ColorSpecificationCollection>
  </cc:Resources>
</cc:CxF>
Couleur unique au format CxF
Pour:
- Fichier certifié
- Format standardisé pour communiquer la couleur
- Possibilité d'ajout de données personnalisées
Contre:
- Inclut un système de version qui demande aux logiciels d'être à jour pour interpréter le fichier
- Sur-personnalisation chaotique
- Le chemin des données n'est pas très intuitif (Où suis-je sensé écrire les valeurs spectrales ? Resources > ObjectCollection > Object > ColorValues > ColorCIELab pour obtenir les valeurs Lab)

Le format CGATS

Ce format n'est pas utilisé comme une table de couleur, c'est surtout un format utilisé pour sauvegarder les couleurs d'une mire à imprimer dans le cadre d'un test (calibration, caractérisation ou contrôle des impressions). Il peut cependant être considéré comme tel puisqu'il contient des informations semblables à ce que l'on pourrait trouver dans un fichier CxF ou QTX.

Le format est plutôt pratique pour une liste de couleurs qui partagent les même conditions (même support,  même spectrophotomètre). Il est simple à lire pour un humain ou un ordinateur et est également adapté pour un copié-collé vers une feuille excel. Vous pouvez ajouter des clés personnalisées et il n'existe pas de contenu répétitif.

Malheureusement, le format CGATS n'est pas très pratique pour la sauvegarde de table de couleur complète car toutes les couleurs partagent un contexte unique (XYZ & LAB & SPECTRAL), si l'une de ces données venait à manquer, l'intégralité du fichier serait illisible pour un ordinateur.

CGATS.17
ORIGINATOR	"Fiery Printer Profiler5.1.1.16"
FILE_DESCRIPTOR	"Output Characterisation"
CREATED	"2019-11-04 15:48:00"
INSTRUMENTATION	"X-Rite i1iO/i1iO2"
KEYWORD	INSTRUMENTATION_SN
INSTRUMENTATION_SN	""
KEYWORD	INSTRUMENT_FILTER
INSTRUMENT_FILTER	"M2 - UV cut"
KEYWORD	TRACKING_ID
TRACKING_ID	"7865-78T6"
KEYWORD	LAYOUT
LAYOUT	"1847 patches"
KEYWORD	MEASURED
MEASURED	"2019-11-04 16:12:53"
BEGIN_DATA_FORMAT
SAMPLE_ID	CMYK_C	CMYK_M	CMYK_Y	CMYK_K	XYZ_X	XYZ_Y	XYZ_Z	SPECTRAL_380	SPECTRAL_390	SPECTRAL_400	SPECTRAL_410	SPECTRAL_420	SPECTRAL_430	SPECTRAL_440	SPECTRAL_450	SPECTRAL_460	SPECTRAL_470	SPECTRAL_480	SPECTRAL_490	SPECTRAL_500	SPECTRAL_510	SPECTRAL_520	SPECTRAL_530	SPECTRAL_540	SPECTRAL_550	SPECTRAL_560	SPECTRAL_570	SPECTRAL_580	SPECTRAL_590	SPECTRAL_600	SPECTRAL_610	SPECTRAL_620	SPECTRAL_630	SPECTRAL_640	SPECTRAL_650	SPECTRAL_660	SPECTRAL_670	SPECTRAL_680	SPECTRAL_690	SPECTRAL_700	SPECTRAL_710	SPECTRAL_720	SPECTRAL_730
END_DATA_FORMAT
BEGIN_DATA
1	60.00	0.00	50.00	0.00	41.64	60.43	43.78	0.14773	0.17724	0.19816	0.23544	0.30003	0.36096	0.41560	0.47331	0.54287	0.62900	0.70874	0.75830	0.78469	0.79415	0.79218	0.78167	0.76566	0.73601	0.68953	0.63560	0.56756	0.48263	0.37687	0.27670	0.20821	0.16947	0.14420	0.12414	0.11660	0.12573	0.14979	0.18434	0.22296	0.24888	0.25621	0.26340
2	10.00	100.00	20.00	0.00	35.70	18.06	20.42	0.22300	0.27595	0.31391	0.34810	0.38639	0.38871	0.35439	0.29652	0.23688	0.17549	0.11434	0.07549	0.05133	0.02626	0.01216	0.01064	0.01226	0.01059	0.01216	0.04120	0.16407	0.36062	0.51761	0.59821	0.62715	0.64484	0.67501	0.71278	0.74878	0.77579	0.79784	0.81395	0.82720	0.83588	0.84080	0.84354
Deux premières couleurs d'un fichier CGATS
Pour:
- Facilement lisible
- Pas de contenus répétitif
- Peut sauvegarder des données spectrales avec un index des longueurs d'ondes personnalisées
- Facilement exportable vers des outils tel XCEL
Contre:
- Les couleurs doivent partager un contexte commun
- Chaque couleur doit suivre la même structure
- Le format text peut-être propice à des erreurs d'interprétation par un ordinateur (ex: s'il ne distingue pas le début de la fin de la donnée)

Les autres formats

Il existe bien d'autre formats qui sont conçus pour transmettre de l'information sur une couleur mais ils ne sont pas très efficaces et ne supportent pas les données spectrales. Ceci s'explique principalement que leur véritable rôle est de seulement de sauvegarder des tons directs et sont plus centré sur la conception graphique que sur l'impression.

Exemples de ces autres formats : Ase, Acb, Aco, Csv, Coreldraw, ...


Structurons la donnée d'une couleur !

Maintenant que nous avons fait un tour des différents formats et comprit quels sont les différentes possibilités de ces derniers, structurons les données de nos couleurs.

Comme dit précédemment, nous utiliserons le format JSON, de cette manière cela sera plus simple à analyser pour un program ou une base de donnée en ligne.

Voici le début de notre fichier couleur:

{}
Fichier JSON vide

Informations minimales

Si nous voulons assurer la compatibilité avec les fichiers QTX, nous nous devons d'établir une équivalence pour les clés suivantes:

  • STD_NAME (Nom de la couleur)
  • STD_DATETIME (Date de la Création/Mesure)
  • STD_REFLPOINTS + STD_REFLINTERVAL + STD_REFLLOW + STD_R (Données spectrales)

Si nous voulons ajouter la compatibilité avec le format CxF, ajoutons une équivalence pour:

  • Name (Nom de la couleur - Commun avec le format QTX)
  • ID (Identifiant unique au sein du fichier
  • GUID (Identifiant unique dans le monde entier)
  • ObjectType (Standard, Trial, Target, Substrate, Colorant, etc.)
  • Creation Date (Date de la Création/Mesure - Commun avec le format QTX)

Ce qui devrait nous donner à peu près ceci:

{
  "id": "CN1",
  "guid": "CORAYE-CN1",
  "name": "My Color Name 1",
  "created_date": "Thu May 07 2020 17:47:46 GMT+0200",
  "color_preview": [0, 0, 0], // Always RGB
  "type": "spot", // light, display
  "header": {
    "filter": "M0",
    "specular_component_mode": "SCE"
  },
  "spectrum": {
    "380": 0,
    "385": 0,
    "390": 0,
    "385": 0,
    ...
  },
  "cie": {
    "lab": [0, 0, 0],
    "xyz": [0, 0, 0],
    "observer": 2,
    "white_reference": {
      "name": "My Custom Illuminant", // Or reserved name "D50", "D65", "A", "B", "C", "E", ...
      "color_preview": [255, 255, 255],
      "type": "light",
      "cie": {
        "lab": [100, 0, 0],
        "xyz": [1, 1, 1]
      },
      "spectrum": {
        "380": 0,
        "385": 0,
        "390": 0,
        "385": 0,
        ...
      }
    }
  }
}
Un fichier couleur supportant les informations essentielles

Depuis ce premier jet, nous supportons déjà les informations essentielles contenus dans les formats CxF, QTX et CGATS. Tout fonctionnerait mais il manquerait toutes les métadonnées qui pourraient être renseignées dans les différents fichiers. La manière dont nous sauvegardons les données spectrales nous renseigne sur toutes les informations nous avons besoin et ce d'un seul coup : nous pourrions même enregistrer des valeurs spectrales comprenant un index de longueur d'ondes irrégulières.

ArgyllCMS fournit des courbes spectrales avec des écarts de 2-2-3 tel que 380, 383, 386, 390, 393, 396, 400, ...

Ajoutons les espaces de couleurs

Tous les logiciels n'incluent pas d'algorithme permettant la conversion des valeurs spectrales vers les valeurs Labs, il serait donc pertinent de les sauvegarder MAIS pour calculer les valeurs Lab (ou les valeurs XYZ) nous avons besoin de l'illuminant d'observation et de l'angle d'observation. La manière idéale de le faire serait de référencer complètement les informations sur cet illuminant d'observation mais se serait un peu exagéré pour l'usage que l'on va vraiment faire de la donnée (disons que se serait parfait pour les logiciels très poussés uniquement). Donnons alors la possibilité de faire les deux : soit en renseignant les données de manière précise, soit en renseignant le nom d'un illuminant de référence.

{
  "white_reference": {
    "name": "D50"
  }
}
Renseigner l'illuminant de référence en utilisant un standard

La version complète suivrait la même structure que la couleur à la différence prête qu'elle serait du type "light"

{
  ...
  "white_reference": {
    "name": "My Custom Illuminant",
    "color_preview": [255, 255, 255],
    "type": "light",
    "cie": {
      "lab": [100, 0, 0],
      "xyz": [1, 1, 1]
    },
    "spectrum": {
      "380": 0,
      "385": 0,
      "390": 0,
      "385": 0,
      ...
    }
  }
}
Illuminant de référence personnalisé avec un jeu de donnée complet

En fusionnant avec ce que l'on avait précédemment, nous devrions obtenir :

{
  "id": "CN1",
  "guid": "CORAYE-CN1",
  "name": "My Color Name 1",
  "created_date": "Thu May 07 2020 17:47:46 GMT+0200",
  "color_preview": [0, 0, 0], // Always RGB
  "type": "spot", // light, display
  "header": {
    "filter": "M0",
    "specular_component_mode": "SCE"
  },
  "spectrum": {
    "380": 0,
    "385": 0,
    "390": 0,
    "385": 0,
    ...
  },
  "cie": {
    "lab": [0, 0, 0],
    "xyz": [0, 0, 0],
    "observer": 2,
    "white_reference": {
      "name": "My Custom Illuminant",
      "color_preview": [255, 255, 255],
      "type": "light",
      "cie": {
        "lab": [100, 0, 0],
        "xyz": [1, 1, 1]
      },
      "spectrum": {
        "380": 0,
        "385": 0,
        "390": 0,
        "385": 0,
        ...
      }
    }
  }
}
Base d'un fichier couleur

À partir de là nous avons un jeu de donné suffisamment précis pour un RIP ou ou de nombreux autres logiciels mais il serait également intéressant de renseigner les valeurs des différents espaces de couleur. Ajoutons les dans un champ colorspace dédié.

{
  ...
  "colorspace": {
    "rgb": [0, 0, 0],
    "cmyn": [0, 0, 0, 0],
    "6clr": [0, 0, 0, 0, 0, 0]
  }
}
Contient toutes les valeurs convertit depuis des espaces de couleurs

Encodage de la couleur ?

Comment devrions nous coder la valeur ? C'ESTest une question complexe puisque les valeurs RGB sont encodées de 0 à 255, XYZ est de 0 à 1, Lab de 0 à 100 pour le L, -125 à 125 pour le a et le b mais tout le reste est de 0 à 100. On pourrait même avoir à encoder des valeurs CMJNOV (O: Orange, V: Vert).

Le meilleur serait de laisser la donnée intacte et de sauvegarder la donnée "telle quelle" : aucun arrondis ni aucune formule mathématique requise.

{
  "colorspace": {
    "rgb": [255, 255, 255]
  }
}
RVB est de 0 à 255 et CMJN ou GREY de 0 à 100

En regardant bien, tout ce qui n'est pas RVB (ou Lab, XYZ, Lch, ...) est CMJN et donc devrait se trouver encoder de 0 à 100.

Où se trouve l'information concernant le profile qui a servit à la conversion ?

Étant donné que le profile à déjà été utilisé pour obtenir les valeurs RVB, CMJN ou NCLR (N -> 1, 2, 3, ... canaux de couleurs), nous n'en avons plus besoin et donc il est inutile de le renseigner à ce stade. Mais il serait tout de même possible de renseigner l'information si vous le souhaitez dans le champs des metadata (métadonnées). Ce champ est fait pour stocker toute information qui pourrait être utile concernant le contexte autour de la couleur.

{
  "metadata": { // Whatever you want, this is a custom field
    "comment": "",
    "rgb_profile": "ADOBE98",
    "spectrophotometer": "MYIRO",
    "manufacturer": "Konica Minolta",
    "serial_number": null,
    "firmware_version": null,
    "area": "LAV",
    "source": "instrument",
    "correlation": false,
    "physical_attributes": {
      "dimensions": null,
      "quantity": null,
      "weight": null,
      "thickness": null,
      "gloss": null,
      "finish": null, // coated, matte, glossy, ...
      "substrate": null, // wood, paper, textile, ...
      "image": null, // binary or URI type
      "opacity": null,
      "attributes": null
    }
  }
}
Example of metadata context based on what CxF would suggest

Lots de couleurs

Les valeurs spectrales sont les meilleures données pour communiquer une couleur sans perte puisque l'on en déduira les valeurs Lab et XYZ puis n'importe quelle valeur d'un quelconque espace de couleur. Mais une même couleur peut avoir différent jeu de valeurs spectrales (et donc d'autres valeurs Lab, XYZ, ...) si vous changez la configuration de votre spectrophotomètre (Changement de filtre ou de réflexion optique ~specular component). C'est ce pourquoi le champs batches ("lots") est fait : sauvegarder les variances de mesure d'une même couleur mais dans une configuration différente.

{
  ...
  "batches": [
    {
      "color_preview": [0, 0, 0],
      "header": {
        "filter": "M1",
        "specular_component_mode": "SCE"
      },
      "spectrum": {
        "380": 0,
        "385": 0,
        "390": 0,
        "385": 0,
        ...
      },
      "cie": {
        "lab": [0, 0, 0],
        "xyz": [0, 0, 0],
        "observer": 2,
        "white_reference": {
          "name": "D50"
        }
      }
    }
  ]
}
Ajout d'une variante de mesure dont le filtre serait M1

Ce nouvelle échantillon de mesure suivrait la même structure que la couleur principale mais ne devrait pas inclure elle même de champs batches, seule la couleur principale devrait l'avoir. Tout ce qui serait renseigné dans cet échantillon serait nouveau par rapport à la couleur principale et tout ce qui ne serait pas renseigné serait "hérité" de la couleur principale : il s'agit ici de ne pas répéter inutilement du contenu sachant que l'information n'est pas très loin.

Exemple final

Si nous incluons tout ce que nous avons présenté jusqu'ici, nous devrions obtenir un fichier dont le contenu ressemblerait à ceci:

{
  "id": "CN1",
  "guid": "CORAYE-CN1",
  "name": "My Color Name 1",
  "created_date": "Thu May 07 2020 17:47:46 GMT+0200",
  "color_preview": [0, 0, 0],
  "type": "spot",
  "header": {
    "filter": "M0",
    "specular_component_mode": "SCE"
  },
  "spectrum": {
    "380": 0,
    "385": 0,
    "390": 0,
    "385": 0,
    ...
  },
  "cie": {
    "lab": [0, 0, 0],
    "xyz": [0, 0, 0],
    "observer": 2,
    "white_reference": {
      "name": "My Custom Illuminant",
      "color_preview": [255, 255, 255],
      "type": "light",
      "cie": {
        "lab": [100, 0, 0],
        "xyz": [1, 1, 1]
      },
      "spectrum": {
        "380": 0,
        "385": 0,
        "390": 0,
        "385": 0,
        ...
      }
    }
  },
  "colorspace": {
    "rgb": [0, 0, 0],
    "cmyn": [0, 0, 0, 0],
    "6clr": [0, 0, 0, 0, 0, 0]
  },
  "metadata": {
    "comment": "",
    "spectrophotometer": "MYIRO",
    "manufacturer": "Konica Minolta",
    "serial_number": null,
    "firmware_version": null,
    "area": "LAV",
    "source": "instrument",
    "correlation": false,
    "physical_attributes": {
      "dimensions": null,
      "quantity": null,
      "weight": null,
      "thickness": null,
      "gloss": null,
      "finish": null,
      "substrate": null,
      "image": null,
      "opacity": null,
      "attributes": null
    }
  },
  "batches": [
    {
      "color_preview": [0, 0, 0],
      "header": {
        "filter": "M1",
        "specular_component_mode": "SCE"
      },
      "spectrum": {
        "380": 0,
        "385": 0,
        "390": 0,
        "385": 0,
        ...
      },
      "cie": {
        "lab": [0, 0, 0],
        "xyz": [0, 0, 0],
        "observer": 2,
        "white_reference": {
          "name": "D50"
        }
      }
    }
  ]
}
Structure de la donnée couleur finale

Ce fichier ne prétend pas être parfait mais essaye d'être le plus complet possible. Il tient compte des problématiques et enjeux colorimétrique du monde de l'imprimerie et du graphisme tout en mêlant l'usage que l'on peut avoir des données. Il se concentre sur un format utilisé dans le web et le JSON se trouve également être l'un des formats les plus utilisés dans le monde (du fait également qu'il soit facilement lisible pour les humains et les ordinateurs).

Partager:

Publications récentes