[IMAGE] Comment dire que deux couleurs sont "proches"?

Comment dire que deux couleurs sont "proches"? [IMAGE] - Algo - Programmation

Marsh Posté le 20-02-2003 à 17:06:39    

Salut,
Pour mon projet je dois faire un programme qui diminue le nombre de couleurs d'une image (nombre de couleurs qu'il faut pouvoir choisir) en coloriant les zonez ayant "a peu pres la meme couleur" d'une seule couleur.
 
Le truc c'est que si c'est facile avec juste une composante (R V ou B) c'est facile ( entiers de 0 à 255) y'a qu'a dire "235 est proche de 233"
 
Ce qui me pose problème c'est quand on prend le triplet de couleurs  auriez vous des idées ou des liens qui pourraient m'aider ?
merci d'avance

Reply

Marsh Posté le 20-02-2003 à 17:06:39   

Reply

Marsh Posté le 20-02-2003 à 17:12:33    

Imagine un cube dont les axes sont les trois composantes RVB. La distance entre deux couleurs (deux points du cube) peuvent donc se déterminer par la formule de distance classique :
 
dist = sqrt ((Rb - Ra)² + (Vb - Va)² + (Vb - Va)²)


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 20-02-2003 à 17:15:46    

Tu peux définir une "distance" entre 2 couleurs, pour ça il "suffit" de donner une norme (au sens mathématique du terme).
Par exemple, tu peux considérer que tes couleurs sont des points (en 3 dimensions) dont les coordonnées sont les composantes X,Y et Z, et tu considères que 2 couleurs sont proches quand leur distance est inférieure à une valeur donnée.
 
par exemple : (r1,v1,b1) et (r2,v2,b2) sont "proches" <=>
 (r1-r2)² + (v1-v2)² + (b1-b2)² <= alpha
 
Maintenant, je ne suis pas sûr du rendu final  :sarcastic:
Bon ca remonte à longtemps tous ces trucs, je dis peut-être des grosses bêtises  :D
 
Edit : grilled


Message édité par dsls le 20-02-2003 à 17:16:05
Reply

Marsh Posté le 20-02-2003 à 17:17:12    

kadreg > ça c'est la théorie, ensuite il y a tout ce qui est notion de contraste, bruit, etc. (et des tas de notions donc je n'ai même pas idée de l'existance :D) et faire un programme capable de faire ce genre de choix doit se comporter comme l'oeil, ce qui est très difficile.
 
mais bon, si c'est un simple projet d'info, cette technique devrais suffir ;)


Message édité par MagicBuzz le 20-02-2003 à 17:17:31
Reply

Marsh Posté le 20-02-2003 à 17:37:36    

merci beaucoup les gars  :hello:  je pense que ca va me faire avancer  
 
MagicBuzz > deja si j'arrive a colorier ca et ca de la meme couleur je serais content  :D


Message édité par sashock le 20-02-2003 à 17:38:24
Reply

Marsh Posté le 20-02-2003 à 17:44:32    

je dirais vert caca d'oie :D
 
(pas pu m'empêcher de dire une connerie ;))
 
Ben la solution donnée ci-dessus est donc la bonne, je sais juste que pour chaque couleur, il faut pondérer en fonction de différents intervalles de luminosité pour un meilleur résultat.
 
=> Pour les couleurs très sombres, surtout dans les bleus, tu peux prendre un alpha plus grand que pour des couleurs plus claires dans les vert par exemple, sâchant que cette pondération est impactée par la luminosité ambiante de la zone de traîtement.
 
En effet, dans une image claire avec des éléments sombres, tu peux mettre tous les éléments sombres de la même couleur, on fait pas la différence, par contre, dans une image sombre, on fait plus la différence entre deux couleurs sombres et qui sont proches... enfin, c'est vachement balèze quoi...
 
En fait, ce phénomère résulte d'une chose très simple :
 
tu es dans la rue, en plein été, tu lis un bouquin.
 
l'indice de réflexion du papier est mettons de 98% et celui de l'encre de 2%
 
Le soleil fourni 10000 "unité de liminosité".
 
Donc, papier = 9800 de lumière réfléchie
Encre = 2000 de lumière réfléchie
 
Maintenant, tu rentre dans une pièce avec des rideaux. La luminosité est de 1/100° de dehors.  
 
Le papier renvoie dont 980 unité, et l'encre 20 unités.
 
Donc l'encre à l'extérieur renvoie plus de lumière que le papier à l'intérieur, et pourtant, ton oeil voit toujours le papier blanc à l'intérieur, et l'encre noire à l'extérieur.
 
Il faut donc prendre cela en compte, sinon tu risque de trop réduire certaines couleurs dont on fait bien la différence, et ne pas assez réduire certaines couleurs dont on ne fait pas la différence de toute façon.
 
En espérant que t'as bien compris mon explication ;)
 
PS: je tiens cet exemple de la thèse qu'avait fait un de mes profs sur la compression MPEG-2


Message édité par MagicBuzz le 20-02-2003 à 17:50:17
Reply

Marsh Posté le 20-02-2003 à 18:16:03    

merci pour tes explications  :hello:

Reply

Marsh Posté le 20-02-2003 à 20:48:19    

euh, oui, les chiffres sont pas bons :D
 
je les ai mis comme ça, ça fait longtemps que j'ai lu l'article alors j'ai pas du tout les chiffres en tête. ;)
 
mais dans l'article, les chiffres étaient donnés à partir de mesures, et en plein soleil, l'encre noire d'un livre réfléchit près du double de lumière que du papier blanc dans une pièce ombragée, hors on voir toujours le blanc blanc, et le noir noir, ct ça qu'il fallait en retenir ;)
 
