Super album photo de famille

Le calcul de la taille par la méthode que j'ai donné (Panoramic pur), ça fait environ 0,5 s par image, c'est interminable s'il y a pas mal d'images, comme c'est le cas dans un album..
(avec IrfanView, c'est 0,3 s par image, ce qui est encore très long).
Il faudrait vraiment trouver un truc pour accéder à ces dimensions (une dll Windows ?).

C'est vraiment si difficile que ça, de trouver directement l'indication de la dimension dans un jpg ?
Car ce serait plus rapide.
Bon, je m'y attèle et j'essaie de trouver.

Non, ce n'est pas si difficile, mais on n'a pas les outils en Panoramic.
Il s'agit de rechercher la séquence FF C0 00 11 08 (en hexa) dans le fichier,
qui est suivie de la hauteur (2 octets) et de la largeur (2 octets) de l'image.
Mais un fichier jpg peut contenir plusieurs images (dont une ou plusieurs 'imagette(s)': thumbnail), avant l'image principale, dont les dimensions sont définies par la même séquence dans le fichier.
Il faut donc reboucler dans la recherche, jusqu'à la dernière séquence trouvée qui précède les vraies dimensions.

Je le fais très facilement en freebasic par exemple: on lit en une seule lecture le fichier entier dans une variable a$, puis on recherche dans cette variable la séquence ci-dessus (INSTR) jusqu'à la dernière occurence trouvée, et là on extrait la hauteur et la largeur.
Ca représente une dizaine d'instructions, et ça va à la vitesse de l'éclair.

On pourrait sans doute le faire en QBasic, mais il faudrait faire des lectures de blocs successives, la longueur des variables chaînes étant limitée.

Malheureusement en Panoramic (je me répète) on est obligé de lire le fichier octet par octet, avec des tests à chaque fois, et ça met un temps fou, et c'est impraticable.

Questions :
- des imagettes en plus de l'image, il peut y en avoir une seule ou plusieurs ?
- ce qui m'intéresse, finalement, c'est le rapport longueur/largeur, je suppose que ce rapport est le même pour l'imagette (ou toutes les imagettes) ?

Il peut y en avoir plusieurs.
Le rapport est le même, mais il faut chercher quand même !
A plus tard, là je sors...

Je viens d'essayer comme tu dis.
C'est carrément beaucoup plus long que les 2 méthodes précédentes,
(par Irfan-View et par transformation en bmp)
pour une image 1024x768 (ce qui est une taille raisonnable)
cela met 23 secondes, ce qui pour 200 photos ferait environ 1h15,
là, il y aurait réellement le temps de faire une bonne sieste !

Bon, ben pendant ce temps

Il n'y plus qu'a attendre que Jack voit le problème de lecture des octets. Je crois qu'il a évoqué, mais en précisant que c'était pas pour demain.

Oh, mais je n'ai pas dit mon dernier mot !
(j'ai déjà trouvé une autre méthode qui ne fait plus que 22 sec)
L'objectif, c'est d'arriver environ à 1/20 de sec.
Bon, c'est vrai, y'a du boulot !

Tu serais, peut-être, bien plus têtu que je ne le pensais.

Le déroulement et l'issu de cette affaire m'intéresse car je viens de démarrer un code, qui promet, et j'aurais besoin d'y gérer des photos. çà va appeler ALPHA_BOOK (je ne dis que çà pour l'instant).
D'ailleurs, c'est grace à ton intervention et celle de Jack sur PRINT, que j'ai découvert les possibilités de ALPHA et je dois dire, qu'avec de l'imagination, çà donne des trucs supers.

A+

Moi ça prend au moins 20 minutes l'attente.
En plus l'ordi est lent.
J'ai environs 200 images dans "Mes documents\Mes images" avec des films que je devrais changer de place.

Je ne sais pas si cela est possible. L'album photo je ne l'ai pas vu, et ne suis pas intéressé (pour l'instant). Je ne sais pas si c'est faisable, mais il n'y a pas moyen de faire un index qui mémorise les éléments des photos qui ont déjà été scutées. Si c'est faisable, seul les nouvelles photos qui ne seraient pas dans la liste seraient à "dimensionner".
Ne sachant rien du programme, je suppose que cela ne doit pas être possible, sinon je pense que l'idée aurait été exploitée.
Il est l'heure de se réveiller, donc j'ai retiré le défilement.

Effectivement, il faut se cramponner pour lire ton texte défilant.
Si tu fais allusion à la lecture des images pour en extraire les dimensions, évidemment ça se fait une fois pour toutes, une seule fois par image, le redimensionnement étant fait par Stretch_On (enfin je suppose, puisque jjn4 ne nous a pas fait partager son source).

@jjn4, je ne vois pas bien quelle méthode tu peux imaginer pour trouver les dimensions du jpg, à part parcourir le fichier en cherchant la séquence que j'ai donnée plus haut. Et comme je l'ai déjà précisé, Panoramic est tout à fait inadapté pour le moment pour faire ça, le temps d'exécution avec les moyens actuels sont absolument rédhibitoires.

Avec un tout petit programme externe c'est très facile, mais justement il faudrait pouvoir le faire sans programme externe.

Ca y est, voilà l'travail !
Pari gagné, et même bien au delà des objectifs prévus,
puisque le programme que j'ai concocté trouve le résultat en 1/66 de sec.
Là, l'attente minimum pourrait être de 3 secondes pour 200 photos,
plus le temps même d'amorcer une toute petite sieste !
Voilà le programme :

Code:

rem ' Essai lecture rapide dimensions photo jpg - Ess-Lect-Dim-Photo
dim i% , a% , b% , c% , d% , e% , f% , g% , h% , x% , y%

list 1
height 1,200

filebin_open_read 1,"C:\04_1024.jpg" : ' Changez le nom de la photo
 for i%=1 to filebin_size(1)/2
  filebin_read 1,a%
  if a%=255
  filebin_read 1,a%
  filebin_read 1,b%
  filebin_read 1,c%
  filebin_read 1,d%
  filebin_read 1,e%
  filebin_read 1,f%
  filebin_read 1,g%
  filebin_read 1,h%
  if a%=192 and b%=0 and c%=17 and d%=8
    y%=e%*256+f% : x%=g%*256+h%
    exit_for
  end_if
  filebin_position 1,i%
  end_if
 next i%
filebin_close 1
item_add 1,x% : item_add 1,y%
item_add 1,x%/y%

Nota: l'affichage du code ci-dessus n'a pas bien respecté mes indentations.

Ca y est, c'est dans la boîte !
J'ai adapté mon programme Album-Photos en fonction de cette méthode.
Et ça marche. Le temps d'attente initial peut durer dans les 3 secondes.
Par contre, d'autres fois, je ne sais pas pourquoi, ça s'arrête et ça attend 5 secondes sans bouger avant de repartir à toute vitesse.
Je me demande si je n'ai pas fait une erreur dans ma formule ci-dessus.

C'est donc la version 1.3 qui est diffusée sur mon site.
Et j'ai ajouté ce détail à la rubrique de mon site
(voir en bas de la page de présentation de ce forum).

Du fait de plusieurs remarques, je me suis posé la question de ce qu'était une présentation intuitive. J'ai cherché sur Internet, je n'ai pas trouvé de définition.

Peut-on dire que si on met un bouton à droite pour dire d'aller à droite
(en plus un bon vieux bouton gris et rectangulaire à la grand-papa),
et même chose pour la gauche, c'est intuitif ?

Je ne crois pas, une présentation intuitive est une présentation qui fait marcher l'intuition chez l'utilisateur.
Genre : vous donnez le programme à un gamin de 10 ans qui ne le connaît pas, qui va se poser 10 questions à la secondes et dont la main va cliquer un peu partout à la même vitesse, et en 3 coups de cuillère à pot, il vous explique comment ça fonctionne.
C'est ça, l'intuition !
Alors un programme intuitif, c'est un programme qui permet à l'utilisateur d'utiliser son intuition, de se poser des questions.
Et alors mon programme Album-Photos, il est plutôt intuitif !


Ceci dit, je l'ai quand même un peu modifié au niveau des commentaires situés en bas sur la couverture (j'ai ajouté des indications de couleurs) :
- Cliquez sur la couverture rouge pour fermer l'album
- Cliquez sur les marges blanches pour tourner les pages
(c'est pour favoriser plus nettement l'intuition...)


Et puis, j'ai rajouté un bouton mauve :
Parce que pour tourner les pages, il n'y avait pas de problème,
pour aller à la dernière page, ou revenir à la première, non plus,
mais pour aller de la page 1 (ou 100) à la page 50, c'était un peu long.
Alors le bouton mauve sert à tourner plusieurs page en bloc.

jjn4, revenons un peu si tu veux bien sur ta solution miracle en binaire.

1) Tel qu'il est présenté, ton code ne peut que boucler: ton filebin_position = i% ramène indéfiniment la lecture sur ce que tu viens de lire (ça devrait être i%+1).
Et je me demande bien comment ta formule ci-dessus a pu fonctionner chez toi sans boucler...

2) Ca ne marche (?) que sur des images simples, puisque tu t'arrêtes à la première séquence trouvée, or il faudrait que tu continues la recherche jusqu'à la fin et noter la dernière séquence trouvée.
Si ton image en contient plusieurs (cas des images d'apn qui contiennent en général au moins une imagette pour accélérer la prévisualisation), tu trouves les dimensions de l'imagette. Mais c'est vrai que toi ce qui t'intéresse ce sont seulement les proportions, et non les dimensions véritables.

3) J'ai fait des tests en boucle sur un certain nombre d'images:
a) solution 'picture' (voir plus haut): 0,5 s par image
b) solution 'irfanview': 0,35 s par image
c) ta solution ci-dessus corrigée pour le filebin_position, mais donnant les dimensions de l'imagette: 1,4 s par image

