Lightroom dans l'impasse?

[Pat91]

Bonjour à tous,

J'attendais beaucoup de LR 3.3 et notamment la correction de problèmes de performances qui m'empêchent d'utiliser le logiciel normalement. Cette nouvelle version ne fait qu'aggraver les choses. Les problèmes listés ci-dessous ont été observés par d'autres utilisateurs sur des configurations très variées (Mac et Windows, 32-bit ou 64-bit), en général très puissantes et largement pourvues en mémoire. Ce qui indique a priori qu'il ne s'agit pas d'un problème de ressources système ou de manque de mémoire.

- Ralentissement progressif mais au final violent de l'outil de retouche locale au fur et à mesure que le nombre (même raisonnable) de corrections apportées à l'image augmente. Le décalage entre l'application d'un coup de pinceau et la modification effective de l'image passe progressivement d'un délai très court à 15-20 secondes de retard.

- Passé un certain seuil de ralentissement, LR commence à se comporter de manière aberrante: duplication de zones rectangulaires dans l'image, renversement complet de l'image dans le sens vertical, effacement complet de l'écran pendant 10 à 15 secondes, même délai pour le changement de forme du curseur quand on passe d'une zone à l'autre de l'interface,... Tout ça finit souvent par un blocage généralisé du logiciel et nécessite toujours une sortie et un redémarrage (ou tout simplement la fin du processus via le Gestionnaire de Tâches).

- Temps de chargement des previews en mode développement extrêmement long (même quand la version 1:1 a déjà été créée).

Et j'en passe. Je précise que je n'ai jamais connu ces problèmes avec LR2. C'est également le cas de mes compagnons d'infortune. J'ai étudié avec attention tous les fils des différents fora sur lesquels ces problèmes sont évoqués. La variété des configurations citées (certaines étant largement surdimensionnées) exclut a priori que tous ces systèmes, Mac ou Windows, souffrent du même problème au niveau hardware ou système d'exploitation qui provoquerait ce comportement aberrant de LR. J'ai également tenté d'appliquer toutes les recommandations glanées ici et là, venant d'Adobe pou de tiers et concernant ces problèmes de performances. Sans aucun effet.

De plus, élément important, je note (et je ne suis pas non plus le seul) que le traitement des mêmes images sous Bibble 5, Photoshop ou DxO Optics Pro ne pose aucun problème du même type. L'utilisation de l'outil de retouche locale dans Camera Raw, équivalent de l'outil LR, ne cause strictement aucun souci.

Arguant du fait que de nombreux utilisateurs ne sont pas touchés par ces problèmes, Adobe a tendance à répondre que le défaut est du côté de l'utilisateur (ou plutôt de son système). Je réfute complètement cette position. Je ne vois pas pourquoi mon système serait assez bon pour les retouches locales sur des RAW dans Camera Raw et s'écroulerait complètement quand je fais la même chose sous LR. On nous a assez rabâché qu'il s'agissait du même moteur dans les deux cas.

Tout développeur de métier sait très bien que le fait qu'un ensemble d'utilisateurs ne soit pas affecté par un bug donné n'est pas une indication de la non existence du bug. Simplement, le contexte d'utilisation fait que le bug ne se manifeste pas dans leur cas. Il est évident que ce genre de bug est difficile à localiser car difficile à reproduire. Il n'empêche qu'il est tout à fait regrettable qu'Adobe ait tendance à botter en touche plutôt que de reconnaître qu'il y a un problème de taille et que ce problème s'aggrave de version en version.

Pour tous les utilisateurs affectés, l'impossibilité d'utiliser LR dans des conditions normales va probablement avoir pour conséquence le basculement sur un autre logiciel. Bien que je considère que Bibble 5 souffre encore de certains défauts au niveau de l'interface et même si j'aurais de loin préféré un LR qui fonctionne, je pense que je vais probablement changer de boutique. Une version 3.4 n'est certainement pas pour tout de suite et il nous faut bien traiter nos images en attendant.

