IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

x86 32-bits / 64-bits Assembleur Discussion :

Lecture d'une image bitmap


Sujet :

x86 32-bits / 64-bits Assembleur

  1. #1
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut Lecture d'une image bitmap
    Pourquoi en mémoire, pour une image bitmap de 4 pixels de larges de
    couleurs alternées blanc, noir, blanc, noir, codée sur 24 bits, le code est
    FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 . Ici, la première couleur semble codée sur 24 bits et les autres sur 32...

    Merci d'avance.
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  2. #2
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    moui , vu le post davant sur les deplacement 24 bits , je pense que revoir ta routine de lecture serait a recommander , tu peux la donner dans le post la ?

  3. #3
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    Voilà mon horreur. Je le pense sérieusement, mais j'apprends...
    C'est inclus dans un programme C++Builder...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
     
     
        int Taille_pixel = 3;
        int Taille = Image1->Picture->Bitmap->Height *
                     Image1->Picture->Bitmap->Width * Taille_pixel;
     
        int *pixel = (int*)Image1->Picture->Bitmap->ScanLine[Image1->Picture->Bitmap->Height-1];
     
        char Moyenne = (0xFFFFFF + 0x000000) /2;
     
        asm
        {
             /**
     
     
     
     
             **/
            xor ebx, ebx;
            mov bl, Moyenne;
     
            xor eax, eax;
            mov eax, Taille_pixel;
     
            xor ecx, ecx;
            mov edx, Taille;
     
            mov esi, pixel;
    Boucle:
            push eax;
            xor eax, eax;
            mov al, [esi+ecx];
            cmp al, bl;
            pop eax;
            jc Noir;
    Blanc:  mov byte ptr [esi+ecx], 0xFFFFFF;
            jmp Suite;
    Noir:   mov byte ptr [esi+ecx], 0x000000;
            jmp Suite;
    Suite:  add ecx, eax;
            cmp ecx, edx;
            jc Boucle;
     
     
        }
     
        Image1->Update();
    [/code]
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  4. #4
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    un truc qui est sur deja , cest que quand tu fais :


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Blanc:  mov byte ptr [esi+ecx], 0xFFFFFF; 
            jmp Suite; 
    Noir:   mov byte ptr [esi+ecx], 0x000000; 
            jmp Suite;
    ca ne copie quun seul octet est non pas 3
    donc deja
    tu ne modifies quun octet sur 3.
    ton compilateur assimile 0xFFFFFF a 0xFF pour la traduction de valeur.
    ca doit donner des trucs bizzare genre tt rouge ou tt vert ou tt bleu
    joli mais pas ce kon veut ^^
    la solution si tu ne veux faire que du n&b , avec des largeurs de pixel variables cest dutiliser les routines de copies de chaine.

    sinon pour un truc qui copie 3 octet tu peux utiliser ca

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    mov word ptr [esi+ecx] , 0xFFFF;
    mov byte ptr [esi+ecx+2] , 0xFF;

  5. #5
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    Oki, je vais essayer.

    Merci.
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  6. #6
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    pour les routines de traitement de chaine ca donne ca


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    mov edi, addresse_pixel;
    movzx ecx,taille_pixel_en_octets;
    mov al,$FF;
    rep stob;
    et voilou

  7. #7
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    OK.

    Tu pourrais m'expliquer ce que fais chaque instruction ?
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  8. #8
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    J'ai corrigé comme tu m'as dit et ça marche pour le déplacement sur 24 bits.

    Mon seul problème est la comparaison de eax avec ebx. La valeur que je mets dans eax est de 24 bits mais il lit 32 bits semble-il et je ne sais pas comment l'empêcher de faire ça.

    Je suis désolé de vous "balancer" tout mon code, mais c'est dur de décrire mon erreur facilement sans celui-ci.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
     int Taille_pixel = 3;
        int Taille = Image1->Picture->Bitmap->Height *
                     Image1->Picture->Bitmap->Width * Taille_pixel;
        Image1->Picture->Bitmap->PixelFormat = pf24bit;
        int *pixel = (int*)Image1->Picture->Bitmap->ScanLine[Image1->Picture->Bitmap->Height-1];
     
        int Moyenne = (0xFFFFFF + 0x000000) /2;
     
        asm
        {
     
            xor ebx, ebx;
            mov ebx, Moyenne;
     
            xor eax, eax;
            mov eax, Taille_pixel;
     
            xor ecx, ecx;
            mov edx, Taille; 
     
            mov esi, pixel;
    Boucle:
            push eax;
            xor eax, eax;
            mov eax, [esi+ecx];  // <--- ICI
     
            cmp eax, ebx; 
            pop eax;
            jc Noir;
    Blanc:  mov word ptr [esi+ecx], 0xFFFF;
            mov byte ptr [esi+ecx+2], 0xFF;
            jmp Suite;
    Noir:   mov word ptr [esi+ecx], 0x0000;
            mov byte ptr [esi+ecx+2], 0x00;
            jmp Suite;
    Suite:  add ecx, eax;
            cmp ecx, edx;
            jc Boucle;
     
     
        }
     
        Image1->Update();
    Merci d'avance.[/code]
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  9. #9
    Membre expert
    Avatar de Eric Sigoillot
    Inscrit en
    mars 2002
    Messages
    1 212
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : mars 2002
    Messages : 1 212
    Points : 3 358
    Points
    3 358
    Par défaut
    Pour répondre à une autre partie de ta question : les lignes des images bitmaps sont toutes alignées sur 32 bits... C'est toujours bon à savoir.

    A+
    Règles du forum
    F.A.Q Pascal

    Pour me joindre (aucune question technique, merci)

  10. #10
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    bon alors deja coupons court a toute tergiversation, les operations sur 24 bits en X86 NEXISTENT PAS !
    voila ....
    donc il te reste 32 16 8 bits
    pour faire 24 tu fais 3*8, 16+8 ou 32-8 mais directement ce nest pas possible.

    ALors rep repete loperation (facile a retenir) tant que ecx<>0 et il decremente une fois ecx a chaque fois quil fait loperation qui le suit.
    celle ci est stob, qui copie le contenu de al dans [edi], donc si tu le fait 3 fois , avec FF ou 00 dans al .... tu as ce que tu veux.


    donc tu me montre une ligne de ton code....
    cette ligne transfert le Dword pointé par esi+ecx dans eax,
    probleme tu ne veux que les 3 premiers octets pointés par esi+ecx
    comme le X86 est une machine grosboutiste les bits de poids fort dun nombre sont aux addresses les plus fortes (je crois que c ca : grosboutiste, je c jamais ^^ ou aors cest petit boutiste) donc les 8 bits de poids de eax ne tinteresse pas puisque ils sont le 4eme octet pointé par esi+ecx pour les "masquer" , on les mets a zero, il suffit de faire

    or eax, $00FFFFFF

    apres loperation de transfert, cest tout

  11. #11
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    mm je ne savais pas que les lignes etaient alignées sur les Dwords, tu peux me dire si tu as un descriptif du format bitmap silteplait hdd34? merci davance.
    en tout cas cela complique un peu les choses au niveua de ton , cela veut dire quil va falloir que tu realignes a chaque ligne..
    pas dur , mais fastidieux

  12. #12
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    a oui jallais oublier, movzx eax , qqchose
    ca met a zero les 16 bit de poids forts de eax et ca transfert la valeur pointée par qqchose (sur 2 octets) dans les bits de poid faible , en fait , on pourrait aussi utiliser mov tout court.

  13. #13
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    Merci pour vos réponses, ça marche... en partie. Du moins, je sais d'où vient le problème.

    En fait, le système où l'on déplace d'abord un word puis ensuite un byte fonctionne bien.

    Mais mon problème maintenant est l'alignement sur 32 bits pour les lignes. Je ne sais pas vraiment comme faire.
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  14. #14
    Inactif
    Profil pro
    Inscrit en
    avril 2002
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 10
    Points : 11
    Points
    11
    Par défaut
    Si tu peux te faire une Macro, c'est bien pratique:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    [Align_On | add #2 #1-1 | and #2 0-#1]
     
    ; usage:  Align_on 32, edi

    en clair:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    add edi, 31
    and edi, 0-32

    Betov.

  15. #15
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    rien a redire ^^

  16. #16
    Membre expert
    Avatar de Eric Sigoillot
    Inscrit en
    mars 2002
    Messages
    1 212
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : mars 2002
    Messages : 1 212
    Points : 3 358
    Points
    3 358
    Par défaut
    Salut !

    Vu que l'alignement sur 32 bits te pose problème...

    Voici une manière de calculer le nombre d'octets réellement présents pour chaque ligne dans une image Bitmap. C'est du Pascal. Mais c'est simple à déchiffrer. A noter que ce n'est sûrement pas la méthode, nin la plus simple, ni la plus rapide. Mais elle a l'avantage de fonctionner.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    Align := InfoHeader.biWidth;
    if Align mod 4 <> 0 then Align := Align + (4 - Align mod 4);
    case InfoHeader.biBitCount of
    1: Align := (Align or 7) shr 3;
    4: Align := Align shr 1;
    end;
    if Align mod 4 <> 0 then Align := Align + (4 - Align mod 4);
    Je peux aussi te mettre de la doc sur les images bitmaps. Bon déchiffrage...

    A+

    ===============================================

    Graphics File Formats

    This topic describes the graphics-file formats used by the Windows operating system. Graphics files include bitmap files, icon-resource files, and cursor-resource files.

    Bitmap-File Formats

    Windows bitmap files are stored in a device-independent bitmap (DIB) format that allows Windows to display the bitmap on any type of display device. The term "device independent" means that the bitmap specifies pixel color in a form independent of the method used by a display to represent color. The default filename extension of a Windows DIB file is .BMP.

    Bitmap-File Structures

    Each bitmap file contains a bitmap-file header, a bitmap-information header, a color table, and an array of bytes that defines the bitmap bits.
    The bitmap-file header contains information about the type, size, and layout of a device-independent bitmap file. The header is defined as a TBITMAPFILEHEADER structure.
    The bitmap-information header, defined as a TBITMAPINFOHEADER structure, specifies the dimensions, compression type, and color format for the bitmap.
    The color table, defined as an array of TRGBQUAD structures, contains as many elements as there are colors in the bitmap. The color table is not present for bitmaps with 24 color bits because each pixel is represented by 24-bit red-green-blue (RGB) values in the actual bitmap data area. The colors in the table should appear in order of importance. This helps a display driver render a bitmap on a device that cannot display as many colors as there are in the bitmap. If the DIB is in Windows version 3.0 or later format, the driver can use the biClrImportant member of the TBITMAPINFOHEADER structure to determine which colors are important.

    The TBITMAPINFO structure can be used to represent a combined bitmap-information header and color table.
    The bitmap bits, immediately following the color table, consist of an array of BYTE values representing consecutive rows, or "scan lines," of the bitmap. Each scan line consists of consecutive bytes representing the pixels in the scan line, in left-to-right order. The number of bytes representing a scan line depends on the color format and the width, in pixels, of the bitmap. If necessary, a scan line must be zero-padded to end on a 32-bit boundary. However, segment boundaries can appear anywhere in the bitmap. The scan lines in the bitmap are stored from bottom up. This means that the first byte in the array represents the pixels in the lower-left corner of the bitmap and the last byte represents the pixels in the upper-right corner.

    The biBitCount member of the TBITMAPINFOHEADER structure determines the number of bits that define each pixel and the maximum number of colors in the bitmap. These members can have any of the following values:

    Value Meaning

    1 Bitmap is monochrome and the color table contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the color table. If the bit is set, the pixel has the color of the second entry in the table.
    4 Bitmap has a maximum of 16 colors. Each pixel in the bitmap is represented by a 4-bit index into the color table. For example, if the first byte in the bitmap is 0x1F, the byte represents two pixels. The first pixel contains the color in the second table entry, and the second pixel contains the color in the sixteenth table entry.
    8 Bitmap has a maximum of 256 colors. Each pixel in the bitmap is represented by a 1-byte index into the color table. For example, if the first byte in the bitmap is 0x1F, the first pixel has the color of the thirty-second table entry.

    24 Bitmap has a maximum of 2^24 colors. The bmiColors (or bmciColors) member is NULL, and each 3-byte sequence in the bitmap array represents the relative intensities of red, green, and blue, respectively, for a pixel.

    The biClrUsed member of the TBITMAPINFOHEADER structure specifies the number of color indexes in the color table actually used by the bitmap. If the biClrUsed member is set to zero, the bitmap uses the maximum number of colors corresponding to the value of the biBitCount member.
    An alternative form of bitmap file uses the BITMAPCOREINFO, TBITMAPCOREHEADER, and TRGBTRIPLE structures.

    Bitmap Compression

    Windows versions 3.0 and later support run-length encoded (RLE) formats for compressing bitmaps that use 4 bits per pixel and 8 bits per pixel. Compression reduces the disk and memory storage required for a bitmap.

    Compression of 8-Bits-per-Pixel Bitmaps

    When the biCompression member of the TBITMAPINFOHEADER structure is set to BI_RLE8, the DIB is compressed using a run-length encoded format for a 256-color bitmap. This format uses two modes: encoded mode and absolute mode. Both modes can occur anywhere throughout a single bitmap.

    Encoded Mode

    A unit of information in encoded mode consists of two bytes. The first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte.
    The first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair, which must be in the range 0x00 through 0x02. Following are the meanings of the escape values that can be used in the second byte:

    Second byte Meaning

    0 End of line.
    1 End of bitmap.
    2 Delta. The two bytes following the escape contain unsigned values indicating the horizontal and vertical offsets of the next pixel from the current position.

    Absolute Mode

    Absolute mode is signaled by the first byte in the pair being set to zero and the second byte to a value between 0x03 and 0xFF. The second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. Each run must be aligned on a word boundary.
    Following is an example of an 8-bit RLE bitmap (the two-digit hexadecimal values in the second column represent a color index for a single pixel):

    Compressed data Expanded data

    03 04 04 04 04
    05 06 06 06 06 06 06
    00 03 45 56 67 00 45 56 67
    02 78 78 78
    00 02 05 01 Move 5 right and 1 down
    02 78 78 78
    00 00 End of line
    09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
    00 01 End of RLE bitmap

    Compression of 4-Bits-per-Pixel Bitmaps

    When the biCompression member of the TBITMAPINFOHEADER structure is set to BI_RLE4, the DIB is compressed using a run-length encoded format for a 16-color bitmap. This format uses two modes: encoded mode and absolute mode.

    Encoded Mode

    A unit of information in encoded mode consists of two bytes. The first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte.
    The second byte contains two color indexes, one in its high-order nibble (that is, its low-order 4 bits) and one in its low-order nibble. The first pixel is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn.
    The first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. In encoded mode, the second byte has a value in the range 0x00 through 0x02. The meaning of these values is the same as for a DIB with 8 bits per pixel.

    Absolute Mode

    In absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. Each run must be aligned on a word boundary.
    Following is an example of a 4-bit RLE bitmap (the one-digit hexadecimal values in the second column represent a color index for a single pixel):

    Compressed data Expanded data

    03 04 0 4 0
    05 06 0 6 0 6 0
    00 06 45 56 67 00 4 5 5 6 6 7
    04 78 7 8 7 8
    00 02 05 01 Move 5 right and 1 down
    04 78 7 8 7 8
    00 00 End of line
    09 1E 1 E 1 E 1 E 1 E 1
    00 01 End of RLE bitmap

    Bitmap Example

    The following example is a text dump of a 16-color bitmap (4 bits per pixel):



    Win3DIBFile
    BitmapFileHeader
    Type 19778
    Size 3118
    Reserved1 0
    Reserved2 0
    OffsetBits 118
    TBITMAPINFOHeader
    Size 40
    Width 80
    Height 75
    Planes 1
    BitCount 4
    Compression 0
    SizeImage 3000

    XPelsPerMeter 0
    YPelsPerMeter 0
    ColorsUsed 16
    ColorsImportant 16
    Win3ColorTable
    Blue Green Red Unused
    [00000000] 84 252 84 0
    [00000001] 252 252 84 0
    [00000002] 84 84 252 0
    [00000003] 252 84 252 0
    [00000004] 84 252 252 0
    [00000005] 252 252 252 0
    [00000006] 0 0 0 0

    [00000007] 168 0 0 0
    [00000008] 0 168 0 0
    [00000009] 168 168 0 0
    [0000000A] 0 0 168 0
    [0000000B] 168 0 168 0
    [0000000C] 0 168 168 0
    [0000000D] 168 168 168 0
    [0000000E] 84 84 84 0
    [0000000F] 252 84 84 0
    Image
    .
    . Bitmap data
    .
    Règles du forum
    F.A.Q Pascal

    Pour me joindre (aucune question technique, merci)

  17. #17
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 933
    Points
    1 933
    Par défaut
    Pfou ! Je vais essayer tout ça. Merci. Si je n'y arrive pas, je vous redemanderai.
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  18. #18
    Membre à l'essai
    Inscrit en
    mai 2002
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2002
    Messages : 15
    Points : 17
    Points
    17
    Par défaut
    mouarf je pensais pas que tu le balancerais a la roots comme ca , mais merci bcp , je vais apprendre plein de chose ))

  19. #19
    Membre expert
    Avatar de Eric Sigoillot
    Inscrit en
    mars 2002
    Messages
    1 212
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : mars 2002
    Messages : 1 212
    Points : 3 358
    Points
    3 358
    Par défaut
    Sur le coup, j'ai un peu hésité... Mais bon, c'est trop tard pour y penser !
    Règles du forum
    F.A.Q Pascal

    Pour me joindre (aucune question technique, merci)

Discussions similaires

  1. Lecture des couleurs d'une image Bitmap
    Par beekeep dans le forum MFC
    Réponses: 4
    Dernier message: 04/05/2009, 19h10
  2. Lecture d'une image bitmap
    Par Nanoucha dans le forum Assembleur
    Réponses: 1
    Dernier message: 17/02/2006, 22h47
  3. Réponses: 3
    Dernier message: 11/11/2005, 17h15
  4. Réponses: 6
    Dernier message: 22/12/2004, 11h00
  5. generer une image bitmap a partir d'une scene OGL
    Par FreshLog dans le forum OpenGL
    Réponses: 4
    Dernier message: 01/07/2003, 11h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo