Discussion :

[BeanzMaster]

Ok jipete je vois ce qui t'embrouille et je suis totalement d'accord avec toi sur Le RawImage c'est comme dans mon topic sur les BitFields je me cite :

Merci sans toi j'aurais pas fais le lien avant un bon moment je pense

Ca j'en tiens même pas compte à ce niveau c'est la sauce graphique de la LCL (Je me demande pourquoi ils ont nommées la classe TRawImage, TRawImage ? Il n'y a plus rien de Brut là dedans ! )

Le fait est que la LCL convertit les données provenant du fichier vers les siens et suivant sa description par defaut. Le RAWIMAGE.DESCRIPTION ne refletera jamais les données du fichier BMP ou autre

Le bitcount et le pixelformat sont à 24bit car il b'y a pas de canal alpha dans le fichier BMP (regarde les valeur AlphaPrec et AlphaShift) dans IntfGraphic dans la procedure de chargement des fichier bmp tu peux voir ça :

Ligne 5543

Code :

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

1
2
3
4
5
6
7
8
if FUpdateDescription
  then begin
    if (Info.BitCount = 32) and (Info.MaskSize.A = 0)
    then Depth := 24
    else Depth := Info.BitCount;
    DefaultReaderDescription(Info.Width, Info.Height, Depth, Desc);
    FImage.DataDescription := Desc;
  end;

En suite lors du decodage du fichier les lignes sont remis en place par defaut de Haut en Bas

voila le pourquoi du comment

[ThWilliam]

Salut JP et Beanz.

On va de surprise en surprise

JP, j'ai repris ton test d'affichage des datas de RawImage dans un Memo (code un peu modifié).
En partant d'un bitmap 24 bits dessiné en runtime, c'est ok et les octets de padding sont = 0.
Mais en partant d'un fichier 24 bits créé préalablement dans Lazarus, les octets couleurs sont ok, mais les octets de padding sont farfelus. En l'occurrence : 240, 173, 186.
Alors que dans un éditeur hexa, ces octets sont bien = 0 !!!
Ce RawImage n'a pas l'air très au point. Alors qu'il s'agit d'une bête lecture de bytes !!!

Par contre, l'écriture du bitmap en partant des données binaires marche bien. Mais testé sous Windows.

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
procedure TForm1.Button1Click(Sender: TObject);
var
  cible,cible2: TBitmap;
  pb: pByte;
  i: integer;
  LongueurDatas: integer;
  bs: TBytesStream;
begin
  // lecture
  bs:= TBytesStream.Create;
  cible:= TBitmap.Create;
  cible.loadfromfile('___bmp3x2.bmp');
  LongueurDatas:= cible.RawImage.Datasize;
  showmessage(inttostr(longueurdatas));
  pb := cible.RawImage.Data;
  for i := 0 to LongueurDatas - 1 do
  begin
     Memo1.Lines.Add(inttostr(i) +' '+inttostr(pb^));
     bs.WriteByte(pb^);
     inc(pb);
   end;
  cible.free;
  // écriture d'après bs
  cible2:= TBitmap.Create;
  cible2.pixelformat:= pf24bit;
  cible2.setsize(3,2);
  bs.position:= 0;
  LongueurDatas:= cible2.RawImage.Datasize;
  pb := cible2.RawImage.Data;
  for i:= 0 to longueurdatas-1 do
  begin
      pb^:= bs.ReadByte;
      inc(pb);
  end;
  image1.picture.assign(cible2);
  cible2.free;
  bs.free;
end;

Amicalement
Thierry

[Jipété]

SLC Salut Les Copains (sur un air connu -- qui ne nous rajeunit pas...)

Salut JP et Beanz.

On va de surprise en surprise

Par contre, l'écriture du bitmap en partant des données binaires marche bien. Mais testé sous Windows.

Chez moi sous Linux c'est l'inverse !

Ce RawImage n'a pas l'air très au point. Alors qu'il s'agit d'une bête lecture de bytes !!!

En ce qui me concerne, hier je suis reparti de la page Wiki, utilisant ce paragraphe et celui juste après, et j'en suis arrivé à ces résultats (sous Linux) :
- si je remplace lRawImage.Description.Init_BPP32_A8R8G8B8_BIO_TTB(0,0); par lRawImage.Description.Init_BPP24_B8G8R8_BIO_TTB(0,0); je gagne une magnifique erreur "div by 0" plus bas...
- si je remplace par lRawImage.Description.Init_BPP32_B8G8R8A8_BIO_TTB(0,0); je ne vois aucune différence dans l'image affichée et ce, que l'image source soit en 24 ou 32 bits.

Par ailleurs, tout ce qui concerne lRawImage peut purement et simplement être viré et remplacé par lii.DataDescription:=GetDescriptionFromDevice(0); (rappel : lii c'est TLazIntfImage) pour avoir une image correctement affichée.
On se demande vraiment comment tout ça fonctionne et surtout à-quoi-ça-sert !

Bref, il n'y a que 10 lignes et c'est le foutoir total, le tuto n'explique rien, on ne sait pas qui fait quoi et la seule explication (avec mes pauvres petits moyens et mes vieux neurones bien usés par tant d'insanités) que je vois à cette histoire de "div by 0" c'est qu'on s'éloigne du mode DIB pour plonger dans le DDB, sans que rien ni personne ne nous en informe.
Pourquoi je dis ça ? Parce que sous Linux avec gtk2, on serait en 32 bits.

Et voilà où ça plante en "div by 0" (oui, j'ai ensuite besoin d'un TBitmap), après le lii.LoadFromfile :

Code :

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

1
2
3
4
bmp := TBitmap.Create;
//bmp.PixelFormat:=pf32bit;
bmp.PixelFormat:=pf24bit;
bmp.LoadFromIntfImage(lii); // "div by 0" en 24 comme en 32 -- pourquoi ? --> il FAUT un init_BPP32, c'est le BPP24 plus haut qui fait planter ici

Allez, une 'tite dernière pour la route : j'ai inséré des ShowMessage avant lii.DataDescription:=GetDescriptionFromDevice(0); (toutes lignes concernant lRawImage commentées), après, et après lii.LoadFromFile(opd.FileName);, j'ouvre un fichier 24 bits et en haut Linux en bas XP :


Qu'on n'ait pas les mêmes résultats (regardez BitOrder, Depth ou le canal Alpha) selon les OS montre bien que RawImage n'est pas indépendant de l'environnement, et ça on le découvre aujourd'hui...

Bon, allez, vais étudier ton code, merci pour ta participation.

[Jipété]

Bon, allez, vais étudier ton code

Voilà, ça aura été rapide
Avec un fichier de 3x2x24, en haut l'original, en bas la copie (images très agrandies) :

Au colorpicker on voit bien que seule la première colonne est identique, donc problème de padding ?

Les datas dans le mémo de log correspondant parfaitement au fichier original, thanks God !, j'ai rajouté une ligne de log dans la copie :

Code :

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

1
2
3
4
5
6
7
8
9
10
  pb := cible2.RawImage.Data;
  for i:= 0 to longueurdatas-1 do
  begin
      pb^:= bs.ReadByte;
      Memo1.Lines.Add(inttostr(i) +' '+inttostr(pb^)); // ajout jpt
      inc(pb);
  end; // ici les données dans le mémo sont identiques à l'original
  image1.picture.assign(cible2); // et là elles sont en vrac (sous Linux !, pas testé sous XP) à l'affichage et
  // dans le fichier que je fais générer par 
  cible2.SaveToFile('/chemin/code_thierry.bmp');

Face à ça, je ne sais plus quoi faire...

Fouiller du côté de TLazIntfImage ? Mais c'est tellement mal documenté...

EDIT :
PS : le fait que la copie fonctionne sans erreurs (hormis les couleurs) est un hasard, car si j'essaye avec d'autres fichiers, il suffit que j'ai une différence là :

Code :

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

1
2
3
4
5
  LongueurDatas:= cible.RawImage.Datasize;
  showmessage(inttostr(longueurdatas));// 24 avec 3x2x24
  ...
  LongueurDatas:= cible2.RawImage.Datasize;
  showmessage(inttostr(longueurdatas));//ajout jpt 24 avec 3x2x24 mais 24 dessus 32 ici et donc erreur avec 4x2x24 et plein d'autres...

pour gagner une erreur "Stream read error" dans la boucle de copie.
Et pourtant, j'ai bien viré cible2.setsize(3,2);, remplacé par cible2.setsize(cible.Width,cible.Height);.

[ThWilliam]

Salut JP.

Alors, je ne vois plus qu'une solution, c'est de travailler uniquement en 32bits, et donc de transformer un éventuel 24bits en 32. Ainsi, plus de padding.
Le code de conversion que j'ai donné (page 5, 21 avril) marche-t-il sous ton Linux ?

[Jipété]

Alors, je ne vois plus qu'une solution, c'est de travailler uniquement en 32bits, et donc de transformer un éventuel 24bits en 32. Ainsi, plus de padding.
Le code de conversion que j'ai donné (page 5, 21 avril) marche-t-il sous ton Linux ?

C'était bien tenté, mais TRawImageDescription est une vraie bouze ! (ou alors nous ne savons pas nous en servir ? Mais vu l'absence totale d'aide là-dessus, c'est un peu normal...)

