Discussion :

[ToTo13]

Bonjour,

je travaille depuis quelques temps sur des images couleurs et j'utilisais des BufferedImage de type TYPE_INT_RGB.

Mais voilà, mes recherches me poussent à devoir travailler dans des espaces de couleur comme HLS, HSV et YCbCr.
En regardant dans la JavaDoc, j'ai vu que l'on pouvait spécifier un ColorModel lors de la création d'un BufferedImage, auquel on pourrait éventuellement spécifier un autre espace de couleur que RGB. C'est justement ce qui m'intéresse.

Mais tout ceci me semble plutôt compliqué et je souhaitais savoir s'il y avait des classes permettant de modifier plus ou moins automatiquement l'espace des couleurs ?

- Si oui, pourriez vous m'aider ?
- Si non, est ce vous pourriez m'aider à créer des images dans l'espace de couleur que je souhaite ? Et surtout, comment ensuite accéder aux pixels (lecture/écriture), car certains espaces sont codés sur [0...1] et non plus sur des entiers.


Merci par avance.

[pseudocode]

Mais voilà, mes recherches me poussent à devoir travailler dans des espaces de couleur comme HLS, HSV et YCbCr.
En regardant dans la JavaDoc, j'ai vu que l'on pouvait spécifier un ColorModel lors de la création d'un BufferedImage, auquel on pourrait éventuellement spécifier un autre espace de couleur que RGB. C'est justement ce qui m'intéresse.

Il y a deux aspects à prendre en compte:

- la classe ColorModel sert à convertir un champ de bits ( dépendant du format de stockage de l'image ) représentant un pixel en composantes et réciproquement. Elle sert donc principalement à gerer le format "binaire" des données.

- la classe ColorSpace qui sert a convertir une valeur RGB ou XYZ dans l'espace de couleur propre au ColorSpace. Elle sert donc principalement a pouvoir passer dans une représentation commune (RGB ou XYZ).

Pour ton problème, il faut commencer par récupérer une instance de ColorSpace (généralement depuis une instance de ICC_Profile), créer une instance de ColorModel utilisant le ColorSpace, puis créer la BufferedImage en utilisant le ComponentColor.

On peut alors utiliser des operateurs comme "ColorConvertOp" pour passer d'une BufferedImage classique (RGB) dans la BufferedImage qu'on vient de créer.

[ToTo13]

Bonjour,

et merci pour ces informations, je viens de regarder tout cela.

Récupérer le ColorSpace ok, mais pour la création du ColorModel... il y a certaines informations que je maîtrise plutôt mal . Le constructeur a la forme suivante : ColorModel(int pixel_bits, int[] bits, ColorSpace cspace, boolean hasAlpha, boolean isAlphaPremultiplied, int transparency, int transferType).
- pixel_bits = nombre de bits servant à coder un pixel.
- int[] bits = nombre de bits par canal.
Mais comment est ce que cela est stocké exactement ? Car j'en ai besoin pour savoir quelles valeurs attribuer.
Je m'explique : certains espaces codent sur [0..1], voire sur [-1...1], donc des réels. Est ce la même chose dans un BufferedImage ?
Auquel cas il faudrait que je passe le nombre de bits codant un double pour chaque canal. Or lors de la récupération des valeurs des pixels, on peut utiliser les méthodes suivantes :
- getRaster().getSample(x, y, Channel)
- getRaster().getSampleDouble(x, y, Channel)
Mais, la valeur est la même, seul le type change : par exemple on récupère pour une image en niveaux de gris 170 et 170.0. Ce qui laisserait penser que la valeur est entière et simplement convertie en Double lors du getSampleDouble.

[pseudocode]

Bonjour,

et merci pour ces informations, je viens de regarder tout cela.

Récupérer le ColorSpace ok, mais pour la création du ColorModel... il y a certaines informations que je maîtrise plutôt mal . Le constructeur a la forme suivante : ColorModel(int pixel_bits, int[] bits, ColorSpace cspace, boolean hasAlpha, boolean isAlphaPremultiplied, int transparency, int transferType).
- pixel_bits = nombre de bits servant à coder un pixel.
- int[] bits = nombre de bits par canal.
Mais comment est ce que cela est stocké exactement ? Car j'en ai besoin pour savoir quelles valeurs attribuer.
Je m'explique : certains espaces codent sur [0..1], voire sur [-1...1], donc des réels. Est ce la même chose dans un BufferedImage ?
Auquel cas il faudrait que je passe le nombre de bits codant un double pour chaque canal. Or lors de la récupération des valeurs des pixels, on peut utiliser les méthodes suivantes :
- getRaster().getSample(x, y, Channel)
- getRaster().getSampleDouble(x, y, Channel)
Mais, la valeur est la même, seul le type change : par exemple on récupère pour une image en niveaux de gris 170 et 170.0. Ce qui laisserait penser que la valeur est entière et simplement convertie en Double lors du getSampleDouble.

C'est à toi d' "expliquer" comment sont stockées les données binaires = c'est à toi de coder les methodes du ColorModel.

Mais bon, pas de panique !

Si ton format de stockage est standard, tu as des implémentations de ColorModel existantes. Par exemple "ComponentColorModel", qui te permet de spécifier un colormodel avec "n" bits par composante, le tout stocké dans un tableau linéaire.

Exemple usuel: chaque pixel est constitué de 3 composantes de 8 bits, le tout stocké dans un tableau byte[]

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ColorModel myColorModel = new ComponentColorModel(
	myColorSpace, new int[] {8,8,8}, false, false, ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);

Le 1er parametre, myColorSpace, indique l'instance du ColorSpace qui sera utilisé (par exemple pour "afficher" dans un label, ou par les opérateurs).

[ToTo13]

C'est à toi d' "expliquer" comment sont stockées les données binaires = c'est à toi de coder les methodes du ColorModel.

Mais bon, pas de panique !

Si ton format de stockage est standard, tu as des implémentations de ColorModel existantes. Par exemple "ComponentColorModel", qui te permet de spécifier un colormodel avec "n" bits par composante, le tout stocké dans un tableau linéaire.

Exemple usuel: chaque pixel est constitué de 3 composantes de 8 bits, le tout stocké dans un tableau byte[]

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ColorModel myColorModel = new ComponentColorModel(
	myColorSpace, new int[] {8,8,8}, false, false, ColorModel.OPAQUE, DataBuffer.TYPE_BYTE);

Le 1er parametre, myColorSpace, indique l'instance du ColorSpace qui sera utilisé (par exemple pour "afficher" dans un label, ou par les opérateurs).

Merci :-)
Mais ça n'a vraiment pas l'air gagné pour stocker des doubles sur [-1,1]. En plus il faut mettre des vérifications car dans les images classiques, si on rentre 256 pour un TYPE_BYTE_GRAY, cela met 0 au pixel.

Je pensais que le format avait été prévu et que c'était déjà existant.
Je crois que je vais me contenter de faire des conversions pixel à pixel et au cas où si je dois faire plusieurs calculs un peu lourds, travailler directement avec des tableaux de Double[width, height, nbChannels].

Merci pour ton aide.

[pseudocode]

Hum. A mon avis je n'ai pas compris ce que tu voulais faire.
- Stocker des double dans le raster ?
- Convertir les bits du raster en double ?

[ToTo13]

