Aide, lenteur et utilisation intensive processeur par LR

Démarré par youli, Juillet 12, 2016, 22:34:18

« précédent - suivant »
Imprimer
En bas Pages1 2 3 4 Toutes
Actions de l'utilisateur

youli

Juillet 12, 2016, 22:34:18
Bonsoir,

depuis deux jours sans changement particulier sur mon pc, LR rame et fait "bosser " mes processeurs anormalement :

- Pour de simples changements de photos dans la bibliothèque il fait monter les processeurs et la ram de façon inhabituel et quand je développe il y a des pics jusqu'à 90/100% !! je précise que çà ne montait jamais comme çà avant pour ceux qui me diraient que c'est normal.. et plus je traite, plus une inertie s'installe au point de le rendre lent comme jamais (même sur des simples zooms/dézooms) et je le ferme ,et mon processeur retombe à 2 à 3% et la ram 12% , normal.

J'ai optimisé évidement le catalogue avec la possibilité qui va bien, et même supprimé l'historique des toutes mes photos, et rien n'y fait! A ne rien comprendre! dois je créer un nouveau catalogue ?
je précise que c'est un catalogue à environ 1500 photos, donc rien d' extraordinaire... Que faire ? je me souviens qu'une personne avait eu le cas il y a un an sur le forum et avait trouvé une solution dans les arcanes du dossier d'installation, bref je n'ai pas retrouvé le post..

Merci de votre aide

carte nvidia geforce GTX 650 Ti

OuiOuiPhoto

#1
Juillet 13, 2016, 07:58:51
THG a parlé de fuite de mémoire récemment dans la dernière version. Pour le processeur a 100% ca m'arrive aussi en developement

youli

#2
Juillet 13, 2016, 08:08:53
c'est peut être une piste alors, car je possède la dernière version ; je vais essayer de retrouver son message. Après je peux revenir à l'ancienne version, mais c'est fâcheux :'( tout de même

Bélisaire

#3
Juillet 13, 2016, 08:58:52
J'ai la dernière version de Lightroom (non CC), et je peux dire que le processeur de mon I5 (+16Go) est fortement sollicité, très souvent à 100%, sans que forcément il y ait des opérations visibles. J'ajoute que ce genre de désagrément ne date pas de la dernière version de Lightroom. J'ai déjà évoqué ce problème, ici même, en faisant allusion à des opérations "souterraines", mais lesquelles? Et dans ces moments-là, il faut avoir les nerfs solides, et une patience de sage. C'est drôle, parce qu'en ce moment, je cherche justement  à changer de PC, en misant beaucoup sur le processeur. J'espère que ton I7 n'est pas de la sixième génération, parce qu'alors, ça craint...  ;)

Bélisaire

#6
Juillet 13, 2016, 10:36:55
Merci pour l'information, je n'étais pas au courant. J'ai suivi les instructions, je vais voir ce que cela donne.

youli

#7
Juillet 13, 2016, 11:13:11
super pour l'info THG, je vais essayer aussi, je ferai un retour

MERCI

youli

#8
Juillet 13, 2016, 11:23:24
j'ai suivi la procédure, par contre une fois décoché "sotcker les paramêtres ", on le laisse définitivement décoché ?

THG

#9
Juillet 13, 2016, 11:28:37
Citation de: youli le Juillet 13, 2016, 11:23:24
j'ai suivi la procédure, par contre une fois décoché "sotcker les paramêtres ", on le laisse définitivement décoché ?

oui, et de toute façon, je pense que c'est mieux, sinon la liste des éditeurs externes disparaît, dans le menu Modifier dans...

THG

#10
Juillet 13, 2016, 11:31:12
pour ceux qui ne le savent pas, le fichier "config.lua" est une sorte de hack qui permet de modifier le comportement de Lightroom.

on peut y coller des instructions diverses. ainsi, j'ai pu récupérer l'accélération GPU de ma carte vidéo blacklistée, mais à mes risques et périls (me demandez pas, je ne peux pas partager).

JamesBond

#11
Juillet 13, 2016, 11:35:26
Capter la lumière infinie

youli

