Copie d'image : résultat bon ou mauvais selon le type d'image

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/04/2017, 15h51
BeanzMaster

Citation:

Envoyé par Jipété

Merci pour les screens, de mon côté, j'ai réussi à avoir quelque chose, très moche, et en 24bit c'est aussi moche mais moins large.
Pièce jointe 266003

En fait c'est pour Windows, ton truc ?

Perds pas ton temps en ce qui me concerne, mes problèmes ne trouveront une solution qu'à la refonte complète de TBitmap... On n'est pas rendus...

Et en attendant on peut oublier les codes trouvés sur le web pour Delphi.

J'ai eu le même truc que toi hier soir c'est qu'il y a un décalage de Bit en Trop la. Par rapport a mes screens La description c'est la même ? Le BitOrder ?
Le seul truc qu'il peut y avoir a faire sous Linux c'est le "SwapRBdatas". pour l'inversion.

Apres dans la version de AndNotOr pour le 24bit j'ai changé le *4 par *3. Ces valeurs sont variables suivant la description.
19/04/2017, 15h59
Andnotor

Citation:

Envoyé par BeanzMaster

Non en fait je tiens ça de toi de 1 par la formule le *4 à la fin c'est pour 4 octets donc 32bits

Alors je te le répète une dernière fois : c'est la longueur totale de la ligne qui doit être multiple de 4 octets, pas le pixel.
Pourquoi y aurait-il un Bmp.Width *Bits sinon ?

Citation:

Envoyé par BeanzMaster

si il y a padding c'est bien pour aligner les données sur 32bits, un pixel 24bit aura une taille de 32bits en mémoire

Le padding est par ligne et non par pixel.

1 pièce(s) jointe(s)

Les neurones à fond, l'aiguille du compte-tours au taquet dans le rouge, :ptdr:

Citation:

Envoyé par ThWilliam

Comme tu voulais (à un certain moment) transférer les data d'un bitmap dans un array de bytes,
la taille de cet array n'est pas = width * height * BytesPerPixel
mais bien : Linesize * height

En fait c'est idiot, dans la mesure où la cible est une bête Array of Bytes sans aucune notion de padding ni autre alignement sur pixel, dWord ou que sais-je (OK, dans l'absolu, on pourrait aligner sur 32 bits, je le conçois, manière d'optimiser le chargement en mémoire des gros fichiers) mais ici, ça n'apporte rien, on est au niveau des bytes.

D'ailleurs j'ai fait la manip suivante, en virant LineSize et en utilisant un TBytesStream pour voir les données :
note : il n'y a qu'une ligne alors on se fiche un peu de parcourir de bas en haut ou l'inverse
(ByPP = bytes-per-pixel, ByPL = bytes-per-line)

1^re proc Bitmap2Bytes :
Code:

1 2 3 4 5 for h := 0 to Bitmap.Height-1 do begin Move(Bitmap.RawImage.GetLineStart(h)^, Bytes[h * ByPL], ByPL); for w := 0 to (Bitmap.Width * ByPP)-1 do bs.WriteByte(Bytes[w*h +w]);// pour contrôle end; bs.SaveToFile('/chemin/bs_bmp2bytes.bin'); // bytes bien stockés
2^e proc Bytes2Bitmap :
Code:

1 2 3 4 5 6 7 8 Bitmap.BeginUpdate(); for h := 0 to Bitmap.Height-1 do begin Move(Bytes[h * ByPL], Bitmap.RawImage.GetLineStart(h)^, ByPL); for w := 0 to (Bitmap.Width * ByPP)-1 do bs.WriteByte(Bytes[w*h +w]);// pour contrôle end; Bitmap.EndUpdate(); Bitmap.SaveToFile('/chemin/bytes2bmp.bmp'); // couleurs en vrac bs.SaveToFile('/chemin/bs_bytes2bmp.bin'); // bytes bien stockés, représentant les pixels attendus
De haut en bas, le fichier source 6x1x24, 6 pixels identiques (15 DE FF), dessous les données foireuses enregistrées par Bytes2Bitamp.Save2File : couleurs en vrac, dessous le TBytesStream témoin de la source et en bas le TBytesStream témoin de la récup : les TBytesStream sont OK.

