Equivalent de MemoryBlock

Eric P.Eric P. Membre
Bonsoir,

Je voudrais convertir 2 procédures écrites en REALbasic qui convertissent une picture en string et inversement.
Ces 2 procédures utilisent les MemoryBlock de REALbasic et la fonction colorValue des MemoryBlock et également la fonction EncodeBase64 de REALbasic.

Y-a-t-il des équivalents en Objective C ou C++ ?

Réponses

  • AliGatorAliGator Membre, Modérateur
    avril 2010 modifié #2
    MemoryBlock en RB c'est à  peu près l'équivalent de NSData en Cocoa.
    Le plus simple pour sérialiser une image c'est d'utiliser la méthode TIFFRepresentation de NSImage. Ca te donne directement un NSData. Tu n'as pas à  parcourir les pixels de l'image un par un ou quoi, il fait la conversion tout seul en une ligne de code.
    Pour faire la conversion inverse (NSData vers NSImage), il suffit d'utiliser [NSImage imageWithData].


    Ensuite, si vraiment tu veux en récupérer une chaà®ne NSString (bien que ça dépend pour quoi tu vas t'en servir, si c'est pour mettre dans une base ou dans un document ou quoi, tu peux directement faire ce genre d'opérations directement avec un NSData) :
    • soit tu crées une NSString directement avec les NSData, mais elle pourra alors contenir des caractères non imprimables (en fait ça reviendra au même, si tu utilises cette NSString pour l'écrire dans un fichier par exemple, que si tu utilisais directement les NSData)
    • soit si tu veux éviter de perdre des données si jamais tu les utilises dans un contexte où les caractères non imprimables peuvent être perdus (genre dans le corps d'une requête HTTP POST, etc), il faut alors effectivement encoder les NSData en Base64 (ce qui fera grossir la taille des données de 33%).

    Il n'y a pas de méthodes fournies dans le framework Cocoa pour faire cette conversion Base64, mais il existe sur le net des catégories toutes faites pour rajouter les méthodes encodeBase64 et decodeBase64 aux classes NSData et NSString, donc il suffit d'ajouter les .h et .m à  ton projet pour les utiliser.
  • Eric P.Eric P. Membre
    07:42 modifié #3
    Merci Ali,

    En fait mes fichiers RealCADD sont des fichiers textes.
    Et un dessin RealCADD peut contenir des objets image Bitmap qui peuvent être stockés soit en référence externe soit dans le fichier sous forme de string.
    La partie principale de l'encodage de la picture en string est :
    <br />&nbsp; For y = 0 to H<br />&nbsp; &nbsp; For x = 0 to W<br />&nbsp; &nbsp; &nbsp; MB.colorValue(i,24) = surface.pixel(x,y)<br />&nbsp; &nbsp; &nbsp; i = i+3<br />&nbsp; &nbsp; Next<br />&nbsp; Next<br />&nbsp; <br />&nbsp; //Return the string<br />&nbsp; Return EncodeBase64(MB.StringValue(0,Size))<br />
    


    où MB est un MemoryBlock.

    Dans iPocket Draw, j'ai le même format de fichier et je sais lire les fichiers RealCADD complets sauf les images.
    Bon sur un iPhone, il y a encore le problème du transfert des fichiers (actuellement en copiant-collant mais c'est une hidden feature) et sur iPad avec le transfert via iTunes mais que je n'ai bien sûr pas encore testé.
    L'idéal serait d'avoir une compatibilité totale de mes fichiers entre iPocket Draw et RealCADD.
    D'où ma recherche actuelle sur cette conversion de procédures REALbasic en Objective C.

    Je vais étudier les NSData et voir ce que je peux en tirer.
  • AliGatorAliGator Membre, Modérateur
    07:42 modifié #4
    Tu veux dire que quand tu stockes les images dans tes fichiers RealCADD, c'est du non compressé, directement les pixels de l'image, pas de compression TIFF ou JPG ? Donc L*H*3 octets pour une image de taille L*H en RGB ? Pfiou, pauvre disque dur :D

    Si tu veux vraiment les données bitmap, avec leur représentation pixel par pixel RGB, regarde du côté des NSBitmapImageRep et de la méthode bitmapData qui retourne un pointeur vers le buffer (zone mémoire) contenant tous les pixels.
  • Eric P.Eric P. Membre
    07:42 modifié #5
    dans 1272273253:

    Tu veux dire que quand tu stockes les images dans tes fichiers RealCADD, c'est du non compressé, directement les pixels de l'image, pas de compression TIFF ou JPG ? Donc L*H*3 octets pour une image de taille L*H en RGB ? Pfiou, pauvre disque dur :D

    A la base c'est du dessin vectoriel, les images sont accessoires et peuvent être utilisées en référence externe si elles sont trop grosses.
    Mais cela me permet d'avoir un format de fichier simple (texte) et compatible avec les 3 plateformes (Mac, Windows et Linux) sur lesquelles tourne RealCADD. Voire 4 maintenant avec l'iPhone/iPad.

    dans 1272273253:

    Si tu veux vraiment les données bitmap, avec leur représentation pixel par pixel RGB, regarde du côté des NSBitmapImageRep et de la méthode bitmapData qui retourne un pointeur vers le buffer (zone mémoire) contenant tous les pixels.

    Merci encore une fois Ali, je regarderai de ce côté quand j'aurai fini d'implémenter la cotation.
  • yoannyoann Membre
    07:42 modifié #6
    dans 1272283040:

    A la base c'est du dessin vectoriel, les images sont accessoires et peuvent être utilisées en référence externe si elles sont trop grosses.
    Mais cela me permet d'avoir un format de fichier simple (texte) et compatible avec les 3 plateformes (Mac, Windows et Linux) sur lesquelles tourne RealCADD. Voire 4 maintenant avec l'iPhone/iPad.


    ça s'appelle du SVG je crois, d'ailleurs ce n'est pas supporté en natif sur l'iPhone ?
  • Eric P.Eric P. Membre
    07:42 modifié #7
    Presque Yoann, le SVG est un format de fichier XML pour les données vectorielles qui est lu par les navigateurs mais sur l'iPhone je ne sais pas.

    Peut-être que RealCADD et/ou iPocket Draw liront un jour ce format bien que je n'aime pas le XML.
  • yoannyoann Membre
    07:42 modifié #8
    dans 1272912739:

    Presque Yoann, le SVG est un format de fichier XML pour les données vectorielles qui est lu par les navigateurs mais sur l'iPhone je ne sais pas.

    Peut-être que RealCADD et/ou iPocket Draw liront un jour ce format bien que je n'aime pas le XML.


    C'était ironique, ce que tu décris est le fonctionnement du SVG, je trouve plus logique de s'embêter un peut plus et se caler sur un standard plutôt qu'un proprio, ça permet plus de chose je trouve :-)

    Cela étant, je suis d'accord, le XML c'est chiant !
Connectez-vous ou Inscrivez-vous pour répondre.