Discussion :

[Jipété]

Bon, ben accrochez-vous j'ai du lourd ( Et vérifié à plusieurs reprises ) avec Lazarus 1.8 sous Mint 18.3 64 bits.
On obtient un résultat différent selon que b.width et b.height soient fixés par un variable ou directement par un nombre en dur.

Hallucinant !
Et moi aussi j'ai du lourd : je n'arrivais pas à comprendre et admettre que des dimensions plus petites que d'autres génèrent un fichier plus gros, rappel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//w := 12000;  h := 8000; // long à venir mais ça a fonctionné (fic = 384 Mo)
//w := 12300;  h := 8200; // long à venir mais ça a fonctionné (fic = 302 Mo, bien plus petit que dessus !)

J'ai regardé les 2 fichiers à l'éditeur hexa et c'est à tomber par terre, l'un des deux est passé en 24 bpp quand l'autre est resté en 32 bpp comme demandé par le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// En haut, E0 2E 00 00 --> 00 00 2E E0 = 12000, 40 1F 00 00 --> 00 00 1F 40 = 8000
// En bas,  0C 30 00 00 --> 00 00 30 0C = 12300, 08 20 00 00 --> 00 00 20 08 = 8200

c'est bien les valeurs que j'avais demandé, mais dans les 2 cas j'avais demandé 32 bpp soit 20₁₆, alors d'où sort ce 18₁₆ ?

Et pour faire les tests je me suis fait chichi : pas de radiobuttons ou de cases à cocher, à chaque fois j'arrête et je commente/décommente les lignes que je veux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  b := TBitmap.Create;
  b.PixelFormat := pf32bit;
  w := 12000;  h := 8000; // long à venir mais ça a fonctionné (fic = 384 Mo)
//w := 12300;  h := 8200; // long à venir mais ça a fonctionné (fic = 302 Mo, bien plus petit que dessus !)
  b.Width:=w;  b.Height:=h;

Truc de malade, le machin fait ce qui lui chante...
Mais on va où, là ?
EDIT : une piste : 12300 / 8 = 1537,5, difficile de gérer ça pour le logiciel, d'autant plus que le pf32bit ne prend pas en compte le padding, donc basculement sur du pf24bit.
Et ce test avec 12320 x 8200 x 32 le confirme : le fichier généré pèse 404 Mo, l'éditeur hexa montre 32 bpp et... 12320 / 8 = 1540, compte rond !

À confirmer avec d'autres tests, mais ça, je le sens bien : on doit avoir une longueur de ligne divisible par 8 sans décimale.
/EDIT

Pour Jipete: Ton système est trop ancien et limité en mémoire, j'arrive à en bouffer 10Gb + du swap avec mes tests.

Mmmmh, on dirait que tu as perdu de vue que j'ai pu ouvrir sans problème le tryptique de Bosch avec le viewer de Linux, Gimp et ImageMagick,

[mm_71]

J'ai regardé les 2 fichiers à l'éditeur hexa et c'est à tomber par terre, l'un des deux est passé en 24 bpp quand l'autre est resté en 32 bpp comme demandé par le code :

Idée peut être stupide que je n'ai pas essayé:
Le résultat correct vient d'une image dont les dimensions sont des multiples de 8 ce qui n'est pas le cas de l'autre.
Il faudrait aussi voir ce que ça donne avec un TJpeg.

[Jipété]

Idée peut-être stupide que je n'ai pas essayée :
Le résultat correct vient d'une image dont les dimensions sont des multiples de 8 ce qui n'est pas le cas de l'autre.

Les grands esprits se rencontrent :

EDIT : une piste : 12300 / 8 = 1537,5, difficile de gérer ça pour le logiciel, d'autant plus que le pf32bit ne prend pas en compte le padding, donc basculement sur du pf24bit.
Et ce test avec 12320 x 8200 x 32 le confirme : le fichier généré pèse 404 Mo, l'éditeur hexa montre 32 bpp et... 12320 / 8 = 1540, compte rond !

À confirmer avec d'autres tests, mais ça, je le sens bien : on doit avoir une longueur de ligne divisible par 8 sans décimale.
/EDIT

+++

Il faudrait aussi voir ce que ça donne avec un TJpeg.

Chaque chose en son temps !
Trouvons déjà les limites, qui a dit qu'il y avait un souci avec le rendu du TImage ? Je le confirme haut et fort :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//  w := 32000;  h :=  1000; // image affichée noire (ok avec viewer, Gimp et ImageMagick, mais ImageJ n'affiche rien)
//  w :=  1000;  h := 32000; // parfaitement correct

[mm_71]

Chaque chose en son temps !
Trouvons déjà les limites, qui a dit qu'il y avait un souci avec le rendu du TImage ? Je le confirme haut et fort :

Le problème c'est que nous n'avons pas les mêmes limites. Comme dit plus haut toutes les valeurs de ton code jusqu'à 32000 * 16000 fonctionnent au moins quand la valeur est passée par une variable et pas en dur alors que ça provoque des erreurs chez toi.

Et je viens de voir un truc dans ta procédure qui expliquerait la différence des résultat selon qu'on utilise une variable ou pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 b.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, w, h);

Ici quand on a commenté toutes les lignes w= et h= pour choisir b.width= h.width=
b.canvas.rectangle devrait faire la tronche ce qui expliquerait un .bmp de 0 octets ainsi que les résultats bizarres que j'ai cités plus haut car je n'ai pas pris garde à ce détail.

[Jipété]

Et je viens de voir un truc dans ta procédure qui expliquerait la différence des résultat selon qu'on utilise une variable ou pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  b.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b.Canvas.Brush.Color:=clLime;
  b.Canvas.Rectangle(0, 0, w, h);

Ici quand on a commenté toutes les lignes w= et h= pour choisir b.width= h.width=
b.canvas.rectangle devrait faire la tronche ce qui expliquerait un .bmp de 0 octets ainsi que les résultats bizarres que j'ai cités plus haut car je n'ai pas pris garde à ce détail.

Vit' vit' parce que j'en ai marre et qu'il commence à faire très chaud et que je vais donc plier, tu parles de la "ligne à rajouter" ? Ça vient de l'autre discussion, où on s'est rendu compte, en zoomant très fort, qu'il fallait avoir ça sinon la colonne de l'extrême-droite et la ligne de l'extrême-bas étaient noires.
Ça peut se retrouver facilement, il y a des petites images noires et grises avec une zone colorée au milieu (vert je crois).

Sinon, si tu parles de commenter toutes les lignes w et h pour utiliser b., je ne suis pas tombé dans ce piège, il me semble, car j'ai les miens, , genre w avec une valeur et h avec une autre et ça fonctionne et je fais plein d'autres tests et je reviens dessus et ça ne fonctionne plus, comme si de la mémoire n'était plus disponible...

[mm_71]

Non, je parle de la ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  b.Canvas.Rectangle(0, 0, w, h);

Si toutes les lignes w et h sont commentées pour utiliser b. alors sur cette ligne b.canvas.rectangle reçoit des valeurs non définies.

[BeanzMaster]

Salut

Juste vite fait avant que je fasses quelques tests moi aussi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  b.Canvas.Rectangle(0, 0, w, h);

Cela devrait être

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  b.Canvas.Rectangle(0, 0, w-1, h-1);

Faut pas oublier que l'on compte à partir de zero

[BeanzMaster]

J'ai réfléchi un peu (oui, ça m'arrive)
Je n'avais pas fait attention à la remarque d'Anapurna

salut

1°) tout dépend du type de variable que tu as pris pour faire tes boucles et de la taille de ton buffer de donnée

sinon j'attend les autres proposition

Ca n'avait pas fait tilt. Mais c'est très logique

Je m'explique

Qu'est ce qu'un bitmap ? C'est un tableau d'octets sur 2 dimensions
Comment fait-on pour ce déplacer dans un tableau ? La formule c'est

L'adresse de la cellule dans le tableau = (Postion_en_Y * Largeur_Du_Tableau) + Position_en_X

L'adresse de la ligne est donc calculée comme ceci :

L'adresse d'une ligne dans le tableau = (Postion_en_Y * Largeur_Du_Tableau)

On est d'accord ?

Maintenant, si mon adresse de ligne est de type Byte (donc de 0 à 255). Que mon tableau a une dimension de 16x16. Qu'elle est l'adresse de la dernière ligne ?

Je reprend la formule

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Const
  Largeur_tableau : Byte = 16;
  Hauteur_tableau : Byte = 16;
Var
  Adresse : Byte;
  Tableau : Array[0..Largeur_tableau-1,0..Hauteur_tableau-1] of byte;
  PosY : Byte;
 
  PosY := 15; // La dernière ligne, il ne faut pas oublié que l'on commence à compter à partir de zéro
  Adresse :=  PosY * Largeur_tableau;

Résultat = 15 * 16 = 240

Ok on est toujours dans les limites du type Byte et en plus le derniers pixels se trouve à l'adresse 240 + (Largeur_tableau-1) = 255

Vous voyez ou je veux en venir ?

Supposons maintenant que la hauteur du tableau soit 16. Notre tableau aura donc une dimension de 16x17.

Calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Const
  Largeur_tableau : Byte = 16;
  Hauteur_tableau : Byte = 17;
Var
  Adresse : Byte;
  Tableau : Array[0..Largeur_tableau-1,0..Hauteur_tableau-1] of byte;
  PosY : Byte;
 
  PosY := 16; // La dernière ligne, il ne faut pas oublié que l'on commence à compter à partir de zéro
  Adresse :=  PosY * Largeur_tableau;

Résultat = 16 * 16 = 256

et le derniers pixels se trouve donc à l'adresse 256 + (Largeur_tableau-1) = 271

Et la paf on est plus dans les clous. Dans mon cas cela sera la solution à mon problème d'affichage le type que j'utilise n'est pas assez "Grand"

Prenons donc notre cas, ou les pixels seraient sur 32 bits donc 4 octets

Supposons maintenant que l'adresse de notre ligne soit de type Cardinal, Longword ou DWord soit un valeur possible comprise entre 0 et 4294967295 (on utilise des type non-signé logique, non ?)


Le calcul de la hauteur maximal sera donc

Taille_du_Pixel ici vaut donc 4 octets

MaxHauteur = Taille_Total_de_l_image_en_octets div (Largeur_de_l'image * Taille_du_Pixel)

Suivant les exemples suivant :

Largeur = 16 000
Hauteur = 16 000

Taille de l'image = (largeur * hauteur) * 4 = 1024 000 000 octet

MaxHauteur = 1024 000 000 div (Largeur * 4) = 1024 000 000 div 64 000 = 16 000 // (Largeur * 4) = 64 000

On peut en déduire l'adresse de la dernière ligne : 1024 000 000 - 64 000 = 1 023 936 000

Vérifions avec [c] Adresse := PosY * Largeur_tableau; (/c]

Adresse = 15 999 * 16 000 = 255 984 000 * 4 = 1 023 936 000 //!\ 15 999 car on compte à partir de zéro

le Résultat est bon

Prenons l'image FireFoxLarge soit une dimension de 20502x19839 avec une taille de 1 626 956 712 octets

Largeur_x_4 = 82 008
MaxHauteur = 1 626 956 712 div Largeur_x_4 = 19 839

Reprenons notre adresse de ligne comprise entre comprise entre 0 et 4 294 967 295

Adresse = 19 838 * 20 502 = 406 718 676 * 4 = 1 626 874 704

Sauf que dans mes logs

[NOTICE] [ 17:03:21 ] TBZCustomBitmap.SetSize : 20502x19839
[NOTICE] [ 17:03:21 ] TBZCustomBitmap.SetSize Buffer size : 1626956712
[NOTICE] [ 17:03:22 ] Load palette : 0
[NOTICE] [ 17:03:22 ] Taille du Stream : 1626956850
[NOTICE] [ 17:03:22 ] Taille d'une ligne : 82008
[NOTICE] [ 17:03:22 ] Y = 0
[NOTICE] [ 17:03:22 ] Adresse_Y = 0
[NOTICE] [ 17:03:22 ] Postion Memory Before Read : 138
[NOTICE] [ 17:03:22 ] Postion Memory After Read : 82146
[NOTICE] [ 17:03:22 ] Adresse_Dernier_pixel_ligne = 82004
[NOTICE] [ 17:03:22 ] Y = 1
[NOTICE] [ 17:03:22 ] Adresse_Y = 82008
[NOTICE] [ 17:03:22 ] Postion Memory Before Read : 82146
[NOTICE] [ 17:03:22 ] Postion Memory After Read : 164154
[NOTICE] [ 17:03:22 ] Adresse_Dernier_pixel_ligne = 164012
.....
[NOTICE] [ 17:03:34 ] Y = 19838
[NOTICE] [ 17:03:34 ] Adresse_Y = 1626874704
[NOTICE] [ 17:03:34 ] Postion Memory Before Read : 83370970
[NOTICE] [ 17:03:34 ] Postion Memory After Read : 83452978
[NOTICE] [ 17:03:34 ] Adresse_Dernier_pixel_ligne = 1626956708

1 626 956 708< 1 626 956 712 normalement le dernier pixel devrait être 1 626 956 707 me manque un pixel non ? c'est ok mais je n'arrive pas à trouver et comprendre qu'est ce qui peux causer ce décalage.

Il y a ton truc jipete de div par 8 que je pige pas bien. On voit bien dans mes capture que l'affichage des images est découpé en 8.

Bon je dois repartir j'approfondirai un peu plus ce soir

A+

[Jipété]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  b.Canvas.Rectangle(0, 0, w, h);

Cela devrait être

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  b.Canvas.Rectangle(0, 0, w-1, h-1);

Faut pas oublier que l'on compte à partir de zero

Vit' fait :
il y a des légendes qui ont la vie dure ! J'en ai parlé il y a un an là-bas (à partir de la ligne en rouge -- mais pas bien, j'en conviens), j'en ai parlé en fin de matinée ou début d'aprème ici, et revoilà la fake-news,