En utilisant ton convertisseur sur la source

Code :

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

1
2
3
4
   cible:= TBitmap.Create;
//jpt  cible.loadfromfile('___bmp3x2.bmp');
  cible.loadfromfile(opd.FileName); // jpt
  ConvertBitmapTo32bits(cible);

je me suis retrouvé avec des couleurs correctes sauf toujours R et B inversés. Qu'à cela ne tienne me suis-je dit, yakà faire corriger ainsi, dans le convertisseur :

Code :

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

1
2
//original     ImgFormatDescription.Init_BPP32_B8G8R8A8_BIO_TTB(aBitmap.Width, aBitmap.Height);
     ImgFormatDescription.Init_BPP32_R8G8B8A8_BIO_TTB(aBitmap.Width, aBitmap.Height);

et incroyable mais vrai, rien ne change au niveau de l'affichage !
Dans le mémo c'est bon (pixel orange en haut à gauche) :

Code :

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

1
2
3
4
0 255
1 139
2 0
3 255

et affichage bleu [0 139 255 255]
Un vrai truc de dingue...

Quant à ce que tu disais en avril,

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

j'ai tenté mais je me prends aBitmap.LoadFromIntfImage(Img2); // "Failed to create handles." si BPP24.

C'est vraiment pas simple...

[Jipété]

Bonjour,

face à tant d'adversité et de complications (l'inversion R<>B), je me suis dit que le problème était peut-être caché dans CopyPixels (dans la proc à Thierry) et je suis un peu allé voir son code ; on y trouve ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
  if (ASource is TLazIntfImage) and
     FRawImage.Description.IsEqual(SrcImg.FRawImage.Description) and (XDst =  0) and (YDst = 0) then
  begin
    // same description -> copy
    if FRawImage.Data <> nil then
      System.Move(SrcImg.FRawImage.Data^,FRawImage.Data^,FRawImage.DataSize);
    if FRawImage.Mask <> nil then
      System.Move(SrcImg.FRawImage.Mask^,FRawImage.Mask^,FRawImage.MaskSize);
    Exit;
  end;

Mais en exécution pas-à-pas IsEqual échoue et on passe à la suite avec la recopie des pixels un par un, pas très performant.

En réfléchissant, je me suis dit que j'allais tenter un truc de guedin dans la proc à Thierry, genre rajouter une variable et l'utiliser à bon escient :

Code :

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

1
2
3
4
5
6
7
8
var
  DataDescription: TRawImageDescription;
begin
  ...
  DataDescription := Img1.DataDescription;
  ...
  Img2.DataDescription := DataDescription;
  ...

puisqu'après tout, les deux doivent être identiques.