donc dans les distances entre couleur, il faut absolument prendre en compte lanotion de luminosité ambiante afin d'utiliser un écart différent selon la luminosité des couleurs étudiées.
 
il y a ensuite les histoires de contraste entre couleur, et aussi, les phénomènes de bruit.
 
par exemple, si tu prends en photo un texte, il n'y a aucun bruit dans les lettres, donc les couleurs doivent être restituées de façon très exacte, et les formes absolument inchangées. si tu prends en photo un bac à sable, ou une pelouse, il y a beaucoup de bruit, donc si les couleurs sont moins précises et que les formes ne sont pas respectées, on ne verra pas la différence. Idem pour un dégradé, ou les couleurs doivent continuer à être les plus exactes possibles.
 
Je cherche un exemple.


Message édité par MagicBuzz le 20-02-2003 à 20:56:22
Reply

Marsh Posté le 20-02-2003 à 21:05:11    

JPG qualité 100% :
http://www.manga-torii.com/files/maximum.jpg
 
JPG qualité 30%:
http://www.manga-torii.com/files/minimum.jpg
 
PNG-8 16 couleurs :
http://www.manga-torii.com/files/16couleurs.png
 
Le sable est à peine impacté par les pertes de définition, le bruit étant insensible aux erreurs liées à la réduction de qualité/couleurs. Le texte et le dégradé devient selon les cas par contre complètement dégueulasses.


Message édité par MagicBuzz le 20-02-2003 à 21:05:37
Reply

Marsh Posté le 20-02-2003 à 21:09:39    

Autrement dis, tu prends les composantes YUV et non RGB.
 
Edit: oups j'avais pas lu....je laisse pour la postérité!


Message édité par Willyzekid le 20-02-2003 à 21:10:31

---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 20-02-2003 à 21:09:39   

Reply

Marsh Posté le 21-02-2003 à 11:39:46    

Juste comme ça une petite image d'exemple pour le coup du livre et de la luminosité ambiante, c'est là qu'on se rends compte que le domaine de l'imagerie c'est le gros bordel :D
 
http://www.manga-torii.com/files/illusionoptiquecases.jpg

Reply

Marsh Posté le 21-02-2003 à 12:18:21    

MagicBuzz a écrit :

Juste comme ça une petite image d'exemple pour le coup du livre et de la luminosité ambiante, c'est là qu'on se rends compte que le domaine de l'imagerie c'est le gros bordel :D
 
http://www.manga-torii.com/files/i [...] ecases.jpg


c'est exactement a cette image que j'ai pensé qd j'ai lu ton post avec l'exemple du livre c vrai que ca parait dingue mais bon apres c'est les mechanismes de la vision et de l'interpretaion des images percues par le cerveau qui rentre en compte( :pt1cable: ).

Reply

Marsh Posté le 21-02-2003 à 13:31:19    

MagicBuzz a écrit :

Juste comme ça une petite image d'exemple pour le coup du livre et de la luminosité ambiante, c'est là qu'on se rends compte que le domaine de l'imagerie c'est le gros bordel :D
 
http://www.manga-torii.com/files/i [...] ecases.jpg

:ouch: faut le faire ( le decoupage/comparaison) pour le croire.
Sinon, c'est sur (intuitivement) que si tu veux adapter ta quatification des couleurs a la preception de l'oeuil, il vaut mieux passer en YUV

Reply

Marsh Posté le 21-02-2003 à 13:33:42    

Si je comprends bien quand je fixe une "distance" et si je prends une couleur précise sont "proches" de ma couleur les pixels (couleurs) se situant dans la sphere de rayon "distance" autout de la couleur choisie?
 
Hmm pas evident pour un parcours total de l'image, disons que je ne vois pas par quel bout le prendre.
 
Et sij'extrapole La sphère en question par un cube? comme ca au moins je pourrais partager l'image (gros cube rvb) en petits cubes alors qu'avec la sphereil peut y avoir des pixels qui sont dans aucune zone  
comment ca je  raconte n'importe quoi?  :pt1cable:  :pt1cable:  
fo ke j reflechisse encore ...

Reply

Marsh Posté le 21-02-2003 à 13:51:24    

saSHOCK a écrit :

Si je comprends bien quand je fixe une "distance" et si je prends une couleur précise sont "proches" de ma couleur les pixels (couleurs) se situant dans la sphere de rayon "distance" autout de la couleur choisie?
 