Bon, tordons-lui le coup une bonne fois pour toutes avec un test et 4 images :

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
procedure TForm1.Button4Click(Sender: TObject);
var
  w,h: integer;
begin
  Form1.Color:=$353535;;
  w := 4;  h := 2;
  b24 := TBitmap.Create; // b24 défini dans private
  b24.PixelFormat := pf24bit; // pf32bit ne fonctionne pas sur le canvas de la form
  b24.Width:=w;  b24.Height:=h;
//  b24.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b24.Canvas.Brush.Color:=clLime;
  b24.Canvas.Rectangle(0, 0, w, h);
  FormPaint(nil);
end;
 
procedure TForm1.FormPaint(Sender: TObject);
begin
  form1.Canvas.Draw(0,0,b24);
end;

Dans le code ci-dessus et l'exemple ci-dessous tout en haut, on a "pen_commenté" et "wh_ok" comme vous pourrez le lire sur les captures, avec les 3 autres possibilités, qui sont, tout en haut celle notée ci-dessus, puis en descendant
pen_commenté et w-1 et h-1, c'est encore tout noir ;
pen_décommenté et w-1 et h-1, ben la couleur verte qui devrait faire 4x2 ne fait que 3x1...
enfin, pen_décommenté et "wh_ok" donc tels quels et sans ces "-1" qui mettent la pagaille et on a bien notre canvas de 4x2.



OK ? C'est noté ? C'est gravé dans le marbre ?
Car, oui, Jérome, on compte à partir de 0 dans une liste par ex., mais là c'est une taille : imagine une hauteur de 1 ligne soit h:=1,, si tu fais ensuite h-1 ça te donne 0. CQFD.
Je ne m'éternise pas, j'ai des exemples à finir de meuler...

[foetus]

imagine une hauteur de 1 ligne soit h:=1,, si tu fais ensuite h-1 ça te donne 0. CQFD.

Tu te fais un nœud au cerveau pour rien

Parce que lorsqu'on parcoure une image (pour l'afficher, pour faire un traitement, ...), tu te places toujours au début de la ligne pour la parcourir en entier.
Et donc la dernière ligne est bien h-1 Édit : <- si on commence à zéro.

Donc si h:=1,, ton test pour parcourir toutes les lignes est 0 < < h, tu as bien ton h-1

[Jipété]

--snip--

Ah, toi aussi tu réfléchis par écrit et à haute voix,

Bon, je me suis concentré sur ça :

Prenons l'image FireFoxLarge soit une dimension de 20502x19839 avec une taille de 1 626 956 712 octets

elle sort d'où cette taille de presque 1,67 milliard d'octets ? Chez moi le .bmp généré en RGB à partir du .png fait 1 220 257 334 bytes.
À partir de ces 1220257334 bytes du fichier, j'enlève 122 (bih v4) et je divise ce qui reste par 3, magie, ça tombe juste, je multiplie par 4 et j'obtiens 1627009616 bytes pour du pf32bit.

Largeur_x_4 = 82 008

pourquoi x_4 ? Ça sort d'où, ce 4 ? Tu assumes des pf32bit ?
Mais une largeur est en bytes. En multipliant par 4 tu vas avoir quoi ? Rappel : quand je demande à Gimp une image de 1x1 en 32 bits, et que je la colorie avec mon bel orange et que je l'ouvre avec l'éditeur hexa, je vois 08 45 CA FF, 4 bytes pour 1 pixel.

Reprenons notre adresse de ligne comprise entre comprise entre 0 et 4 294 967 295