En bref, je voulais savoir si on pouvait appeler une méthode (ou la programmer si c'était possible et pas monstrueux) qui convertisse un BufferedImage RBG aux formats HLS, HSV (HSB), YCbCr (YUV), CIELab tout en gardant la classe BufferedImage.

Car certains des espaces de couleurs que je souhaite utiliser ont un codage sur [-1,1], [0,360], etc. et non pas sur [0...255] ou [0...65535].

[pseudocode]

En bref, je voulais savoir si on pouvait appeler une méthode (ou la programmer si c'était possible et pas monstrueux) qui convertisse un BufferedImage RBG aux formats HLS, HSV (HSB), YCbCr (YUV), CIELab tout en gardant la classe BufferedImage.

oui, en créant ta propre instance de ColorSpace.

Car certains des espaces de couleurs que je souhaite utiliser ont un codage sur [-1,1], [0,360], etc. et non pas sur [0...255] ou [0...65535].

oui aussi, en créant ta propre instance de ColorModel.

Je vais essayer de coder vite fait un exemple.

[ToTo13]

Je vais essayer de coder vite fait un exemple.

Oh grand manitou
Juste un petit exemple, après je fais tout ça comme un grand

[pseudocode]

Bon, voila un exemple d'une BufferedImage utilisant un ColorSpace HSV, ou chacune des 3 composantes est un "float".

Le Colorspace

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
class HSVColorSpace extends ColorSpace {
 
	// internal use : conversion RGB/XYZ
	private ColorSpace csrgb = ColorSpace.getInstance(ColorSpace.CS_sRGB);
 
	protected HSVColorSpace() {
		super(ColorSpace.TYPE_HSV, 3);
	}
 
	@Override
	public float[] fromCIEXYZ(float[] colorvalue) {
		return fromRGB(csrgb.fromCIEXYZ(colorvalue));
	}
 
	@Override
	public float[] fromRGB(float[] rgbvalue) {
		int r = (int)(255*rgbvalue[0]);
		int g = (int)(255*rgbvalue[1]);
		int b = (int)(255*rgbvalue[2]);
		return Color.RGBtoHSB(r, g, b, null);
	}
 
	@Override
	public float[] toCIEXYZ(float[] colorvalue) {
		return csrgb.toCIEXYZ(toRGB(colorvalue));
	}
 
	@Override
	public float[] toRGB(float[] colorvalue) {
		Color c = Color.getHSBColor(colorvalue[0], colorvalue[1], colorvalue[2]);
		return new float[] {c.getRed()/255f, c.getGreen()/255f, c.getBlue()/255f};
	}
 
}

Création d'une BufferedImage utilisant un ColorModel de type float sur ce ColorSpace

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public BufferedImage createHSVBufferedImage(int w, int h) {
 
	ColorSpace myColorSpace = new HSVColorSpace();
 
	//  ColorModel : components stored as float 
	ColorModel myColorModel = new ComponentColorModel(
			myColorSpace, null, false, false, ColorModel.OPAQUE, DataBuffer.TYPE_FLOAT);
 
	// create new (empty) image
	WritableRaster raster = myColorModel.createCompatibleWritableRaster(w, h);
	BufferedImage image = new BufferedImage( myColorModel, raster, false, null);
 
	return image;
}

Exemple d'utilisation pour copier une BufferedImage JPG "classique" dans cette nouvelle BufferedImage.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
BufferedImage orig = null;
try {
	orig = ImageIO.read( new File("tiger.jpg") );
} catch (IOException e) {
	e.printStackTrace();
}
 
int w = orig.getWidth(), h=orig.getHeight();
 
// create new (empty) image
BufferedImage dest = createHSVBufferedImage(w,h);
 
// fill new image (pixel by pixel)
for(int y=0;y<h;y++)
	for(int x=0;x<w;x++)
		dest.setRGB(x, y, orig.getRGB(x, y));
 
// display the new image like a normal BufferedImage
/* Display.bufferedImage(dest); */
 
// get components of one pixel
float[] pixel = new float[3];
dest.getRaster().getDataElements( 0 /*X*/ , 0 /*Y*/, pixel);
System.out.println(pixel[0]+" "+pixel[1]+" "+pixel[2]);

[ToTo13]

Merci INFINIMENT, je vais regarder tout cela en détail et faire tout ce qu'il faut.

Petite question annexe (et oui, une de plus) : si je souhaite convertir de RGB vers YCbCr, je sais qu'il y a deux normes possibles (CIE 601 et 709). Sais tu qu'elle est la norme qui est utilisée pour la conversion si j'utilise le code que tu viens de me donner (en l'adaptant à YUV bien entendu) ?

[pseudocode]

Petite question annexe (et oui, une de plus) : si je souhaite convertir de RGB vers YCbCr, je fais qu'il y a deux normes possibles (CIE 601 et 709). Sais tu qu'elle est la norme qui est utilisée pour la conversion si j'utilise le code que tu viens de me donner (en l'adaptant à YUV bien entendu) ?