#12
Juillet 13, 2016, 11:35:54 Dernière édition: Juillet 13, 2016, 11:41:34 par youli
 Alors je viens de faire deux développements habituels, lecture bibliothèque, un peu de pinceau et de filtre radial.. Pour moi, effectivement la mémoire vive se "porte" mieux. Là ou je montais à 40% de RAM, je suis revenu à 20/25 % de moyenne. Par contre , pour le processeur ( mais j'ai bien lu que c'était pour de la fuite de mémoire)  toujours des pics, mais j'avoue moins forts, je ne cotoie plus les montées à 80/100%. Mais je le trouve de suite, moins lent. (pour le moment ;)

Alors c'est mon test ponctuel, à voir par la suite

en tous cas merci pour l'info ;)

THG

#13
Juillet 13, 2016, 11:51:22
Citation de: JamesBond le Juillet 13, 2016, 11:35:26
Bonjour Gilles,
Est-ce que ceci est également recommandé / utile pour LR 5.7.1 ?

No Sir, only CC 2015.6 and 6.6 ;-)

THG

#14
Juillet 13, 2016, 11:53:09
Citation de: youli le Juillet 13, 2016, 11:35:54
Alors je viens de faire deux développements habituels, lecture bibliothèque, un peu de pinceau et de filtre radial.. Pour moi, effectivement la mémoire vive se "porte" mieux. Là ou je montais à 40% de RAM, je suis revenu à 20/25 % de moyenne. Par contre , pour le processeur ( mais j'ai bien lu que c'était pour de la fuite de mémoire)  toujours des pics, mais j'avoue moins forts, je ne cotoie plus les montées à 80/100%. Mais je le trouve de suite, moins lent. (pour le moment ;)

Alors c'est mon test ponctuel, à voir par la suite

en tous cas merci pour l'info ;)

Ne pas oublier de transmettre les log files !

Concernant les pics du CPU, c'est même plutôt normal :-)

THG

#15
Juillet 13, 2016, 22:31:26
Bon, la cause du problème a été clairement identifiée. J'espère un correctif assez rapidement ;-)

livre

#16
Juillet 14, 2016, 11:35:33
THG, bonjour je viens très rarement sur ce fil, j'ai fait un livre photos sur Lightroom et comment le transférer sur CD ou DVD, merci d'avance. ;)
J'ai lu le livre Lightroom par la pratique mais il n'y a aucune information sur la manip mentionnée plus haut.

jesus

#17
Juillet 14, 2016, 15:32:07
Il faut que tu choisisse PDF ou JPG en haut à droite et exporter en bas à droite ...

THG

#18
Juillet 14, 2016, 16:30:52
Citation de: livre le Juillet 14, 2016, 11:35:33
THG, bonjour je viens très rarement sur ce fil, j'ai fait un livre photos sur Lightroom et comment le transférer sur CD ou DVD, merci d'avance. ;)
J'ai lu le livre Lightroom par la pratique mais il n'y a aucune information sur la manip mentionnée plus haut.

Parce que j'ai aussi co-écrit un bouquin sur le module Livres, dans la même série ;-)

Transfert CD/DVD ? Il y a plus moderne, non ?

livre

#19
Juillet 15, 2016, 19:53:42
Citation de: jesus le Juillet 14, 2016, 15:32:07
Il faut que tu choisisse PDF ou JPG en haut à droite et exporter en bas à droite ...

Merci jesus, J'ai pu mettre une sauvegarde sur disque dur. ;)
J'ai une autre problème quand je veux faire un tirage par blurb sur quatre photos j'ai cette mise en garde : certaines photos du livre présentent des zones transparentes, ces zones transparentes s'afficheront de façon opaque dans votre livre.
Que faut-il faire ?

JamesBond

#20
Juillet 15, 2016, 21:05:56
Livre, c'est ici un fil qui parle de la lenteur de LR6.6 ; si vous avez des questions précises à poser sur d'autres sujets, je vous invite à ouvrir un autre fil.
Je ne dis pas cela pour le plaisir de faire la police, mais dans le but de faciliter la recherche pour des personnes qui auraient les mêmes problèmes que vous ; enfouir des sujets divers dans un même fil, c'est enterrer les réponses.
Capter la lumière infinie

Nävis

#21
Juillet 16, 2016, 18:28:47
Citation de: JamesBond le Juillet 15, 2016, 21:05:56
Livre, c'est ici un fil qui parle de la lenteur de LR6.6 ; si vous avez des questions précises à poser sur d'autres sujets, je vous invite à ouvrir un autre fil.
Je ne dis pas cela pour le plaisir de faire la police, mais dans le but de faciliter la recherche pour des personnes qui auraient les mêmes problèmes que vous ; enfouir des sujets divers dans un même fil, c'est enterrer les réponses.
+1

Samoreen

#22
Juillet 16, 2016, 19:51:43
On dirait que cette mise à jour a été retirée.
Patrick

Samoreen

#23
Juillet 16, 2016, 20:24:52
Citation de: Samoreen le Juillet 16, 2016, 19:51:43
On dirait que cette mise à jour a été retirée.

N'importe quoi, un moment de faiblesse passagère...  :P
Patrick

Samoreen

#24
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...
Patrick

Samoreen

#25
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.

Patrick

THG

#26
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

#27
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.
Patrick

Samoreen

#28
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).
Patrick

Samoreen

#29
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.
Patrick

THG

#30
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

#31
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

#32
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

#33
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

#34
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

#35
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

#36
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 ;D . 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).
Patrick

THG

#37
Juillet 18, 2016, 12:44:03 Dernière édition: Juillet 18, 2016, 12:52:18 par THG
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

#38
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.
Patrick

babelkot

#39
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...
Nikon D500

Bélisaire

#40
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

#41
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...
Patrick

Samoreen

#42
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...
Patrick

Bélisaire

#43
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

#44
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...
Patrick

Samoreen

#45
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.
Patrick

Christophe Mely

#46
Juillet 19, 2016, 15:37:24
Merci pour ton analyse et tes recommandations, Samoreen  :)

Miaz3

#47
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

#48
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.
Patrick

THG

#49
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.

THG

#50
Juillet 20, 2016, 09:32:30
On verra si le correctif intervient aussi au niveau du pinceau et du mode plein-écran, mais je reste sceptique vu que le fichier config.lua ne semble pas améliorer les choses sur ce point précis.

Bélisaire

#51
Juillet 20, 2016, 15:26:00
Citation de: THG le 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.

Difficile de ne pas s'en rendre compte...  ;)

babelkot

#52
Juillet 21, 2016, 02:40:30
Bonsoir,
ben voilà,j'ai créé un nouveau catalogue dans LR 6.6, ne contenant que les NEF de mon Nikon D500..environs 2500.Tout est d'une fluidité a n'y rien comprendre.
L'importation se fait rapidement.L'outil suppression des défauts et le pinceau même avec une taille de 50(sans intérêt,mais juste pour tester)glissent et répondent sans à-coups.Je n'ai corrigé aucun réglage et depuis 2 jours c'est le bonheur.J'espère qu'en gonflant mon catalogue ne va pas me remettre le moral à zéro.Les spécialistes pourront sans doute me répondre... :)
Nikon D500

Chauvin

#53
Juillet 21, 2016, 12:23:32
Bonjour à tous ,
cela ne va sans doute pas apporter de réponse à ceux qui ont des problèmes avec la dernière maj , mais personnellement je ne rencontre aucun soucis...
je précise que j'utilise LR quotidiennement en traitant des centaines de photos par semaine.
j'utilise 2 catalogues , un pour les traitements en cours et un autre 'consolidé' pour les recherches éventuelles (les 2 sur ssd externe).
pour info la config de mon PC qui me donne satisfaction de puis 4 ans déjà.
Bonne journée à tous.

Version de Lightroom : CC 2015.6 [ 1078672 ]
Licence: Creative Cloud
Système d'exploitation : Windows 10
Version : 10.0
Architecture de l'application : x64
Architecture du système : x64
Nombre de processeurs logiques: 4
Vitesse du processeur : 3,3 Ghz
Mémoire intégrée : 16359,0 Mo
Mémoire réelle disponible pour Lightroom : 16359,0 Mo
Mémoire réelle utilisée par Lightroom : 916,8 Mo (5,6%)
Mémoire virtuelle utilisée par Lightroom : 881,2 Mo
Taille de la mémoire cache : 698,8 Mo
Nombre maximal de liens utilisé par Camera Raw  : 4
Optimisation SIMD de Camera Raw : SSE2,AVX
Paramètre PPP du système : 96 PPP
Composition sur le Bureau activée: Oui
Affichages : 1) 1920x1080
Types d'entrée: Tactile multipoint : Non, Tactile intégré : Non, Plume intégrée : Non, Tactile externe : Non, Plume externe : Non, Clavier : Non

