Discussion :

[Jipété]

Et comment peux-tu voir ça dès lors que tu lis systématiquement 4 octets integer(p1^)

Parce qu'on croit lire systématiquement 4 octets !

Regarde :
1^er pixel différent entre l'original (en haut) et le modifié (avec le M rouge et la souris dessus, pour que la loupe fasse son office).


Regarde bien le mémo 3^e colonne : c'est l'original, et le carré noir dans la loupe montre où je "pipette" la couleur, 1 pixel à gauche du rouge (ça n'aurait présenté aucun intérêt d'être dessus) et 4^e colonne c'est integer(p2^) où on voit bien les suites rouges (0 0 225, RGB inversé), on attaque en haut à gauche du M.
(1^re colonne c'est h du balayage vertical, 2^e colonne c'est w de l'horizontal).
Quant au bleu dans l'original, il fluctue un poil 201 dans la loupe mais pas dans le mémo, puis 202 ... 203 ... 202, les deux autres sont stables (217 222)

Si on regarde bien, on a l'impression que le carré noir de la loupe est presque à la même distance du bord gauche et du bord haut, presque, hein, à peine un poil plus court en largeur, or le mémo dit 22 et 57.
Oui ! Parce que 57 / 3 = 19 et 19 c'est presque 22.
22 c'est la ligne de pixels, et 57 c'est le byte dans la ligne en cours d'analyse, pas le pixel. Si on parlait en colonnes, on dirait 22 (de haut) 19 (depuis le bord), ce qui correspond à la grande image (pas la loupe, qui ne montre pas les bords, méfiance !)

De plus et du fait que la boucle soit fausse (inc(p1) décale de un octet et non de un pixel) tu dois obligatoirement te retrouver à un moment ou un autre avec des valeurs supérieures ou égales à 2²⁴ (à moins que l'image soit noire).

Elle est fausse ? Elle me va très bien, je peux comparer les octets, je pourrai choper l'alpha, bientôt !

Et le plus fou, donc, c'est que si je teste avec deux fichiers 32 bits, le résultat dans le mémo est le même ! Pas de copie d'écran, croyez-moi sur parole, merci.
J'ai même rajouté, tout en fin de boucle,

Code :

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

1
2
3
      inc(h);
    end;
    memo1.lines.Add(inttostr(h)+' '+inttostr(w)); // 300 1199 avec fic 24 (1199 = 400x3 -1)

400 parce que mes fichiers font 400 px de large sur 300 lignes de haut.

Et lol de lol, j'ai les deux mêmes valeurs avec mon fichier 32 bits, or à aucun moment je n'interviens sur ces paramètres ! Au contraire même, la proc appelante force le bmp.PixelFormat en fonction du BitmapInfoHeader (et j'ai vérifié à coups de ShowMessage, c'est good).
La seule intervention qui peut mettre sa pagaille, c'est les bmp.Scanline[h], je ne vois que ça...

quand c'est inférieur à 16 c'est du mono dans mon souvenir donc
1 byte suffisait à définir le pixel

J'ai lu à la va-vite (suis pressé c't'aprème...), j'ai cru à une histoire de padding, désolé.

[Jipété]

Salut salut,

allez, pour vous mettre l'eau à la bouche, voici un petit intermède sympathique :

• à gauche le fichier original avec canal alpha, plusieurs calques tous avec l'opacité à 100 % et une exportation A8R8G8B8 demandée à The Gimp. -- Basique.
• au milieu j'ai rajouté un calque "nouveau depuis le visible" en haut de la pile et je lui ai descendu l'opacité à 80 %, puis j'ai décoché la visibilité de tous les calques dessous SAUF le fond tout en bas, qui est blanc, et export comme précédemment.
• à droite je me suis ensuite contenté de juste décocher la visibilité du calque blanc du fond, résultat l'image s'est affichée avec le damier matérialisant la transparence, et export comme les deux autres. Vous allez me dire "mais elle n'est pas transparente ton image !" "Bah nan je réponds, voir dessous la seconde constatation..."

Analyse :
les 4 bytes qu'on lit proviennent de l'affichage d'un éditeur hexa et représentent ce que voit une pipette positionnée sur le coin complètement en haut à droite de l'image.

• Première constatation, l'ordre des bytes n'est pas A8R8G8B8 tel que demandé dans la fenêtre des options avancées d'exportation, mais B8G8R8A8 (confirmé au colorpicker). Pourquoi ? Mystère... Mais la liste des 4 bytes de chaque pixel serait-elle parcourue à l'envers ?
• Seconde constatation sur l'image de droite : là le canal alpha a changé (CC_hex ça fait 204₁₀ et 255 x 80 / 100 = 204, rappel : le calque a une opacité de 80 %) et les couleurs sont intactes ; ce n'est pas vraiment ce qu'on voit à l'écran, mais d'après ce que j'ai compris, mon environnement de bureau sous Linux ne gère pas la transparence.

Voilà.

Et du coup je profite de ce post, j'ai la joie l'honneur le plaisir et l'avantage de vous annoncer que je peux sans problèmes détecter les différences entre ces fichiers à condition de virer ces cochonneries de RawImage.Description, RawImage.GetLineStart et autres Scanline, toutes choses donnant l'impression qu'on est proche du cœur des choses mais c'est faux !
Pour atteindre les bonnes datas, pas d'autre solution que de passer par des procédures perso après avoir récupéré les bonnes données à coups de BlockRead dans les fichiers.

Bientôt un zip pour démontrer tout ça, soyez un peu patients...

[BeanzMaster]

Salut salut,

allez, pour vous mettre l'eau à la bouche, voici un petit intermède sympathique :

• à gauche le fichier original avec canal alpha, plusieurs calques tous avec l'opacité à 100 % et une exportation A8R8G8B8 demandée à The Gimp. -- Basique.
• au milieu j'ai rajouté un calque "nouveau depuis le visible" en haut de la pile et je lui ai descendu l'opacité à 80 %, puis j'ai décoché la visibilité de tous les calques dessous SAUF le fond tout en bas, qui est blanc, et export comme précédemment.
• à droite je me suis ensuite contenté de juste décocher la visibilité du calque blanc du fond, résultat l'image s'est affichée avec le damier matérialisant la transparence, et export comme les deux autres. Vous allez me dire "mais elle n'est pas transparente ton image !" "Bah nan je réponds, voir dessous la seconde constatation..."

Analyse :
les 4 bytes qu'on lit proviennent de l'affichage d'un éditeur hexa et représentent ce que voit une pipette positionnée sur le coin complètement en haut à droite de l'image.

• Première constatation, l'ordre des bytes n'est pas A8R8G8B8 tel que demandé dans la fenêtre des options avancées d'exportation, mais B8G8R8A8 (confirmé au colorpicker). Pourquoi ? Mystère... Mais la liste des 4 bytes de chaque pixel
  serait-elle parcourue à l'envers ?

Elle ne sont pas parcourue, les données des pixels dans les fichiers au format BMP sont écrites en BIG-ENDIAN. Donc normal jusque là.

Les Informations de l'encodage BitField, vu qu'il n'y pas d'encodage les pixels sont bien écrit au format par défaut ABGR comme décrit dans les spécifications

• Seconde constatation sur l'image de droite : là le canal alpha a changé (CC_hex ça fait 204₁₀ et 255 x 80 / 100 = 204, rappel : le calque a une opacité de 80 %) et les couleurs sont intactes ; ce n'est pas vraiment ce qu'on voit à l'écran, mais d'après ce que j'ai compris, mon environnement de bureau sous Linux ne gère pas la transparence.

Voilà.

Normal là aussi cela provient des spécifications du format bmp et de la gestion d'affichage en transparence de Windows

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

AlphaFormat
This member controls the way the source and destination bitmaps are interpreted. AlphaFormat has the following value.
Value Meaning
AC_SRC_ALPHA : This flag is set when the bitmap has an Alpha channel (that is, per-pixel alpha). Note that the APIs use premultiplied alpha, which means that the red, green and blue channel values in the bitmap must be premultiplied with the alpha channel value. For example, if the alpha channel value is x, the red, green and blue channels must be multiplied by x and divided by 0xff prior to the call.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Donc je pense que Gimp applique ce principe en sens inverse lors de la sauvegarde.

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
function UnPremultiplyAlpha(const Pixel: TColorFPRec): TColorFPRec;
begin
  Result.A := Pixel.A;
  if Pixel.A <> 0.0 then
  begin
    Result.R := Result.R / Pixel.A;
    Result.G := Result.G / Pixel.A;
    Result.B := Result.B / Pixel.A;
  end
  else
  begin
    Result.R := 0;
    Result.G := 0;
    Result.B := 0;
  end;
end;

Il faut te dire que RawImage ne reflète pas ton fichier BMP tel qu'il est. Le RawImage est une "passerelle" pour afficher et convertir les données (par rapport au format par défaut définit par les développeurs de FPC et en plus il peut être différent suivant les OS). Le problèmes et il est vrai c'est que parfois les informations fournies ne sont pas très limpides. Par exemple le bitCount, il faut le coupler avec HasAlpha, pour en déduire la valeur juste du PixelFormat. Mais ces 2 informations sont surtout utilisées dans la gestion de l'affichage. Exemple prend le fichier bmpsuite-2.5/g/rgb32.bmp. Regardes les valeurs du canal Alpha. Elles sont à 0. 0 = Transparent, donc normalement tu ne devrait pas la voir. non ?
Pas évident à comprendre, tout ça. Toi t'as de la chance tu as encore plein de cheveux à t'arracher ! moi j'ai plus rien

Bref je suis très curieux de voir ton test

A+

[BeanzMaster]

Je viens de faire un petit test, j'ai créé les 3 fichiers comme tu l'as décrit sous Gimp et je les ai lu et affiché dans mon projet. Je vais t'aider en démontrant que RawImage n'est pas FINI et que des incohérences existent

Petite capture :




On vois bien que TBitmap se vautre carrément là, y'a même pas besoin de regarder les informations

[EDIT] Oups oublié d'encadrer le pixelformat aussi
Notes également le BytesPerLine dans la description du TBitmap. C.'est la que tu veux en venir avec ton test, non ?

[/EDIT]

[EDIT]
Petite info en passant les incohérences du TBitmap proviennent de la procédure de chargement des fichiers BMP de la LCL (TLazReaderDIB dans l'unité lcl/IntfGraphics) car c'est là que sont initialisés et ou modifiés certains paramètres du RawImage, comme le Depth par exemple.

[/EDIT]

[anapurna]

salut

j'adore la lecture des sources

officially no alpha support, but that breaks older LCL compatebility

oh moins comme cela tu est au courant

[Jipété]

salut

j'adore la lecture des sources


au moins comme cela tu es au courant

Merci, c'est une bonne tranche de rigolade, ce soir ! Mais sait-on de quand ça date ? Tant bien c'est périmé et ça a été oublié ? Tu l'as trouvé dans quel fichier ?

Et je te (vous !) rappelle que j'ai un jour trouvé ça sur le web (tout en bas de la page), déjà posté mais faut longtemps taper sur le clou pour l'enfoncer :

TRawImage : This object currently is subject to refactoring, don't use it in application code.

Et là aussi on n'a pas de dates. Na-vrant !

Bon, allez, j'y retourne, je poursuis mon petit bonhomme de chemin à base de BitmapInfoHeader et de Streams, ça avance bien

[Jipété]

Petit montage gif amusant pour se détendre un peu :



Vous noterez en bas à droite "Images identiques" ! On le croirait pas, hein, vu comme ça. Pourtant ça doit être vrai, au niveau des bytes c'est surement les mêmes.

Je rappelle que l'image moche vient d'une discussion chez les voisins de Delphi, créée (l'image, pas la discussion) par Andnotor, et que cette image moche s'affiche bien sous Windows ainsi que sous Linux avec Qt et Laz 1.6.2 (là vous voyez Gtk2 et Laz 1.4).
J'attends donc avec impatience la sortie de la 1.8 définitive...

Quant à l'image "belle", c'est juste l'ouverture de la moche dans Gimp (où elle s'affiche bien) et sa réexportation sous un autre nom, sans rien changer.
Pi d'abord la moche n'est moche que dans Lazarus : elle est parfaite dans l'explorateur de fichiers, dans le visionneur rapide, dans Gimp, dans ImageJ, etc.

D'après Andnotor, post 38,

Il y a clairement un problème d'offset si l'image d'origine n'est pas supportée sous Lazarus. Par exemple si la taille de l'entête est calculée par SizeOf(BITMAPV5HEADER) plutôt que récupérée dans le fichier lui-même ou peut-être en supposant qu'il y a toujours des informations de couleur.

Va encore falloir jouer avec l'éditeur hexa : z'avez pas vu mon aspirine ?

Un dernier mot : le dégradé moche dans le bleu vient de la compression gif, je ne contrôle pas ce process.

[Jipété]

Bonjour,

Va encore falloir jouer avec l'éditeur hexa

Voilà qui est fait.

Je reviens donc sur cette histoire qui me prend la tête car je n'arrive pas à voir où Lazarus se vautre, dans la mesure où l'examen des headers ne révèle pas de différences (bas de la 1^re image), pas plus que les infos remontées par imgDisplay.Picture.Bitmap.RawImage.Description, au bas de la seconde image (honte sur moi pour avoir utilisé RawImage, ).
1^re image :

Le point curieux dans le beau fichier, c'est ce 02 à l'adresse 6A (7^e ligne) dont je ne sais pas à quoi il correspond. Est-ce lui qui fait la différence ?
seconde image :

On voit bien que les pixels en couleurs sont identiques, 7B B8 E7 et FF de padding pour le 1^er pixel, et ainsi de suite.

Bref, c'est à n'y rien comprendre, et pourtant le fichier "moche" s'affiche comme je vous l'ai montré, tout en vrac dans Lazarus (ailleurs c'est good, je le rappelle), alors que les données sont strictement les mêmes...

Si quelqu'un a une idée, ça pourrait être utile.
Ah, je remets le fichier suspect : FondRVB.zip

[Jipété]

Bref je suis très curieux de voir ton test

J'avais dit "3 jours", ça risque d'être 3 semaines si ça continue comme ça (à lire en 2 temps, comme une histoire avec un rebondissement au milieu) :

[Jipété]

Bonjour,

j'avais dit qu'il n'y aurait plus de code, et pour le moment je tiens parole,
EDIT : quoique...
pour une utilisation (qui a parlé d'expérience , comme un peu partout depuis quelque temps ?) encore plus confortable, rajoutez-vous une ligne tout à la fin de la proc de drag'n'drop, comme ça :

Code :

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

1
2
3
4
5
procedure TMainForm.FormDropFiles(Sender: TObject;
  ...
  btnOpenClick(nil);
  MainForm.BringToFront; // <-- pour que la fenêtre se réaffiche par-dessus l'explorateur après le drop
end;

/EDIT


Je fais du ménage dans mes vieux fichiers, je retrouve ce joli dégradé et une intuition me pousse à le drag'n'droper (que du bonheur ce truc !) dans mon nouvel outil, et bien m'en a pris :



Alors cette fois c'est le rouge (à gauche toute, 255 0 0) qui marque la couleur de la transparence, mais d'où le TImage sort-il cette information ?
Car si sans fermer le prog je lui drag-n-drope le 200x150x24_T, cette fois c'est le gris 84 84 84 qui devient la couleur de la transparence.
C'est enregistré dans les fichiers ? Où ?
Je rappelle que ces deux fichiers sont en pf24bit, et qu'il n'y a donc aucune info de transparence dans le TBitmapInfoHeader...

J'ai fouillé dans d'autres fichiers, et j'ai découvert un Rouge pas franc (255 17 77), un gris 169 169 169, un bleu 127 255 255, bref, ça a l'air aléatoire mais, j'y pense tout d'un coup, on dirait que ça part toujours d'en bas à gauche...

J'ai fait un test avec une image de carrés colorés dont celui en bas à gauche était bleu et transparent en activant la case : je l'ai édité pour remplacer ce bleu par du jaune, il y avait un autre carré jaune ailleurs, et maintenant les deux deviennent transparents en fonction de l'état de la case à cocher.

Voilà.
C'est une info qu'on a tendance à oublier : si on active la transparence du TImage, celui-ci détermine la couleur transparente en se basant sur celle du pixel en bas à gauche, si on ne précise pas TransparentColor := ...;.
Difficile à détecter avec les images de test 400x300 "Lena" car le pixel en question est... blanc ! Et blanc ou rien_sur_fond_blanc c'est un peu pareil,

[Jipété]

Bonjour,

j'avais dit qu'il n'y aurait plus de code, et pour le moment je tiens parole,

Microscopique cafouillage lors du drag-n-drop de 2 fichiers (découvert par l'utilisation intensive des filtres -- tout sert à tout, dans la vie)...

J'en profite pour vous signaler qu'il existe une option en cas d'images différentes : si vous faites afficher les différences, vous pouvez sauvegarder cette images par "Clic droit / Enregistrer cette image sous..."

Le zip de juste unit1.pas et unit1.lfm : unit1_v4.zip