Pièce jointe 266070

On retombe sur la problématique du TBitmap découverte il y a quelques jours, et qui fait que cet animal, en l'état, n'est pas utilisable simplement.

Si encore ta manip, Thierry avait empêché TBitmap de perdre des pixels, ça aurait été cool, mais ça n'est pas le cas. Si je travaillais avec un pf32bit et que le code bas niveau se fasse des nœuds et passe en pf24bit, je comprendrais aussi.
Mais non, c'est le truc d'origine (et sans solution), avec ces décalages inexplicables...
Ou alors essayer de passer par RawImage.Init_valeurs_compliquées_n'ayant_plus_rien_à_voir_avec_une_simple_array_of_bytes ?

Se sont pas autant compliqués la vie, les gourous d'Experts-Exchange...

19/04/2017, 17h55
Jipété

1 pièce(s) jointe(s)

Ah, BeanzMaster disait qu'il fallait se prendre la tête avec Bitmap.RawImage.Description, c'est chose faite et ça donne ça (juste les différences) : à gauche depuis le fichier d'origine, à droite après la récupération par un bitmap des données issues de l'Array of Bytes :
Pièce jointe 266079

On voit bien que Lazarus se prend les pieds dans le tapis et nous entraîne dans sa chute, sans compter le fait qu'utiliser ou pas Bitmap.RawImage.Description.Init_BPP24_B8G8R8_BIO_TTB(aWidth,aHeight); ne change pas le résultat (peut-être que je le mets mal eu œuvre ? L'aide ne dit rien...)

Pourquoi 32 bpp à droite ? Ils sortent d'où ? Je les ai définis à 24...

EDIT : Ah, test sous XP, sans rien changer au code :

source dest

BitOrder=riboBitsInOrder BitOrder=riboReversedBits

MaskBitOrder=riboBitsInOrder MaskBitOrder=riboReversedBits
19/04/2017, 18h17
anapurna

salut

tu as déjà un soucis dans le processus ci dessous

Code:

for w := 0 to (Bitmap.Width * ByPP)-1 do bs.WriteByte(Bytes[w*h +w]);

ce devrais etre

Code:

for w := 0 to (Bitmap.Width -1) * ByPP do bs.WriteByte(Bytes[w*h +w]);
19/04/2017, 18h22
Jipété

Citation:

Envoyé par anapurna

salut

tu as déjà un soucis dans le processus ci-dessous

Code:

for w := 0 to (Bitmap.Width * ByPP)-1 do bs.WriteByte(Bytes[w*h +w]);

ce devrait être

Code:

for w := 0 to (Bitmap.Width -1) * ByPP do bs.WriteByte(Bytes[w*h +w]);

Non, car
1- j'avais commencé comme ça et c'était pas bon ;
2- sur cette ligne je travaille au niveau des bytes, or Width renvoie des pixels !
Pour parcourir tous les bytes il me faut donc cette multiplication de la largeur en pixels par le nombre de bytes par pixels. ;)

salut

ah oui autant pour moi ;)

tes octets par Pixel tu le récupère de cette façon ?

Code:

BytePerPixel := RawImage.Description.BitsPerPixel div 8;

ensuite pour recuperer les donnée je ferais comme ceci si et seulement si BytePerPixel = 4
Code:

1 2 3 4 5 6 7 8 9 10 ... z := 0; for h:= (Bitmap.Height-1) downto 0 do begin DestPtr := PInteger(Bitmap.RawImage.GetLineStart(h)); System.Move(Src[z], DestPtr^, Bitmap.Width * BytePerPixel ); z := z + ( Bitmap.Width * BytePerPixel ); ... end;
PS : en regardant le code il y a un truc qui me gênais mais je trouvais pas ce que c’était.
est tu sûr de ta fonction ci dessous ?

