Des nouvelles de Lightroom 4.1 ?

[samlawry]

Ca devient long là .... 

[pgrat]

Voilà l'adresse du forum d'Adobe : http://forums.adobe.com/community/lightroom

[Pat91]

À la lecture du forum Adobe et vu et l'inquiétante longueur du fil Lightroom 4 is slow, je ne serais pas franchement surpris si on voyait arriver une RC3 (ce qui serait un événement exceptionnel, j'en conviens). Je ne demande qu'à être démenti mais je me base sur le vieil adage statisticien qui dit que plus un problème dure, plus il a de chances de durer encore plus longtemps... . C'est comme les bugs. Plus un bug est ancien, plus il a de chances de survivre à des bugs plus récents.

J'ai été amusé par l'intervention d'un des participants au forum qui compare l'évolution de LR à celle de la hyène. Cet animal a une particularité : il semble que son évolution se soit mal enclenchée au départ et soit partie sur une piste qui s'avère être une impasse. Chaque étape de l'évolution des hyènes a rendu plus difficile et plus improbable la survie de la génération suivante.

Considérant l'histoire de LR, ce n'est pas une comparaison idiote.

[THG]

À la lecture du forum Adobe et vu et l'inquiétante longueur du fil Lightroom 4 is slow, je ne serais pas franchement surpris si on voyait arriver une RC3 (ce qui serait un événement exceptionnel, j'en conviens). Je ne demande qu'à être démenti mais je me base sur le vieil adage statisticien qui dit que plus un problème dure, plus il a de chances de durer encore plus longtemps... . C'est comme les bugs. Plus un bug est ancien, plus il a de chances de survivre à des bugs plus récents.

J'ai été amusé par l'intervention d'un des participants au forum qui compare l'évolution de LR à celle de la hyène. Cet animal a une particularité : il semble que son évolution se soit mal enclenchée au départ et soit partie sur une piste qui s'avère être une impasse. Chaque étape de l'évolution des hyènes a rendu plus difficile et plus improbable la survie de la génération suivante.

Considérant l'histoire de LR, ce n'est pas une comparaison idiote.

Je pense que tu confonds l'aventure de Lightroom avec celle d'Aperture.

Pour 4.1, encore un peu de patience. Il y a en moyenne 4 mises à jour par année (Lr et ACR), donc tous les 3 mois environ, et Lightroom 4.0 est sorti début mars...   ;-)

[Olivier Chauvignat]

J'ai été amusé par l'intervention d'un des participants au forum qui compare l'évolution de LR à celle de la hyène. Cet animal a une particularité : il semble que son évolution se soit mal enclenchée au départ et soit partie sur une piste qui s'avère être une impasse. Chaque étape de l'évolution des hyènes a rendu plus difficile et plus improbable la survie de la génération suivante.

Ce n'est pas ce que j'ai observé (depuis la version Béta 1)

[OuiOuiPhoto]

J'ai été amusé par l'intervention d'un des participants au forum qui compare l'évolution de LR à celle de la hyène. Cet animal a une particularité : il semble que son évolution se soit mal enclenchée au départ et soit partie sur une piste qui s'avère être une impasse. Chaque étape de l'évolution des hyènes a rendu plus difficile et plus improbable la survie de la génération suivante.

Considérant l'histoire de LR, ce n'est pas une comparaison idiote.

Les hyènes, lorsqu'elles sont en très grand nombre, n'ont pas d'adversaire particulier (wikipedia). Ca a l'air de corespondre assez a l'hitoire de LR aussi non ?  (aller un petit coup d'huile sur le feu).

[BIRD]

À la lecture du forum Adobe et vu et l'inquiétante longueur du fil Lightroom 4 is slow, je ne serais pas franchement surpris si on voyait arriver une RC3 (ce qui serait un événement exceptionnel, j'en conviens). Je ne demande qu'à être démenti mais je me base sur le vieil adage statisticien qui dit que plus un problème dure, plus il a de chances de durer encore plus longtemps... . C'est comme les bugs. Plus un bug est ancien, plus il a de chances de survivre à des bugs plus récents.

J'ai été amusé par l'intervention d'un des participants au forum qui compare l'évolution de LR à celle de la hyène. Cet animal a une particularité : il semble que son évolution se soit mal enclenchée au départ et soit partie sur une piste qui s'avère être une impasse. Chaque étape de l'évolution des hyènes a rendu plus difficile et plus improbable la survie de la génération suivante.

Considérant l'histoire de LR, ce n'est pas une comparaison idiote.

?
Personnellement, j'avais essayé LR2 et était resté avec mes outils.
Maintenant avec LR4.1, je suis convaincu de chez convaincu.
Les nouveautés et améliorations de LR4 font clairement la différence pour moi.
Par rapport à mes précédents outils, c'est LR qui à le plus évolué (dans le bon sens).
De même pour l'ergonomie, Y a pas photo.

[THG]

?
Personnellement, j'avais essayé LR2 et était resté avec mes outils.
Maintenant avec LR4.1, je suis convaincu de chez convaincu.
Les nouveautés et améliorations de LR4 font clairement la différence pour moi.
Par rapport à mes précédents outils, c'est LR qui à le plus évolué (dans le bon sens).
De même pour l'ergonomie, Y a pas photo.

C'est bien ça qui est malheureux. Quand on voit la liste de nouveautés longue comme le bras à chaque révision majeure et les progrès spectaculaires de la qualité d'image - entre Lr3 et son moteur de dématriçage remarquable pour contenir le bruit et la correction de la tonalité dans Lr4 - et que tout ce que certains ont à dire porte uniquement sur les bugs, c'est à se taper la tête contre les murs et ça me laisse dans une abîme d'incompréhension, au point que je finis par passer outre, découragé par le fait qu'à part les bugs, il n'y a pas moyen d'avoir ou d'entamer de conversation sérieuse sur les outils et les fonctionnalités de l'application.
Ce forum est devenu un bureau des pleurs, et c'est lamentable.

[OuiOuiPhoto]

et la correction de la tonalité dans Lr4

