Bonjour à tous,
Avant tout un grand bravo et un grand merci pour l'existence de ce forum!
Voilà mon tracas :
Dans le passé (pas si lointain car à l'époque en GFA Basic sur Atari 1040 ST ;)), j'aimais à jouer avec les différents modes graphiques, et notamment l'eXclusive OR ou XOR, avec du noir et du blanc. Je tente le même avec processing avec la fonction blend() et le mode EXCLUSION (que je suppose être le XOR...).
Et là, je ne comprends pas pourquoi, après plusieurs superpositions d'images en noir et blanc, on obtient du... gris!!!
Autre incompréhension : si les valeurs des largeurs et hauteurs sont identiques dans la fonction blend() entre image source et image cible (compensées par -1 dans le code que je soumets), il y a alors un contour sur les formes.
Qqun peut-il m'éclairer, svp?
PGraphics img1;
int nb = 2;
int x, y, a;
boolean bStop;
void setup() {
size(400, 400);
background(0);
img1 = createGraphics(400, 400, P2D);
img1.ellipseMode(CENTER);
img1.fill(255);
img1.noStroke();
smooth();
}
void draw() {
img1.beginDraw();
img1.background(0);
x = width/nb * int (random(nb+1));
y = int (width/nb * int (random(nb+1)));
a = width/nb*2;
img1.ellipse(x,y,a,a);
img1.endDraw();
blend(img1, 0, 0, width, height, 0, 0, width-1, height-1, EXCLUSION); //pourquoi -1 pour la taille de l'image cible???
}
void keyPressed(){
bStop = !bStop;
if (bStop)
noLoop();
else
loop();
}
Dernière modification par step (2010-06-21 18:02:02)
Hors ligne
Bonjour et bienvenue,
Une hypothèse : c'est peut-être du à des approximations dans les calculs, dans les calculs internes, les couleurs sont stockés dans des entiers de 32 bits (cf color_datatype. Et les opérations de BLEND se font par décalage de bits.
Si tu te sens de regarder en détail voila le code pour le mode blend / exclusion (d'après la source de PIMage):
/** * Cousin of difference, algorithm used here is based on a Lingo version * found here: http://www.mediamacros.com/item/item-1006687616/ * (Not yet verified to be correct). */ private static int blend_exclusion(int a, int b) { // setup (this portion will always be the same) int f = (b & ALPHA_MASK) >>> 24; int ar = (a & RED_MASK) >> 16; int ag = (a & GREEN_MASK) >> 8; int ab = (a & BLUE_MASK); int br = (b & RED_MASK) >> 16; int bg = (b & GREEN_MASK) >> 8; int bb = (b & BLUE_MASK); // formula: int cr = ar + br - ((ar * br) >> 7); int cg = ag + bg - ((ag * bg) >> 7); int cb = ab + bb - ((ab * bb) >> 7); // alpha blend (this portion will always be the same) return (low(((a & ALPHA_MASK) >>> 24) + f, 0xff) << 24 | (peg(ar + (((cr - ar) * f) >> 8)) << 16) | (peg(ag + (((cg - ag) * f) >> 8)) << 8) | (peg(ab + (((cb - ab) * f) >> 8)) ) ); }
Peut-être un élément de réponse tout en bas de cette page
« Finally, Aside, FWIW: the disclaimer should be that p5 uses "fast" code, not
necessarily "correct" code. No biggie, it seems most software does. A nitpicker would
find numerous "off by 1 division" problems in the blend code (including toxi's original
alpha blend and the new blend modes as i submitted) where >>8 or >>7 is used
when strictly speaking /255 or /127 should have been used. For instance, my own
version of exclusion (not intended for real-time use) reads "r1 + r2 - ((2 * r1 * r2) /
255);" because 255==1.0 not 256==1.0. In other words: (255*255)>>8 !=
(255*255)/255. But for real-time use the shifts are preferrable, and I doubt the
difference is significant for any practical application. »
Pour le décalage de -1, je ne sais pas...
ps : tu peux changer le titre de ton message après qu'il ait été posté (modifier en bas à droite)
Hors ligne
Merci bcp emoc pour cette réponse!
En effet, il semble que le calcul approximatif a été choisi au bénéfice de la rapidité, pas forcément de la qualité.
Le code pour le mode blend / exclusion ne me parle malheureusement pas. J'ai cru un moment que le souci pouvait provenir de P2D, spécifié en createGraphics mais pas en size dans le setup() de mon code. En fait, non.
Je pense soumettre ce trouble sur processing.org. Peut-être un calcul slow (optionnel) pourrait-il voir le jour pour un rendu plus exact? Par ailleurs, le liseret apparent autour des formes lorsque les positions et tailles des images source et cible sont identiques, reste pour moi un énorme mystère...
Je vous dirai.
P.S. : on peut tout modifier d'un message, sauf son titre, non?
Hors ligne
Tiens, tiens...
http://code.google.com/p/processing/iss … colspec=ID
Dernière modification par step (2010-06-24 17:46:24)
Hors ligne
Voila un point d'éclairé, ça ne t'avance pas vraiment parce que pour l'utiliser avec des cercles, ça risque d'être coton.
L'auteur du patch a même proposé un moyen "correct et rapide"
// aside: the way to do alpha blends "correct AND fast" is to prebuild a 64K
// lookup of RGB*A/255 indexed by (RGB<<8)+A [or (A<<8)+RGB], don't know if
// you wanna go there though...
pps : pour les modifications de sujet, il me semble que c'est possible, à moins que ça ne soit plus possible une fois que quelqu'un a répondu ?
Hors ligne
Hi all,
Back from the states avec des réponses
1. les gris sont clairement dûs à des approximations de calcul, apparemment plus hard en mode EXCLUSION. Je ne sais si un jour on pourra obtenir des résultats graphiques exacts (j'aimerai bien!)...
2. les contours sur les formes sont un bug de scaling avec la fonction blend(), bug accepté en priorité medium.
Ci-dessous le fil des discussions :
http://forum.processing.org/#topic/25080000000037162
http://code.google.com/p/processing/iss … colspec=ID
@+
ppps : non, j'avais essayé avant mon 2nd message, et il n'y avait déjà aucun champ titre.
Hors ligne
Pages: 1