Code:

bs.WriteByte(Bytes[w*h +w]);

ce ne serais pas plutôt

Code:

bs.WriteByte(Bytes[(BPL*h) +w]);

19/04/2017, 23h22
Jipété

Citation:

Envoyé par anapurna

tes octets par Pixel tu les récupères de cette façon ?

Code:

BytePerPixel := RawImage.Description.BitsPerPixel div 8;

Non !
Tu vois, tu ne suis pas ;)
J'ai dit que je ne voulais plus utiliser RawImage.Description, qui remonte de la daube !
Par exemple, le fichier XP 8x2x24 que j'utilise pour tester en bas de ce post m'est remonté avec BitsPerPixel=32 :aie: !

Pour les BytesPerPixel j'utilise BitmapInfoHeader.biBitCount div 8; // BytesPerPixel. et je ne l'ai pas encore pris en défaut.

Citation:

Envoyé par anapurna

ensuite pour récupérer les données je ferais comme ceci si et seulement si BytePerPixel = 4

Et comment ça va se passer si BytePerPixel = 3 ? C'est le cas des fichiers issus de XP...

Citation:

Envoyé par anapurna

PS : en regardant le code il y a un truc qui me gênait mais je trouvais pas ce que c’était.
es-tu sûr de ta fonction ci-dessous ?

Code:

bs.WriteByte(Bytes[w*h +w]);

ce ne serait pas plutôt

Code:

bs.WriteByte(Bytes[(BPL*h) +w]);

Non, je n'en suis pas sûr du tout pour la bonne et simple raison que pour le moment je fais des tests avec des fichiers de 1 ligne, donc [w*h +w] avec h à 0 devient [w] et ça passe.

Mais je prends bonne note de ta remarque et vais la tester, plutôt avec (Bitmap.Width * ByPP *h) +w que juste(BPL *h) +w, d'ailleurs ! -- Testé avec juste un fichier "facile", 8x2, résultat ok en ce qui concerne le balayage (et le fichier résultat à partir du TBytes Stream), mais les couleurs c'est toujours pas ça : toujours ces pertes de bytes à partir du 2^e pixel, sur chaque ligne, c'est désespérant.

salut

pour un BytePerPixel <> 4

Code:

1
2
3
4
5
6
7
8
9
10
11
 
     for h:= (Bitmap.Height-1) downto 0 do
     begin
        DestPtr := PInteger(Bitmap.RawImage.GetLineStart(h));
        for w:=0 to Bitmap.Width-1 do
        begin
           DestPtr^ := ...;
           Inc(PByte(DestPtr), BytePerPixel);
           ...
        end;
      end;

Linux est le parent pauvre de Lazarus, c'est confirmé

Salut,

Citation:

Envoyé par anapurna

pour un BytePerPixel <> 4

Tu tombes bien avec ton truc, je suis dessus depuis ce matin et, encore une fois, Linux est le parent pauvre de Lazarus.

Je l'avais déjà dit, je le maintiens, et démonstration :

j'utilise 2 MemoryStream, un TMemory qui contient les données source (un fichier de 8x2x24) et un TBytes comme témoin, et p et q sont des pBytes.
La partie utile c'est ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 //2 recopier les bytes bmp.RawImage.Description.Init_BPP24_B8G8R8_BIO_TTB(aWidth,aHeight); bmp.BeginUpdate(); for h := aHeight-1 downto 0 do begin q := bmp.RawImage.GetLineStart(h); for w := 0 to LineSize-1 do begin p^ := ms.ReadByte; // récup byte bs.WriteByte(p^); // copie pour témoin, bytes ok q^ := p^; inc(q); // pour GetLineStart -- L: fausses couleurs, W: ok { dessus ou dessous au choix, mais pas exactement les mêmes fausses couleurs sous Linux } //bmp.RawImage.Data[(LineSize*h)+w] := p^; // L: fausses couleurs, W: ok end; end; bmp.EndUpdate(); //3 vérif bs.Position:=0; //bmp.LoadFromStream(bs, bs.Size); // témoin, ok
J'ai fait ce genre d'essai car je voulais passer par GetLineStart, le ScanLine de Lazarus.