C'est clair que moi je l'utilise depuis deux ou trois semaine et ce nouveau moteur me laisse sur le cul. Ça m'a perturbé 2 minutes (avec l'age on accepte moins les changements ) mais je trouve cela beaucoup plus naturel maintenant et vachement efficace. En fait je vais beaucoup moins dans les courbes qu'avant. J'obtient le résultat que je souhaite plus rapidement

Et finalement le modules Maps dont je ne voyais qu'une utilité limité je trouve cela très sympa et pratique.

[Jc.]

...
Ce forum est devenu un bureau des pleurs, et c'est lamentable.

justement, je viens de poser un post qui contrebalancera ça...

[Pat91]

Il y a en moyenne 4 mises à jour par année (Lr et ACR), donc tous les 3 mois environ, et Lightroom 4.0 est sorti début mars...   ;-)

Sauf que dans ce cas précis, il ne s'agit pas d'une mise à jour de routine mais de la correction des problèmes de la version originale dont le moins que l'on puisse dire est qu'elle a été démoulée trop chaude. Ce qui justifierait donc un petit peu plus d'empressement.

[Pat91]

Ce n'est pas ce que j'ai observé (depuis la version Béta 1)

Je sais, j'ai le défaut d'observer l'animal non pas purement du point de vue de l'utilisateur mais aussi en tant que développeur. Cette expérience permet de repérer certains comportements caractéristiques qui échappent à l'utilisateur non informaticien. Je commence à penser que malgré les qualités indiscutables du logiciel (je m'en sers quotidiennement), il y a quelque part dans le design une sorte de "faute originelle" que je ne peux pas expliquer complètement puisque je n'ai pas accès au code mais dont on commence à voir les effets.

J'ai déjà expliqué (et je suis absolument certain de cela) qu'Adobe fait assez largement l'impasse sur les tests de régression. C'est un fait avéré et tous les symptômes sont là qui le démontrent. Aucun développeur de bonne foi ne peut prétendre le contraire. Et c'est déjà, à mon humble avis de professionnel du développement, une faute grave puisqu'ils déportent verrs l'utilisateur la responsabilité de ces tests.

Mais le concept même du logiciel, basé sur le mode paramétrique et le recalcul permanent de l'image dans sa totalité, présente de toute évidence un problème de mise en oeuvre. Sinon, on ne peut pas expliquer les différences massives de performances entre Lightroom en mode développement et Camera RAW. Il y a, depuis le début, quelque chose qui ne tourne pas rond (j'aurais pu caractériser le problème de manière plus précise si j'avais conservé mes outils de débogage et de développement mais j'ai décidé justement que je ne coderai plus). J'ai juste quelques soupçons assez nets mais que je ne peux étayer. En tous cas, je constate, de version en version, que ces bizarreries comportementales vont en s'aggravant. Cela n'empêche pas de travailler si on possède une configuration dont la puissance peut compenser mais il apparaît que la configuration minimale recommandée est maintenant loin de faire l'affaire.

La lecture du fil cité plus haut (Lightroom 4 is slow) est extrêmement intéressante sur ces points. Mais le nombre de messages peut rebuter .

À mon (toujours très humble) avis, il y a dans Lightroom un problème architectural et Adobe ferait mieux de paser du temps sur ce point plutôt que de jouer le jeu du marketing en ajoutant des fonctions pas nécessairement utiles (je ne parle pas du nouveau processus de dématriçage bien sûr). L'histoire du software est remplie d'exemples de logiciels qui se sont "auto-étouffés" parce que la décision de refonte de l'architecture n'a jamais été prise ou a été prise trop tard. Il me semble bien que Lightroom est sur une trajectoire identique.

Maintenant, je ne veux pas jouer les rabat-joie. Que ceux qui sont satisfaits restent satisfaits. J'exprime seulement quelques craintes qui sont, je le crois, fondées. Mais personne n'est infaillible...

Et pour répondre à THG qui joue toujours fort honnêtement son rôle d'évangéliste assumé , il ne s'agit pas de "pleurer" mais d'émettre des critiques qui ne sont pas destructives. J'ai juste quelques doutes dont je fais part régulièrement et en argumentant et quelques réclamations ma foi bien justifiées puisque je suis un client qui a déjà cotisé largement au chiffre d'affaires d'Adobe. Je revendique en tant que tel le droit d'exprimer de temps en temps mon insatisfaction malgré, encore une fois, le fait que Lightroom (3) est un outil que j'utilise en permanence et pour lequel je ne vois pas de concurrent.

Est-ce plus clair?

[THG]

Sauf que dans ce cas précis, il ne s'agit pas d'une mise à jour de routine mais de la correction des problèmes de la version originale dont le moins que l'on puisse dire est qu'elle a été démoulée trop chaude. Ce qui justifierait donc un petit peu plus d'empressement.

Un avis que je ne partage pas.

[Pat91]

Un avis que je ne partage pas.

Je m'en doutais un peu...

[toukrikri]

Moi pendant ce temps , avec le bug du double écran ( la visu double ecran est fausse en couleur et en luminosité ) en mode développement je passe mon temps à faire du D -> traitement-> E vérification et puis prochaine photo et c'est reparti
Je suis Pas un pro donc je m'en tape mais pour un pro qui travaille avec ce bug et qui apprecie les nouveautés de la rc2 il y a de quoi etre un peu enervé

[Olivier Chauvignat]

Je sais, j'ai le défaut d'observer l'animal non pas purement du point de vue de l'utilisateur mais aussi en tant que développeur. Cette expérience permet de repérer certains comportements caractéristiques qui échappent à l'utilisateur non informaticien. Je commence à penser que malgré les qualités indiscutables du logiciel (je m'en sers quotidiennement), il y a quelque part dans le design une sorte de "faute originelle" que je ne peux pas expliquer complètement puisque je n'ai pas accès au code mais dont on commence à voir les effets.

J'ai déjà expliqué (et je suis absolument certain de cela) qu'Adobe fait assez largement l'impasse sur les tests de régression. C'est un fait avéré et tous les symptômes sont là qui le démontrent. Aucun développeur de bonne foi ne peut prétendre le contraire. Et c'est déjà, à mon humble avis de professionnel du développement, une faute grave puisqu'ils déportent verrs l'utilisateur la responsabilité de ces tests.

