Aide, lenteur et utilisation intensive processeur par LR

Samoreen · Juillet 17, 2016, 00:51:07

Citation de: Samoreen le Juillet 16, 2016, 23:22:36
Est-ce que le fichier AgNegativeCache.log est généré uniquement en cas de problème? Parce que je ne le vois pas. config.lua est bien pris en compte, je le vois dans Help | SystemInfo...

Le fichier config.lua n'empêche pas LR de se vautrer dès que j'utilise le pinceau d'une manière un peu intensive. CPU à 100%, près de 4 Go utilisés par LR, système à plat... Et toujours pas de fichier AgNegativeCache.log. Peut-être parce que Mes Documents sont sur D:\ et que l'emplacement du dossier a été codé plus ou moins en dur au lieu d'utiliser l'API adéquate.

On va encore dire que je rouspète mais franchement, ça fait au moins 10-15 ans que les débogueurs modernes indiquent de manière automatique les fuites mémoire en fin de session. Enfin, quand on utilise des outils de développement modernes. Ça ne devrait plus arriver ce genre de choses.

THG · Juillet 17, 2016, 10:10:37

Le pinceau n'a rien à voir avec les "fuites de mémoire". Le problème a été identifié, avec des configs de 32 Go et plus, Lightroom chargeait beaucoup trop d'aperçus (les images traitées précédemment) dans la RAM, finissant par impacter la réactivité.

Ça sera corrigé dans la prochaine mise à jour, très bientôt.

Samoreen · Juillet 17, 2016, 13:27:33

Citation de: THG le Juillet 17, 2016, 10:10:37
Le pinceau n'a rien à voir avec les "fuites de mémoire". Le problème a été identifié, avec des configs de 32 Go et plus...