Je vous laisse lire les commentaires dans le code, je précise juste que si je commente les 2 lignes avant le bmp.EndUpdate et active le chargement du bmp à partir du bs pour vérifier que les données qu'il contient sont bonnes, la réponse est oui, elles sont bonnes.
Et quand j'écris fausses couleurs, c'est toujours ces histoires de décalages : le 1^er pixel de chaque ligne est bon avec q^ := p^; mais juste le 1^er de tous avec Data...
Je vais chercher de ce côté-là.

Ah, la ligne n° 2 (Description.Init_...) semble ne servir à rien.

salut

as tu essayé ?
Citation:
Envoyé par Jipété
Salut,
...
Code:

1 2 3 4 5 6 7 ... q := Pinteger(bmp.RawImage.GetLineStart(h)); ... q^ := p^; Inc(PByte(q), 1); ...
...

20/04/2017, 11h28
Jipété

Citation:

Envoyé par anapurna

salut

as-tu essayé ?

Même cause mêmes effets :aie:

Même cause dans le sens où ton bout de code ne prend pas en compte le décalage...

1 pièce(s) jointe(s)

Presque !

Plus que l'inversion rouge-bleue à gérer !
en haut la source (8x2x24, XP), en bas sa copie dans Linux :yaisse:

Pièce jointe 266370

Comment j'ai fait ? Je rajoute systématiquement un byte dans la cible tous les 3 bytes recopiés depuis la source :
('tention, c'est pas beau, y a des trucs en dur, c'est juste pour voir si ça fonctionne -- ByPP = BytesPerPixel, 3 ou 4)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 bmp.BeginUpdate(); for h := aHeight-1 downto 0 do begin q := bmp.RawImage.GetLineStart(h); //for w := 0 to LineSize-1 do begin // gestion du décalage : il FAUT être au niveau des bytes for w := 0 to (aWidth*3)-1 do begin ////////////////////////// "3" dépend de la source p^ := ms.ReadByte; // récup byte bs.WriteByte(p^); // copie pour témoin, bytes ok q^ := p^; // pour GetLineStart -- L: pas les bonnes couleurs, W: ok // tous les 3 bytes, en crée un 4e dans la cible si Linux /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ if ((w+1) mod (ByPP-1) = 0) then if (ByPP = 4) then begin inc(q); q^ := 255; end; inc(q); end; end; bmp.EndUpdate();
Je me sens vachement plus léger et détendu, tout d'un coup ! 8-)
Le reste sera, je pense, de la gnognotte :ccool:

20/04/2017, 14h09
anapurna

salut

tu veut dire que tout ça c'est parce que ton fichier de base est en 24bits et que tu le copie dans un 32bits ?
donc tu as un RGB que tu transforme en RGBA
20/04/2017, 14h35
Jipété

Citation:

Envoyé par anapurna

salut

tu veux dire que tout ça c'est parce que ton fichier de base est en 24bits et que tu le copies dans un 32bits ?
donc tu as un RGB que tu transformes en RGBA

Ben c'est à peu près ce que je dis depuis une grosse dizaine de jours, oui, plus le gag donc tu as un ~~RGB~~ que tu transformes en RGBA --> donc tu as un BGR sous Windows que tu transformes en RGBA, ce qui n'a pas aidé au diagnostic, étant entendu qu'en plus, sous Linux TheGimp est parfaitement capable de générer du 24 bits !

Bon, cet aprème relâche (comme au théâtre :mrgreen:)

Citation:

Envoyé par Jipété

Bon, cet aprème relâche (comme au théâtre :mrgreen:)

Bonsoir,

voici donc le cœur de la routine de recopie d'un fichier ouvert dans un TMemoryStream et envoyé dans un TBitmap en utilisant un pRGBQuad (qui, contrairement à son nom qui ne l'indique pas, organise les bytes comme BGRA) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bmp.BeginUpdate(); for h := (bmp.Height-1) downto 0 do begin p4 := pRGBQuad(bmp.RawImage.GetLineStart(h)); for w := 0 to (bmp.Width)-1 do begin p4^.rgbRed :=ms.ReadByte; p4^.rgbGreen:=ms.ReadByte; p4^.rgbBlue :=ms.ReadByte; case BiPP of // info de la source 24: p4^.rgbReserved:=255; 32: p4^.rgbReserved:=ms.ReadByte; end; inc(p4); end; // for w end; // for h bmp.EndUpdate();
Les choses à mettre en place :