Effectivement, là le test IsEqual est positif, c'est bien, mais paf ! sur la ligne System.Move en surbrillance, celle dont l'infobulle indique des datas dans le Mask (sorties d'où ?) :


Dans la fonction IsEqual on peut lire, concernant le Mask, // The next values are only valid, if there is a mask (MaskBitsPerPixel > 0).
Le charme (ironique) de RawImage.Description c'est que ça remonte HasMask->False et MaskBitsPerPixel=1 !

Dans ces conditions, comment peut-on s'y retrouver ?

Pour essayer de comprendre, dans un autre bouton j'ai rajouté des infos comme ça, et suivez bien l'évolution de MaskBitsPerPixel dans les commentaires :

Code :

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

1
2
3
4
5
6
7
8
9
bmp := TBitmap.Create;
bmp.PixelFormat:=pf32bit;
ShowMessage(StringReplace(bmp.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll])); 
// MaskBitsPerPixel=1
ShowMessage(StringReplace(lii.DataDescription.AsString, ' ', LineEnding, [rfReplaceAll])); 
// MaskBitsPerPixel=1
bmp.LoadFromIntfImage(lii);  // lii = TLazIntfImage
ShowMessage(StringReplace(bmp.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll])); 
// MaskBitsPerPixel=0

Comment le fait de charger le bmp avec un lii dont le MaskBitsPerPixel est à 1 passe celui du bmp à 0 ?

Je vous laisse méditer là-dessus...
(en général, quand je vous écris, il me vient des idées, ) Et donc, j'ai rajouté une ligne (après tout, pour le moment j'en ai rien à cirer des Masks) :

Code :

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

1
2
3
4
5
6
7
8
9
var
  DataDescription: TRawImageDescription;
begin
  ...
  Img1.DataDescription.MaskBitsPerPixel:=0; // ajout
  DataDescription := Img1.DataDescription;
  ...
  Img2.DataDescription := DataDescription;
  ...

et là, miracle !, le test IsEqual passe sans planter et surtout, surtout, j'ai les bonnes couleurs !
Enfin !

Ouais, sauf qu'il y a toujours une ligne qui n'a aucune influence sur le rendu des couleurs, alors il faudrait qu'on m'explique, là.
Que j'utilise l'une ou l'autre de ces lignes (notez bien la 3^e où je passe le canal Alpha devant),

Code :

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

1
2
3
lRawImage.Description.Init_BPP32_B8G8R8A8_BIO_TTB(aBitmap.Width, aBitmap.Height);
lRawImage.Description.Init_BPP32_R8G8B8A8_BIO_TTB(aBitmap.Width, aBitmap.Height);
lRawImage.Description.Init_BPP32_A8R8G8B8_BIO_TTB(aBitmap.Width, aBitmap.Height);

c'est exactement pareil à l'affichage.

Et je n'ai plus d'idées...

[anapurna]

salut

bon rien à voir avec tes soucis mais peut être que cela pourra te donner des idées

j'ai trouvé sur le web une chose forte intéressante, le jour ou tu veut reprendre le code Delphi sans modif
il suffit de créer un helper de la class parente a ton image en l’occurrence la classe parente est ... (suspens) ... TRasterImage

et le code du Helper est ...

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
 
interface
type
  TRasterImage = Graphics.TRasterImage;
 
  TRasterImageHelper = class helper for TRasterImage
  strict private
    function _GetScanLine(const AY: cardinal): pointer;
  public
    property ScanLine[const AY: cardinal]: pointer read _GetScanLine;
  end;
 
implementation
 
function TRasterImageHelper._GetScanLine(const AY: cardinal): pointer;
begin
  Result := RawImage.Data + RawImage.Description.BytesPerLine * AY;
end;

de cette façon tu as un scanline valide pour toutes les images
.... c'est super intéressant de rechercher dans les sources on y trouve des petit trésor

[Jipété]

Merci pour cette proposition sympathique, que je testerai rapidement, mais pas ce soir.

Ce soir j'ai pas le moral, entre l'initiative nulle à vomir de l'autre abruti aux States et l'abandon de mon gtk par les gars de Lazarus, c'est pas la joie.

