[Traitement d'image] halo de lumière incrusté dans une image

Hello le monde! ;)

Je voudrais savoir comment créer un halo de lumière de couleur xxx dans une image (ex: une image.bmp) et l'incruster dans une image de fond.

L'image de travail de départ est toute noir (vide).
Le halo consiste a commencer par remplir un grand cercle de couleur comme le bleu sombre, de superposer un autre cercle de couleur plus clair vers le bleu, et etc.. pour arriver au milieu en réduisant le rayon d'un pixel à chaque fois.

Or, ce halo est dessiné dans un bitmap et c'est ce bitmap qu'il faut incruster sur un autre bitmap qui est elle une image non vide.

LE BUT: simuler un éclairage dans un jeu en 2 dimensions vue de haut à la sauce zelda.

Avez vous une idée de comment incruster une image dans une autre image comme le ferait si bien PhotoShop quand vous cliquez sur l'option éclairage...
Sinon connaissez vous un site qui montre L'ALGORITHME de l'incrustation.

Merci.
Séb.
8)

salut,

pour créer ton halo, j'utiliserais (je suis pas un expert dans ces trucs) des effets basés sur (d est la distance d'un point de la scène au centre du halo) :

- une gaussienne 2D (pour avoir un effet intense au centre et rapidement décroissant sur la périphérie) : luminosité proportionnelle à (exp(-d²/(2*g²))/sqrt(2*pi*g) ou g est l'écart-type qui te permettra, dans ce cas là, d'accentuer ou de diminuer l'intensité du halo)
- une décroissance en puit d'attraction (effet comme le précédent mais beaucoup plus appuyé) : luminosité proportionnelle à (1 / d²)
- une décroissance en demi-sphère (pour avoir un effet en cratère inversé) : luminosité proportionnelle au (1 - d)²

Quand à la fusion de 2 images c'est facile :

il te faut une opaciité a (comprise entre 0 et 1 ou entre 0% et 100%, si tu veux)

image_resultat = a * image_source1 + (1-a) * image source2;

-pour a = 0.0, image_resultat = image_source2
-pour a = 1.0, image_resultat = image_source1
-pour a = 0.5, image_resultat = (image_source1 + image_source2) / 2 (degré d'incrustation égal pour les 2 images)

En faisant varier a de 0 à 1 tu auras une incrustation plus ou moins prononcée.

Dans ton cas, mettons qu'on a :
- image_source : image de ta scène
- image_halo : image du halo
- image_resultat : image resultant de l'incrustation du halo dans la scène

dans ton cas, pour un pixel de coordonnées (i, j),

- si image_halo[i,j] = noir (vide), image_resultat[i,j] = image_source[i,j]
- si non, image_resultat[i,j] = a * image_halo[i,j] + (1-a) * image_source[i,j]

a toi de définir a entre 0 et 1 qui te convienne

A+

Flo.

salut,

j'y pense là maintenant, mais photoshop, gimp, etc., utilisent beaucoup de pattern pour certains de leur effets, comme l'effet "toile de peinture". Cet effet (la toile de peinture) n'est pas généré à la volée. C'est un pattern (un motif) qui est une image brute de la toile. La réalisation de l'effet constite ensuite seulement à faire une incrustation du motif (du bitmap de la toile brute) sur l'image source avec des parametres tels que le degré d'incrustation ou encore un parametre pour bruiter le motif original histoire de pas avoir une répétition à l'identique du même motif.

Il se peut que le halo se fasse aussi de la même façon. Car l'inconvénient de la méthode que j'ai donné précédemment est qu'elle donne un résultat identique radialement. Tu n'as pas les losanges croissant générés par un rayon qui vient droit sur la caméra (effet d'éblouissement)... En utilisant un motif d'un halo (dans ce cas tu peux utiliser un halo de gimp ou autre ou sur le net), tu aurais juste a faire l'incrustation de l'image halo avec l'image scène .... Puis pour faire varier tes halos, changer la teinte du halo, lui faire subir une rotation, ajouter du bruit, etc...

C'est tout ce que j'avais à dire :D

A+

Flo.

Salut Flo !

Je te remercie d'avoir tapé tout ce texte !
Je m'en suis fait une copie dans un fichier texte....

Bon alors! par où comencer....

Au sujet de la fusion et donc surtout de ton équation : R = (µ)F + (1-µ)B
En fait, j'utilise déjà cette technique mais le résultat n'est pas encore bon.
Je m'explique:

avec ce mode de fusion, quand je souhaite fondre mon halo dans l'image de fond: j'obtient un effet de "brouillard" au centre du halo, alors qu'avec PhotoShop, l'image et VRAIMENT illuminé! (le centre surtout qui prend une apparence très clair vers le blanc tandis que pour moi, au contraire l'image s'obcurci avec du bleu foncé)
Je veux dire qu'avec PShop, la lumière se propage bien et colore vraiment le fond.
Tandis qu'avec cette fusion on s'apercoit que ce n'est encore que fusion et non pas éclairage!

Il faut sans doute que je revois mon halo qui part au centre avec une couleur de (0,0,255) et s'obsurcie pour arriver à (0,0,0).
Je pense aussi qu'il faut augmenter la valeur de pixels du milieu et diminuer vers les cotés....

Qu'en penses-tu?

Salut,

En ce qui concerne l'incrustation :

en fait, dans la formule

R = (µ)F + (1-µ)B

ton µ doit être fonction de la distance d du pixel courrant au centre. Un truc du style (si F est le halo) :

µ(d) = (dmax - d) / dmax

ou dmax est le rayon maximal du halo

comme ça au coeur du halo ou d ~ 0, on aura un µ = 1 (on verra que le halo) et à la périphérie ou d ~ dmax, on aura un µ = 0 (on verra que l'image source).

Tu peux changer de formule pour avoir une incrustation plus prononcée au centre, etc ...

Par ailleurs, il te faut faire autre chose pour colorer l'image, pour l'illuminer.

Il faut modifier la luminance et la teinte de l'image source en fonction de la distance de chaque pixel au centre du halo. C'est-à-dire, passer dans l'espace HLS, modifier la luminance et la teinte du pixel, revenir en RGB, ainsi tu auras ton image originale teintée de la couleur du halo avec une luminosité modifiée et le tout en fonction du centre du halo.

Tu trouveras (si cette solution te convains) facilement de la doc sur le net pour changer la teinte d'une image, ainsi que sa luminance (peut être même sur le forum).

Mais tu peux déjà essayé de faire varier le dégré d'incrustation en fonction de la distance, ça devrait déjà donné qque chose de mieux. Quant à la solution de prendre un halo déjà fait (et non pas de se le construire soi-même), je ré-itère, ça me semble être la meilleure solution pour avoir un halo de bonne qualité.

A+

Flo.

Re - salut!

Je viens de me rendre compte que le terme halo peut porter à confusion.
En effet, il y a tout de même une différence entre un halo de lumière et une source lumineuse.
Une source lumineuse modifie tout le décor, le colorise et illumine réellement ce décor, tandis qu'un halo de lumière et localisé et ne s'étend pas comme la source. C'est même possible qu'il ne fasse aucune lumière autour de lui mais simplement un voile localisé de la couleur du halo.
Dans la cas d'un halo, il est évident que la simple fision et bonne (comme je l'avais dit plus haut, cela crée un effet de brouillard qui traduit un éblouissement sans rayons de lumière ni autres....)

Comme tu me l'a confirmé, il faut modifier la luminosité des pixels en fonction du centre du halo et non pas fondre 2 images.

Mais pour ma part, comme je fait un éditeur de niveau pour jeu en 2D, il faut que l'utilisateur place des sources lumineuses sur la carte et qu'il les paramêtre, donc je doit créer la source lumineuse moi même.
(en plus, ces sources lumineuse doivent PULSER dynamiquement).

Voila, je te remercie pour ta réponse.
et encore merci Flo !!!!
:wink:

Je ne suis aps rentré dans le détail des post précédent ; mais dont "but" m'intersse beaucoup .
Je n'y ai pas encore réfléchi , mais une implémentation de la lumiére en temps réel en 2D doit être assez sympatique ;)

Par contre, je vois mal ce que tu cherche a obtenir :
Si mes souvenirs sont bon , dans zelda3 , il y a ( ex -> egout du chateau au debut du jeu ), il y a un "halo" ; cercle autour du perso, et l'on voit uniquement dans ce cercle .
Si cce n'est pas , quel genre d'effet cherche tu a produire ? ( un sortilége, une lumiére venant d'un certain type d'objet ect ... ? ).

Ensuite, tu veux implémenter ca dans ton editeur de jeu c'est ca ?
Donc c'est du précalcul et pas du temps réél si je comprend bien . Ton "cercle" ne va donc pas bouger ? ( j'ai du mal a voir ce que tu cherche a avoir comme effet hihi , je susi curieux que tu me décrive ca ^^)

Bon, admetton que cette derniére possibilité soit la bonne , tu posséde donc un tableaux de pixel ( r g b a ) associé a ton image de départ ?
Avant d'aller plus loin et d'y réfléchir plus, je vais attendre quelque "lumiéres" de ta part :)

Sinon tu utilsie quel lib graphique ? sdl , openGL, directX ?
En tout cas, bonne chance, et tient nous au courant, ca minteresse :)