Pourquoi comprise entre 0 et 4,3 milliards ?
Pour moi ce que tu appelles "adresse de ligne" (et qui serait plutôt position d'un byte (ou d'un pixel, selon ce que tu comptes) doit se situer entre 0 et la fin de la ligne, pas la valeur max du cardinal. Si ta ligne fait 10 pixels à 32 bpp, tu auras 40 bytes donc 40 positions possibles, alors les 4,3 milliards, euh...

Adresse = 19 838 * 20 502 = 406 718 676 * 4 = 1 626 874 704

Adresse du dernier pixel tu veux dire ?

[Jipété]

Tu te fais un nœud au cerveau pour rien

En fait, quand "on" nous dit qu'on part de x1,y1 (left, top) pour aller jusqu'à x2,y2 (right, bottom), personne ne nous dit si x2,y2 est inclus ou exclu du dessin.

Et moi, quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
procedure TForm1.Button5Click(Sender: TObject);
var
  w,h: integer;
begin
  b24 := TBitmap.Create;
  b24.PixelFormat := pf24bit; // pf32bit ne fonctionne pas sur le canvas de la form
  b24.Width:=form1.Width;  b24.Height:=form1.Height;
//  b24.Canvas.Pen.Color:=clLime; // ligne à rajouter
  b24.Canvas.Brush.Color:=clLime;
  b24.Canvas.Rectangle(0, 0, form1.Width-1, form1.Height-1);
  FormPaint(nil);
end;

je vois bien avec mes yeux et une loupe que j'ai une ligne noire à l'extrême-droite et une autre à l'extrême-bas, lignes qui disparaissaient si j'enlève les "-1".
à gauche avec les -1, à droite sans :


Après, chacun fait comme il le sent.

[Jipété]

Bonsoir,

en attendant qu'on me démontre le contraire, voilà ce que j'ai fait, avec le code suivant (trouvé je ne sais plus où et adapté à mes besoins), ici en mode "essai 1" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
procedure TForm1.Button6Click(Sender: TObject);
var
  w,h: integer;
begin
  w := 3;  h := 2;
  with Form1.Canvas do begin
    Brush.Style := bsSolid;
    Brush.Color := $80FF00; // Vert avec un nuage de bleu
    FillRect(Rect(0,0,w,h));
  end;
end;

essai 1 avec w := 3; h := 2; et Rect(0,0,w,h); l'image c'est celle de gauche
essai 2 avec w := 3; h := 2; et Rect(0,0,w-1,h-1); l'image est à droite
essai 3 avec w := 2; h := 1; et Rect(0,0,w-1,h-1); et il n'y a pas d'image car il n'y a rien à voir : pas la moindre petite goutte de vert...

Les 2 images sont très agrandies pour qu'on puisse bien voir, et il suffit de savoir que le petit carré gris-bleu en haut à gauche fait 1x1.

Que dire de plus ?
Que j'attends les contre-exemples, ou qu'on me dise où je me suis trompé.

[BeanzMaster]

Yop !

Vit' fait :
il y a des légendes qui ont la vie dure ! J'en ai parlé il y a un an là-bas (à partir de la ligne en rouge -- mais pas bien, j'en conviens), j'en ai parlé en fin de matinée ou début d'aprème ici, et revoilà la fake-news,

.....

OK ? C'est noté ? C'est gravé dans le marbre ?
Car, oui, Jérome, on compte à partir de 0 dans une liste par ex., mais là c'est une taille : imagine une hauteur de 1 ligne soit h:=1,, si tu fais ensuite h-1 ça te donne 0. CQFD.
Je ne m'éternise pas, j'ai des exemples à finir de meuler...

On n'a pas fait attention mais nous ne parlons pas de la même chose, c'est de ma faute

Tu tu parles de la fonction Canvas.Rectangle Alors que j'y ai vue un TRect (ne me demandes pas pourquoi) 2 choses totalement différentes Mais voir la doc ici . Car je n'ais pas d'ou tu sort que Bottom/Left sont à l'extérieur. Ca c'est uniquement valable sous windows, car c'est la spéficiation de l'api qui est décrite comme ça. Et pourquoi Top et Left seraient à l'intérieur ?

Nan c'est du brassage dans FPC et Lazarus regardes la (un de mes post chez les voisiins ) Tu l'expliques comment celle là ?

Ah, toi aussi tu réfléchis par écrit et à haute voix,

Bon, je me suis concentré sur ça :

elle sort d'où cette taille de presque 1,67 milliard d'octets ? Chez moi le .bmp généré en RGB à partir du .png fait 1 220 257 334 bytes.