Je peux te garantir que le problème survient avec beaucoup moins de 32 Go de mémoire (j'en ai 12) et que cela affecte le pinceau. Je n'avais aucun problème de ce type jusque là mais là, c'est massif. Après quelques minutes d'utilisation du pinceau, LR perd complètement les pédales, l'espace mémoire consommé est énorme et la CPU est bloquée à 100%. Et je ne suis pas tout seul à constater la même chose. Voir le forum de feedback, le forum Adobe et d'autres...

Bref. Attendons la mise à jour de la mise à jour. Et que personne ne me dise que ça ne pouvait pas être détecté avant la mise à disposition.

Samoreen · Juillet 17, 2016, 14:53:19

Je viens de refaire un test:

1. Je lance LR en mode bib, aucune image visible. 500 Mo occupés.

2. Je passe en mode développement d'une image assez chargée en retouches au pinceau. Ça monte immédiatement à 3,5 Go pour finir à 4,5 Go alors que je n'ai encore touché à aucun réglage. CPU à 50%.

3. Après utilisation du pinceau qui se met très vite à accuser des retards de 15 à 20 secondes, le comportement de LR devient aberrant. CPU à 100%. Inutilisable. Il faut tuer le processus.

Ce problème d'utilisation abusive de la mémoire se présente donc sur des configurations avec largement moins de mémoire que les 32 Go annoncés (ce qui est confirmé par nombre de posts sur les forums).

Samoreen · Juillet 17, 2016, 15:38:07

Citation de: Samoreen le Juillet 17, 2016, 14:53:19
Ça monte immédiatement à 3,5 Go pour finir à 4,5 Go.

Que dis-je ? 5,6 Go rien qu'en appuyant sur F pour passer en plein écran. Mais il n'arrive pas à afficher l'image plein écran au bout de 10 minutes montre en main. Bref, c'est n'importe quoi. J'ai du boulot sur Capture One en attendant que ça se réveille de l'autre côté de la flaque...

Et toujours pas de fichier AgNegativeCache.log à l'horizon.

THG · Juillet 17, 2016, 15:38:13

Le phénomène constaté affecte en général des configs avec les quantités de RAM les plus élevées, notamment 32 Go et plus. J'aurais du préciser "en général", certes, mais plus on a de RAM, et plus le phénomène s'amplifie.

Miaz3 · Juillet 17, 2016, 17:45:23

Citation2. Je passe en mode développement d'une image assez chargée en retouches au pinceau. Ça monte immédiatement à 3,5 Go pour finir à 4,5 Go alors que je n'ai encore touché à aucun réglage. CPU à 50%

Dépend comment tu appel chargé ?

En même temps de la retouche pinceau ça pompe un max, d'autant plus sur des images avec des reso de plus de 4K et encore plus si elle sont en RAW...

Question, est que les copies virtuelles de Lr font office de cacheDisk ?
Si oui, ce serais la solution pour pallier au problème. Ainsi sur de lourd traitement, il n'y aurai pas besoin de venir charger toutes les opérations.

Petit test, de mon coté :
Lr vierge, j'ai chargé un dossier de 94 photos(raw) issus d'un 50D depuis un NAS (~20Mo l'image).
L'affichage a pris 4-5mn, cpu à 12% puis après sélection de la dite photo (4752x3168 [at] 10bit).
Toujours depuis le nas, catalogue en local :
Retouche au pinceau (1:1) , c'est assez stable et aucun freeze.
Monté max du cpu 47%, moyenne de 32%.
Ram constante à ~ 6Go

Retard de pinceau lorsque je bascule dans un autre mode d'affichage (full screen 1:1).
Mais bon c'est normal, mon réseaux bloque à 50mo/s et surtout sur mon NAS j'ai des HDD de stockage.
Une fois avoir copié/collé le dossier en local sur un SSD, c'est assez fluide. Mais ça pourrait être mieux.

Ha oui, la nuance qui peut faire varié c'est l'affichage, ici c'est en 1920x1080.

coté hardware :
Nas synology : ds212j, 2x3To red
i7 4930k
32Go ram
SSD 512Go
Gtx 980.

THG · Juillet 17, 2016, 17:47:40

Citation de: Samoreen le Juillet 17, 2016, 15:38:07
Que dis-je ? 5,6 Go rien qu'en appuyant sur F pour passer en plein écran. Mais il n'arrive pas à afficher l'image plein écran au bout de 10 minutes montre en main. Bref, c'est n'importe quoi. J'ai du boulot sur Capture One en attendant que ça se réveille de l'autre côté de la flaque...

Et toujours pas de fichier AgNegativeCache.log à l'horizon.

à mon avis, ton problème d'affichage plein écran et le ralentissement à cause du pinceau ne sont pas liés au problème d'occupation de RAM et donc, le fichier de configuration ne génère pas de rapport.

THG · Juillet 18, 2016, 09:01:59

Renseignements pris, la version actuelle du fichier config.lua ne comporte plus la commande générant un log. L'origine du problème étant identifiée, seuls les commandes qui libèrent la RAM sont présentes.

Pour déclencher l'occupation excessive de RAM, il faut être dans le module Développement, et passer d'un fichier Raw à l'autre avec les flèches droite ou gauche du clavier, ce qui va provoquer la mise en cache des images originales. En principe, à 16 Go de RAM, il devrait y avoir 4 images en cache et, dès que la quantité de RAM augmente (plus de 16 Go), la quantité de fichiers mis en cache montait en flèche.

THG · Juillet 18, 2016, 09:09:10

Et pour savoir si le fichier config.lua est installé au bon endroit (à la racine du dossier des paramètres prédéfinis Lightroom), on peut voir les infos et commandes associées dans le menu Aide > Informations système.

Mais je persiste, je suis certain que les problèmes dénoncés par Samoreen n'ont rien à voir avec le bug d'occupation mémoire. Faudra voir ce qu'il se passe lorsque le correctif sera disponible (et ça donne quoi, un retour à la version précédente ?).

gilbert · Juillet 18, 2016, 10:57:17

Voilà l'occupation de la mémoire avec Windows 7 ultimate et 32 Go de mémoire.

Gilbert

Samoreen · Juillet 18, 2016, 12:16:54

Citation de: THG le Juillet 18, 2016, 09:09:10
Mais je persiste, je suis certain que les problèmes dénoncés par Samoreen n'ont rien à voir avec le bug d'occupation mémoire.

Je ne dénonce pas, je signale ou je rapporte

. Comme l'indiquent les diagrammes ci-dessus, il y a un lien entre occupation de la mémoire et ralentissement du pinceau. Je n'ai pas les mêmes chiffres que gilbert car je n'ai que 12 Go de mémoire installés. Mais il y a corrélation. Si je n'utilise pas le pinceau sur une image, ça se passe mieux même si LR est nettement plus lent que précédemment.

Et une fois de plus, comme à chaque fois qu'il y a un souci après une mise à jour (ce qui est en train de devenir une tradition, voire un rite), il ne s'agit pas de récriminations isolées de la part d'un supposé vieux teigneux : il y a un tas de gens qui ont exactement les mêmes difficultés. Je ne vois pas pourquoi à chaque fois, tu t'acharnes à nier ou à minimiser les évidences. Il y a un bug dont la portée est plus large que ce qu'annonce Adobe qui n'en est pas à une intoxication près. C'est un fait. Ça ne sert à rien de prétendre que ça n'existe pas. Au contraire, ça conforte Adobe dans leur attitude "négationniste" ou "réductionniste" habituelle.

Cette mécanique de mise en cache n'est visiblement pas encore au point et chez moi, quand l'occupation mémoire commence à dépasser les limites raisonnables, bien évidemment, ça commence à paginer de manière intensive, ce qui occupe la CPU et donc, provoque les ralentissements du pinceau. J'ai des délais de prise en compte du coup de pinceau qui peuvent atteindre les 20-25 secondes. Je n'ai jamais vu ça auparavant. Je n'avais aucun problème avant la 2015.6, mon catalogue est sain et optimisé, j'ai purgé toutes les previews et vidé le cache ACR pour être sûr. Rien n'explique ces problèmes soudains sinon un souci au niveau du code.

Je crois que d'ici peu, on va voir arriver les premières demandes de mise en place d'une option qui permettrait de désactiver ce mécanisme (que personne n'avait demandé, soit dit en passant).

THG · Juillet 18, 2016, 12:44:03

Quoi qu'il en soit, j'ai demandé aux intéressés s'ils avaient constaté une recrudescence de plaintes concernant l'occupation mémoire en utilisant le pinceau.

Moi ce que je ne comprends pas, c'est pourquoi tu persistes à faire croire que j'essaye de nier ou de minimiser les problèmes, si ce n'est pour me nuire sur ce forum, car ça n'est pas possible autrement, en regard de l'énergie considérable que je mets en œuvre pour dépanner les gens - et pour quels remerciements, et c'est bien pour ça que je ne mets quasiment plus les pieds ici, parce que c'est du dénigrement systématique. Entre ça et les cons qui en profitent pour me faire passer pour un type hautain, imbu et vendu, ce que je ne suis absolument pas, ça devient carrément insupportable (d'ailleurs, il me semble que tu es proche de Paris, en l'espace d e4 ou 5 ans, tu n'as jamais eu le courage de passer au Salon pour vérifier par toi-même quel genre de gugusse j'étais vraiment, ce qui démontre bien que tu as décidé de t'accrocher à une image négative et à la promouvoir).

Nulle part je n'ai prétendu que ça n'existait pas, j'essaye simplement de rassurer les utilisateurs face à des gens comme toi qui dramatisent tout et qui vont jusqu'à affirmer que tel ou tel problème est d'ordre général, et quand tu cites les forums US, on se rend compte, à chaque fois, que les posts - même s'ils existent, personne ne le conteste - ne sont pas aussi nombreux que tu le laisses penser.

Ceci dit, le négationniste imbu de sa personne que je suis, est quand même le seul à venir poser ici des infos de première main, ainsi que des solutions ou des pistes de travail comme cette histoire de fichier config.lua

Samoreen · Juillet 18, 2016, 13:09:10

Personne n'a jamais nié ton engagement et ta compétence. Et je n'ai jamais eu l'intention d'engager une campagne de dénigrement en ce qui te concerne. C'est une idée que tu te fais mais c'est faux. Par contre, j'ai eu à souffrir, comme beaucoup d'autres, de tes remarques peu courtoises et de ta tendance à vouloir critiquer toute personne qui n'est pas de ton avis. Ça, c'est également un fait. C'est ton caractère, tout le monde ici apprend à vivre avec en considération des services rendus. Si tu ne rendais pas ces services, les réactions seraient probablement plus hostiles.

Face à des problèmes techniques, il n'y a pas à rassurer ou à dramatiser mais à constater les faits et à les expliquer si possible. C'est ce que je fais au travers de mon expérience d'ex-ingénieur système et de développeur. Je ne conteste pas ta compétence produit et personne ne peut contester ma compétence dans le domaine du logiciel. Adobe fait montre d'une déficience certaine dans certains domaines et ce n'est pas parce que j'utilise et que j'apprécie leurs produits que je je dois m'empêcher d'émettre une opinion technique. Et à chaque fois que je le fais, tu viens contredire, c'est également un autre fait.

Voilà. Tu peux considérer si tu veux que le monde entier t'en veut mais c'est une illusion.

babelkot · Juillet 18, 2016, 20:03:05

Je suis content(façon de parler)de ne pas être le seul a constater que le pinceau est inemployable avec LR6.Je m'étais résigné a me servir de ma version LR5,lorsque je voulais m'en servir.
Le problème c'est que j'ai acheté un Nikon D500 et que mes NEF ne sont reconnus que pas la version 6...et là je me heurte a un mur.Je précise que j'ai un i7-16 Gigas de ram et 2 disques SSD...Pas top,Adobe...

Bélisaire · Juillet 19, 2016, 08:50:00

L'utilisation poussive du pinceau n'est pas un phénomène récent; en tout cas, elle ne date pas de la dernière version. Je crois me souvenir que la version 5 était affublée du même décalage, entre le coup de pinceau et son résultat (je ne dirais pas 15/20 secondes pour ce qui me concerne; c'est plutôt de l'ordre de 5 secondes). Je n'ai pas constaté pire avec la 6.6. Ce n'est pas tant l'occupation de la mémoire qui me gêne que l'utilisation toujours maximale du processeur, qui génère (ici aussi) un délai d'attente entre l'appui sur la touche et le résultat attendu, notamment "zoom" et "dézoom", quelles que soient les valeurs; passage d'une image à l'autre, etc. Cependant, si Lightroom était un être humain, je préciserais que cela dépend de son humeur: il y a des jours où tout est fluide et des jours où, tant il est lourd et lent, il vaut mieux aller à la pêche. Jamais compris pourquoi.

Lua est installé, pris en compte. AgNegativeCache.log non produit.

(Je traite des fichiers.nef issus d'un D810, entre 50 et 70 mégas pièce...).

Samoreen · Juillet 19, 2016, 09:48:09

Citation de: Bélisaire le Juillet 19, 2016, 08:50:00
Lua est installé, pris en compte. AgNegativeCache.log non produit.

La nouvelle version de config.lua ne produit plus de log, comme indiqué ci-dessus par THG.

J'ai insisté sur le problème pinceau parce que c'est pour moi nouveau (c'était très fluide avant cette mise à jour) mais il y a d'autres soucis avec la 2015.6 qui me semblent également liés à l'utilisation de la mémoire. Par exemple, l'appui sur la touche F (plein écran) pour certaines images peut prendre plusieurs minutes dans un sens comme dans l'autre, notamment pour les images qui ont été travaillées avec le pinceau. Parfois, ça fige LR. Ça s'accompagne en général d'une activité disque anormale.

Le paroxysme est atteint (CPU à genoux, grosse consommation mémoire et le plus souvent obligation de tuer le processus) quand on combine retouche pinceau, débruitage et Upright. Rien de tout ça avec la version précédente.

Il y a cependant quelque chose que je n'ai pas encore testé : traiter les mêmes images sous ACR. J'y retourne immédiatement...

Samoreen · Juillet 19, 2016, 10:34:08

Citation de: Samoreen le Juillet 19, 2016, 09:48:09
Il y a cependant quelque chose que je n'ai pas encore testé : traiter les mêmes images sous ACR. J'y retourne immédiatement...

C'est pareil. Il m'a même fallu sur une image 1mn30 pour sortir du mode pinceau en cliquant sur l'icône dans la barre d'outils ACR.

Ce n'est pas une surprise car si je ne me trompe, ACR a été mis à jour en même temps sur LR et PS. Ce qui me conforte dans l'idée que les problèmes de gestion mémoire s'étendent au-delà de la mise en tampon des aperçus dans LR.

Attendons la suite...

Bélisaire · Juillet 19, 2016, 13:38:25

Ces dernières heures j'ai usé et abusé du pinceau, du filtre radial et des autres outils... Par appui sur la touche F, il faut environ quinze secondes pour un affichage standard (2560 px - sans que celui-ci ait été préparé), et une trentaine de secondes pour un affichage à 100%, sans non plus que Lightroom ait été fermé puis rouvert.

Les temps lus plus hauts (Samoreen) me renvoient à de nombreux mois en arrière (donc avant la version 6.6), quand, connaissant la lenteur de Lightroom, je me disais malgré tout : "Ça n'est pas normal". J'ai rétabli mon PC à une date antérieure de plusieurs mois avec une image système. Et là, miracle (?), Lightroom s'est remis à fonctionner avec sa lenteur de croisière habituelle, donc forcément acceptable, quand on a connu l'immobilisation; on ne pouvait même pas dire que ça ramait puisque ça n'avançait pas...

Confronté à des temps de "plusieurs minutes", de 1 minute et 15 secondes pour sortir du pinceau, je dirais "Ça n'est pas normal".
Maintenant (face à Samoreen), je ne crois pas avoir de conseils à donner.

L'utilisation intensive de Lightroom a des effets nocifs sur le fonctionnement du PC tout entier. Par exemple, le pointeur de ma souris disparaît. Il faut attendre. Et là, il n'y a pas d'autre solution que de fermer le logiciel. Et ça, je crois bien que c'est nouveau.

Samoreen · Juillet 19, 2016, 14:55:43

Je viens de me replonger dans l'analyse des données XMP créées lors de l'utilisation du pinceau et je pense avoir trouvé une possibilité de connexion avec les problèmes mémoire. Faire un rapport technique approfondi me prendrait trop de temps mais je peux détailler quelques éléments. Allons-y...

Quelques constats

- Quand on crée un masque sous LR, celui-ci est stocké sous forme de données XML (XMP) que ce soit dans le fichier XMP ou dans le catalogue. Pas sous forme de données binaires.

- Le masque n'est pas décrit sous forme de surface mais par une collection de "coups de pinceaux" eux-mêmes constitués d'une liste de points, liste accompagnée de paramètres (rayon d'application, réglages courants du pinceau, etc.)

- Toutes les actions sont stockées, il n'y a pas de "fusion" des doublons éventuels. Si vous passez le pinceau 3 fois au même endroit, il y aura 3 descriptifs enregistrés, même s'il y a duplication de l'info. De même, les annulations (corrections avec Alt+souris) sont des actions comme les autres. Il n'y a pas élimination des coups de pinceaux qu'elles corrigent.

- Plus le rayon du pinceau est faible et plus la valeur du flux est élevée, plus le nombre d'actions (et donc de balises XML) générées est grand.

- À chaque recalcul de l'aperçu, toutes les actions sont rejouées. Avec un masque contenant des points d'ancrage associés à une surface importante, le nombre de lignes générées dans les données XML (XMP ou catalogue) peut atteindre plusieurs centaines de milliers.

Le traitement des données XML

Un peu de technique... Les données de type XML (les données XMP sont au format XML qui est un format texte) ne sont pas traitées n'importe comment par le programme utilisateur. Pour pouvoir manipuler le contenu de chaque balise, on construit une arborescence qui part d'une balise principale qui contient toutes les autres qui contiennent elles-mêmes des sous-balises, etc. (comme les dossiers d'un disque). Chaque élément de cette arborescence se voit allouer un petit morceau d'espace mémoire, paradoxalement plus grand en taille que les données qu'il contient . Quand on traite des masques importants, on en arrive vite à une occupation mémoire massive et a des accès mémoires ultra fréquents, d'où une mobilisation intense de la CPU. Si de plus la mémoire est occupée par des structures de mise en tampon et si la CPU est également occupée par les tâches relatives à cette mise en tampon, on arrive assez vite à un écroulement des performances.

Sous PS, la production d'un masque est très différente : il est représenté de manière binaire sous forme d'une bitmap. C'est peu encombrant et rapide à utiliser. Pourquoi avoir choisi pour les masques de Lightroom une représentation texte, représentation qui est par nature beaucoup plus importante en volume et beaucoup plus lente à traiter ? Probablement parce que la nature paramétrique de LR qui oblige à un recalcul permanent de l'aperçu ne peut pas utiliser une bitmap dont la forme changerait au fur et à mesure que d'autres réglages sont appliqués. Il y a cependant d'autres solutions comme celle utilisée par LightZone par exemple. En tous cas, c'est le choix d'Adobe.

Et alors ? va me dire THG. Ce n'est pas nouveau. Non, ça ne l'est pas. Le mécanisme est le même depuis la première version de LR. Par contre, si on fait évoluer (si on dégrade) le contexte mémoire et CPU pendant que ces opérations ont lieu, cela accentue le problème. À mon sens, c'est ce qui se passe dans la 2015.6. Maintenant, on ne peut être affirmatif qu'avec le code source sous les yeux.

Recommandations

En dehors des problèmes spécifiques à la 2015.6, afin de diminuer le nombre de lignes générées et donc d'accélérer le processus de reconstitution du masque à partir de ses points, on peut déduire de ce qui précède un certain nombre de recommandations :

1. Commencez le masque par des coups de pinceau aussi larges que possible et les plus longs possibles, doucement, sans reprise.
2. Ne revenez pas inutilement sur une zone déjà traitée
3. Positionnez le curseur flux à la valeur la plus basse possible admissible pour le travail en cours.
4. Utilisez un pinceau de petite taille pour les bords du masque, lentement, avec un flux minimum
5. Désactivez l'enregistrement automatique des XMP.
6. Si vous envisagez des masques de surface importante, passez de préférence sous Photoshop pour faire cette correction (pas Camera RAW qui aura bien sûr exactement le même comportement).

J'ai trouvé peu de commentaires sur les mécanismes évoqués ci-dessus mais ceux-ci suivent à peu près le même raisonnement.

Mon grain de sel...

Samoreen · Juillet 19, 2016, 15:16:43

Citation de: Bélisaire le Juillet 19, 2016, 13:38:25
Confronté à des temps de "plusieurs minutes", de 1 minute et 15 secondes pour sortir du pinceau, je dirais "Ça n'est pas normal".

Avec la touche F, je viens de faire 4mn aller et 5mn30 retour sur une image qui contient 2 masques et dont le XMP a grimpé à 100 000 lignes. Il s'agit de masques complexes qui ont nécessité beaucoup d'actions d'ajustement comme décrit plus haut.

Christophe Mely · Juillet 19, 2016, 15:37:24

Merci pour ton analyse et tes recommandations, Samoreen

Miaz3 · Juillet 19, 2016, 15:54:50

C'est le même principe avec les bezier, plus il y a de point plus c'est lourd à gérer.

Le principe reste le même dans beaucoup de logiciels pro dans l'audiovisuel (retouche pinceau image par images).
Certain fonctionnes en sidecar + diskCache, d'autre via des balises dans les en-tête de fichier de sauvegarde.

Et on se retrouve avec des tables de ce type :

Citation
{x44bc8000 x42a80000 1}
{x44bac000 x42a80000 1}
{x44b98000 x42a80000 1}
{x44b68000 x42a80000 1}
{x44b28000 x42a80000 1}
{x44ad4000 x42a80000 1}
...

Pour éviter les crash, rien de plus simple, se faire un diskCache de ses opérations.
Dans le cas de Lr, ça devient destructif, dans le sens ou il n'existe pas cette fonction. Mais ça peut-être une solution en attendant.

CàD :
Après avoir effectués quelques opérations (ici retouche pinceau), vous pensez ne pas revenir en arrière.
"Verrouiller" votre image en la sauvegardant.
Puis de l'ouvrir et continuer votre popote...

Samoreen · Juillet 19, 2016, 15:57:16

Citation de: Samoreen le Juillet 19, 2016, 14:55:43
Chaque élément de cette arborescence se voit allouer un petit morceau d'espace mémoire, paradoxalement plus grand en taille que les données qu'il contient . Quand on traite des masques importants, on en arrive vite à une occupation mémoire massive et a des accès mémoires ultra fréquents, d'où une mobilisation intense de la CPU.

J'ai oublié une précision. Les données nécessaires à la reconstitution du masque étant stockées dans cette arborescence, la récupération de ces données se fait à chaque fois en parcourant à nouveau l'arborescence. C'est un mécanisme infiniment plus lent que l'accès direct à des données binaires.

On pourrait imaginer qu'elles sont extraites une bonne fois pour toutes mais ça semble improbable. Comme chaque coup de pinceau nécessite l'insertion en temps réel dans l'arborescence de données nouvelles, il faut bien en repasser par là quand il s'agit de "relire" le masque. Je précise en temps réel car si on arrête LR juste après un coup de pinceau, il faut que le catalogue (la base de données) soit à jour. Et comme on ne stocke pas du binaire, comme précisé plus haut, mais des données XML dans un champ de la table (Adobe_imageDevelopSettings en l'occurrence), il faut bien que la structure XML soit mise à jour instantanément.

Juste pour préciser ce qui se passe quand vous terminez un coup de pinceau et que vous attendez... un moment avant de voir un résultat à l'écran.

THG · Juillet 19, 2016, 16:07:44

Et, pour info, lorsque vous zoomez dans l'image, les calculs pour afficher les corrections en temps réel ne se font évidemment que sur la partie visible de l'image. Si vous la décalez, Lr refait tous les calculs nécessaires.