[yannick-f]

personnellement, sur ma machine, la version 3 se montre plus véloce que la version 2. Maintenant, je ne pense pas qu'adobe laisse ses utilisateurs "en rade" si le problème est effectivement générale. Un patch sera probablement proposé.

J'utilise lightroom au quotidien, mais jamais les fonctions de retouches.

[Pat91]

J'utilise lightroom au quotidien, mais jamais les fonctions de retouches.

Je n'ai pas de problèmes sur les autres fonctions. C'est seulement quand j'utilise les outils de retouche locale que LR part en vrille. Je ne parle pas des problèmes de performances également évoqués pour le module Bibliothèque. Je n'ai pas de problèmes de ce côté.

[pgrat]

Je n'ai pas de problèmes sur les autres fonctions. C'est seulement quand j'utilise les outils de retouche locale que LR part en vrille. Je ne parle pas des problèmes de performances également évoqués pour le module Bibliothèque. Je n'ai pas de problèmes de ce côté.

Idem pour moi. De mon côté, je trouve l'interface de Bibble 5 plus grossière et la qualité de l'interpolation moindre. Capture One v6 (j'ai déjà la v5) me fait de plus en plus de l'oeil avec ses derniers ajouts : correction des perspectives, impression et retouche locale même si elle est encore un peu embryonnaire. Je me demande d'ailleurs si les dévelopeurs de Capture One ne courent pas le risque d'être confrontés aux mêmes types de problèmes en augmentant les possibilités de retouche locale ...

[THG]

Je me demande d'ailleurs si les dévelopeurs de Capture One ne courent pas le risque d'être confrontés aux mêmes types de problèmes en augmentant les possibilités de retouche locale ...

Pas si sûr parce que, comme Aperture, ils semblent avoir choisi la voie de la facilité en basant la retouche locale sur des masques bitmap.

[pgrat]

Pas si sûr parce que, comme Aperture, ils semblent avoir choisi la voie de la facilité en basant la retouche locale sur des masques bitmap.

Merci pour l'info, c'est intéressant.

[Pat91]

Pas si sûr parce que, comme Aperture, ils semblent avoir choisi la voie de la facilité en basant la retouche locale sur des masques bitmap.

Depuis que j'utilise Lightroom, je sens confusément (bien que ne disposant d'aucune information technique concrète pour le confirmer) que les problèmes de Lightroom en retouche locale sont liés à un choix de design "monoplan". Tout étant traité au même niveau, chaque correction provoque le recalcul complet de la vue et la reprise en compte des autres corrections. Un système par calques ne présente pas les mêmes inconvénients. Les données correspondant à un calque non affecté par une modification n'ont pas à être rafraîchies. La division des tâches allège la charge de la CPU.

Bibble Labs a évité cet écueil en basant les retouches locales sur un système de calques. Et cela semble fonctionner correctement.

Là où j'ai un doute, c'est sur le fait que je n'ai absolument pas de problèmes quand j'utilise la retouche locale dans Camera Raw. Ce qui semblerait indiquer que les 2 outils n'ont peut-être pas autant de points architecturaux en commun que l'on a bien voulu nous le dire.

La probabilité pour que LR soit basé sur un design inadapté m'apparaît comme de plus en plus grande. C'est pour cela que j'ai délibérément choisi le terme d'impasse dans le titre de ce fil. Je ne serais pas étonné de voir apparaître une prochaine version majeure basée sur des fondamentaux totalement différents et s'articulant sur un système de calques. Comme tout le monde. Il y a un bout de temps que je réfléchis au problème et si je me positionne en tant que développeur ayant à concevoir un programme équivalent, c'est très probablement le choix d'architecture que je ferais.

Mais attendre la version 4.x pour disposer d'un logiciel qui fonctionne n'est pas une perspective qui me réjouis d'autant plus qu'il faudra que je paie pour voir arriver la correction d'une erreur de conception. D'où l'idée de basculer dès maintenant (et avec regret) vers un autre logiciel.

