Est-ce qu'il y a une limite à  la conso CPU?

13»

Réponses

  • HerveHerve Membre
    octobre 2015 modifié #62

    Merci Mala. Selon toi, je dois bien utiliser la méthode "setPixel: (tableau de 4 int) atX: (abscisse) andY:(ordonnée) " ? Je ne vois pas comment attendre les données sinon.


     


    Céroce, je m'amuse à  modifier un de tes effets, mais j'ai du mal à  comprendre comment récupérer les valeurs d'origine. Par exemple, en me souvenant de comment on programme un delay en audio, j'ai eu l'idée de créer un tableau de PixelsRGBx.


     


    Si je fais :




    PixelRGBx *lesPixW[width];

    for(y = 0; y < height; y++){
    for(x = 0; x < width; x++){
    lesPixW[x] = sourcePixelPtr;
    float xFl = x * 1.0 / width;
    NSUInteger posX = (NSUInteger) floorf(powf(xFl, 2.0)* width) ;
    PixelRGBx *nPixel = lesPixW[posX];

    destPixelPtr->comp.r = nPixel->comp.r;
    destPixelPtr->comp.g = nPixel->comp.g;
    destPixelPtr->comp.b = nPixel->comp.b;

    sourcePixelPtr++;
    destPixelPtr++;
    }
    }

    Je fais mon miroir déformant, mais si je crée le tableau, puis je m'en sers :



    for(y = 0; y < height; y++)
    {
    for (int p = 0; p < width; p++)lesPixW[p] = sourcePixelPtr;//je crée le tableau
    for(x = 0; x < width; x++)
    {//suite identique, en me servant du tableau
    }
    }

    c'est comme si j'utilisais sur toute la ligne y le même pixel : cela me fait des lignes continues et horizontales de couleurs.


     


    Je devine que comme en audio où on envoie des paquets de valeurs, on a un gros tableau de with*height valeurs de pixels, ce qui ne m'explique toutefois pas ce comportement. Par exemple, 



    destPixel = sourcePixel + 100;

    décale l'image vers la droite. Bref, serait-il possible que l'on m'explique comment cela marche? 


  • CéroceCéroce Membre, Modérateur
    L'adresse d'un pixel se calcule par:
    addr = addrBitmap + sizeOf(Pixel32)*(y*width + x);
    (encore une fois: voir la présentation)
    À partir de ça, tu peux accéder à  n'importe quel pixel dans la bitmap d'entrée ou celle de sortie.

    Et à  chaque fois que tu incrémentes le pointeur de 1, tu passes au pixel suivant.
  • HerveHerve Membre
    octobre 2015 modifié #64

    Merci Céroce. Voilà  de quoi s'amuser! :)


     


    Effectivement, c'est dans la doc... La formule est encore un peu "magique" pour moi, mais je peux m'en servir.


     


    C'est étonnant cette référence à  une structure additionnée à  des valeurs numériques. Je comprends un peu, c'est tout!


  • CéroceCéroce Membre, Modérateur
    octobre 2015 modifié #65
    Il faut être assez à  l'aise avec les pointeurs, certes... Mais c'est assez simple: les Pixel32 se suivent en mémoire. sizeOf(Pixel32) te donne la taille en octets de Pixel32.

    Fais quand même attention, les pointeurs sont typés: incrémenter un Pixel32* le fait pointer non pas 1 octet plus loin, mais 4, pour pointer sur la prochaine Pixel32. (Donc, il ne faut pas multiplier par sizeOf(Pixel32) si c'est un Pixel32*).
  • Oui, je comprends. J'ai commencé à  faire des "filtres déformants" avec des fonctions trigo ou des puissances, tant avec les ordonnées qu'avec les abscisses. C'est marrant.


     


    Ceci dit, j'ai regardé aussi ce que disait Mala au sujet des NSBitmapImageRep. Il dit travailler directement avec le data : est-ce avec une méthode similaire à  celles des effets? Je pense qu'il faut travailler avec "setPixel" et non "setColor" pour plus d'efficacité. Mais y a t-il mieux?


  • CéroceCéroce Membre, Modérateur
    octobre 2015 modifié #67
    Mala utilise exactement la même méthode. Il n'appelle pas setColor, ou setPixel, c'est trop lent. La différence est que c'est NSBitmapImageRep qui alloue la bitmap.
  • Ah, OK. Je comprends mieux. Merci.


    Je me suis bien amusé aujourd'hui, je tente de mettre tout cela dans mon soft (avec d'autres effets peut-être?) durant les prochains jours.


    Merci beaucoup à  tous.


Connectez-vous ou Inscrivez-vous pour répondre.