Nouvelles fonctions du 24/4

- Les fonctions d'accès au clipboard (CLIPBOARD_STRING_COPY et PASTE) fonctionnent parfaitement, on peut faire ce qu'on veut, y compris transmettre des textes entiers.

- Pour les fonctions FILEBIN_BLOCK_READ et WRITE, certes on a beaucoup plus de possibilités qu'avant (par exemple modifier un fichier binaire existant), mais je regrette un peu le mode d'accès: passage par un tableau d'entiers.
Il faut dimensionner préalablement ce tableau, sans connaître la taille du fichier (on ne peut pas le dimensionner dynamiquement).
Le fait de ranger octet par octet dans un tableau est extrêmement long, et l'exploitation n'est pas très facile.

J'aurais plutôt vu la lecture dans une string continue de longueur demandée, composée de caractères de 0 à 255, beaucoup plus facile à exploiter ensuite (découpage, recherches par INSTR, etc, et l'écriture de même dans une string à écrire d'un seul coup.

Je teste:

Code:

 DIM f$, sz, lbu, i% , nbl, rst
 lbu = 4096
 DIM u%(4096), v%(453787): ' taille du fichier lu
 LABEL Lecbloc

 f$ = "C:\Graph\Jpg\IMG_9504.jpg"
 
 GOSUB Lecbloc
 ' end
 
 PRINT "Lecture en un bloc": PRINT TIME$
 FILEBIN_OPEN_READ 1, f$
 sz = FILEBIN_SIZE(1): ' Lecture du fichier un une seule fois
 FOR i% = 1 TO sz: FILEBIN_BLOCK_READ 1, sz, v%(0): NEXT i%
 FILEBIN_CLOSE 1
 PRINT TIME$
 PRINT "Terminé !"
 END

 Lecbloc:
 FILEBIN_OPEN_READ 1, f$
 sz = FILEBIN_SIZE(1)
 nbl = INT(sz/lbu):  ' nb de blocs entiers à lire
 rst = lbu*FRAC(sz/lbu): ' taille du dernier bloc
 PRINT "Lecture par blocs de 4096": PRINT STR$(nbl)+" blocs, reste: " + STR$(rst)
 PRINT TIME$
 FOR i% = 1 TO nbl
    FILEBIN_BLOCK_READ 1, lbu, u%(0)
 NEXT i%
 FILEBIN_BLOCK_READ 1, rst, u%(0)
 FILEBIN_CLOSE 1
 PRINT TIME$
 RETURN

dans le sous programme Lecbloc, lecture en plusieurs morceaux, ça marche (mais 2s quand même).
Par contre la tentative de lecture en un seule bloc tourne en rond (tableau trop grand ?).

Autre remarque: on doit commencer à partir de l'indice 0 du tableau, sinon il est trop court (Indice de tableau hors limites) pourquoi ?

- A première vue, les fonctions FILEBIN_HEXA READ et WRITE semblent fonctionner de manière satisfaisante.
J'ai essayé de lire de grands blocs pour limiter les lectures, mais on est limité à 2000 octets...

Citation :

J'aurais plutôt vu la lecture dans une string continue de longueur demandée, composée de caractères de 0 à 255, beaucoup plus facile à exploiter ensuite (découpage, recherches par INSTR, etc, et l'écriture de même dans une string à écrire d'un seul coup

Mais c'est tout à fait possible, cher JL35.
Alors, certes, il y a une limite à 2000 pour la longueur du string
(2000 mm pour les femmes un peu obèses )

mais c'est tout à fait exploitable !

J'aimerais bien savoir comment tu fais ? pour lire un string de 2000 octets dans un fichier binaire (pas dans un tableau hein ! et pas non plus sous forme hexa, dans une variable chaîne).
De toute façon, 2000 octets ce n'est pas beaucoup, pour un fichier de plus d'1M, ça fait quand même 500 lectures minimum...

Pourquoi pas dans une variable chaîne ?

Code:

rem ' l'image 04_1024 fait 251943 octets
rem ' lecture et recherche en à peine une seconde
dim i , v$ , t , d , r
memo 1 : bar_horizontal 1
filebin_open_read 1,"c:\04_1024.jpg"
 t=filebin_size(1)
 d=int(t/2000)
 r=t-int(t/2000)*2000
 for i=1 to d
  filebin_hexa_read 1,2000,v$
  item_add 1,v$
 next i
 filebin_hexa_read 1,r,v$