[yannick-f]

Il faut aussi garder à l'esprit que lightroom n'est pas un logiciel de retouches....

[FrancoisC]

Tout développeur de métier sait très bien que le fait qu'un ensemble d'utilisateurs ne soit pas affecté par un bug donné n'est pas une indication de la non existence du bug.

Tout à fait exact. Mais également tout développeur de métier doit savoir que l'occurrence d'un même dysfonctionnement dans des environnements différents n'exclut pas forcément une cause liée à l'environnement.
D'ailleurs de ma petite expérience les problèmes de performances sont finalement souvent liées à un ensemble de facteurs (environnement, (mes)usage, défaut d'architecture, mauvaise pratique de programmation...) Rien n'est simple.

Ceci dit j'ai l'impression que depuis l'introduction de la retouche locale les retours après chaque version (mineure ou majeure) sont assez divers. On ne sait pas ou en est Adobe en ce moment là dessus. Avoir une non-réponse de leur part quand on éprouve les problèmes que tu décris est un peu... gênant.

Je n'ai pas ces problèmes de mon coté mais j'avoue n'utiliser la retouche locale que de façon légère (maximum un à deux masques et un dégradé). Les temps de réponse ne sont pas immédiats sur les curseurs d'ajustement mais restent acceptables. Je n'ai pas chronométré mais je dirais 1 à 2 secondes max (MacBook Pro 2009)

[kalimantan]

Perso je n'utilise pas LR3, que je n'ai pas trouvé génial, pour des retouches locales car je constate aussi qu'il a tendance à partir en vrille. Donc je passe sur Photoshop où les calques et masques fonctionnent très bien.

LR2 me donnait entière satisfaction pour la gestion des importations et de la bibliothèque.

Utilisateur de CaptureOne, depuis longtemps, la version 6 me donne entière satisfaction sur les retouches locales. Mais ils ont opté pour une gestion par calque.....! On peut ainsi multiplier les calques sans que cela influence le fonctionnement.

Et il va bientôt totalement remplacer LR3 si ils continuent d'améliorer le fonctionnement de la bibliothèque.

[Pat91]

Il faut aussi garder à l'esprit que lightroom n'est pas un logiciel de retouches....

Il est bien entendu que pour les retouches un peu lourdes, il faut basculer sur Photoshop ou autres. Ceci étant, ou bien ils décident d'implémenter une fonction dans LR (retouche locale) et dans ce cas, elle doit fonctionner comme annoncé ou bien ils décident que ce n'est pas possible dans des conditions correctes et alors ils ne la proposent pas. Sinon, c'est juste pour faire joli dans les spécifications du logiciel et sur les plaquettes marketing et cela s'appelle de la publicité mensongère.

[THG]

Depuis que j'utilise Lightroom, je sens confusément (bien que ne disposant d'aucune information technique concrète pour le confirmer) que les problèmes de Lightroom en retouche locale sont liés à un choix de design "monoplan". Tout étant traité au même niveau, chaque correction provoque le recalcul complet de la vue et la reprise en compte des autres corrections. Un système par calques ne présente pas les mêmes inconvénients. Les données correspondant à un calque non affecté par une modification n'ont pas à être rafraîchies. La division des tâches allège la charge de la CPU.

Bibble Labs a évité cet écueil en basant les retouches locales sur un système de calques. Et cela semble fonctionner correctement.

Là où j'ai un doute, c'est sur le fait que je n'ai absolument pas de problèmes quand j'utilise la retouche locale dans Camera Raw. Ce qui semblerait indiquer que les 2 outils n'ont peut-être pas autant de points architecturaux en commun que l'on a bien voulu nous le dire.