détermination simple et facile du BitsPerPixel du fichier source (24 ou 32 bits, les autres options, euh...)
détermination du BitsPerPixel du fichier destination (selon quels critères ? Les infos de la source ? À réfléchir car, si Linux est 32 bits, The Gimp est capable de générer du 24 et du 32 bits, et ces fichiers-là sont bien affichés en mode icônes ou miniatures dans l'explorateur de fichiers, également dans le visionneur rapide et aussi dans ImageJ, ImageMagick, LibreOffice).
vérification dans Windows que les couleur "tombent" en place : à l"heure actuelle, pou éviter d'utiliser SwapRBdatas, il suffit de copier dans p4^.rgbRed le byte correspondant au bleu (et inversement pour le rgbBlue et le byte Red), le 1^er byte des pixels de la source si fichier créé sous Windows. Vérifier avec ceux créés sous Linux.

Voilà :coucou:

Hola !

Hier j'ai fait des tests avec des fichiers dont les datas étaient bien alignées : 8x2, 96x96, trop fastoche !

Aujourd'hui j'ai créé un 5x2 et paf !, le padding qui fait des siennes...

Mais qu'à cela ne tienne : un peu d'afficheur hexa, un peu de café, un peu de papier-crayon et hop :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Padding := LineSize - (aWidth * (BiPP div 8)); //... bmp.BeginUpdate(); for h := (bmp.Height-1) downto 0 do begin p4 := pRGBQuad(bmp.RawImage.GetLineStart(h)); for w := 0 to (bmp.Width)-1 do begin // new 21/04 : byteR := ms.ReadByte; byteG := ms.ReadByte; byteB := ms.ReadByte; case BiPP of // info de la source 24: byteA := 255; 32: byteA := ms.ReadByte; end; // // réservé pour éventuelles modif des bytes // p4[w] := RGBAtoRGBAQuad(byteR,byteG,byteB,byteA); end; // for w -- fin de ligne // termine le parcours de la ligne avec le padding, if any if Padding > 0 then // /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ for w := 0 to Padding -1 do ms.ReadByte; // avance automatique end; // for h bmp.EndUpdate();
Vérifié avec tous les fichiers de test que je possède, et c'est tout bon. :ccool:

Mais il aura fallu 2 semaines (si si !) et presque 100 posts, ouch !
Reste plus que les vérifs sous Windows et ce genre de choses, mais ça devrait aller.
Bientôt :resolu: :P

Salut JP.

Houla ! Je perd le fil de cette discussion.

Je vois maintenant (dans ton avant-dernier post) qu'il s'agit de transformer un 24bits en 32bits.
J'ai retrouvé la fonction que j'utilisais pour faire cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 procedure ConvertBitmapTo32bits(aBitmap: Tbitmap); var Img1, Img2: TLazIntfImage; ImgFormatDescription: TRawImageDescription; begin try Img1:= aBitmap.CreateIntfImage; ImgFormatDescription.Init_BPP32_B8G8R8A8_BIO_TTB(aBitmap.Width, aBitmap.Height); Img2:= TLazIntfImage.Create(aBitmap.Width, aBitmap.Height); Img2.DataDescription:= ImgFormatDescription; Img2.CopyPixels(Img1); aBitmap.LoadFromIntfImage(Img2); finally Img1.Free; Img2.Free; end; end;
La même fonction peut être utilisée pour passer d'un 32bits à un 24bits. Il suffit de changer le Init :
Init_BPP24_B8G8R8_BIO_TTB

Tu peux tester avec d'autres initialisations.

Sous Delphi7, c'était vachement plus simple : il suffisait de modifier le pixelformat :
if Bitmap.PixelFormat <> pf32bit then Bitmap.PixelFormat:= pf32bit

Avec Lazarus la procédure SetPixelFormat fait un FreeImage (tous les octets data sont mis $00), donc pas moyen de l'utiliser pour un bitmap déjà "chargé".

Dans ton dernier post, je ne comprend pas le case BiPP. Car si le bitmap est au format 24, pourquoi utiliser un pRGBQuad et non un pRGBTriple ? (ou alors j'ai sauté des étapes).

Amicalement
Thierry

1 pièce(s) jointe(s)

Yop !

Citation:

Envoyé par ThWilliam

Salut JP.

Houla ! Je perd le fil de cette discussion.

Pas grave, ça se termine, :mouarf:

Citation:

Envoyé par ThWilliam

Dans ton dernier post, je ne comprend pas le case BiPP. Car si le bitmap est au format 24, pourquoi utiliser un pRGBQuad et non un pRGBTriple ? (ou alors j'ai sauté des étapes).

BiPP = Bits-Per-Pixels (24 ou 32, donc. Je me limite à ça) de la source, j'ai besoin de cette info pour savoir comment naviguer dans l'Array of Bytes contenant les datas.

Et pour la cible, pour le moment je me coltine tout le code sous Linux donc 32 bits en natif.

À partir du moment où ça, ça fonctionne (et c'est le cas depuis une heure), ça me fait une base solide pour dériver dans d'autres directions à coups de {$IFDEF PLATEFORME}.

Je rappelle que l'idée de base ~~était~~ est de faire fonctionner deux procs travaillant ensemble, Bitmap2Bytes puis ensuite Bytes2Bitmap, lien vers la source dans le 1^er post.

Et j'ai appris un million de trucs, au cours de ces 100 posts, merci à tous.
:coucou:

EDIT
As-tu bien noté, dans la boucle, ce passage ?
Code:

1 2 3 // // réservé pour éventuelles modif des bytes //
Pour démo ultra-rapide, j'ai rajouté un CheckBox et ça :
Code:

1 2 3 4 5 6 7 8 9 10 // réservé pour éventuelles modif des bytes if ckbxInvertBytes.Checked then begin byteR := 255 - byteR; byteG := 255 - byteG; byteB := 255 - byteB; case BiPP of // info de la source 24: byteA := 255; // ne pas l'inverser, sinon image invisible (complètement transparente) 32: byteA := 255 - byteA; end; end;
et voilà :
Pièce jointe 266838
à gauche la source, à droite le résultat.
/EDIT

21/04/2017, 17h27
Alcatîz

Citation:

Envoyé par Jipété

Et j'ai appris un million de trucs, au cours de ces 100 posts, merci à tous. :coucou:

Oui, ce fil de discussion restera dans les annales du forum !

:)

Voir 40 message(s) de cette discussion en une page

source	dest
BitOrder=riboBitsInOrder	BitOrder=riboReversedBits
MaskBitOrder=riboBitsInOrder	MaskBitOrder=riboReversedBits