Mais le concept même du logiciel, basé sur le mode paramétrique et le recalcul permanent de l'image dans sa totalité, présente de toute évidence un problème de mise en oeuvre. Sinon, on ne peut pas expliquer les différences massives de performances entre Lightroom en mode développement et Camera RAW. Il y a, depuis le début, quelque chose qui ne tourne pas rond (j'aurais pu caractériser le problème de manière plus précise si j'avais conservé mes outils de débogage et de développement mais j'ai décidé justement que je ne coderai plus). J'ai juste quelques soupçons assez nets mais que je ne peux étayer. En tous cas, je constate, de version en version, que ces bizarreries comportementales vont en s'aggravant. Cela n'empêche pas de travailler si on possède une configuration dont la puissance peut compenser mais il apparaît que la configuration minimale recommandée est maintenant loin de faire l'affaire.

La lecture du fil cité plus haut (Lightroom 4 is slow) est extrêmement intéressante sur ces points. Mais le nombre de messages peut rebuter .

À mon (toujours très humble) avis, il y a dans Lightroom un problème architectural et Adobe ferait mieux de paser du temps sur ce point plutôt que de jouer le jeu du marketing en ajoutant des fonctions pas nécessairement utiles (je ne parle pas du nouveau processus de dématriçage bien sûr). L'histoire du software est remplie d'exemples de logiciels qui se sont "auto-étouffés" parce que la décision de refonte de l'architecture n'a jamais été prise ou a été prise trop tard. Il me semble bien que Lightroom est sur une trajectoire identique.

Maintenant, je ne veux pas jouer les rabat-joie. Que ceux qui sont satisfaits restent satisfaits. J'exprime seulement quelques craintes qui sont, je le crois, fondées. Mais personne n'est infaillible...

Et pour répondre à THG qui joue toujours fort honnêtement son rôle d'évangéliste assumé , il ne s'agit pas de "pleurer" mais d'émettre des critiques qui ne sont pas destructives. J'ai juste quelques doutes dont je fais part régulièrement et en argumentant et quelques réclamations ma foi bien justifiées puisque je suis un client qui a déjà cotisé largement au chiffre d'affaires d'Adobe. Je revendique en tant que tel le droit d'exprimer de temps en temps mon insatisfaction malgré, encore une fois, le fait que Lightroom (3) est un outil que j'utilise en permanence et pour lequel je ne vois pas de concurrent.

Est-ce plus clair?

Pourquoi n'essaierais tu pas d'en parler aux développeurs, avec un descriptif le plus précis possible ?

[samlawry]

Je sais, j'ai le défaut d'observer l'animal non pas purement du point de vue de l'utilisateur mais aussi en tant que développeur. Cette expérience permet de repérer certains comportements caractéristiques qui échappent à l'utilisateur non informaticien. Je commence à penser que malgré les qualités indiscutables du logiciel (je m'en sers quotidiennement), il y a quelque part dans le design une sorte de "faute originelle" que je ne peux pas expliquer complètement puisque je n'ai pas accès au code mais dont on commence à voir les effets.

J'ai déjà expliqué (et je suis absolument certain de cela) qu'Adobe fait assez largement l'impasse sur les tests de régression. C'est un fait avéré et tous les symptômes sont là qui le démontrent. Aucun développeur de bonne foi ne peut prétendre le contraire. Et c'est déjà, à mon humble avis de professionnel du développement, une faute grave puisqu'ils déportent verrs l'utilisateur la responsabilité de ces tests.

Mais le concept même du logiciel, basé sur le mode paramétrique et le recalcul permanent de l'image dans sa totalité, présente de toute évidence un problème de mise en oeuvre. Sinon, on ne peut pas expliquer les différences massives de performances entre Lightroom en mode développement et Camera RAW. Il y a, depuis le début, quelque chose qui ne tourne pas rond (j'aurais pu caractériser le problème de manière plus précise si j'avais conservé mes outils de débogage et de développement mais j'ai décidé justement que je ne coderai plus). J'ai juste quelques soupçons assez nets mais que je ne peux étayer. En tous cas, je constate, de version en version, que ces bizarreries comportementales vont en s'aggravant. Cela n'empêche pas de travailler si on possède une configuration dont la puissance peut compenser mais il apparaît que la configuration minimale recommandée est maintenant loin de faire l'affaire.

La lecture du fil cité plus haut (Lightroom 4 is slow) est extrêmement intéressante sur ces points. Mais le nombre de messages peut rebuter .

À mon (toujours très humble) avis, il y a dans Lightroom un problème architectural et Adobe ferait mieux de paser du temps sur ce point plutôt que de jouer le jeu du marketing en ajoutant des fonctions pas nécessairement utiles (je ne parle pas du nouveau processus de dématriçage bien sûr). L'histoire du software est remplie d'exemples de logiciels qui se sont "auto-étouffés" parce que la décision de refonte de l'architecture n'a jamais été prise ou a été prise trop tard. Il me semble bien que Lightroom est sur une trajectoire identique.

Maintenant, je ne veux pas jouer les rabat-joie. Que ceux qui sont satisfaits restent satisfaits. J'exprime seulement quelques craintes qui sont, je le crois, fondées. Mais personne n'est infaillible...

Et pour répondre à THG qui joue toujours fort honnêtement son rôle d'évangéliste assumé , il ne s'agit pas de "pleurer" mais d'émettre des critiques qui ne sont pas destructives. J'ai juste quelques doutes dont je fais part régulièrement et en argumentant et quelques réclamations ma foi bien justifiées puisque je suis un client qui a déjà cotisé largement au chiffre d'affaires d'Adobe. Je revendique en tant que tel le droit d'exprimer de temps en temps mon insatisfaction malgré, encore une fois, le fait que Lightroom (3) est un outil que j'utilise en permanence et pour lequel je ne vois pas de concurrent.

Est-ce plus clair?