EDIT : j'ai relu un peu les postes précédent ; il est clair que a moins d'avoir des dizaines de halo différents, le plus simple est encore de le créer toi même , puis de jouer sur le blending pour incrusté ca non ? ( enfin la je suis pas certain que le résultat obtenu soit "jolie" mais bon ... meme pas certain du tout ... ) a tester ...

salut

Citation:

---

Mais pour ma part, comme je fait un éditeur de niveau pour jeu en 2D, il faut que l'utilisateur place des sources lumineuses sur la carte et qu'il les paramêtre, donc je doit créer la source lumineuse moi même.

---

Ce que je voulais dire c'est que si tu veux faire des sources complexes par le simple calcul, ça va être difficile. En plus ça rajoute du code à écrire tout ça et ça prend du temps de calcul. Ce que je ferais, c'est trouver une image de source lumineuse (ou plusieurs images de sources si t'en veux plusieurs) (ou te les fabriques sous gimp) puis de la /les rajouter dans ton projet de développement. Quand tu veux l'utiliser en un endroit donné, tu as juste à la rapatrier dans un buffer et puis de l'intégrer à la scène. Ca sera bcp plus rapide puis tu n'auras pas créer l'image durant l'éxécution.

La faire pulser, c'est pas compliqué ... il suffit juste d'un timer et de faire varier sa luminance (luminosité) ...

A+

Flo.

Bonjour tout le monde! :wink:

Alors voila ou j'en suis:

Pour répondre clairement à ta question Clad3,
Je souhaite programmer de A à Z un zelda en 2D avec une nouvelle histoire en béton, et des graphismes qui respectent le genre mais qui seront VRAIMENT amélioré (pour le coté artistique y a pas de problème) d'où un défi que je me suis lancé qui est de pouvoir placer dans le jeu des sources lumineuses dont l'intensité/couleur vari, le rayon bref, un paramétrage total. Ce genre de lumière devra être dynamique, c-a-d qu'elle peut très bien être une aura de lumière autour du joueur ou d'autres objets (DONC DYNAMIQUE!!) donc modifiant la luminosité du décor de façon dynamique!
Comme dans le jeu de rôle Diablo.
Ce genre de sources permettraient de simuler l'éclairage de torches de lampadaires, la simulation temps réelle du jour et de la nuit comme en 3D sauf que c'est en 2D.
J'ai bien conscience que c'est du travail, mais je suis REELLEMENT motivé.
Donc pour finir, c'est pas le simple disque jaune de l'ancien zelda sur supernes, mais une vrai source de lumière.

Pour continuer sur ces sources lumineuses, j'ai réussi a placer plusieurs sources qui s'incrustent parfaitement au décor avec une possibilité de réglage du rayon du point de lumière centrale et du d° de luminosité, et je remercie Flo. qui m'a mis sur la piste avec des equa. tel que les puissances ou l'utilisation de l'exponentielle().

Je ne peut obtenir cette qualité de lumière que par ajustage de la lumière du décor suivant un cercle et non pas une fusion avec un motif de halo car celle ci crée un effet de brouillard et de combinaison de couleur qui ne donne pas vraiment l'impression d'une source (cela va bien pour un halo comme dans photoshop).

Tout ceci pour répondre à ta question Flo.
Effectivement, comme tu le dit, ca prend beaucoup de temps de calcul.
J'avais fait un test consistant à bouger dynamiquement le centre de la source de lumière en fonction du pointeur souris donc le halo devait se déplacer en même temps que le pointeur sur l'image et c'est la ou ca crée des problèmes : c'est pas encore assez rapide.

SOLUTION:
gérer les sources en muti-tâches par threads (un thread s'occupe d'une source de lumière) et un sémaphore sécurise l'écran pour empêcher les threads de redessiner les halos tous en même temps.

OUTILS UTILISES:
Visual c++ v6.0
PhotoShop
les images sont en BMP (logique pour le traitement d'image)

Pour finir de répondre à ta question Clad3, je souhaite réellement construire un éditeur puissant avec lequel je vais construire les cartes des différents niveaus ainsi que paramétrer et placer les personnages, ennemis, BOSS, gérer l'IA, les scripts qui changent les textes, les actions, les sons (importation seulement), les calques dynamiques (exemple: ombre des nuages sur la carte, effets de reflets de l'eau, des surfaces)
Et que je puisse voir le tout en pseudo-action dans l'éditeur avant de lancer le jeu ou de lancer la carte courante (un peu comme dans l'éditeur d'Unreal Tournament 2000, 2004)

wow j'ai fait un petit roman là!
Cela répond mieux aux questions comme ca ?? :D ****

Si tu dois le faire uniquement par soft, t'es pas rendu du tout...
Avec Diablo II, par exemple, c'est l'API Direct3D qui s'occupe de 90% des calculs de lumière, avec moult accélération hardware... Voilà pourquoi ton jeu tourne à vitesse normale. Tu as d'ailleurs deux modes d'affichage sous D2 : "DirectDraw" et "Direct3D". Essaie les deux, constate l'impact sur les graphismes, tu verras que c'est plutôt flagrant.

Sans accélération hardware, un simple halo type SNES (=simple masque appliqué en blending sur l'image) risque déjà d'être trop long à calculer... Je te laisse imaginer si tu en as plein de petits !!!

JE ne m'y suis pas encore interessé, masi est-il possible de gérer dynamiquement de la lumiénre en 2D avec openGL ? ( on voit souvent ca en 3D, mais j'ignore si c'est jouable en 2D ...

En général, c'est quand même de la 3D, simplement la caméra et les textures sont calculées pour faire "comme de la 2D"...

Quand tu y réfléchis : une caméra (vue de dessus), des carreaux texturés formant une zone rectangulaire, d'autres "carreaux" avec des textures transparentes pour faire les sprites, ça fait de la 2D...
Le scrolling est assuré à l'ancienne : déplacement de caméra, rajout d'une ligne/colonne de carreaux dans la nouvelle direction + suppression de celle venant de disparaître... Pas très dur à implémenter, même si ça change quelques mentalités. On peut certainement améliorer en utilisant des textures construites à la volée, mais de toutes façons le nombre de polygones à l'écran est tellement réduit que même une carte pourrie sur une machine poussive tournera à 60 fps !! ;-)

Salut Mak Lak!

Tout ceci me pousse, d'après tes dires, à faire une appli. qui utilise OpenGL! GRRRRR!
Mais j'ai un doute tout de même!
Il y a de cela un petit bout de temps, j'avais fait une appli. qui ouvre un bitmap et qui le fait vrier de façon sinusoïdale en dynamique donc en temps réel, comme de l'eau en fait (j'appelerais ça une distorsion dynamique de l'image) comme on peut le voir dans certains jeu vidéo.

Pour cela je créais un buffer image, puis découpais des bandelettes horizontales de pixels et les collais dans mon bitmap de travail.
A chaque passage je décalais les bandelettes (de façon horizontales) suivant un sinus.
Et, en faisant du double tamponnage, ca marchait nickel (c'était super fluide!!) et pas besoin de faire de la 3D simulé en 2D.

Mon halo rame car l'éditeur est en MFC Single document!
Tandis que ma distorsion dynamique de l'image était en Win32 Application.

Je reste certain que les halos en Win32 App. seront fluide (si c'est pas tout à fait fluide, je les programmerais en Multi-Threads)

Qu'en pensez-vous? Surtout toi Mak Lak....
Séb.

Citation:

---

Envoyé par cyber_N

Tout ceci me pousse, d'après tes dires, à faire une appli. qui utilise OpenGL! GRRRRR!

---

Non, tu peux aussi utiliser Direct3D, ou regarder si (par hasard) DirectDraw ne possède pas quelques primitives simples sur le sujet...

Citation:

---

Envoyé par cyber_N

Mais j'ai un doute tout de même!

---

En mode GDI ??? Moi, je n'en ai AUCUN !! :mrgreen:

Citation:

---

Envoyé par cyber_N

Et, en faisant du double tamponnage, ca marchait nickel (c'était super fluide!!) et pas besoin de faire de la 3D simulé en 2D.

---

Normal, ce sont de simples BitBlt qui sont utilisés : dans ce cas, même le GDI profite de l'accélération matérielle de la carte... Un blending ou une fusion d'images, c'est une autre paire de manches...

Citation:

---

Envoyé par cyber_N

Mon halo rame car l'éditeur est en MFC Single document!
Tandis que ma distorsion dynamique de l'image était en Win32 Application.

---

Il n'y a pas de différences vraiment significatives, surtout si ton canvas de dessin est géré "en brut de fonderie" en appelant directement le GDI...

Citation:

---

Envoyé par cyber_N

Je reste certain que les halos en Win32 App. seront fluide (si c'est pas tout à fait fluide, je les programmerais en Multi-Threads)

---

La synchro multithread pour faire ça ? Pas gagné... N'oublie pas que les threads "consomment" un peu de temps machine lors de la commutation, et que si tu n'as pas un multiprocesseur, le traitement ne sera pas réellement parallèle... En plus, le calcul du halo est assez intensif côté utilisation CPU !!
Un thread, c'est bien lorsqu'une tâche va nécessairement beaucoup attendre (lecture depuis le dur, attente d'évènements, etc...), ou pour "répartir" la charge CPU de manière plus ou moins cachée : ça n'est pas adapté à un traitement "lourd", car le thread consommerai alors la plupart du temps CPU disponible... Ou rendrait ses résultats très tardivement si sa priorité est faible.
Je ne suis pas sûr que ça te fasse gagner les performances attendues, bien au contraire.

Pour moi, la solution passe soit par un simple blending (ça consomme, mais la carte peut parfois aider à l'accélération du traitement même en GDI), soit par le passage à DirectDraw ou Direct3D. Faudrait que tu regardes ce qu'offre DirectDraw en matière de fonctionnalités avancées, j'avoue ne jamais m'être penché très sérieusement dessus.

Citation:

---

Qu'en pensez-vous? Surtout toi Mak Lak....

---

bha moi je pense quand meme :D ( bon j'ai peut-etre un niveau inférieur au tient, mais je réfléchi quand meme ^^ )

J'ai surement du zapper ca a la lecture, mais quelle lib graphique utilise-tu ?
Sinon , pourquoi te restreindre au bitmap ? Tu devrai utiliser des format gérant un canal alpha c'est trés pratique ( png ( kré bien celui la ) ou tga ect ... ) .

L'avantage d'une lib graphique c'est que ca te permet de gérer des choses bien plus rapidement ( dessein de primitive, certain effet ( lumiére ect .. ) plus rapidement qu'avec des algo trés lent fait a la main .

En tout cas, tient nous au courant de l'avancement de ton jeu :) ( si ta des screen, je suis preneur ! )

Citation:

---

Envoyé par Clad3

bha moi je pense quand meme :D ( bon j'ai peut-etre un niveau inférieur au tient, mais je réfléchi quand meme ^^ )

---

Sois pas vexé, mon cher Clad : c'est juste que cyber_N et moi, on se connaît en dehors de DVP... ;-)

non non, il n'y a pas de mal :) Il m'en faut bien plus pour être vexé, d'autant plus, que je n'irai pas nier que tu as plus de compétence que moi dans le domaine .

y'a pas d'mal ;)

ou alors, tu passes un maximum de chose en MMX / XMMX, ça te permettra de parelleliser les traitements sur les images ...

C'est pas la peine de partir dans de l'openGL ou du directX si c'est seulement un problème de temps de calcul sur du traitement d'images temps réel. Il vaut mieux dans ce cas partir sur des solutions adaptées au traitements d'images temps réel.

Par rapport en un code c++ classique et optimisé, une fusion d'images se fait jusqu'à 8 fois plus vite en XMMX, et 4 fois plus vite en MMX (on traite 8 pixels par 8 pixels ou 4 pixels par 4 pixels ). Pour faire un masque, on travaille alors directement en byte (on fait du 16 par 16 ou du 8 par 8 ).

Apres faut savoir coder en MMX. Et puis faut pas oublier de dupliquer le code pour les pc qui supporte pas le MMX et puis ceux qui supporte pas le SSE2.

C'est une solution comme une autre. C'est celle que j'envisagerais dans le cas ou je n'aurais pas du tout envisagé d'openGL ou autre au départ du projet.

A+

Flo.

C'est quoi que tu appelle un blending,

car moi mon halo ne fait que retoucher une image et éclaircir les bits de données au fur et a mesure que l'on se rapproche du centre indiqué.
donc pas de fusion, une retouche des bits seulement !!
(j'ai tout de même fait une copie des bits de données pour pouvoir revenir à l'image d'origine si nécessaire)

re-salut,

ton histoire me travaille ...

en fait, je pense que la meilleure manière (à mes yeux de naif :D ) de procéder serait la suivante (du moins la méthode à laquelle je me rattacherais si j'avais un problème de temps d'éxécution trop long) . J'essaierais de ramener l'affichage du halo sur une image, à une multiplication.

- j'ai une image source S
- j'ai une image résultat R
- j'ai un buffer B composé de coefficients à valeur comprise entre 0.0 et 1.0 (pour du SSE3) ou entre 0 et 255 (pour du c++ standart et dans ce cas un décalage de 8 bytes vers la droite te permettra de revenir avec un résultat de 0 à 255).

L'opération consisterait à faire une multiplication saturée (dont le résultat ne peut dépasser 255 par exemple) :

R = S * B0

Ces buffers Bi, à toi de les construire à l'initialisation du jeu de façon intelligente.

L'avantage est que le calcul suivant est facilement optimisable en c++ standart avec des astuces simples et carrément faisable en SSE. D'autre par, en choisissant convenablement ton ou tes buffers de coefficients (coefficients gaussiens puisque l'idée t'avais plu :D ), tu devrais pouvoir obtenir de jolis halos.

C'est une solution comme une autre pour éviter l'utilisation des exponentielles (à bannir au mieux d'un code temps réel).

A+

Flo.