Y'a pas photo.
Si je puis dire.

Pour le filebin_position, je me suis posé la question,
s'il fallait que je mette i% ou i%+1
et comme ça marche avec i%, je me suis dis que ça devait être bon.

Pour ce qui est de ton calcul de temps, je ne suis pas du tout d'accord.
Avec l'album-photos, quand j'utilisais Irfan-View, c'était très long
avec la transformation des jpg en bmp, j'avais remarqué que c'était un petit peu plus long,
et avec ma nouvelle méthode, c'est au moins quatre ou cinq fois plus rapide que la première méthode.
Donc, c'est bien un plus !

et si, y'a photo, y'en a même pas loin de 200 !

Mais je vais me pencher sur ce filebin_position...

J'ai vérifié, c'est bien i% et pas i%+1.
pour : for i%=1 to filebin_size(1)
avant la première lecture, filebin_pos(1) est à 0
et après, il est à 1,
donc mettre filebin_position 1,i% pour rétablir la position, est bon.
et la « solution miracle » est opérationnelle !

J'ai repris ton code ci-dessus et je dois bien me rendre à l'évidence, ça fonctionne pour ce que tu veux en faire, c'est à dire trouver la proportion w/h.
Et c'est rapide parce que les caractéristiques de la première imagette ne sont pas très loin du début du fichier.
Je cherche toujours une solution pour trouver les dimensions réelles (en Panoramic), mais pour l'instant je sèche un peu.

J'ai chronométré :
si je prends un répertoire qui contient des images jpg simples,
fabriquées avec un captureur d'écran que j'ai programmé en langage panoramic,
(je vais bientôt le publier sur ce site)
cela prend exactement 3 secondes (pour traiter les 200 photos)
ce qui fait 1/66 de seconde par photo

Si je prends des images que j'ai téléchargées sur Internet,
alors je ne sais pas comment elles sont faites,
elles sont peut-être trafiquées, avec des imagettes, des titres, des textes codés...
cela prend environ 20 secondes (à +/- 2,5 secondes près) (toujours pour 200 photos)
ce qui fait environ 1/10 de secondes par photo.
C'est moins bien, mais ça reste correct.

Nos textes se sont croisés.

Pour ce qui est de ton problème de dimensions réelles,
je ne vois pas bien de solution (rapide).
Puisque tu ne sais pas combien de fois la séquence (FF-C0...) peut être répétée,
alors il faudrait connaître la distance maximum entre 2 séquences pour pouvoir s'arrêter sans avoir à faire tout le fichier.

Et il y a des inscriptions qui sont loin du début
(je crois que c'est ça qui immobilise quelquefois ma progress_bar pendant plusieurs secondes, et non une erreur du programme).

Moi je ne te parle que d'images d'appareil photo numérique (il me semble que c'est le plus fréquent pour un album personnel), en ce qui me concerne des images de 2560 x 1920 pixels, d'environ 1,5 M. C'est à dire des images assez complexes.
Mais je reconnais que la rapidité d'exécution de ton code me surprend, j'ai toujours trouvé que les accès fichier octet par octet de Panoramic étaient d'une lenteur insupportable.

Je viens d'essayer une astuce (?) qui ne marche pas:

Code:

Filebin_Open_Read 1, f$: sz = Filebin_Size(1): Filebin_Close 1
File_Open_Read 1, f$: File_Readbuf 1, a$, sz: File_Close 1

En comptant faire les recherches dans la variable a$ avec des Instr.

Hélas ! Patatras ! dès que la lecture trouve un caractère 26 (hexa 1A), elle remplit tout le reste de a$ (1.352.782 octets, taille du fichier) avec ce caractère... ce qui n'est pas sympa du tout de la part de Panoramic.

On s'est encore croisés... non, je ne crois pas qu'il y ait de solution simple, et qu'il faut parcourir tout le fichier et prendre en compte la dernière occurence trouvée.

Là je suis en train d'étudier des infos supplémentaires sur le format jpg...

Pour faire dans la rapidité, il ne faut surtout pas utiliser de variables alphanumériques (f$...),
elles bouffent beaucoup de temps,
il faut prendre exclusivement des variables numériques,
et de préférence des variables entières (f%).
Ca doit être ça, qui t'étonne dans mon code.

Je pense à un truc, c'est purement théorique, mais ça reste à voir.
Il doit y avoir un code pour désigner la fin de tout ce qui se met en entête,
et un autre pour désigner le début de l'image (équivalent de <body>),
il faudrait repérer l'un ou l'autre pour savoir où s'arrêter de chercher.
Il serait même possible de commencer par ce code et de chercher à reculons. A voir.