La probabilité pour que LR soit basé sur un design inadapté m'apparaît comme de plus en plus grande. C'est pour cela que j'ai délibérément choisi le terme d'impasse dans le titre de ce fil. Je ne serais pas étonné de voir apparaître une prochaine version majeure basée sur des fondamentaux totalement différents et s'articulant sur un système de calques. Comme tout le monde. Il y a un bout de temps que je réfléchis au problème et si je me positionne en tant que développeur ayant à concevoir un programme équivalent, c'est très probablement le choix d'architecture que je ferais.

Mais attendre la version 4.x pour disposer d'un logiciel qui fonctionne n'est pas une perspective qui me réjouis d'autant plus qu'il faudra que je paie pour voir arriver la correction d'une erreur de conception. D'où l'idée de basculer dès maintenant (et avec regret) vers un autre logiciel.

Oui, tu délivres la un point de vue pertinent, et je suis également curieux de voir comment ça va évoluer (retouche locale par calques vs retouche locale purement par écriture dans les métadonnées).
Par contre, je pense que la comparaison avec les performances d'ACR n'est pas la meilleure façon de présenter le problème, tout simplement parce que Camera Raw n'a pas une base de données accrochée à la patte.

[Pat91]

Tout à fait exact. Mais également tout développeur de métier doit savoir que l'occurrence d'un même dysfonctionnement dans des environnements différents n'exclut pas forcément une cause liée à l'environnement.

Nous sommes d'accord. Cependant, quand on parcourt les différents fils sur les fora et les articles glanés ici et là, il y a une chose qui saute immédiatement aux yeux: la variété des configurations utilisées par les personnes rapportant ce même type de problème. Encore une fois, cela va du Mac avec un quadcore hyper cadencé et chargé de RAM jusqu'au yeux au PC plus modeste tournant sous XP 32-bit. Statistiquement, cela signifie quelque chose. Trouver un point commun entre ces configurations et ces OS différents qui fait que LR se met à battre la campagne en retouche locale est hautement improbable.

Tout est possible mais la probabilité pour que le problème soit dans le logiciel est quand même de loin plus élevée (je dirais 10 contre 1). D'autant plus que la plupart du temps, les mêmes personnes n'avaient pas de problèmes sous LR2. Le bon fonctionnement des retouches locales sous Camera Raw sur les mêmes machines est pour moi également significatif et abonde dans le même sens.

[Pat91]

Par contre, je pense que la comparaison avec les performances d'ACR n'est pas la meilleure façon de présenter le problème, tout simplement parce que Camera Raw n'a pas une base de données accrochée à la patte.