Heu... j'ai (encore) pas compris.

Tu mets les formules que tu veux dans ta classe ColorSpace (dans les 2 méthodes fromRGB() et toRGB()).

[millie]

Les perfs. ne sont ils pas complètement plombés avec un espace de couleur maison HSL en cas d'application d'un opérateur standard ?

[pseudocode]

Les perfs. ne sont ils pas complètement plombés avec un espace de couleur maison HSL en cas d'application d'un opérateur standard ?

Si, bien sur. Les opérateurs "standards" utilisent soient la représentation RGB ou XYZ, et doivent donc passer par les 2 fonctions correspondantes du ColorSpace. Dans mon exemple ci dessus, si j'avais utilisé "ColorConvertOp" pour copier une image d'ans l'autre les perfs seraient catastrophiques : pour chaque pixel on fait la conversion (RGB) -> XYZ -> (RGB -> HSV)

Mais bon, si on crée son propre ColorSpace/ColorModel c'est généralement qu'on veut faire des traitements spécifiques, donc on créera ses propres opérateurs.

[ToTo13]

Merci pour les explications.
Ma question était : je vais mettre les formules pour la conversion dans le ColorSpace, ok. Mais après, lorsque je vais entrer des valeurs au format YCbCr. Est ce qu'elles vont repasser dans les conversions ou être stockées directement ?
Parce que si je dois continuer à entrer les valeurs au format rgb et que le colorspace les converties à chaque affectation, je n'ai aucun intérêt à utiliser tout ce système, mieux vaut travailler avec des tableaux de doubles.

[pseudocode]

Merci pour les explications.
Ma question etait : je vais mettre les formules pour la conversion dans le ColorSpace, ok. Mais après, lorsque je vais entrer des valeurs au format YCbCr, est ce qu'elles vont repasser dans les conversions ou être stockées directement ?

Les données sont toujours stockées dans ton format (YCbCr) dans le Raster.

Donc si tu utilises les méthodes de BufferedImage.getRaster(), ca fait une simple copie des valeurs. Mais si tu utilises les méthodes de BufferedImage (genre setRGB()) alors ca passe par les fonctions de conversion du ColorSpace avant d'aller dans le Raster.

[ToTo13]

Merci c'est parfait, c'est ce que je voulais.
Je vais faire tous les tests nécessaires :-)

[ToTo13]

Bonsoir,

je viens de tester et tout fonctionne parfaitement, c'est exactement ce que je cherchais.

J'ai tout de même des questions de clarification (j'aime bien comprendre ce que je fais).