Ton fichier est en 24 bits, le mien en 32 bits

À partir de ces 1220257334 bytes du fichier, j'enlève 122 (bih v4) et je divise ce qui reste par 3, magie, ça tombe juste, je multiplie par 4 et j'obtiens 1627009616 bytes pour du pf32bit.

En plus du BIH il faut soustraire le "GapSize" si il est présent. mais ok.

chez moi taille du fichier = 1*626*956*850 octets - 138 (bmp v5) = 1 626 956 712

Le tien = 1 220 257 334

mon tampon 1 626 956 712. J'ai bien la bonne taille. --> [NOTICE] [ 17:03:21 ] TBZCustomBitmap.SetSize Buffer size : 1626956712

pourquoi x_4 ? Ça sort d'où, ce 4 ? Tu assumes des pf32bit ?

Oui et seulement je à la lecture d'un fichier je convertit tous les pixels (de 1 bit à 64 bits) vers un format BGRA/RGBA en 32 bits. Ca me permet ausii de gérer la transparence. La structure ressemble au TFastBitmap dans TGifViewer. La base est similaire.

Mais une largeur est en bytes.

Comment ça en octets ??? La largeur et la hauteur sont en nombre de pixels = 20502x19839

En multipliant par 4 tu vas avoir quoi ? Rappel : quand je demande à Gimp une image de 1x1 en 32 bits, et que je la colorie avec mon bel orange et que je l'ouvre avec l'éditeur hexa, je vois 08 45 CA FF, 4 bytes pour 1 pixel.

L'adresse de mon pixel dans le tampon de mon bitmap ou je dois lire sa valeur

Pourquoi comprise entre 0 et 4,3 milliards ?

Par ce que c'est l'ensemble possible des valeur pour les type Cardinal, LongWord et DWord. Obtenu du manuel de FPC

Pour moi ce que tu appelles "adresse de ligne" (et qui serait plutôt position d'un byte (ou d'un pixel, selon ce que tu comptes)

Oui c'est ça c'est la position de l'octet dans le tampon

doit se situer entre 0 et la fin de la ligne, pas la valeur max du cardinal. Si ta ligne fait 10 pixels à 32 bpp, tu auras 40 bytes donc 40 positions possibles, alors les 4,3 milliards, euh...

doit se situer entre 0 et la fin des données

Imagines que chaque case correspondent à 1 pixel :

Dimension du bitmap 5x5

x	0	1	2	3	4
0	Adresse ligne 1 = 0
1	Adresse ligne 2 = 5
2	Adresse ligne 3 = 10
3	Adresse ligne 4 = 15
4	Adresse ligne 5 = 20

Adresse du premier pixel de la ligne 1 dans le tampon = 0*5 = 0
Adresse du premier pixel de la ligne 2 dans le tampon = 1*5 = 5
Adresse du premier pixel de la ligne 3 dans le tampon = 2*5 = 10
Adresse du premier pixel de la ligne 4 dans le tampon = 3*5 = 15
Adresse du premier pixel de la ligne 5 dans le tampon = 4*5 = 20

La c'est pour 1 pixel de 1 octet mais si la taille du pixel est de 4 octet comme c'est le cas en 32bits

R

G

B

A

Le même tableau mais avec des pixels de 4 octets (4 cases)

x

0

1

2

3

4

0

R

G

B

A

r

g

b

a

r

g

b

a

r

g

b

a

r

g

b

a

1

R

G

B

A

r

g

b

a

r

g

b

a

r

g

b

a

r

g

b

a

2

R

G

B

A

r

g

b

a

r

g

b

a

r

g

b

a

r

g

b

a

3

R

G

B

A

r

g

b

a

r

g

b

a

r

g

b

a

r

g

b

a

4

R

G

B

A

r

g

b

a

r

g

b

a

r

g

b

a

r

g

b

a

il faut donc multiplier par 4

ligne 3 = 2*5 = 10 * 4 = 40
ou 2*(5*4) = 2* 20 = 40

Adresse du dernier pixel tu veux dire ?

Oui c'est ça.
Dans le tableau ci-dessous il est à la position x = 4 et y = 4

Donc pour trouver l'adresse précise d'un pixel n'importe ou il faut faire

Adresse pixel = y * (Width *4 ) + (X * 4) simplifié = (Y* Width + X)*4

Avec X et Y compris entre 0 et Width-1 ou 0 et Height-1

[Jipété]

Comment ça en octets ??? La largeur et la hauteur sont en nombre de pixels = 20502x19839