Complètement d'accord !! Avant d'ajouter des fonctions, il faut toujours s'assurer de faire disparaître les anciens bugs et de ne pas (trop) en rajouter de nouveaux. Pour ma part, j'attends avec impatience que LR 4.1 corrige des bugs de la 3.6 (notamment concernant les services de publications) et me permette de garder mes anciennes images à l'identique (notamment concernant les courbes). (La RC2 semble aller dans ce sens, mais elle n'est pas officielle)

[THG]

Complètement d'accord !! Avant d'ajouter des fonctions, il faut toujours s'assurer de faire disparaître les anciens bugs et de ne pas (trop) en rajouter de nouveaux. Pour ma part, j'attends avec impatience que LR 4.1 corrige des bugs de la 3.6 (notamment concernant les services de publications) et me permette de garder mes anciennes images à l'identique (notamment concernant les courbes). (La RC2 semble aller dans ce sens, mais elle n'est pas officielle)

euh... les nouvelles fonctions, c'est VOUS, les utilisateurs, qui les réclamez. s'il y avait moins de nouveautés, qu'est ce qu'on n'entendrait pas...

[samlawry]

euh... les nouvelles fonctions, c'est VOUS, les utilisateurs, qui les réclamez. s'il y avait moins de nouveautés, qu'est ce qu'on n'entendrait pas...

Pas la peine de m'inclure, je ne demandais rien à part la stabilisation de certains trucs hein ? Et elle n'est pas gratuite cette mise à jour ?

[ambre099]

euh... moi je veux une gomme

[THG]

Pas la peine de m'inclure, je ne demandais rien à part la stabilisation de certains trucs hein ? Et elle n'est pas gratuite cette mise à jour ?

et demain, quand tu iras bosser, ce sera gratuitement ?

[lawre51]

Lightroom est clairement un logiciel de haut niveau comparé à la concurrence...Du moins celle que je connaisse (DPP, Dxo).
Imaginer qu'Adobe ai pu commettre un choix déraisonné sur ...on ne sait pas quoi finalement me parait vraiment osé. Pat parle de soupçons sans preuve .....

Alors c'est vrai qu'il y a une vraie lourdeur avec LR4, moi qui ai investit dans le top hardware...Je le vois tous les jours....le disque travail à fond rien qu'au démarrage.....

Et je dirais à Pat, que s'il y a un marché, Adobe a les capacités de refondre l'architecture du programme si besoin est!
Je me suis déjà tapé une refonte d'un de mes programmes (12000 lignes de code) en 3 mois...Alors j'imagine qu'une équipe d'expert ne restera pas sur le carreau comme le prétends Pat. Adobe n'est pas un petit éditeur!

Mais je pense sincèrement que la base des algos sont à la pointe et c'est ça qui compter finalement. Pat a un préjugé mais finalement il l'utilise tous les jours.

Lightroom a une philosophie bien à part, avec ses corrections paramétriques. c'est un avantage ou un inconvénient puisqu'avec ce choix, tout outil U-Point , calque n'est pas envisageable. Peut être un handicap à terme....C'est peut être de cela que parle PAT.

Néanmoins,je pense qu'il est bien construit (vu les résultats), complet mais au prix d'une certaine lourdeur sur des config  à la traine.

Le seul reproche que je ferais c'est la mise en production un peu trop hâtive, avec un essai grandeur nature sur le parc des clients....Une des raisons qui me fait fuir les RC....Mais l'enjeu est de taille vis à vis de la concurrence.

[samlawry]

et demain, quand tu iras bosser, ce sera gratuitement ?

C'est quoi ce parallèle à deux balles ?

[THG]

C'est quoi ce parallèle à deux balles ?

écoute, si l'arrivée de 4.1 te pose un problème existentiel, voici ce que je te propose, pendant qu'Adobe peaufine les derniers réglages :
- prévois un weekend avec madame et les enfants
- emmène ton réflex pour faire quelques photos
- trempe toi les pieds dans l'eau pour la circulation
- etc

parce que en attendant, c'est toi qui a posé la question au départ et, là, on a deux cas possibles :
1) La mise à jour se fait attendre, c'est pas normal, qu'est ce qui foutent
OU
2) La mise à jour est déjà là, mais les bugs sont à moitié corrigés, c'est pas normal, qu'est ce qui foutent

En attendant, 4.1 c'est :
- Une liste de bugs corrigés
- De nouveaux outils

Et malgré ça, il y en a qui arrivent à ne pas être contents...

[THG]

Enfin, comme je l'ai laissé entendre un peu plus tôt aujourd'hui, la version 4.1 sortira conformément aux habitudes de mise à jour de Lightroom et Camera Raw.

[Reflexnumerick]

j'ai LR 3.6. LR 4 ça rame vraiment plus en comparaison ? mon outil informatique : Intel Core 2 Quad Q8200, 8 go mémoire.

[Pat91]

Pat parle de soupçons sans preuve .....

Ce n'est pas tout à fait ça. Je peux clairement prouver qu'Adobe ne fait pas de tests de régression ou ne les fait pas correctement. Ce point ne mérite même pas une discussion tellement c'est évident. Je peux également montrer, dans une discussion technique avec un développeur (ce qui n'a pas lieu d'être ici), que LR ne se comporte pas de manière orthodoxe. J'ai des idées sur ce qui provoque ces dysfonctionnements (et ces lenteurs) et c'est ça que je ne peux pas démontrer, n'ayant accès ni au code, ni à des documents architecturaux précis.

Par exemple : j'ai lu que 40% du code de LR est écrit en LUA, langage interprété (le reste, dont très probablement le moteur de dématriçage, est écrit en C/C++). C'est un choix très surprenant pour un programme fondamentalement orienté calcul. Même en admettant que les parties critiques soient écrites en C/C++, on voit mal ce qu'un langage de scripting interprété vient faire dans le décor. Ceux qui disposent d'une configuration puissante sont naturellement moins affectés. Cela peut expliquer les différences perçues par les utilisateurs.

Autre exemple : le choix du moteur de base de données. Il y a des solutions plus performantes (et de loin) que SQLite. Là aussi, le choix est surprenant, surtout quand on ne voit pas comment expliquer les différences de performances entre LR et Camera RAW autrement que par les tâches supplémentaires effectuées en parallèle par LR : la mise à jour permanente du catalogue et le recalcul des aperçus.

