11-08-20, 20:21
(Modification du message : 11-08-20, 20:23 par nicoauffray.)
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.
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.