Non non non non non et non !

Trouvé ça chez SO (tout en bas) :

A bitmap is usually organised such that there are "height" spans of "width" pixels. Therefore you should step through each pixel in a span and then move to the next span.

J'ai demandé à google de me traduire "span", il m'a sorti "envergure", que je surtraduirais par "ligne" pourquoi pas, auquel cas la dernière phrase devient : vous pouvez parcourir tous les pixels d'une ligne puis passer à la ligne suivante.

biHeight c'est un compteur de lignes et rien de plus.

On en a parlé ici même au début de cette discussion, j'ai montré une copie d'écran d'une image 4x1x32 où on voit bien 16 bytes qui se suivent et c'est tout.

Un jour un stagiaire pas trop au courant a fait un copier-coller malencontreux de biWidth vers biHeight, a changé l'identifiant et depuis l'énormité du texte explicatif dans la structure du header perdure...

On a biHeight lignes qui contiennent biWidth pixels, compliquons pas les choses, elles le sont assez comme ça.

Je lirai le reste demain, à la fraîche, là, c'est intenable.

[BeanzMaster]

Non non non non non et non !

Trouvé ça chez SO (tout en bas) :

J'ai demandé à google de me traduire "span", il m'a sorti "envergure", que je surtraduirais par "ligne" pourquoi pas, auquel cas la dernière phrase devient : vous pouvez parcourir tous les pixels d'une ligne puis passer à la ligne suivante.

biHeight c'est un compteur de lignes et rien de plus.

On en a parlé ici même au début de cette discussion, j'ai montré une copie d'écran d'une image 4x1x32 où on voit bien 16 bytes qui se suivent et c'est tout.

Un jour un stagiaire pas trop au courant a fait un copier-coller malencontreux de biWidth vers biHeight, a changé l'identifiant et depuis l'énormité du texte explicatif dans la structure du header perdure...

On a biHeight lignes qui contiennent biWidth pixels, compliquons pas les choses, elles le sont assez comme ça.

Je lirai le reste demain, à la fraîche, là, c'est intenable.

T'arrives pas à te mettre dans la tête que TAILLE_D_UN_PIXEL = 4 BYTES dans mon cas

LA TAILLE D'UN LIGNE = LARGEUR_DU_BITMAP * TAILLE_D_UN_PIXEL
TAILLE TOTAL DE L IMAGE = (LARGEUR_DU_BITMAP * HAUTEUR_DU_BITMAP) * TAILLE_D_UN_PIXEL

NUMERO_DE_COLONNE entre 1 et LARGEUR_DU_BITMAP compris (biWidth)
NUMERO_DE_LIGNE entre 1 et HAUTEUR_DU_BITMAP compris (biHeght)

POSITION D UN PIXEL DANS UN LIGNE = (((NUMERO_DE_LIGNE - 1) * LARGEUR_DU_BITMAP ) + (NUMERO_DE_COLONNE-1)) * TAILLE_D_UN_PIXEL
Compte les cases de mon tableau tu verras bien par toi même

Et voila ton image de 4x1x32
R = 1 Octet - G = 1 Octet - B = 1 Octet - A = 1 Octet = 4 octets

x	0	1	2	3
0	RGBA	RGBA	RGBA	RGBA

Fais un test avec Canvas.Pixels[X,Y];Que te donne [/c]Couleur_pixel_4x1 := Canvas.Pixels[4,1];[/c] ?

Pour parcourir ton image tu fais bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
For y:= 0 to Height - 1 do
  For X:= 0 to Width - 1 do
  begin
  end;

Non ? tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
For y:= 1 to Height  do
  For X:= 1 to Width  do
  begin
  end;

?

que tu le veuille ou non l'adresse du premier pixel d'une image sera toujours à 0

Bref, ceci étant dit merci pour ta remarque, et passons à autre chose

Adresse du dernier pixel tu veux dire ?

J'ai été vérifié mes logs et l'adresse de lecture ndans le fichier ne correspondait pas.
J'ai donc corrigé le bug et tadam







Je vais de ce pas testé sous linux

[foetus]

J'ai demandé à google de me traduire "span", il m'a sorti "envergure", que je surtraduirais par "ligne" pourquoi pas, auquel cas la dernière phrase devient : vous pouvez parcourir tous les pixels d'une ligne puis passer à la ligne suivante.

wordreference est plus efficace (je tape dans mon moteur Web favori le mot à traduire suivi de wordreference)