Imaginer qu'Adobe ai pu commettre un choix déraisonné sur ...on ne sait pas quoi finalement me parait vraiment osé.

Si un éditeur de logiciel est capable de bâcler la partie assurance qualité (c'est le cas pour LR et c'est probablement un choix délibéré pour cause politique/économique), il est également capable de faire des choix politiques peu judicieux en termes d'architecture, éventuellement contre l'avis des développeurs - et j'ai eu sur ce point quelques retours très clairs d'un des développeurs de l'équipe lors d'échanges privés). Donc je n'ose rien du tout, je parle d'expérience, ayant vécu des situations similaires chez d'autres "grands" éditeurs ou chez des sociétés de service travaillant pour eux.

On en revient toujours au même problème : il est naïf de croire qu'une société de renom fait systématiquement des choix basés sur le bon sens technique. Rien n'est plus faux car ce sont le calendrier et les financiers qui de nos jours, dictent unilatéralement leur loi aux ingénieurs. Chez Adobe comme chez beaucoup d'autres.

[Pat91]

Pourquoi n'essaierais tu pas d'en parler aux développeurs, avec un descriptif le plus précis possible ?

J'ai déjà eu ce type d'échanges en privé avec un des développeurs de LR - non, je ne dirai pas qui - et il avait à l'époque parfaitement reçu mes arguments et remarques. J'ai cependant cru comprendre (je dois encore avoir ses messages en archive) qu'il y avait quelques tiraillements entre ce que les développeurs souhaiteraient faire (ou défaire) et le management qui leur imposait certains choix dictés par des considérations non techniques.

Il y a dans ce monde du logiciel des relations complexes entre 4 groupes d'acteurs:

- les utilisateurs : ils vivent des expériences diverses, sont satisfaits ou non, ne peuvent en général que constater (ou non) les problèmes.
- les développeurs : qui souvent voudraient être libres de leurs choix techniques et ne le sont pas en pratique.
- les marketeurs : qui ne sont motivés que par les profits et ne se préoccupent de qualité que lorsque sa dérive peut affecter ceux-ci.
- les évangélistes : qui font en général un bon travail de soutien aux utilisateurs mais s'interposent quand le problème n'est pas lié à une mauvaise pratique de l'utilisateur mais à un défaut du produit. Jeff Schewe en est un bon exemple (compétentissime mais fanatique).

Les rapports de force entre ces groupes ne sont plus aussi équilibrés qu'ils le furent dans le passé (et pas seulement chez Adobe). Les causes les plus évidentes en sont l'absence de compétiteurs, une politique de profit immédiat, un déficit de vision à long terme et une incompréhension totale du fait que la qualité est la meilleure garantie pour des revenus et des économies à long terme (et je pense ici en particulier aux méthodologies de développement modernes qui permettent un contrôle de qualité pendant le développement et non pas après coup). En ce qui concerne Adobe, leur politique de qualité au début des années 90 était totalement différente. Elle a fait leur réputation. Maintenant ils en vivent et oublient un peu leurs fondamentaux d'il y a 20-25 ans...

[Jc.]

j'ai LR 3.6. LR 4 ça rame vraiment plus en comparaison ? mon outil informatique : Intel Core 2 Quad Q8200, 8 go mémoire.

Tu ne devrais pas sentir de différence "agaçante"...

[Manu_14]

...Les causes les plus évidentes en sont l'absence de compétiteurs, une politique de profit immédiat, un déficit de vision à long terme et une incompréhension totale du fait que la qualité est la meilleure garantie pour des revenus et des économies à long terme...

Si cet état d'esprit était confiné aux éditeurs de logiciels, le monde serait plus gai...

[lawre51]

Pat tu en veux à Adobe.

Crois tu sincèrement qu'il n'y ai pas la même logique chez DXo? Que derrière ce grand laboratoire il n'y a que des idées et pas de contraintes financières.....Oui chez Adobe comme chez les autres il y a ce compromis...Cela ne signifie en rien que le travail soit bâclé.

Maintenant le choix du langage interprété n'est pas des plus judicieux. La micro machine passe son temps à traduire les micros instructions à la volée....Avec la quantité de donnée qui transitent entre les étages du pipeline, des registres et de la mémoire, le programme est plus tributaire de la couche soft que matériel.
Sur ce point je suis d'accord avec toi.

On peux s'interroger aujourd'hui sur le choix du SQLlite. Mais dans le cadre d'une application qui n'utilise pas de base de donnée décentralisée, le SQLite  permet un meilleur accès aux données  totalement indépendant de la plateforme, tout en ne portant pas atteinte à la facilité de déploiement de l'application qui l'utilise.
la latence d'accès aux données est ainsi réduite car la liaison entre LR et son catalogue est direct, sans SGBD lourd et coûteux comme par exemple le système client /serveur.
La plateforme.net propose de belles évolutions,notamment avec les nouveaux espaces de noms, parions que, demain, Lightroom réorientera son moteur de base de donnée.

cyril

[Pat91]

Pat tu en veux à Adobe.

