›

[Renoncé] Pixels d'une image

berfisberfis Membre
juin 2014 modifié dans API AppKit #1

Bonsoir,


 


Rien à  faire pour lire les pixels d'une image 64x64 comme celle de la pièce jointe. J'ai essayé l'exemple de Mala sans succès.


 


Je me doute que je dois traiter un vecteur de pixels de 64x64 (4096 positions) mais comment le "lire" de façon à  savoir si le pixel est noir (ou non-transparent éventuellement) ?


 


Essai:




NSString *imgPath = [[NSBundle mainBundle] pathForImageResource:@HWalls];

NSData *data = [NSData dataWithContentsOfFile:imgPath];

NSBitmapImageRep* bitmapImageRepOri = [NSBitmapImageRep imageRepWithData:data];

unsigned char *pixPtrOri = (unsigned char *)[bitmapImageRepOri bitmapData];

long bufferLength = [bitmapImageRepOri pixelsHigh]*[bitmapImageRepOri pixelsWide];

int pix = 0;

while( pix<bufferLength )

{

NSLog(@%d = %d,pix, pixPtrOri[pix+3]);

pix=pix+4;

}

Tentative infructueuse. Pourriez-vous me souffler la réponse?


Réponses

  • MalaMala Membre, Modérateur
    #2

    Mon exemple est basé sur une image N&B sans couche alpha et avec une taille de 2028 pixels pour avoir un alignement optimal (la largeur d'une NSBitmapImageRep peut être plus grande que la taille de l'image pour des raisons d'optimisation des performances pour certains traitement.).


     


    Donc première étape déterminer l'agencement des pixels de ton image. Un NSLog sur la descritpion de ta bitmapImageRepOri cela te donne quoi?


  • berfisberfis Membre
    juin 2014 modifié #3

    Bonjour Mala,


     


    ça me donne ça:


     


    2014-06-18 23:45:41.606 Labyrinthe[20275:303] NSBitmapImageRep 0x6000000ba400 Size={64, 64} ColorSpace=(not yet loaded) BPS=8 BPP=(not yet loaded) Pixels=64x64 Alpha=NO Planar=NO Format=(not yet loaded) CurrentBacking=nil (faulting) CGImageSource=0x6000001636c0


     

    En fait je suis aussi passé à  une bitmap NB, ça prend moins de place et cela suffit pour l'emploi que je veux en faire.

     

    J'essaie de faire une version différente de celle fournie par Apple dans leur exemple de SpriteKit, en utilisant deux bitmaps 64x64 pour placer les "parois" de mon labyrinthe: une bitmap pour les murs horizontaux et une autre pour les murs verticaux, fournis en pièces jointes.

     

  • berfisberfis Membre
    #4

    Bon j'ai laissé tomber, c'était une fausse bonne idée. Si la lecture des pixels et la création des murs est triviale pour la partie horizontale, elle devient franchement alambiquée pour la création des murs verticaux.


     


    J'ai mis les coordonnées de départ, la longueur et le sens (horizontal/vertical) dans une plist, ça prend 7K (moins que les deux images) et c'est plus rapide. ça m'apprendra à  coller aux exemples d'Apple...


  • DrakenDraken Membre
    #5
    Plus rapide, mais moins intuitif pour la personne créant le labyrinthe.
  • CéroceCéroce Membre, Modérateur
    #6
    Pourquoi n'utilises-tu pas un bête fichier texte ?
    ça reste intuitif à  éditer, et relativement facile à  parser.
  • DrakenDraken Membre
    #7
    Pas bête le fichier texte. En plus ça permet d'ajouter des objets spéciaux si nécessaire (monstres, bonus, pièges, etc. ..)
  • MalaMala Membre, Modérateur
    juin 2014 modifié #8

    Désolé, je suis pas souvent connecté à  Internet en ce moment.


     


     


    Si je reste sur la question de départ, ton code il sensé faire quoi exactement? Ce que je constate:


    - tu passes tes pixels 3 par trois (cf pixPtrOri[pix+3]) alors que tu n'as qu'une compostante noir & blanc.


    - et derrière tu fais "pix=pix+4;" Ok. Pourquoi pas, mais ça n'avance à  rien on est bien d'accord? Car pas de couche alpha non plus...


  • MalaMala Membre, Modérateur
    #9


    J'ai mis les coordonnées de départ, la longueur et le sens (horizontal/vertical) dans une plist, ça prend 7K (moins que les deux images) et c'est plus rapide. ça m'apprendra à  coller aux exemples d'Apple...




    Heu, non. Plus simple je veux bien mais plus rapide j'en doute... Fais grimper la taille de ton labyrinthe un peu. On va rire. ;)


     


    Au passage, quel intérêt d'utiliser deux buffers pour les murs horizontaux et verticaux?

  • MalaMala Membre, Modérateur
    #10

    Dans mon exemple je travaille sur une manipulation de pixels où je n'ai pas à  me soucier de l'espace 2D. Je parcours donc mon image comme un buffer 1D. Dans ton cas, tu dois juste extrapoler tes coordonnées X/Y pour ton labyrinthe 2D. Donc cela donnerait quelque chose du genre:



    
for( int y=0; y<height; y++)
    
{
    
    for( int x=0; x<width; x++)
    
    {
    
        pixPtr[width*y+x] = ... -valeur du pixel x/y-
    
    }
    
}

  • berfisberfis Membre
    #11

    Ce ne serait sans doute pas une grande difficulté si je créais une sprite par pixel. Mais j'aurais voulu limiter le nombre d'objets, surtout si ce sont des murs inertes.


     


    Donc il me faudrait faire une sorte d'automate qui "débuterait"  un rectangle et le "terminerait", du genre (pseudocode):


     


    si (pixel noir)


        si (rectangle == NON)


            rectangle = OUI


            débuter rectangle


    sinon


       si (rectangle == OUI)


            créer rectangle


            rectangle = NON


    ...


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