OK, c'est indubitable. Mais que fait LR avec la base de données pendant que l'on édite? Au pire il met à jour quelques infos de taille réduite dans le catalogue (il suffit de regarder le contenu d'un XMP pour se rendre compte que ça ne va pas chercher bien loin). Quelques valeurs numériques à modifier ici et là. Même s'il le fait à chaque modif (mais je suppose qu'il ne met à jour dans le catalogue que les valeurs qui ont été modifiées), cela ne doit prendre que quelques fractions de secondes.

Je suis plus dubitatif sur le choix de SQLite comme moteur de base de données. Il présente l'avantage d'être léger et gratuit mais côté performances, ce n'est pas un foudre de guerre. Que les performances du logiciel se dégradent rapidement dans la gestion de la bibliothèque au fur et à mesure que le nombre d'images augmente n'est pas franchement une surprise. Une solution plus pro, surtout pour un logiciel de ce prix, aurait été bienvenue. Par exemple, le moteur Microsoft SQL Server peut maintenant être intégré à des applications autonomes et côté performances, c'est quand même autre chose. Je suppose qu'il existe un équivalent pour les versions Mac.

[Pat91]

Ah, on commence à causer chez Adobe. Et on reconnait le problème. C'est déjà ça. Voir le dernier post de ce fil.

http://forums.adobe.com/thread/760245?tstart=0

[THG]

OK, c'est indubitable. Mais que fait LR avec la base de données pendant que l'on édite? Au pire il met à jour quelques infos de taille réduite dans le catalogue (il suffit de regarder le contenu d'un XMP pour se rendre compte que ça ne va pas chercher bien loin). Quelques valeurs numériques à modifier ici et là. Même s'il le fait à chaque modif (mais je suppose qu'il ne met à jour dans le catalogue que les valeurs qui ont été modifiées), cela ne doit prendre que quelques fractions de secondes.

Je suis plus dubitatif sur le choix de SQLite comme moteur de base de données. Il présente l'avantage d'être léger et gratuit mais côté performances, ce n'est pas un foudre de guerre. Que les performances du logiciel se dégradent rapidement dans la gestion de la bibliothèque au fur et à mesure que le nombre d'images augmente n'est pas franchement une surprise. Une solution plus pro, surtout pour un logiciel de ce prix, aurait été bienvenue. Par exemple, le moteur Microsoft SQL Server peut maintenant être intégré à des applications autonomes et côté performances, c'est quand même autre chose. Je suppose qu'il existe un équivalent pour les versions Mac.

Oui, et c'est aussi le choix de SQLite qui interdit, tout au moins pour l'instant, une version "network" de Lightroom, justement à cause de problèmes de performances et de stabilité.

Mais d'un autre côté, je suis certain qu'Adobe réfléchit à tout ça et que la marmite bout.

[THG]

Ah, on commence à causer chez Adobe. Et on reconnait le problème. C'est déjà ça. Voir le dernier post de ce fil.

http://forums.adobe.com/thread/760245?tstart=0

Oui, Dan Tull est un des ingénieurs directement impliqués dans le développement de Lightroom. Mais ce qu'il dit ici, c'est qu'il dispose de nouveaux outils permettant de reproduire des problèmes de performances mais, là encore, on va plutôt dans la direction d'une correction mineure. Ce qui qui m'intéresse, c'est de savoir quelles sont les solutions à long terme.
J'ai lu les discussions et ça part un peu dans tous les sens, toujours un problème avec les forums.

[Pat91]

Oui, Dan Tull est un des ingénieurs directement impliqués dans le développement de Lightroom. Mais ce qu'il dit ici, c'est qu'il dispose de nouveaux outils permettant de reproduire des problèmes de performances mais, là encore, on va plutôt dans la direction d'une correction mineure. Ce qui qui m'intéresse, c'est de savoir quelles sont les solutions à long terme.

Je suis d'accord. Maintenant, il y a quand même un point central qu'Adobe ne devrait pas oublier: nous cotisons depuis la version 1 et je pense que peu d'utilisateurs seront d'accord pour continuer à alimenter la caisse en attendant qu'une stratégie de développement fiable soit définie. Il fallait y penser avant (le choix de SQLite est un bon exemple). Il se trouve que c'est maintenant que nous avons des photos à traiter. Pas dans un an ou deux après être passés par des cotisations supplémentaires pour cause de mise à jour.

Je ne jetterai jamais la pierre à une équipe de développement qui fait des erreurs. J'ai exercé ce métier très longtemps et l'idée même de logiciel sans bug est une incongruité. La question est "comment réagit l'éditeur quand les clients remontent des problèmes?". Si j'avais dit à mes propres clients "Ça sera corrigé dans la prochaine version mais je vous demanderai de payer pour ça", je n'aurais pas tenu 17 ans en tant que consultant indépendant.

S'intéresser à la stratégie à long terme est une bonne chose mais les clients touchés par ces problèmes, parce qu'ils ont payé pour un produit qui ne fonctionne pas, attendent une correction à court terme sur la version 3. Il ne s'agit pas d'une gêne que l'on supporterait jusqu'à ce que le problème soit réglé. Pour les malchanceux, le programme est tout simplement inutilisable. Cela justifie la mise en oeuvre de moyens supplémentaires. Adobe a les moyens de mettre du monde sur le problème. Si leur conclusion est qu'un re-design est nécessaire pour remettre tout ça d'aplomb, il faudra qu'ils assument financièrement leur erreur. Si le constructeur de ma voiture rappelle certains modèles pour cause de défaut patent, il ne me fait pas payer la réparation. Je ne vois pas pourquoi cela serait différent en matière de logiciels.

Les utilisateurs ont pris l'habitude d'accepter des éditeurs de logiciels des comportements qu'ils n'admettraient pas de la part de leur fabricant de machine à laver. C'est curieux, non?

[Nikojorj]

je pense que peu d'utilisateurs seront d'accord pour continuer à alimenter la caisse en attendant qu'une stratégie de développement fiable soit définie.

Oui enfin... on ne va pas basculer sous BlueMarine non plus pour autant!
Soyons réalistes : on est un peu coincés.

Pour l'instant la seule alternative est B5, et moi s'il faut parler de moi, tant que je n'ai pas de bug bloquant sous LR (XP32b et pas de coinçage comme tu les décris) je ne vais pas tout basculer pour perdre tous mes traitements et m'exposer à d'autres bugs...
D'ailleurs où en est la stabilité de B5.1?

[Pat91]

Soyons réalistes : on est un peu coincés.

En étant méchant, on pouurait effectivement dire que les marketeurs d'Adobe sont plus rusés que leurs développeurs. Mais je ne suis pas très méchant.

je ne vais pas tout basculer pour perdre tous mes traitements et m'exposer à d'autres bugs...

Pas de raison de changer quoi que ce soit pour ceux qui n'ont pas de problème. C'est évident.

D'ailleurs où en est la stabilité de B5.1?

Le logiciel est stable pour l'expérience que j'en ai. En dehors des problèmes de l'interface utilisateur qui reste à corriger (je ne dis pas améliorer mais bien corriger), le problème chez Bibble Labs est plutôt leur train de sénateur. On attend une 5.2 depuis un bout de temps et seule une RC devrait être dispo incessament. Certaines fonctions importantes ne sont couvertes que par des plugins provenant de tierce-parties. Ça me gêne un peu. Les gros points positifs sont la rapidité (comparé à LR), le besoin beaucoup plus limité en ressources système et les calques. Là, ils sont plus forts qu'Adobe.

[THG]

Là, ils sont plus forts qu'Adobe.

Sauf qu'il n'y a pas de secret, on ne peut pas appliquer un traitement de haute qualité aux images de manière rapide sans faire de concessions.

[Olivier Chauvignat]

Sauf qu'il n'y a pas de secret, on ne peut pas appliquer un traitement de haute qualité aux images de manière rapide sans faire de concessions.

concessions de quel genre ?

[THG]

concessions de quel genre ?

Je ne crois pas une seule minute qu'on puisse extraire des images avec un traitement du bruit impeccable, une excellente restitution des détails et une correction optique de qualité - tout en assurant la possibilité de revenir travailler dans l'application pendant l'export - au même titre que Bibble qui te sort des fichiers à tour de bras.

[THG]

Mais ceci ne remet bien évidemment pas en cause ces problèmes de ralentissement avec la retouche locale, et bien entendu, j'ai des doutes quant à la voie à suivre.

[basic]

Pat91...

Je partage tout à fait ton point de vue, ayant un Pc équipé d'une mémoire de 1 GO avec LR3.3 sans possibilité d'extension, mes raw font seulement 5 Mo, j'ai admis un temps de traitement un peu long mais acceptable pour un amateur. Par contre j'ai les même problèmes que toi avec génération d'artéfacts inadmissibles dans l'état actuel des choses.
J'ai installé LR à ses débuts et le coût final aujourd'hui est élevé.
On ne peut pas accepter l'explication fournie ici, selon laquelle:

--  ce logiciel n'est pas fait pour la retouche, il faut aussi utiliser PShop.

J'attend simplement une correction.
Basic.