Informations relatives au processeur graphique :
AMD Radeon HD 6800 Series

daniel 14

#54
Juillet 25, 2016, 19:16:05
Bonjour à tous
Depuis environ 1 mois je rencontre des lenteurs en mode développement
je me demande si ce n'est pas depuis la dernière mise à jour 6.6 ?
Les symptôme sont les suivants: à l'ouverture de la première image tout va bien, je peu zoomer et dezoomer et c'est tres rapide. après 5 ou 6 images il y a un ralentissement très net et les réglages demandent plusieurs secondes avant d'être pris en compte.
Ma configuration est la suivante: iMac Mi2011 avec core I5 a 2,7 GH - 12 Go de RAM - système et stockage sur SSD 480 Go (libre 270 Go )- carte graphique AMD Radeon HD 6770M 512 Mo - et je suis sous El Capitan 10.11.5
mais durant ce temps j'ai vérifié les paramètres de configuration ligtroom sur un MBP que j'utilise également (début 2011-i5 2 cores à 2,3 GHz- 16 Go de ram-même OS et même version de ligtroom - DD de 320 Go avec 140 Go de libre) ,et qui n'as pas de ralentissement. la seule différence que j'ai trouvé dans les paramètres de lightroom concerne la gestion des fichiers et notamment les paramètres de la mémoire cache vidéo. Sur le MBP la case est cochée et la taille maximale est à 3 Go. J'ai fait le même parametrage sur l'i-Mac et le résultat était meilleur. Puis j'ai augmenté progressivement la taille du cache jusque 20 Go. j'ai retrouvé avec ces paramètres une fluidité que je pense identique a celle d'il y a un mois.
Pensez vous que ces réglages puissent être améliorés et que ces réglages soient bon ?

THG

#55
Juillet 26, 2016, 09:26:30
Comme je l'ai dit il y a quelques posts, le doigt a été mis sur la source du ralentissement du module Développement, et un correctif sera très bientôt disponible. Il corrigera également les problèmes de concordance des couleurs à l'impression sur Mac.

Samoreen

#56
Juillet 27, 2016, 18:47:43
Citation de: THG le Juillet 20, 2016, 09:32:30
On verra si le correctif intervient aussi au niveau du pinceau et du mode plein-écran, mais je reste sceptique vu que le fichier config.lua ne semble pas améliorer les choses sur ce point précis.

[Copié depuis un autre fil où j'étais hors sujet]

Après la 2015.6.1, donc...

Eh bien, c'est assez confus...

1. Globalement, le pinceau fonctionne mieux et de manière plus fluide avec cette mise à jour...

2. ... sauf sur une image où le masquage est particulièrement lourd. Là, j'ai exactement les mêmes problèmes qu'avant la 2015.6.1 .

3. mais je viens de me rendre compte de quelque chose qui pour moi est nouveau (probablement pas pour la 2015.6.1 mais pour la 2015.6 - détrompez moi éventuellement). J'utilise Lightroom Mobile et je garde toujours la synchro active (pas en mode pause). Ça ne m'a jamais gêné car j'avais compris que la synchro se suspendait automatiquement quand l'utilisateur était actif. Je viens de constater que maintenant, la synchro continue même si je suis en train de travailler sur une image. Je pars d'une situation où tout est à jour et donc la synchro inactive. Je passe sur mon image au masque un peu sévère, je commence à faire des modifs et que vois-je en haut à gauche ? La notification de synchro en cours sur 1 fichier (celui que je traite). Évidemment, vu que LR est déjà en train de patiner sur mon masque, ça n'arrange pas du tout les choses.  Si je redémarre l'édition en prenant soin de mettre la synchro mobile en pause, ça se passe beaucoup, beaucoup mieux.

Voilà. Donc, je ne sais pas conclure. Trop de paramètres qui bougent en même temps. Pour moi, ce problème avec la synchro est nouveau. Je n'y avais pas porté attention jusque là mais en tous cas, ça ne m'a jamais gêné de l'avoir ON en permanence même si bien sûr, c'est plus logique de la mettre en pause quand on travaille sur un lot d'images synchronisées - ce que je ferai donc maintenant systématiquement).
Patrick

Samoreen

#57
Juillet 27, 2016, 23:11:47
Citation de: Samoreen le Juillet 27, 2016, 18:47:43
Je passe sur mon image au masque un peu sévère, je commence à faire des modifs et que vois-je en haut à gauche ? La notification de synchro en cours sur 1 fichier (celui que je traite). Évidemment, vu que LR est déjà en train de patiner sur mon masque, ça n'arrange pas du tout les choses.  Si je redémarre l'édition en prenant soin de mettre la synchro mobile en pause, ça se passe beaucoup, beaucoup mieux.

Je dois toutefois reconnaître que l'impact de la synchro sur la CPU n'est pas énorme. Ça ne justifie pas en soi une activité à 99%. Plus ça va, moins je comprends. Il faudrait que je passe à la vitesse supérieure en termes de débogage mais sans le code source, c'est en assembleur. Beaucoup trop chronophage.
Patrick

jb57

#58
Août 19, 2016, 10:17:36
Bonjour,

Je viens de tomber sur un article concernant l'activation du GPU dans Lightroom et les settings.

Donc, comme beaucoup, j'ai mon GPU actif dans Lightroom, et je trouve qu'il n'y a pas une formidable fluidité!!

Attention: Pour les cartes NVIDIA, il faut aller dans le panneau configuration de la carte (driver). Gérer les paramètres 3D, sélectionner dans la liste déroulante le programme Lightroom, et enfin, activer "vsync et triple buffer".

La différence est notoire.

A bientôt

OuiOuiPhoto

#59
Août 19, 2016, 11:41:48
Citation de: jb57 le Août 19, 2016, 10:17:36
Donc, comme beaucoup, j'ai mon GPU actif dans Lightroom, et je trouve qu'il n'y a pas une formidable fluidité!!

Moi c'est moins fluide avec. Donc je l'ai désactivé

jb57

#60
Août 19, 2016, 12:03:00
Ouioui

Essayez la manip que j'ai signalé

Comtois91

#61
Août 19, 2016, 12:58:51
Citation de: jb57 le Août 19, 2016, 12:03:00
Ouioui
Essayez la manip que j'ai signalé

Je viens d'essayer avec une carte nvidia gtx970 et ça n'a rien donné. C'est toujours plus fluide avec la carte désactivée.
Comtois91

jb57

#62
Août 19, 2016, 13:49:53
Moi j'ai une gtx580.

La fluidité est manifeste lorsque l'on utilise le pinceau, le dégradé radiale ou circulaire, et pour le ré-affichage de l'image corrigée.

Encore une fois, il faut mettre "vsync sur activé et triple buffer sur on"

Samoreen

#63
Août 19, 2016, 13:52:23
Citation de: Comtois91 le Août 19, 2016, 12:58:51
Je viens d'essayer avec une carte nvidia gtx970 et ça n'a rien donné. C'est toujours plus fluide avec la carte désactivée.

Idem. Je ne vois pas très bien en quoi un réglage relatif au 3D qui optimise l'affichage des frames en vidéo ou dans les jeux peut améliorer l'affichage 2D dans un logiciel photo. Il suffit de lire les commentaires affichés pour chaque réglage pour voir que ça ne concerne en rien la photo. Mais bon, je ne demande qu'à être convaincu. On pourrait avoir un lien sur l'article mentionné plus haut ?
Patrick

OuiOuiPhoto

#64
Août 19, 2016, 13:53:08
Citation de: jb57 le Août 19, 2016, 12:03:00
Essayez la manip que j'ai signalé

pas possible. Je suis en AMD ;)

Samoreen

#66
Août 19, 2016, 14:08:03
Citation de: jb57 le Août 19, 2016, 13:58:28
Et voilà le lien : https://www.reddit.com/r/photography/comments/3vlon4/i_found_a_lightroom_graphics_card_fix/

