blocages nombreux sous LR 3

[lolo2]

depuis que je suis passé à LR3, j'ai ce message "erreur de type indéterminé" qui revient cycliquement quand je suis dans le module développement et que je travaille 20 à 30 fichiers RAW de suite.
Mon PC est récent. caractéristiques:
Système d'exploitation : Windows XP 32 bits
Version : 5.1 Service Pack 3
Architecture système : UC Intel Famille :6, modèle :5, niveau :5 avec MMX, SSE Entier, SSE FP, SSE2, SSE3, SSE4.1, SSE4.2
Nombre de processeurs physiques : 4
Vitesse du processeur : 3066 MHz
Mémoire intégrée : 3447 Mo

Cela inspire-t-il certains d'entre vous ? Quand ce message s'affiche, il me reste qu'a fermer LR (heureusement mon travail est sauvegardé dans le catalogue) et r'ouvrir jusqu'au prochain message !!!

[olivier_aubel]

Installation d'une vieille licence XP 32bits sur un PC récent ?

Dommage de ne pas avoir pris une licence seven 64bits.

[THG]

Il faudrait voir ce qui se passe dans le Task Manager à cet instant, parce que là c'est un peu vague.

[kaf]

Ça m'arrivait régulièrement en 32 bits (avec Seven et 4 Go), plus jamais en 64 bits (toujours Seven, mais 16 Go). Dans mon cas, ça se produisait quand j'arrivais aux limites imposées par mon système. Par exemple, si j'exportais une images vers Photoshop et que le tif généré y devenait très volumineux (1-2 Go). Au retour dans LR, j'avais un souci. J'ai résolu ce problème:
- en arrêtant de faire l'andouille avec des objets dynamiques dans Photoshop
- en passant à Seven 64 bits et en augmentant la mémoire