[Jipété]

Pas eu le temps de m'occuper de ton affaire, anapurna, je suis sur un truc là, c'et invraisemblable, inimaginable, je ne sais pas je n'ai pas de mots pour décrire ce qui se passe, allez hop, l'image (réduite) du soir :


Explications : c'est le même code en haut et en bas qui ouvre le même fichier, en utilisant un bête TPicture ; la seule différence c'est qu'il s'agit de deux projets, mais c'est un bête TImage utilisé pour afficher, sans options particulières...
Vous noterez que ce sont les zones blanches qui sont concernées, les gris très clair ne sont pas touchées, comme si le blanc dans celle du bas était concerné par... Par quoi, au fait ? Si c'était par de la transparence, je verrais ce qu'il y a dessous, et ce n'est pas le cas.
Je ne sais plus quoi penser, et du coup je ne sais pas quoi chercher ni où.

Je répète :

c'est le même code qui ouvre le même fichier.

[Jipété]

Bon voilà,

encore un truc de malade !


Là c'est deux fois le même prog, la seule différence c'est la couleur de la fiche, en haut 2C2C2C_hex et en bas Default.

Ce qui m'a foutu dedans, c'est le damier et la zone "Testing with text" dans lesquelles, en regardant vite, on dirait qu'en bas le blanc est blanc mais que nenni ! Au colorpicker, ce blanc est en fait 237 236 235, la même couleur que la fiche ! (On dirait pas, hein !, quand on compare le gris lumineux sous le bouton et le "blanc" sur l'épaule de Lena : j'avais complètement oublié que notre cerveau corrige en permanence et que là, comme je voulais voir du blanc, mes neurones corrigeaient et je voyais du blanc ; mais avec le fond gris très foncé, c'était trop difficile de corriger.)

Or sur le fichier original le blanc est bien à 255 3 fois : j'en conclus que bien que n'ayant pas activé la transparence, celle-ci est quand même active.

Avec Lazarus il faut prendre l'habitude de réfléchir à l'envers -- des fois mais pas toujours.
Vous voyez le gag ?
Allez, encore quelques heures de perdues, merci les codeurs

Maintenant, la grande question c'est : comment faire pour se débarrasser de ce problème ?
Car, que je code

Code :

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

1
2
3
4
5
procedure TForm1.Button1Click(Sender: TObject);
begin
  imgDisplay.Transparent:=False;
  if opd.Execute then OpenImage(opd.FileName);
end;

et/ou

Code :

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

1
2
3
4
5
6
7
8
procedure TForm1.OpenImage(Filename: string);
var
  pic: TPicture;
begin
  pic := TPicture.Create;
  pic.Bitmap.Transparent:=False;
  ...
end;

le problème reste entier à l'affichage...

Pour le moment, je m'en sors en posant mon TImage dans/sur un TPanel dont la couleur est mise à blanc et ça le fait, mais d'aucuns diront que c'est "sale".
Ben oui, pi faut aussi penser à le gérer sur le long terme, répliquer cette solution dans tous les projets où il y a un TImage (tiens, faudrait que je me fasse un composant dédié à ça), mais bon, la courroie de l'alternateur avait cassé je me suis dépanné avec un bas de ma chérie, à l'ancienne, et je peux reprendre la route.

Allez, cadeau :