Hmm pas evident pour un parcours total de l'image, disons que je ne vois pas par quel bout le prendre.
 
Et sij'extrapole La sphère en question par un cube? comme ca au moins je pourrais partager l'image (gros cube rvb) en petits cubes alors qu'avec la sphereil peut y avoir des pixels qui sont dans aucune zone  
comment ca je  raconte n'importe quoi?  :pt1cable:  :pt1cable:  
fo ke j reflechisse encore ...


 
En fait, les solutions proposees etaient pour comparer deux couleurs, dans ce cas, l'erreur quadratique moyenne semble appropriee. Mais si tu veux quantifier ( reduire le nb de couleurs), tu vas effectivement passer par un decoupage en "cubes"

Reply

Marsh Posté le 21-02-2003 à 19:17:09    

saSHOCK a écrit :

Si je comprends bien quand je fixe une "distance" et si je prends une couleur précise sont "proches" de ma couleur les pixels (couleurs) se situant dans la sphere de rayon "distance" autout de la couleur choisie?
 
Hmm pas evident pour un parcours total de l'image, disons que je ne vois pas par quel bout le prendre.
 
Et sij'extrapole La sphère en question par un cube? comme ca au moins je pourrais partager l'image (gros cube rvb) en petits cubes alors qu'avec la sphereil peut y avoir des pixels qui sont dans aucune zone  
comment ca je  raconte n'importe quoi?  :pt1cable:  :pt1cable:  
fo ke j reflechisse encore ...


Pour le MPEG par exemple, ils découpent l'image en un damier, et se basent là dessus. D'où les défauts d'images avec des carrés bizarres quand c'est trop compressé, ou qu'il y a des gros applats de couleur

Reply

Marsh Posté le 21-02-2003 à 19:36:37    

MagicBuzz a écrit :


Pour le MPEG par exemple, ils découpent l'image en un damier, et se basent là dessus. D'où les défauts d'images avec des carrés bizarres quand c'est trop compressé, ou qu'il y a des gros applats de couleur

:heink: heu la, je vois pas trop le rapport


---------------
get amaroK plugin
Reply

Marsh Posté le 21-02-2003 à 19:59:37    

ca m'interesse carrement packe la je galere un peu rien qu'a faire une approximation "cubique"
pour moi pour que b soit ds le meme cube de cote "dist" que a il faut que :

Code :
  1. (2*abs(Rb - Ra)<=dist)and(2*abs(Vb - Va)<=dist)and(2*abs(Bb - Vb)<dist))


ou bien  

Code :
  1. (abs(Rb - Ra)+abs(Vb - Va)+abs((Bb - Vb)))<dist


je sais pas trop lequel mais a priori aucun puisque cette methode devrait etre plus "tolerante" que la sphérique or ca se vérifie pas sur les essais que j'ai faits...


Message édité par sashock le 21-02-2003 à 20:00:41
Reply

Marsh Posté le 21-02-2003 à 20:03:21    

a moins que pour tester il faille prendre le double du "dist" de la methode spherique puisque ca en est le rayon et non pas le diametre ...

Reply

Marsh Posté le 21-02-2003 à 22:47:12    

saSHOCK a écrit :

Salut,
Pour mon projet je dois faire un programme qui diminue le nombre de couleurs d'une image (nombre de couleurs qu'il faut pouvoir choisir) en coloriant les zonez ayant "a peu pres la meme couleur" d'une seule couleur.
 
Le truc c'est que si c'est facile avec juste une composante (R V ou B) c'est facile ( entiers de 0 à 255) y'a qu'a dire "235 est proche de 233"
 
Ce qui me pose problème c'est quand on prend le triplet de couleurs  auriez vous des idées ou des liens qui pourraient m'aider ?
merci d'avance


 
En utilisant les API. En particulier Setpixel qui te retourne une valeur...

Reply

Marsh Posté le 22-02-2003 à 20:02:50    

bobuse a écrit :


 
En fait, les solutions proposees etaient pour comparer deux couleurs, dans ce cas, l'erreur quadratique moyenne semble appropriee. Mais si tu veux quantifier ( reduire le nb de couleurs), tu vas effectivement passer par un decoupage en "cubes"


Est'ce que je dois faire des cubes qui contiennent le meme nombre de couleurs ou juste decouper le gros cube de l'image en cubes reguliers(au quel cas il pourrait  y avoir des cubes sans aucune couleur a linterieur ...)?
pour moi si j'ai N couleurs et que j'en veux n il faut que je fractione le cube representant l'image en n cubes(qui ne seront pas forcément des cubes) contenant chacun N/n pixels?
 
Si quelqun comprend ce que je raconte  
pouvez vous me dire si je suis sur la bonne voie?
Merci

Reply

Marsh Posté le 05-03-2003 à 16:44:40    

up

Reply

Marsh Posté le 05-03-2003 à 16:59:35    

Si ca t'interesse j'ai fini par trouver un algo fais des recherches sur "Median-cut" :hello:

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed