Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
[résolu] latence affichage aperçu
#1
Bonjour à tous
je viens de charger la version 3.2.1; Premiers essais chambre noire montrent une meilleure réactivité en général; les fonctions d'affichage sur les miniatures dans la TL tres bien
Une seule difficulté: l'affichage des aperçus en TL avec les raccourcis "W" ou "Alt+W" met 2 à 3 sec pour des Jpeg et des raw petit capteur, une dizaine de sec pour des raw plein format, pendant lesquelles la zone d'affichage est grise. En 3.02 c'était pratiquement instantané.

Une fois que j'ai affiché l'aperçu d'une miniature, si je passe sur une autre photo (avec même temps de réponse) et que je reviens sur la précédente, l'affichage est alors instantané. Mais cela est temporaire; si je passe en chambre noire par exemple (ou que je ferme DT) et que je reviens en TL, j'ai toujours le même  temps de réponse sur l'affichage des aperçus, y compris ceux qui avaient été ouverts précédemment.
J'ai fait des essai en mode "navigateur de fichiers"  ou "TL zoomable" c'est pareil;
pour l'instant je contourne la difficulté en affichant 1 seule miniature en mode "navigateur de fichier".

J'ai cherché sans succès dans les préférences de la TL. Quelqu'un aurait-il constaté la même chose ?

J'en profite pour remercier les développeurs pour ces superbes évolutions de DT



systeme Windows 10

[résolu]
Richard
Windows 10
Répondre
#2
Bonsoir,

C'est plutôt le fait que tu avais un affichage instantané en 3.0.2 avec la même config matériel qui m'étonne, plutôt que l'inverse.

J'ai pour ma part suivi de très près les évolutions de la table lumineuse, en assistant notamment AlicVB autant sur l'amélioration visuelle via le CSS que des bugs détectés pendant le développement de la refonte faite pour la 3.2.1. Et je n'ai vu que des améliorations de performance même sur les modes aperçu et sélection, sur lesquels j'ai passé du temps (je ne parle même du temps passé par AlicVB, ce serait indécent ;-) !). Et j'ai un ordi de plus de 6 ans, sans carte OpenCL (en bref, pas une bête de course). Par contre, le seul truc est que je suis sous Linux, tout comme AlicVB. Ca reste pas impossible que darktable sous Windows se comporte pas tout à fait pareil.

Bref, l'affichage de ces modes (c'était déjà le cas en 3.0.x) est l'affichage de l'image développée. Donc, déjà tout ce que tu décris est normal puisque darktable calcule l'image à afficher (et en gros plan, bah c'est plus long qu'en miniature). Et surtout si un module comme la réduction du bruit (profil) est activé (performant mais gourmand).

La seule manière d'améliorer un peu, est d'activer les options de cache dans l'onglet cpu/gpu/mémoire des préférences. Attention, le premier affichage (et après toute modif en chambre noire) prendra un peu de temps, le temps que l'image jpg du cache soit générée. Tu peux aussi générer un cache avant via l'outil darktable-generate-cache (voir l'article linuxfr sur la 3.0 ou le manuel à ce sujet). Attention, ce dernier outil s'utilise en ligne de commande, darktable fermé et peut être plus ou moins long selon le nombre d'images (il ne refait le cache que des images nouvelles ou nouvellement traitées.
Aussi appelé Nilvus !
Debian Sid - darktable master
Répondre
#3
bonjour
En janvier 2020, avec ton aide et aussi celle de Gegel j'avais réglé le problème en générant tous les caches avec la commande darktable-generate-cache.exe -m 6
(fil de discussion ici: https://forums.darktable.fr/showthread.php?tid=4418)

est-il possible que l'installation de la 3.2.1 ait modifié quelque chose dans l'utilisation des caches ? ou que l'emplacement des caches ait été modifié et donc que la nouvelle version ne trouve pas les caches existants que j'avais générés à l'époque ?
Richard
Windows 10
Répondre
#4
Bonjour à tous,
Darktable 3.2.1 Ubuntu 18.04 LTS, j'ai moi aussi constaté une lecture en plein écran avec la touche alt+w beaucoup plus lente que la version précédente de darktable, mais le comportement est difficile à comprendre, parfois c'est instantané, parfois je dois attendre plusieurs secondes ?
Je n'ai pas eu le temps de chercher plus loin pour l'instant.

C'était le cas hier, jour de l'installation, je viens de démarrer darktable aujourd'hui et la rapidité d'affichage est redevenue normale.
Répondre
#5
bonjour à tous
j'ai refait des essais pour mieux cerner le comportement de DT sur l'affichage plein écran des miniatures.
Je rappelle que j'ai généré il y a quelques mois tous les caches au moyen de la commande darktable-generate-cache.exe -m 6.

si je tente d'ouvrir un aperçu d'une miniature j'ai plusieurs secondes de temps de reaction (3 à 10-12 selon la taille de la photo) lors de la première commande W ou Alt+W.
Si je reviens ultérieurement sur la même photo (même après fermeture puis réouverture de DT) le temps d'affichage de l'aperçu redevient normal.

Donc DT accède bien aux caches qu'il génère au fil de l'eau,
mais pour une raison que j'ignore (là je suis dans ma zone d’incompétence) DT 3.2.1 n'a plus accès aux caches générés avant l'installation de la 3.2.1
Richard
Windows 10
Répondre
#6
Salut,

Ce qui se passe chez moi :
- sur l'ensemble de mes 109 photos sur la table lumineuse, avec alt-w la première met un certain temps (4-5 sec) à s'afficher et ensuite les autres s'affichent quasi instantanément (mais quelque fois 1/2 sec) en jouant avec les flèches droite et gauche.
Cordialement
François


EOS 1Ds, 7D Mark I/II, #M42, FujiX20

Flickr

[Image: dt4-61.jpg]










Répondre
#7
A noter tout de même que si le traitement d'une image a changé depuis la génération du cache, le cache n'est plus utilisé pour cette image puisqu'il n'est plus à jour. Donc, à l'ouverture de l'image, le cache est généré de nouveau, pouvant entraîner selon la puissance de l'ordinateur quelques secondes d'affichage. Donc, la commande que j'ai cité à faire régulièrement pour prendre en compte les changements (les nouvelles fois sont plus rapides, seules les nouvelles images modifiées/importées étant traitées).

Pour ma part, j'ai plutôt un affichage plus rapide, je mets à jour mon cache régulièrement. Après mon impression est peut-être faussée puisque j'utilise que la master et est donc les évolutions graduellement et non pas une transition comme vous d'une version officielle à une autre.

Pouvez-vous tester la différence après mise à jour du cache ?
Aussi appelé Nilvus !
Debian Sid - darktable master
Répondre
#8
bonjour à tous
j'ai refait la manip (W et Alt+W) sur des images de quelques années dont je suis sûr à 100% que je n'ai pas modifié le développement depuis que j'ai généré tous les caches de ma photothèque (janvier 2020).
Même constat:
- lorsque j'ouvre un aperçu la 1ère fois, plusieurs secondes d'attente pour avoir l'aperçu (3 pour un jpeg de moins de 2 Mo; 17 pour un raw Sony de 40 Mo)
- affichage quasi instantané lors des ouverture suivantes des mêmes images

tout se passe "comme si" il ne prend en compte que les caches générés depuis l'installation de la 3.2.1

Bon c'est un peu agaçant mais pas dramatique; si j'ai besoin de vérifier la netteté, je passe en chambre noire sinon je joue sur le nombre de miniatures de la TL pour trier mes photos.
Merci à tous
Richard
Windows 10
Répondre
#9
Relance au moins la génération du cache si tu constate que darktable ne prend en compte que le cache généré depuis la 3.2.1. Ca réglera le problème dans ce cas.
Aussi appelé Nilvus !
Debian Sid - darktable master
Répondre
#10
oui j'ai bien pensé à refaire la génération des caches de la photothèque; j'hésite pour 2 raisons:
le temps de traitement: il a fallu plus de 8 h de traitement la dernière fois
et puis surtout est ce que cette 2ème géneration de caches écrasera la précedente ? autrement dit sera-t-elle stockée au même endroit ?

Je vois que tu "mets à jour ton cache régulièrement". Est ce avec la ligne de commande darktable-generate-cache.exe -m 6 ?
peut on limiter la génération des caches (darktable-generate-cache.exe -m 6) à une partie de la photothèque: un dossier par exemple ?
ou mieux une selection dans une collection ?
merci
Richard
Windows 10
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)