Merci. Mais je ne comprends toujours pas comment le buffering des frames peut interférer dans l'affichage de Lightroom vu qu'il n'y a aucune animation et donc ni de frames, ni de besoin de les synchroniser avec la fréquence de rafraîchissement de l'écran. En tous cas, aucun effet sur ma Quadro K620.
Patrick

OuiOuiPhoto

#67
Août 19, 2016, 14:14:34
Alors j'ai trouvé ou ca se règle sur AMD. Ca ne change rien. La brosse suppression des défaut est pas fluide avec l'acceleration

jb57

#68
Août 19, 2016, 14:16:43
moi j'ai fait l'essai, et cela est bien mieux chez moi.

J'ai un core i7 2600k 8 gb de ram et une carte mère Asus, rien de bien spécial.

Voyons si pour d'autres intervenants cela change?

THG

#69
Août 20, 2016, 11:59:52
Le problème du GPU, c'est toujours un "trade-off". Il y a toujours un "dialogue" CPU-GPU qui impacte les performances, notamment si la config n'est pas "musclée". Et, donc, si la fluidité n'est pas bonne, mieux vaut la désactiver.

D'autre part, cette accélération GPU a été introduite surtout pour les utilisateurs d'écrans 4K et 5K. Pour les autres, la différence est minime.

Sur mon vieil iMac, j'en tire profit, mais il a fallu que j'installe un "hack" pour retrouver l'accélération GPU qui m'a été enlevée à la version 6.4, ma carte graphique rentrant dans la longue série blacklistée en ce qui concerne les Mac.

Les utilisateurs de PC sont plus chanceux car ils peuvent mettre à jour les pilotes, et même les installer en bêta ou carrément changer de carte, ce qui n'est pas possible chez la pomme.

jb57

#70
Août 20, 2016, 14:15:23
Oui c'est possible que ma machine soit très bien optimisée cpu-gpu. Regardez cette video!! http://www.nvidia.com/object/adobe-lightroom-cc.html

Cordialement

OuiOuiPhoto

#71
Août 20, 2016, 15:27:02
Citation de: jb57 le Août 20, 2016, 14:15:23
Oui c'est possible que ma machine soit très bien optimisée cpu-gpu. Regardez cette video!! http://www.nvidia.com/object/adobe-lightroom-cc.html

sur la partie CPU je ne sais pas ce qu'ils on mis comme config mais c'est pas du très puissant. Perso avec l'accélération graphique en route je déplace aussi plus rapidement le filtre dégradé ou radial mais c'est sur la suppression des défaut que la ca rame

Samoreen

#72
Août 20, 2016, 15:42:46
Citation de: OuiOuiPhoto le Août 20, 2016, 15:27:02
Perso avec l'accélération graphique en route je déplace aussi plus rapidement le filtre dégradé ou radial mais c'est sur la suppression des défaut que la ca rame

Idem. Et c'est logique, sinon normal. Le filtre dégradé ou radial se décrit de manière extrêmement concise et il y a très peu de données à interpréter et à stocker. Pour les autres corrections, et notamment le pinceau, c'est beaucoup plus lourd et complexe. Voir ce message.

Je reste toujours très dubitatif sur le choix de la méthode d'enregistrement et de stockage de la description du masque. C'est incroyablement grossier, algorithmiquement parlant, voire primitif. Mathématiquement, décrire une surface en stockant l'ensemble de ses points est quand même assez absurde alors qu'il suffit de décrire le contour. Vu qu'Adobe maîtrise déjà le vectoriel, voire les fractales dans d'autres logiciels, on peut se demander si les développeurs de LR et de PS déjeunent à la même cantine. Parfois, je me demande s'ils habitent le même pays.

Je vais me répéter mais il y a des gens qui ont pensé la même problématique de manière beaucoup plus fine et subtile: dans C1 ou mieux, dans LightZone (malheureusement moribond). Je ne comprends pas pourquoi les concepteurs de LR ne se décident pas à revoir ça.
Patrick

OuiOuiPhoto

#73
Août 20, 2016, 16:19:49
Citation de: Samoreen le Août 20, 2016, 15:42:46
Idem. Et c'est logique, sinon normal.

Une fonction qui doit permettre d'aller plus vite doit permettre d'aller plus vite tout le temps. Donc pour moi ce n'est pas normal. Les contraintes techniques sont la pour être levées. Donc pour moi l'accélération graphique est juste pas assez aboutie dans LR. C'est comme la fonction Panorama. Ca va dans le bon sens mais c'est encore perfectible