- 1 - Lorsque tu fais "ColorSpace.getInstance(ColorSpace.CS_sRGB)", tu récupères une instance du ColorSpace, mais pourquoi CS_sRGB ?
J'ai essayé aussi avec CS_LINEAR_RGB et les résultats sont similaires. Pourquoi ?
Qu'elle est exactement la différence car pour l'instant tout ce que je vois est identique :-(.


- 2 - Lorsque l'on instancie le ColorModel, on passe DataBuffer.TYPE_FLOAT. Mais on peut aussi passer TYPE_DOUBLE. Mais lorsque l'on crée notre propre classe du ColorSpace que l'on passe au ColorModel , les arguments des méthodes (entrée/sortie) sont tous des float.
Donc on peut se demander à quoi sert de type TYPE_DOUBLE, à moins que l'on puisse surcharger les méthodes ?

[pseudocode]

- 1 - Lorsque tu fais "ColorSpace.getInstance(ColorSpace.CS_sRGB)", tu récupères une instance du ColorSpace, mais pourquoi CS_sRGB ?
J'ai essayé aussi avec CS_LINEAR_RGB et les résultats sont similaires. Pourquoi ?
Qu'elle est exactement la différence car pour l'instant tout ce que je vois est identique :-(.

CS_sRGB (espace sRGB) est un espace non linéaire (gamma ~= 2.2 ). C'est le colorspace habituel utilisé par les écrans LCD/CRT. C'est également celui utilisé dans les fichiers images récents (jpeg2000, png, ...).

C'est également celui utilisé "nativement" dans Java. C'est à dire que les méthodes "toRGB()/fromRGB()" de CS_sRGB ne modifient pas les valeurs.

On peut donc simplement "copier" directement les valeurs d'un jpeg2000/png dans le raster, ca revient au meme que de passer par ce colorspace qui ne fait rien .

CS_LINEAR_RGB est un espace linéaire. Les méthodes "toRGB()/fromRGB()" de CS_LINEAR_RGB font donc la transformation gamma afin de fournir des valeurs sRGB.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// exemple de transformation pour des niveaux de gris (r=g=b)
CS_sRGB.fromRGB(0,0)=0,0  <->  CS_LINEAR_RGB.fromRGB(0,0)=0,000000
CS_sRGB.fromRGB(0,1)=0,1  <->  CS_LINEAR_RGB.fromRGB(0,1)=0,349233
CS_sRGB.fromRGB(0,2)=0,2  <->  CS_LINEAR_RGB.fromRGB(0,2)=0,484520
CS_sRGB.fromRGB(0,3)=0,3  <->  CS_LINEAR_RGB.fromRGB(0,3)=0,583764
CS_sRGB.fromRGB(0,4)=0,4  <->  CS_LINEAR_RGB.fromRGB(0,4)=0,665156
CS_sRGB.fromRGB(0,5)=0,5  <->  CS_LINEAR_RGB.fromRGB(0,5)=0,735317
CS_sRGB.fromRGB(0,6)=0,6  <->  CS_LINEAR_RGB.fromRGB(0,6)=0,797665
CS_sRGB.fromRGB(0,7)=0,7  <->  CS_LINEAR_RGB.fromRGB(0,7)=0,854246
CS_sRGB.fromRGB(0,8)=0,8  <->  CS_LINEAR_RGB.fromRGB(0,8)=0,906249
CS_sRGB.fromRGB(0,9)=0,9  <->  CS_LINEAR_RGB.fromRGB(0,9)=0,954604
CS_sRGB.fromRGB(1,0)=1,0  <->  CS_LINEAR_RGB.fromRGB(1,0)=0,999924

- 2 - Lorsque l'on instancie le ColorModel, on passe DataBuffer.TYPE_FLOAT. Mais on peut aussi passer TYPE_DOUBLE. Mais lorsque l'on crée notre propre classe du ColorSpace que l'on passe au ColorModel , les arguments des méthodes (entrée/sortie) sont tous des float.
Donc on peut se demander à quoi sert de type TYPE_DOUBLE, à moins que l'on puisse surcharger les méthodes ?

C'est vrai que l'interface de ColorSpace ne prend en compte que des "float". Si tu veux plus de précision, il va falloir surcharger les méthodes et également réécrire tes propres opérateurs pour qu'ils utilisent la définition de la classe et pas celle de l'interface.

[Jack Sparrow]

Pour récapituler ce que tu dis (voir si j'ai bien compris) :

Pour sRGB et linearRGB, on a des valeurs pour chaque canaux qui vont de 0 à 255.
La différence étant que certaine zone sont plus étalées dans sRGB (a priori les zones clairs).

Quand je lis la spéc. de BufferedImage pour get/setRGB, je vois que l'on travaille en fait toujours en sRGB.
Du coup, ma question est : Quand utilise-t'on le ColorSpace LinearRGB ?