filebin_close 1
for i=1 to count(1)
 v$=item_read$(1,i)
 if instr(v$,"122B")=1 then beep
next i

(ah, je vois que tu parlais du filebin_block... alors que moi, je parlais du filebin_hexa...,
désolé, je n'en suis pas encore là...)
alors à suivre...

Ca y est, j'en suis à BLOCK
c'est intéressant :

Code:

dim d , i
memo 1 : bar_vertical 1
filebin_open_read 1,"c:\orange.bmp"
 d=filebin_size(1)
 dim v%(209000)
 ' là, j'aurais voulu mettre dim v%(d) mais pas possible !
 filebin_block_read 1,d,v%
filebin_close 1
for i=1 to d
 item_add 1,v%(i)
next i
' ce qui est long, c'est le remplissage du memo avec for i=1 to d
' mais la lecture en filebin_block_read 1,d,v% c'est presque instantané

il y a juste le dim v%(d) qui n'est pas possible, et ça c'est dommage !

Je ne connaissais pas ces trucs-là.
A priori, le filebin_hexa... me paraît plus intéressant.

Et puis,

Code:

dim v%(20) , i
for i=0 to 20
 v%(i)=i+64
next i
filebin_open_write 1,"c:\orange.bmp"
 filebin_position 1,66666
 filebin_block_write 1,20,v%
filebin_close 1

Pauvre image orange.bmp,
avec tous ces essais, elle a maintenant une drôle de tronche !

Je reviens sur ce que j'ai dit: effectivement le FILEBIN_BLOCK_READ est assez rapide, et surtout apparemment on peut définir un tableau de taille gigantesque qui suffise pour y lire le fichier en entier en une seule fois.
Dommage comme le fait remarquer jjn4 qu'on ne puisse redéfinir le tableau à chaque fois avec la taille du fichier à lire.
Pour un fichier de 1,3M, ça met environ 6 secondes, ce n'est pas la vitesse de l'éclair, mais bon...
jjn4 a simplifié la commande puisqu'il met FILEBIN_BLOCK_READ 1, n, v% (sans préciser l'indice du tableau) et ça marche, ça remplit le tableau à partir de l'indice 0.

Ca permet donc de tout lire d'un coup, contrairement au FILEBIN_HEXA_READ qui est limité à 2000 octets.

Je continue à expérimenter, notamment la recherche d'une série dans un tableau au lieu d'une chaîne, ça doit être bien plus long...

Finalement, le plus rapide pour rechercher dans un fichier est sans doute la méthode en hexadécimal, la recherche dans un tableau prend un temps fou, alors que si on lit entièrement le fichier dans une chaîne en hexa on peut utiliser ensuite le INSTR qui est très rapide.
La lecture du fichier dans la chaîne est elle un peu longue, du fait de la limitation des lectures à 2000 octets, alors il faut en faire autant que nécessaire (8 secondes pour 1,3 M).
Par contre, après, la manipulation de la chaîne obtenue (Instr) est très aisée et rapide.

Ici on recherche la chaîne FFC00011 qui rappellera peut-être quelque chose à mon ami jjn4

Code:

 ' Recherche dans un fichier binaire d'une séquence en hexadécimal
 DIM f$, sz, lbu, i% , j%, k%, nbl, rst, a$, b$, seq$
 DIM lh%, d, vh$
 LABEL rrb, DecHex

 f$ = "C:\Graph\Jpg\IMG_2022.jpg"
 seq$ = "FFC00011"

 FILEBIN_OPEN_READ 1, f$
 sz = FILEBIN_SIZE(1): lbu = 2000
 PRINT "Fichier: " + f$ + " " + STR$(sz) + " octets."
 PRINT TIME$ + ": Lecture du fichier dans une chaîne hexa"
 nbl = INT(sz/lbu): ' nombre de lectures de 2000 octets
 rst = lbu*FRAC(sz/lbu): ' reste
 a$ = ""
 FOR i% = 1 TO nbl
    FILEBIN_HEXA_READ 1, lbu, b$: a$ = a$ + b$
 NEXT i%
 IF rst > 0 THEN FILEBIN_HEXA_READ 1, rst, b$: a$ = a$ + b$
 FILEBIN_CLOSE 1
 PRINT TIME$ + ": Fin de lecture, recherche de séquence"
 rrb:
 k% = INSTR(a$, seq$)
 if k% > 0
    d = (k% - 1)/2: GOSUB DecHex: PRINT vh$ + ": " + seq$
    a$ = MID$(a$, k%+2, LEN(a$)-k%-1): GOTO rrb
 END_IF
 PRINT TIME$ + ": Fin de recherche"
 END

 DecHex:
' conversion décimal/hexa de d, résultat vh$ (complété si utile à lh% caractères)
 vh$="": IF lh% < 1 THEN lh% = 1
 REPEAT
    vh$ = MID$("0123456789ABCDEF", 16*(d/16-INT(d/16))+1, 1) + vh$: d = INT(d/16)
 UNTIL d <= 0
 IF LEN(vh$) < lh% THEN vh$ = STRING$(lh% - LEN(vh$), "0") + vh$
 RETURN

@JL35 : J'y songe, j'y songe...
Dis-moi, pourquoi tu ne mets pas le 08 à la fin de la séquence,
ce n'est plus d'actualité ?

J'ai fait une formule à ma manière
(mon cher JL35, ce n'est pas élégant de mettre un goto dans une programmation événementielle)

Code:

rem ' Détermination des dimensions d'une image - Dim-Ph-six.bas
dim i% , v$ : rem Variables provisoires
dim c$ : rem Chaîne à analyser
dim d% : rem Diviseur
dim e% : rem Emplacement à trouver
dim h$ , h% : rem Hauteur de l`image
dim l$ , l% : rem Longueur de l`image
dim r% : rem Reste
dim t% : rem Longueur Totale de la chaîne

filebin_open_read 1,"C:\04_1024.jpg" : ' Changez la photo
 t%=filebin_size(1)
 d%=int(t%/2000) : c$=""
 r%=t%-int(t%/2000)*2000
 for i%=1 to d%
  filebin_hexa_read 1,2000,v$ : c$=c$+v$
 next i%
 if r%>0 then filebin_hexa_read 1,r%,v$ : c$=c$+v$
filebin_close 1
repeat
 e%=instr(c$,"FFC0001108")
 if e%>0
  h$=mid$(c$,e%+10,4) : l$=mid$(c$,e%+14,4)
  c$=right$(c$,len(c$)-e%-10)
 end_if
until e%=0
h%=0 : l%=0
for i%=1 to 4
 v$=mid$(h$,i%,1)
 if numeric(v$)=1
  h%=h%+val(v$)*power(16,4-i%)
 else
  h%=h%+(asc(v$)-55)*power(16,4-i%)
 end_if
 v$=mid$(l$,i%,1)
 if numeric(v$)=1
  l%=l%+val(v$)*power(16,4-i%)
 else
  l%=l%+(asc(v$)-55)*power(16,4-i%)
 end_if
next i%
print "Hauteur = "+str$(h%)
print "Largeur = "+str$(l%)

et je l'ai appliquée dans mon Album-Photos.
C'est environ 5 fois plus lent
(que ma formule avec max=1000 sinon plan B)
(même si ça a l'avantage de trouver les dimensions réelles)
Résultat : fiasco complet !

C'est le fait d'employer une variable-chaîne qui ralentit (et quelle variable-chaîne !)
Il faudrait finalement chercher une méthode avec BLOCK pour que ce soit plus rapide.


Et n'oubliez-pas : une nouvelle histoire drôle chaque dimanche sur mon site

Cette fois, j'ai appliqué la même formule, mais simplifiée,
qui comme ma formule d'avant, ne cherche que le rapport h/w,
donc se contente du premier FFC0001108 trouvé :

Code:

rem ' Détermination des dimensions d'une image - Dim-Ph-sep.bas
dim i% , v$ : rem Variables provisoires
dim e% : rem Emplacement à trouver
dim h$ , h% : rem Hauteur de l`image
dim l$ , l% : rem Longueur de l`image

filebin_open_read 1,"C:\04_1024.jpg" : ' Changez la photo
 filebin_hexa_read 1,2000,v$
filebin_close 1
e%=instr(v$,"FFC0001108")
if e%>0
 h$=mid$(v$,e%+10,4) : l$=mid$(v$,e%+14,4)
 h%=0 : l%=0
 for i%=1 to 4
  v$=mid$(h$,i%,1)
  if numeric(v$)=1
  h%=h%+val(v$)*power(16,4-i%)
  else
  h%=h%+(asc(v$)-55)*power(16,4-i%)
  end_if
  v$=mid$(l$,i%,1)
  if numeric(v$)=1
  l%=l%+val(v$)*power(16,4-i%)
  else
  l%=l%+(asc(v$)-55)*power(16,4-i%)
  end_if
 next i%
 print "Hauteur = "+str$(h%)
 print "Largeur = "+str$(l%)
else
 print "Employer le plan B"
end_if

Pas mal, c'est environ 2 fois plus rapide que ma formule d'avant !

Et n'oubliez-pas : une nouvelle histoire drôle chaque dimanche sur mon site

1) je ne me sens pas coupable de mettre un goto local pour reboucler dans une recherche, ça ne me paraît pas du tout illicite même en programmation événementielle. Ca a exactement le même effet qu'un FOR NEXT ou WHILE END_WHILE ou REPEAT UNTIL.

2) dans le FFC0001108, le 08 est une des caractéristiques de l'image (genre profondeur de couleurs), bon c'est toujours 08 mais ça pourrait théoriquement être autre chose.

3) avec ta recherche, on ne joue pas dans la même cour, évidemment que c'est beaucoup plus rapide si tu t'arrêtes au premier FFC0, qui est tout près du début du fichier (pour moi par exemple en 5256 sur un total de 1352782, soit moins de 0,4% du fichier !).
Ce n'est pas sérieux de dire que tu abandonnes si ta séquence n'est pas dans les 2000 premiers octets sous prétexte que la lecture est limitée à 2000 octets.
Et de toute façon tu obtiens une valeur fausse puisque ce ne sont pas les vraies dimensions de l'image, seulement les proportions, qui ne servent pas à grand chose, sauf dans ton cas particulier.
Là c'est un cas particulier, je parlais d'une manière générale de recherche d'une séquence donnée dans tout un fichier.

A mon avis ce n'est pas le fait d'utiliser une variable chaîne qui ralentit, c'est le fait d'avoir à faire près de 700 lectures disque pour la constituer, et aussi le fait que cette chaîne est deux fois plus longue que le fichier, puisqu'en hexa. Sans compter que la conversion interne en hexa doit aussi prendre du temps.
Et le File_Block_Read je ne le sens pas trop non plus, ça fait un tableau immense qui doit prendre une place folle en mémoire (combien d'octets de tableau occupés pour 1 octet de donnée ?), et ensuite la recherche dans un tableau ce n'est pas évident et encore moins optimal.

Je voyais plutôt la lecture dans une chaîne des octets tels quels, de valeur entre 0 et 255, qui aurait pu supporter toutes les opérations sur chaînes (INSTR, MID$ etc).
(en basic tu faisais a$=Space$(Lof(f)): Get #f,,a$ et tu avais tout le fichier dans a$. Testé sur une série de 172 fichiers de 2M en moyenne: 50 millisecondes par fichier).

Oui, pour pouvoir utiliser filebin_block_read,
il faudrait disposer de deux nouvelles possibilités :
- pouvoir dimensionner une variable avec une autre variable
- pouvoir redimensionner une variable (toujours avec une autre variable)
DIM v%(d) et REDIM v%(d).
Sinon, je ne vois pas comment.

Ben oui, faire des DIM dynamiques et paramétrables...
Mais de toute façon, mettre un fichier (ou même seulement une partie) dans un tableau, ça me paraît un peu... aberrant, d'autant plus que c'est difficile et coûteux à exploiter après.
Et même en interne, ranger les données lues octet par octet dans un tableau ça doit consommer des instructions et ... du temps machine alors qu'il aurait pu suffire de transférer le buffer de lecture tel quel dans une seule variable (en une seule instruction assembleur).

Allez, cette fois-ci