(agrandissement de mon image de test 400x300 à 600x450 avec l'algorithme Mitchell, pour les curieux)

[ThWilliam]

Salut JP.

Pour le moment, je m'en sors en posant mon TImage dans/sur un TPanel dont la couleur est mise à blanc et ça le fait, mais d'aucuns diront que c'est "sale".

Absolument pas !
Quand une image contient des zones transparentes, ces zones, à l'écran, prennent la couleur du composant parent.
Ce qui explique les différences selon la couleur de la fiche.
Donc, si tu désires que les zones transparentes soient "vues" blanches, ton panel blanc est une bonne solution si la couleur de la fiche n'est pas blanche.

Amicalement
Thierry

[Jipété]

Salut, Thierry

Quand une image contient des zones transparentes, ces zones, à l'écran, prennent la couleur du composant parent.
Ce qui explique les différences selon la couleur de la fiche.
Donc, si tu désires que les zones transparentes soient "vues" blanches, ton panel blanc est une bonne solution si la couleur de la fiche n'est pas blanche.

Oui, tout ça je l'ai découvert tout seul comme un grand, et l'image en cadeau est là pour en témoigner. La seule question qui reste en suspens, c'est "d'où sortent ces zones transparentes ?"
D'autant plus qu'avec des nouveaux tests ce matin (mise en place d'autres filtres), les fichiers générés n'ont plus de zones transparentes !
Me serais-je mélangé les pinceaux quelque part ?
C'est curieux car dans ce domaine, il suffit de simplement penser qu'on risque de se faire des nœuds pour que le prog t'explose à la tête au prochain F9 ! Or je n'ai rien eu de dramatique

Bon, faut que je termine ces histoires de filtres...

[Jipété]

Bon, faut que je termine ces histoires de filtres...

Et je vais enfin pouvoir cliquer sur et ça c'est cool ! Mais d'abord quelques lignes et deux images :

Ces jours-ci j'ai vécu un peu l'enfer car je me suis à nouveau retrouvé face aux traits verticaux qui indiquent un problème de scanline mal exécuté ou mal paramétré ou que sais-je encore, et pas clair du tout car si je fais un petit scénario, on va voir que c'est tout à la fin que ça débloque mais que c'est difficile à voir :

1. je choisis un fichier .bmp ou .jpg avec l'OpenPictureDialog ;
2. je fais afficher son image au moyen d'un TImage ; c'est bon ;
3. je redimensionne cette image au moyen d'un filtre de resampling (rappel : toutes ces manips servent à comparer le rendu esthétique de ces filtres) et je fais afficher le résultat ; c'est toujours ok ;
4. j'ai prévu la possibilité (clic droit / Enregistrer l'image sous...) d'enregistrer le TImage avec un TSavePictureDialog et un bête image.Picture.Bitmap.SaveToFile(spd.Filename) et là, selon comment on regarde le fichier enregistré, il est bon ou pas !

Un exemple ? Choisissons donc de l'ouvrir, ce fichier enregistré, et voilà une copie d'écran de l'OpenPictureDialog avec la vue miniature correcte dans la partie "explorateur de fichiers" à gauche, et la preview à la ramasse à droite.
Que dire de plus ?


Le drame c'est que ces fichiers pourris semblent pourris dans Lazarus car par exemple sur la copie d'écran suivante on voit à gauche mon diaporama en cours de dév avec au centre de l'image la zone d'affichage et le fichier moisi mais pas tant que ça puisqu'à droite on a la vision de l'outil "visionneur rapide" de Linux et pour lui, le fichier est bon, tout comme la miniature affichée sur le Bureau, en haut à gauche.
Alors ? Qui a raison, qui a tort ?


Bien sûr j'ai cherché un tas de trucs (pendant un temps dément), j'ai tenté un tas de machins (avec cette chaleur, est-ce bien raisonnable ?) avant le resampling, et je suis bon, je ne vous fais pas languir plus longtemps, la solution fut de remplacer le (trop ?) simple bmp.SaveToFile par un bien plus sophistiqué

Code :

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

1
2
3
4
5
6
7
8
var
  lii: TLazIntfImage;
begin
  //... dst est le TBitmap resamplé 
  //dst.SaveToFile(chemin/fichier); //génère des traits verticaux si dst resamplé
  lii := dst.CreateIntfImage;
  lii.SaveToFile(chemin/fichier); // plus de problème
  lii.Free;

Bien sûr je ne prétends pas détenir la vérité absolue et peut-être que j'ai tout faux avec l'introduction de TLazIntfImage, en tout cas je n'ai plus les défauts signalés sur les copies d'écran.
Donc en attendant mieux, on va dire que c'est bon comme ça.
Notez-le sur vos tablettes !