span : c'est intervalle ou durée. "span of time", l'exemple qui me semble le plus connu.
Je pense qu'ici on peut le remplacer par chunk

biHeight c'est un compteur de lignes et rien de plus.

Oui tu as raison, height c'est la hauteur d'une image et width la largeur.

Donc,

• 1 pixel = nb_bits
• 1 ligne (row) = (1 pixel * width) + padding
• taille donnée brute = 1 ligne * height

Pour parcourir ton image tu fais bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
For y:= 0 to Height - 1 do
  For X:= 0 to Width - 1 do
  begin
  end;

Non ?

Si on ne le fait pas c'est parce que la mémoire est linéaire et qu'on précharge toujours la valeur et des valeurs contiguës.
Et en respectant ce fonctionnement, on évite autant que faire se peut des défauts de cache (cache misses)

[BeanzMaster]

Et voila sous Linux (désolé pour compression GIF )





Au cas ou mon erreur se trouvais dans mon TBZCustomBufferStream

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
Procedure TBZCustomBufferedStream.Flush;
Begin
 
  //Clear;
  StreamViewStart := StreamViewStart + BufferPosition; // ----- C'ETAIT ICI
 
  //StreamViewEnd :=
  // StreamViewLength :=StreamViewEnd - StreamViewStart + 1;
  StreamBytesLeft := StreamSize - BufferPosition;
  BufferSize := BufferDefaultSize;
 
  BufferBytesRead := 0;
  BufferBytesLeft := -1;//BufferSize;
  BufferPosition := 0;
  BytesInBuf := 0;
  NeedStreamWrite := False;
End;

Quid, alors, pourquoi le TBITMAP se vautre et surtout ou ????

Si on ne le fait pas c'est parce que la mémoire est linéaire et qu'on précharge toujours la valeur et des valeurs contiguës.
Et en respectant ce fonctionnement, on évite autant que faire se peut des défauts de cache (cache misses)

Bonne remarque

[BeanzMaster]

Je viens de faire un test avec BGRABitmap

Le FireFoxLarge est chargé, mais convertit en niveau de gris. Pourquoi ? aucune idée



Le triptique lui s'affiche bien



Le code

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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
unit Unit1;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls,
  StdCtrls, ExtDlgs, BGRABitmap;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    OPD: TOpenDialog;
    Timer1: TTimer;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure FormPaint(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
    image: TBGRABitmap; 
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  image := TBGRABitmap.Create(1,1);
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  if opd.execute then
  begin
    image.LoadFromFileUTF8(opd.FileName);
  end;
end;
 
procedure TForm1.FormDestroy(Sender: TObject);
begin
  image.Free;
end;
 
procedure TForm1.FormPaint(Sender: TObject);
 var stretched: TBGRABitmap;
begin
  stretched := image.Resample(ClientWidth, ClientHeight) as TBGRABitmap;
  stretched.Draw(Canvas,0,0,True);
  stretched.Free;
end;
 
end.

Ca se précise l'erreur provient de TLazIntfImg ou de TBitmap voir de TFPCustomImage . BGRABitmap descend de TFPCustomImage. BGRABitmap corrigerait-il corrigé des erreurs provenant de TFPCustomImage ???

[jurassic pork]

1^re question : j'ai trouvé une image énorme dans le sens où elle fait 30000 x 17078, c'est un jpeg qui pèse 234 Mo, et comment a-t-elle bien pu être créée si l'une de ses dimensions est en dehors des clous ?
Bien sûr aucun de mes outils Lazarus ne l'ouvre, pas plus que d'autres outils Linux, mais ImageMagick et The Gimp s'en sortent haut la main (en y passant 5 minutes quand même).

L'ayant ouverte dans The Gimp, je me suis dit que j'allais la ramener dans les supposés clous avec un redimensionnement à 28106 x 16000 et il aura fallu au Gimp environ 20 à 25 minutes pour enregistrer un fichier de 176 Mo (peut-être à cause de la compression que je n'ai pas eu l'idée de ramener à "aucune") :
Pièce jointe 398857

sous windows il y a un logiciel gratuit léger qui a l'air de s'en sortir pas mal pour manipuler de grosses images c'est IrfanView téléchargeable ici

avec la version 64 bits , il lui faut 10 secondes pour charger votre grosse image :




pour retailler l'image en 28106 x 16000 en utilisant lanczos il lui faut une dizaine de secondes et pour sauvegarder l'image une quinzaine de secondes.

Ami calmant J.P (sans T)