Cela dit, il y a très certainement un leak, ou au moins une mauvaise gestion des ressources dans LR, mais je n'ai jamais vraiment investigué En effet, Un OS 32 bits et moins de 4 Go de mémoire, de nos jours, c'est vraiment très très limite (ce qui n'excuse en rien le problème, qu'on s'entende bien).

[THG]

Ça m'arrivait régulièrement en 32 bits (avec Seven et 4 Go), plus jamais en 64 bits (toujours Seven, mais 16 Go). Dans mon cas, ça se produisait quand j'arrivais aux limites imposées par mon système. Par exemple, si j'exportais une images vers Photoshop et que le tif généré y devenait très volumineux (1-2 Go). Au retour dans LR, j'avais un souci. J'ai résolu ce problème:
- en arrêtant de faire l'andouille avec des objets dynamiques dans Photoshop
- en passant à Seven 64 bits et en augmentant la mémoire

Cela dit, il y a très certainement un leak, ou au moins une mauvaise gestion des ressources dans LR, mais je n'ai jamais vraiment investigué En effet, Un OS 32 bits et moins de 4 Go de mémoire, de nos jours, c'est vraiment très très limite (ce qui n'excuse en rien le problème, qu'on s'entende bien).

Les fuites mémoire de Windows posent des problèmes récurrents. 4 Go, effectivement, c'est un peu juste.

[Powershot]

... quand je suis dans le module développement et que je travaille 20 à 30 fichiers RAW de suite ...

Ben là si c'est uniquement dans ce type de cas-là on pourrait effectivement parler de mémoire 
Pour être sûr, tu peux installer un utilitaire de gestion de la mémoire, et surveiller ce qui se passe.
Je suppose que les réglages de cache et de swap sont déjà bien ajustés ?
Peut-être envoyer le swap sur un disque plus rapide, avec plus d'espace ??
Mais le mieux est peut-être d'investir dans la barrette ... "légale" bien sûr, ou de passer à des versions plus récentes (OS et logiciel).
Bonnes photos à tous !

[kaf]

Les fuites mémoire de Windows posent des problèmes récurrents. 4 Go, effectivement, c'est un peu juste.

Ce n'est pas nécessairement Windows le problème
Si tu as une fuite d'huile à ta voiture et que tu tombes en panne, est-ce nécessairement la faute du moteur?

[lolo2]

Donc, il me faudrait passer à Windows 7 64 bits pour m'en sortir? pourtant j'ai beaucoup d'amis photographes qui s'en tire avec un XP 32 bits et 2 fois moins de mémoire que moi.....d'ailleurs j'utilise CS5 sans problemes !

[kaf]

Donc, il me faudrait passer à Windows 7 64 bits pour m'en sortir? pourtant j'ai beaucoup d'amis photographes qui s'en tire avec un XP 32 bits et 2 fois moins de mémoire que moi.....d'ailleurs j'utilise CS5 sans problemes !

C'est bien ce que je dis, le problème vient de LR, pas de CS Et effectivement, quand on est un peu juste en ressources, on a des problèmes. Passer en 64 bits ne résout en rien le problème, il repousse juste la limite Certains s'en sortent sans doute bien avec moins de ressources, mais que font-ils exactement de leurs photos? Comment travaillent-ils? Qu'ont-ils comme appareil photo? Pour en revenir à mon cas, avec le 40D je n'ai jamais eu le moindre souci, mais quand je suis passé au 5D2, aïe aïe aïe!

[Powershot]

... pourtant j'ai beaucoup d'amis photographes qui s'en tirent avec un XP 32 bits et 2 fois moins de mémoire que moi ...

Il faudrait voir dans ce cas si leur système réagit de la même façon au travail avec la même somme de données.
Si oui, ça ne vient pas du système.
Sinon, il faut revoir la configuration et le paramétrage de la machine 
C'est très fréquent, quand on utilise des applications pointues qui demandent des ressources (fréquencements des bus, qualités des barrettes, taille du swap, etc ... etc ...).
Bonnes photos à tous !

[Nikojorj]

Où est ton cache CameraRaw (un disque un peu plein et/ou à défragmenter?) et quelle est sa taille?

[THG]

Je le répète : le problème évoqué ici est lié à la gestion parfois calamiteuse de la RAM par Windows, et notamment Windows XP. Ce problème est récurrent mais totalement aléatoire.

D'ailleurs, j'en profite au passage : abandonnez Windows XP dès que possible. La prise en charge de ce système par les grands éditeurs de logiciels ne va pas être éternelle, croyez-moi.

[JEANPAUL]

... D'ailleurs, j'en profite au passage : abandonnez Windows XP dès que possible. La prise en charge de ce système par les grands éditeurs de logiciels ne va pas être éternelle, croyez-moi.

Et il ne faudra plus 4Go de Ram mais 16Go voire plus... pour que le programme fonctionne au moins aussi rapidement pour faire les même traitements...

Et si les développeurs commencaient plutot par optimiser leur code ?.... leurs performances seraient boostées même si le code source n'exploitera pas les dernières API "exceptionnelles" du Windows nouveau encore plus révolutionnaire que le précédent !

Non pas taper ! Bien amicalement à vous...

[THG]

Et il ne faudra plus 4Go de Ram mais 16Go voire plus... pour que le programme fonctionne au moins aussi rapidement...

Et si les développeurs commencaient plutot par optimiser leur code ?.... leurs performances seraient boostées même si le code source n'utiliserait les dernières API "révolutionnaires" du Windows encore plus révolutionnaire que le précédent !

Penses-tu sérieusement que les développeurs n'optimisent pas leur code ? Allons...

Quant à la RAM, je rappelle que Lightroom est surtout exigeant en puissance CPU.

Lorsque j'exporte des images, les 8 coeurs de mes processeurs sont monopolisés, alors que l'utilisation de RAM stagne à 2 Go environ (sur 16 au total)...

[Verso92]

Je le répète : le problème évoqué ici est lié à la gestion parfois calamiteuse de la RAM par Windows, et notamment Windows XP. Ce problème est récurrent mais totalement aléatoire.

C'est étonnant : on lit tout et son contraire à ce propos : XP était réputé pour bien géré la RAM, contrairement à W98...
(personnellement, je n'ai pas rencontré de problèmes de ce genre avec XP... bon, OK, j'utilise pas LR, non plus)

D'ailleurs, j'en profite au passage : abandonnez Windows XP dès que possible. La prise en charge de ce système par les grands éditeurs de logiciels ne va pas être éternelle, croyez-moi.

Il sera bien temps d'en changer le moment venu, n'est-ce pas ?
(mettre à la poubelle mes Coolscan, par exemple, ne m'enchante pas plus que ça... par quoi les remplacer ?)

[Nikojorj]

D'ailleurs, j'en profite au passage : abandonnez Windows XP dès que possible. La prise en charge de ce système par les grands éditeurs de logiciels ne va pas être éternelle, croyez-moi.

Ah, les alpha de LR4 demandent déjà W7?

C'est étonnant : on lit tout et son contraire à ce propos : XP était réputé pour bien géré la RAM, contrairement à W98...

De ce que j'ai compris, oui pour les quantités de l'époque (et bon, W98, difficile de faire pire, ça a été la meilleure pub pour Linux et MacOS à l'époque )... mais de nos jours, c'est vrai que la limite de 2Go par appli est plus contraignante.
Après, c'est vrai que les besoins de l'OS seul ne font qu'empirer à chaque version supplémentaire (W2k tournait bien avec 256-512k, XP tourne bien avec 1-2G, et avec W7 il en faut au moins 4 on dirait...) ce qui a une certaine tendance à faire rétropédaler l'affirmation précédente.

[THG]

Quand je parle de gestion de RAM calamiteuse, ça ne concerne pas les quantités consommées par tel ou tel process, mais bien de fuites au niveau du système et des choses comme la mémoire non restituée à la fin d'un process.

Mais bon, peu-être y a-t-il des personnes ici qui pourront expliquer cela bien mieux que moi.

En ce qui concerne les Coolscan, ils marchent très bien avec Vuescan et Silverfast.

[kaf]

Quand je parle de gestion de RAM calamiteuse, ça ne concerne pas les quantités consommées par tel ou tel process, mais bien de fuites au niveau du système et des choses comme la mémoire non restituée à la fin d'un process.

Il n'y a pas à proprement parlé de fuite au niveau du système, mais plutôt une gestion des ressources parfois surprenante. Par exemple, la mémoire allouée lors de la création d'une fenêtre n'est pas immédiatement libérée une fois celle-ci détruite. Elle l'est évidemment, plus tard, quand le système le juge utile. De même au niveau des ressources système il y a des limitations, si on alloue trop de ressources sans les libérer, le système fini par saturer. Ces comportements ne sont pas des bugs, mais des héritages d'une époque où les ressources système étaient très limitées et où il fallait quand même essayer d'aller vite malgré les limitations physiques et technologiques. Sur les systèmes récents, ces comportements ont disparu, et une programme qui n'en tient pas compte a plus de chance de fonctionner sans planter. Mais le problème est bien au niveau du logiciel, qui utilise mal l'OS, plutôt qu'au niveau de l'OS lui-même.

Cela dit, au vu de la quantité de données à gérer à l'heure actuelle, le 32 bits avec sa limitation à 2 Go par processus et XP avec son architecture assez ancienne ne représentent plus une solution vraiment viable.

Quant à la remarque à propos de l'optimisation du code par les développeurs, elle vient évidemment de quelqu'un qui n'a jamais vu un code source de sa vie. Évidemment que le code est optimisé. Mais à l'heure actuelle, on n'optimise plus le code pour utiliser le moins de mémoire possible en général, mais plutôt pour être le plus rapide possible (ce qui souvent, va dans le sens de l'augmentation de l'usage mémoire). De plus, les OS modernes utilisent plus de mémoire qu'il y a 10 ans c'est évident, mais regardez les avancées en terme d'interface et vous comprendrez pourquoi les systèmes sont de plus en plus gourmands. D'autant qu'au vu du pris de la mémoire, les développeurs n'essayent plus de faire tourner leur OS dans 256 Ko, ça n'a plus aucun sens à un époque où la majorité des machines sont vendues avec 3 ou 4 Go. Enfin, pensez à l'augmentation de résolution des APN, et donc à la quantité de mémoire à traiter par les logiciels, et vous comprendrez pourquoi il faut de plus en plus de mémoire pour travailler.

[Verso92]

En ce qui concerne les Coolscan, ils marchent très bien avec Vuescan et Silverfast.

J'ai personnellement comparé les performances respectives de Vuescan et de Nikonscan sur les fonctions évoluées (genre multi-échantillonnage), et ça me ferait bien ch... d'être obligé de me passer du logiciel fabricant...

[THG]

J'ai personnellement comparé les performances respectives de Vuescan et de Nikonscan sur les fonctions évoluées (genre multi-échantillonnage), et ça me ferait bien ch... d'être obligé de me passer du logiciel fabricant...

J'ai eu aussi l'occasion de comparer à l'époque, et si j'ai toujours apprécié et préféré NikonScan à toute autre solution, Silverfast est au moins aussi bon... et puis pas le choix.

[Verso92]

J'ai eu aussi l'occasion de comparer à l'époque, et si j'ai toujours apprécié et préféré NikonScan à toute autre solution, Silverfast est au moins aussi bon... et puis pas le choix.

C'est bien pour ça que je lâcherai XP le plus tard possible, puisque pour l'instant je ne ressens aucun des inconvénients évoqués ici...

[gerarto]

C'est bien pour ça que je lâcherai XP le plus tard possible, puisque pour l'instant je ne ressens aucun des inconvénients évoqués ici...

Verso, tu peux faire si nécessaire un (tout petit) pas en avant : Nikon Scan fonctionne sans pb avec Vista32 !

[Verso92]

Verso, tu peux faire si nécessaire un (tout petit) pas en avant : Nikon Scan fonctionne sans pb avec Vista32 !

Vista ? Surtout pas !!!

[Nikojorj]

Verso, tu peux faire si nécessaire un (tout petit) pas en avant : Nikon Scan fonctionne sans pb avec Vista32 !

Ca, c'est le genre de pas en avant qu'on fait lorsqu'on est au bord du gouffre... (copyright Boumédienne, à moins que je ne me sois fait abuser par les légendes urbaines de colons circulant dans la famille?)

[gerarto]

Vista ? Surtout pas !!!

Bof... depuis que j'ai Vista, je trouve que ça tourne beaucoup mieux qu'avec XP : plus d'écran bleus, très peu de problèmes.

Mais bon, pour exploiter mon matériel et sa mémoire, je devrais passer à W7 64, mais je suis comme toi : que faire avec mon Nikon Scan ?