Ah non! THG me joue déjà ce refrain depuis plusieurs années, parfois assorti de la variante "théorie du complot". Dans ce monde du tout ou rien et du blanc ou noir, il faut toujours être pour ou contre. Je ne fonctionne pas comme ça. J'ai toujours dit que Lightroom et Photoshop étaient des logiciels sans vrais concurrents. Je me contente de critiquer certaines pratiques commerciales et certains choix techniques discutables. Je n'en veux pas à Adobe en général mais je regrette que certaines personnes chez Adobe prennent des décisions qui vont à l'encontre d'une politique de la qualité (et ce probablement contre l'avis des développeurs).

Cela ne signifie en rien que le travail soit bâclé.

Quand je dis que le contrôle qualité est bâclé, ce n'est pas en me basant sur ce que je pense de la politique marketing d'Adobe. Ce n'est pas une supposition, c'est un fait démontrable. Quand un bug n'est pas présent dans une version bêta et qu'il apparaît dans la release officielle, c'est la preuve indiscutable que les tests de régression adéquats n'ont pas été faits. Le (gros) bug de la RC2 relatif à la visualisation en mode double écran est un autre exemple du même type. Si le passage d'une RC1 à une RC2 introduit de nouveaux bugs, il y a de toute évidence quelque chose de non maîtrisé dans la méthode de travail. Il y a eu beaucoup d'autres cas similaires avec Lightroom. Quand un bug persiste d'une version majeure à une autre, on peut également être sûr qu'il y a un problème dans le cycle de développement.

On peux s'interroger aujourd'hui sur le choix du SQLlite. Mais dans le cadre d'une application qui n'utilise pas de base de donnée décentralisée, le SQLite  permet un meilleur accès aux données  totalement indépendant de la plateforme, tout en ne portant pas atteinte à la facilité de déploiement de l'application qui l'utilise.
la latence d'accès aux données est ainsi réduite car la liaison entre LR et son catalogue est direct, sans SGBD lourd et coûteux comme par exemple le système client /serveur.
La plateforme.net propose de belles évolutions,notamment avec les nouveaux espaces de noms, parions que, demain, Lightroom réorientera son moteur de base de donnée.

J'ai toujours été dubitatif sur la capacité de SQLite à fonctionner correctement dans un environnement multithreads et Lightroom utilise de toute évidence de nombreux fils d'exécution (et on peut d'ailleurs mettre en évidence de temps en temps des problèmes de synchro). SQLite n'est déjà pas capable de fonctionner en accès multiples, c'est dire (c'est d'ailleurs la raison pour laquelle Adobe interdit l'utilisation d'un disque réseau pour stocker les catalogues). Il y a d'autres solutions locales performantes et probablement mieux adaptées.

Je suis d'accord sur la remarque concernant .Net. C'est portable et cette technologie présente un gros avantage sur LUA : lors de la compilation initiale à la première exécution, le framework .Net produit directement du code machine et pas des byte codes interprétables par une runtime. De plus, .Net permet la mise en oeuvre très facile de méthodologies de test modernes comme le TDD (Test Driven Development). Cette approche permet de détecter la majorité des bugs pendant le développement et non pas chez le client. Mais la majorité des développeurs à qui je l'ai enseignée m'a toujours tenu le même discours : c'est très bien mais ça allonge le cycle de développement. Et quand je leur expliquai qu'à moyen terme cela faisait gagner du temps (moins de recherches stériles en cas de bug indétecté) et de l'argent (beaucoup moins de support client), la réponse était toujours la même : le marketing veut que le produit soit prêt le plus tôt possible. Donc vision à court terme et profit immédiat sont favorisés au détriment du bénéfice à long terme, de la qualité et de la satisfaction client.

PS : dans les temps glorieux où je faisais partie des "Microsoft MVP" et où j'enseignais de temps en temps chez un formateur bien connu, j'ai connu un Cyril qui s'occupait de .Net. Coïncidence?

[lawre51]

Non Pat, je ne suis pas ce Cyril!

Je crois savoir que l'équipe de développement n'est pas une grande équipe...Ceci peut peut-être expliquer cela.
Je suis persuadé que Lightroom a un bel avenir, et je crois qu'il y a de plus en plus d'adeptes......Le code source tel qu'il est aujourd'hui évoluera demain et les axes de travail seront sûrement redéfinis. Un logiciel pour vivre, doit être capable d'accomplir cette mutation....ça, tu le sais. Donc je suis confiant sur l'avenir même si je partage partiellement ton analyse sur les choix de codage.

Mais étant donné que je ne connais pas le code source, je me garderais bien de faire la moindre critique structurelle. Je ne peux juger que le comportement du logiciel et je trouve qu'effectivement travailler à une meilleure performance est nécessaire......DXo a eu ce problème avec la version 6. Ils ont corrigé le tir......Soyons confiants.

[THG]

Lua sert essentiellement pour l'interface de Lightroom.

Les raisons de son adoption ont été largement expliquées par les fondateurs du logiciel.

[Pat91]

Lua sert essentiellement pour l'interface de Lightroom.
Les raisons de son adoption ont été largement expliquées par les fondateurs du logiciel.

Explication n'est pas raison et tout dépend de ce que l'on inclut dans le vocable "interface". Ce qu'ils n'ont encore jamais commenté avec précision, ce sont les raisons profondes des différences de performances entre LR et Camera RAW. Je reste extrêmement curieux sur ce point.

[THG]

Explication n'est pas raison et tout dépend de ce que l'on inclut dans le vocable "interface". Ce qu'ils n'ont encore jamais commenté avec précision, ce sont les raisons profondes des différences de performances entre LR et Camera RAW. Je reste extrêmement curieux sur ce point.

ah bon ?

ce n'est pourtant guère compliqué : ACR n'est pas assis sur une base de données, et la mise ne cache de certaines opérations - là où c'est possible - n'est certainement pas la même.

[Pat91]

ah bon ?
ce n'est pourtant guère compliqué : ACR n'est pas assis sur une base de données, et la mise ne cache de certaines opérations - là où c'est possible - n'est certainement pas la même.

Eh bien justement. C'est là que nous revenons aux messages précédents : si le simple fait de mettre à jour le catalogue et l'historique justifie de tels écarts, c'est qu'il y a un problème massif au niveau du SGBD (SQLite). J'exclus la mise à jour des XMP puisque l'écart est présent même si la mise à jour automatique des XMP est désactivée.

Chaque opération de correction ne nécessite que quelques kilooctets à stocker dans un champ de la base de données. Cela ne prend qu'un temps ridiculement court par rapport aux opérations de calcul qui découlent de cette correction (en particulier quand le nombre de corrections locales augmente car c'est là que les écarts avec Camera RAW sont les plus flagrants). C'est là (entre autres choses) que je soupçonne une erreur de conception ou de codage. Comme par exemple une erreur assez fréquente qui consiste à ouvrir et à fermer la base de données à chaque accès pour des raisons de sécurité au lieu de la garder ouverte en permanence. Erreur très fréquente qui allonge considérablement les temps de réponse.

Cela peut également être un choix délibéré parce que SQLite n'est pas sûr en multithreading. De ce fait, cela ne serait plus une erreur mais une obligation : si plusieurs fils d'exécution dans Lightroom ont besoin d'accéder simultanément à la base de données - ce qui arrive tout le temps - et que les développeurs n'ont pas confiance, ils ont pu décider d'ouvrir et de fermer systématiquement après usage pour sécuriser les accès. Dans ce cas, le temps consacré à la manipulation des données via SQLite devient infiniment plus long (en programmation, le coût en temps de l'ouverture d'une connexion sur une base de données même locale est considérable par rapport au temps nécessaire pour une simple lecture ou une écriture dans un champ une fois la base ouverte). Je serais également curieux de savoir au travers de quelle couche logicielle la connexion sur la base de données est effectuée via le programme principal. Là également, il peut y a avoir des écarts massifs selon la technologie utilisée.

Je pense que l'on pourrait vérifier cela assez facilement avec les outils adéquats (qui n'ont plus droit de cité chez moi ). Encore une fois, je ne peux pas affirmer mais je constate : il y a un écart important et il n'est pas, à mon sens, justifié.

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.

On pourrait cependant travailler comme avec les disques durs : en écriture les données sont mises en cache en mémoire et envoyées physiquement sur le disque quand on n'a rien d'autre à faire. S'il y a une coupure de courant ou un crash, il y a un risque de perte des données créées récemment. Mais ce n'est pas toi qui va arguer que LR se plante tout le temps, non ? Et on pourrait de toute façon ajouter une commande de sauvegarde (flush des données) que l'on pourrait activer de temps en temps (éventuellement automatiquement à intervalles réguliers) pour préserver le travail en cours.

Juste une idée...

[kaf]

Eh bien justement. C'est là que nous revenons aux messages précédents : si le simple fait de mettre à jour le catalogue et l'historique justifie de tels écarts, c'est qu'il y a un problème massif au niveau du SGBD (SQLite). J'exclus la mise à jour des XMP puisque l'écart est présent même si la mise à jour automatique des XMP est désactivée.

Chaque opération de correction ne nécessite que quelques kilooctets à stocker dans un champ de la base de données. Cela ne prend qu'un temps ridiculement court par rapport aux opérations de calcul qui découlent de cette correction (en particulier quand le nombre de corrections locales augmente car c'est là que les écarts avec Camera RAW sont les plus flagrants). C'est là (entre autres choses) que je soupçonne une erreur de conception ou de codage. Comme par exemple une erreur assez fréquente qui consiste à ouvrir et à fermer la base de données à chaque accès pour des raisons de sécurité au lieu de la garder ouverte en permanence. Erreur très fréquente qui allonge considérablement les temps de réponse.

Cela peut également être un choix délibéré parce que SQLite n'est pas sûr en multithreading. De ce fait, cela ne serait plus une erreur mais une obligation : si plusieurs fils d'exécution dans Lightroom ont besoin d'accéder simultanément à la base de données - ce qui arrive tout le temps - et que les développeurs n'ont pas confiance, ils ont pu décider d'ouvrir et de fermer systématiquement après usage pour sécuriser les accès. Dans ce cas, le temps consacré à la manipulation des données via SQLite devient infiniment plus long (en programmation, le coût en temps de l'ouverture d'une connexion sur une base de données même locale est considérable par rapport au temps nécessaire pour une simple lecture ou une écriture dans un champ une fois la base ouverte). Je serais également curieux de savoir au travers de quelle couche logicielle la connexion sur la base de données est effectuée via le programme principal. Là également, il peut y a avoir des écarts massifs selon la technologie utilisée.

Je pense que l'on pourrait vérifier cela assez facilement avec les outils adéquats (qui n'ont plus droit de cité chez moi ). Encore une fois, je ne peux pas affirmer mais je constate : il y a un écart important et il n'est pas, à mon sens, justifié.

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.

On pourrait cependant travailler comme avec les disques durs : en écriture les données sont mises en cache en mémoire et envoyées physiquement sur le disque quand on n'a rien d'autre à faire. S'il y a une coupure de courant ou un crash, il y a un risque de perte des données créées récemment. Mais ce n'est pas toi qui va arguer que LR se plante tout le temps, non ? Et on pourrait de toute façon ajouter une commande de sauvegarde (flush des données) que l'on pourrait activer de temps en temps (éventuellement automatiquement à intervalles réguliers) pour préserver le travail en cours.

Juste une idée...

Sauf que ce genre d'idée sort largement du domaine de compétence du public ciblé par LR. Le photographe lambda n'a aucune idée de ce qu'est un sgbdr, encore moins de ce que représente une connexion ou une transaction. Lui demander de les gérer lui-même (parce que c'est en gros ce que tu proposes) ne pourrait mener qu'à la confusion ou pire, à la perte d'information. Je ne connais pas le fonctionnement en interne de LR, et il y a certainement des choses améliorables côté performances, mais je ne crois pas que les choses soient aussi simples que tu sembles le penser. Ne serait-ce que parce que l'utilisateur du logicien n'est pas informaticien mais photographe!

[Pat91]

Lui demander de les gérer lui-même (parce que c'est en gros ce que tu proposes) ne pourrait mener qu'à la confusion ou pire, à la perte d'information.

Ne tombons pas dans la caricature et n'exagérons rien . J'ai bien dit que la sauvegarde décalée peut être automatisée. C'est d'ailleurs exactement ce qui se passe, encore une fois, avec les disques durs. On ne demande pas à l'utilisateur de gérer lui-même le flush des écritures décalées. Cela est réalisé automatiquement de manière régulière quand l'utilisateur est inactif ou que l'on ferme la session ou que l'on arrête (proprement) le système. On ne demande pas à l'utilisateur de devenir informaticien pour ça. Rien de ce que je propose ci-dessus n'implique nécessairement une contrainte supplémentaire pour l'utilisateur.

[kaf]

Rien de ce que je propose ci-dessus n'implique nécessairement une contrainte supplémentaire pour l'utilisateur.

Ben si tu ajoutes un bouton pour vider le cache manuellement, immanquablement, les gens vont se demander pourquoi et ne comprendront rien

Par contre, je pense que certaines choses pourraient être améliorées aussi, mais trouver le juste équilibre entre performances et sécurité est difficile!

[Pat91]

Ben si tu ajoutes un bouton pour vider le cache manuellement, immanquablement, les gens vont se demander pourquoi et ne comprendront rien

Disons que je retire cette proposition malvenue, typique d'un développeur , et que l'on reste sur le principe d'un automatisme. Mais ça ne change rien à ma proposition : décaler complètement la mise à jour de la base de données dans le temps au lieu de mettre à jour en temps réel. À partir du moment où la migration vers le 64-bit commence à se généraliser, occuper quelques kiloctets de plus en mémoire pour cacher ces infos ne portera pas à conséquence. Au point où nous en sommes...

Cette idée ne fait d'ailleurs que prolonger la recommandation qui est déjà faite de ne pas activer la sauvegarde automatique des XMP, justement à cause de l'impact sur les performances. Ce mécanisme (la mise à jour d'un fichier XML) pose en fait exactement la même problématique. C'est un processus lent par nature.

En fait, je suppose qu'il y a déjà une sorte de temporisation dans LR mais elle est très courte si j'en juge par les données que je récupère quand Lightroom se crashe sur mon système. En général, je retrouve les choses en l'état quand je relance. Si la fréquence des crashes diminue, je peux admettre de perdre quelques données de temps en temps à cause d'une mise à jour décalée dans le temps si je récupère en contrepartie de la performance.

[lawre51]

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.
Juste une idée...

J'ai une  approche qui suit la tendance actuelle.....Travailler en mode déconnecter. Le framework 4.0 fournit le DataSet, PiecesTableAdapter, l'objet Command et connexion etc etc.....
L'idée est de charger les données, réaliser un container xml afin de stocker tout ça, puis demander une nouvelle connexion afin de mettre à jour vers la BDD. En assurant une gestion multi-accès sécurisée. On minimise les accès à la BDD, on garantit un niveau de sécurité etc etc

Donc c'est exactement celle que tu évoques Pat en libérant le processus d'une écriture lecture à la BDD permanente.
Je suis juste un petit amateur, et je peux me planter.

[Pat91]

J'ai une  approche qui suit la tendance actuelle.....Travailler en mode déconnecter. Le framework 4.0 fournit le DataSet, PiecesTableAdapter, l'objet Command et connexion etc etc.....
...
Je suis juste un petit amateur, et je peux me planter.

Pas du tout. C'est une des approches que j'ai enseignées aux développeurs qui fréquentaient mes cours .Net. Le Dataset de .Net est en fait une mini base de données en mémoire que l'on peut strictement limiter aux données dont on a besoin. C'est une approche tout à fait en phase avec ce que je propose. Mais elle suppose qu'Adobe adopte le framework .Net .

Il y a à l'encontre de cette technologie des a priori bien regrettables. D'abord, certains la rejettent d'emblée puisqu'elle vient de Microsoft. Ensuite, beaucoup pensent qu'elle n'est pas portable sur les plates-formes non Windows (et découvrent avec surprise qu'elle est disponible pour Mac et Linux et d'autres plates-formes et que c'est une technologie ouverte - toutes les spécifications sont disponibles -). Le framework .Net est pourtant ce que j'ai vu de plus intelligent et de plus abouti comme technologie de développement depuis que j'ai commencé à coder, ce qui remonte à la fin des années 70. DxO l'a d'ailleurs adoptée mais seulement partiellement, ce qui compromet un certain nombre des avantages qui lui sont liés. Enfin, la mise en oeuvre de méthodologies de test modernes et performantes est particulièrement aisée sur ce framework. Tout cela relègue LUA et consorts aux poubelles de l'histoire informatique. Mais que faire contre les préjugés ?

[kaf]

Pas du tout. C'est une des approches que j'ai enseignées aux développeurs qui fréquentaient mes cours .Net. Le Dataset de .Net est en fait une mini base de données en mémoire que l'on peut strictement limiter aux données dont on a besoin. C'est une approche tout à fait en phase avec ce que je propose. Mais elle suppose qu'Adobe adopte le framework .Net .

Il y a à l'encontre de cette technologie des a priori bien regrettables. D'abord, certains la rejettent d'emblée puisqu'elle vient de Microsoft. Ensuite, beaucoup pensent qu'elle n'est pas portable sur les plates-formes non Windows (et découvrent avec surprise qu'elle est disponible pour Mac et Linux et d'autres plates-formes et que c'est une technologie ouverte - toutes les spécifications sont disponibles -). Le framework .Net est pourtant ce que j'ai vu de plus intelligent et de plus abouti comme technologie de développement depuis que j'ai commencé à coder, ce qui remonte à la fin des années 70. DxO l'a d'ailleurs adoptée mais seulement partiellement, ce qui compromet un certain nombre des avantages qui lui sont liés. Enfin, la mise en oeuvre de méthodologies de test modernes et performantes est particulièrement aisée sur ce framework. Tout cela relègue LUA et consorts aux poubelles de l'histoire informatique. Mais que faire contre les préjugés ?

+1

[lawre51]

Patrick,

Pourquoi écris tu "Pas du tout " puisque c'est une approche tout à  fait en phase avec ce que tu proposes.

Oui, le jeu de résultat de la requête d'un objet DataSet ADO.NET peut être recrée à partir d'un flux ou d'un document XML pourvu qu'il ai été mappé vers ce document standard.

[Pat91]

Pourquoi écris tu "Pas du tout " puisque c'est une approche tout à  fait en phase avec ce que tu proposes.

C'est simplement la réponse à l'affirmation : "Je suis juste un petit amateur, et je peux me planter.".

[geraldb]

J'ai installer la version 4.1 RCII sur la 4.0, pas de problèmes
remarqués à ce jour, catalogue en place, 2ème écran sans
problème.
Il me semblerait que c'est plus rapide, est-ce subjectif!
Par contre, pas de boite de dialogue à l'ouverture, jusqu'à
quelle date est-elle valable...