Christophe Mely

#74
Août 20, 2016, 16:37:56
Citation de: Samoreen le Août 20, 2016, 15:42:46
[...] Je ne comprends pas pourquoi les concepteurs de LR ne se décident pas à revoir ça.

...je pense que c'est parce qu'il n'y en a plus...ils les ont tous virés depuis la version 5, ils n'ont gardés que les actionnaires  ;D

Samoreen

#75
Août 20, 2016, 17:18:30
Citation de: OuiOuiPhoto le Août 20, 2016, 16:19:49
Une fonction qui doit permettre d'aller plus vite doit permettre d'aller plus vite tout le temps. Donc pour moi ce n'est pas normal. Les contraintes techniques sont la pour être levées.

Ce n'est pas tout à fait exact. Si on a un trajet de 10 000 km à faire, on aura beau accélérer, ça prendra quand même un temps non négligeable, même en Ferrari. Pour 500 km, je peux envisager de prendre la voiture mais pour 10 000, je prends l'avion.

Entre les 2 filtres et le masquage par le pinceau, il y a plusieurs ordres de grandeur d'écart dans la quantité de données à traiter. Ça n'a rien à voir. Ce n'est pas une accélération graphique qui va régler ça. Je crois que l'erreur est d'avoir considéré que cela pouvait être traité par le même type d'algorithme (probablement parce qu'ils considéraient à l'époque que l'usage du pinceau serait anecdotique). C'est la manière de faire qui ne convient pas :

- si je donne 10 coups de pinceau qui passent par le même point, ce point sera stocké 10 fois et réinterprété 10 fois. Ça paraît incroyable mais c'est comme ça que ça fonctionne aujourd'hui.

- la puissance d'un processeur ne doit pas être utilisée à compenser la faiblesse de l'algorithmique. De nos jours, c'est un vœu pieux mais quand on prétend faire du high-tech et qu'on aborde des sujets où la performance est critique, il faut revenir aux fondamentaux : apprendre à coder efficacement (et accessoirement utiliser des langages de programmation qui produisent nativement un code plus rapide - l'utilisation massive de LUA dans LR m'a toujours sidéré).

Même si on utilise une machine puissante et une super carte graphique, ça ne modifiera les performances que de manière marginale.
Patrick

OuiOuiPhoto

#76
Août 20, 2016, 17:51:40
Citation de: Samoreen le Août 20, 2016, 17:18:30
Ce n'est pas tout à fait exact.

Si tu le dis. Une fonction qui doit améliorer les performances ne doit pas les dégrader. Et la pour le cas du pinceau de retouche locale ca dégrade. Donc ce n'est pas au point.

Samoreen

#77
Août 20, 2016, 18:11:41
Citation de: OuiOuiPhoto le Août 20, 2016, 17:51:40
Si tu le dis. Une fonction qui doit améliorer les performances ne doit pas les dégrader. Et la pour le cas du pinceau de retouche locale ca dégrade. Donc ce n'est pas au point.

Je ne dois pas être assez clair. Je ne discute pas du fait que l'utilisation de l'accélération dans LR soit au point ou pas, je dis que même si c'était au point, ça ne changerait pas grand-chose pour l'utilisation du pinceau (que ce soit en bien ou en mal) parce qu'il y a un problème bien plus important à traiter dans ce cas particulier : la manière dont le pinceau est géré.

Pour reprendre la comparaison avec les transports : même si je fonce à 300 kmh pour faire mes 10 000 km, je ne vais pas fondamentalement changer le résultat parce qu'à la base, le bon choix n'est pas l'automobile mais l'avion.
Patrick

OuiOuiPhoto

#78
Août 20, 2016, 18:14:25
Citation de: Samoreen le Août 20, 2016, 18:11:41parce qu'il y a un problème bien plus important à traiter dans ce cas particulier : la manière dont le pinceau est géré.

Pour moi ce n'est pas un problème lorsque je désactive l'accélération. Donc vu de me fenêtre il est juste mal géré avec l'accélération.
Imprimer
En haut Pages1 2 3 4 Toutes
Actions de l'utilisateur