LR 5, problème bi-écran

Démarré par fouyas, Mars 09, 2014, 19:31:03

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

fouyas

Mars 09, 2014, 19:31:03
Salut à vous,
je rencontre un problème dans la gestion du bi-écran de Lightroom depuis quelques temps ( peut être depuis la version 5.2 ou 5.3 ).
Lors du développement, la photo sur l'écran secondaire qui est en mode loupe est flou ! j'ai l'impression que le rafraîchissement ne se fait pas toujours.
Est ce que certains d'entre ont aussi ce problème ?
Merci de votre aide,
A++

Dub

#1
Mars 09, 2014, 20:48:51
Oui , de temps en temps ...
(LR 5.3 Mac 10.8.5)

;)

fouyas

#2
Mars 09, 2014, 22:04:15
Merci de ta réponse Dub :) Moi Mac OS 10.9.2 et LR 5.3 CC

Ca craint quand même, je viens de tomber sur des post de personnes qui ont ce problème depuis aout 2013... pas pressé de résoudre les bugs chez Adobe depuis qu'ils ont les utilisateurs sagement abonné !

http://forums.adobe.com/message/5837287

http://feedback.photoshop.com/photoshop_family/topics/second_monitor_initially_not_rendering_image_clearly

titroy

#3
Mars 09, 2014, 22:36:24
Oui et ce n'est pas drôle  ::)

Youssef

#4
Mars 10, 2014, 09:16:38
Je n'ai pas rencontré ce problème.
LR5.3 et OSX10.9

THG

#5
Mars 10, 2014, 09:48:13
Les bugs ça ne se corrige pas en un coup de baguette magique, surtout quand il affecte peu d'utilisateurs et, donc, difficile à reproduire et à cerner.

fouyas

#6
Mars 10, 2014, 10:51:33 Dernière édition: Mars 10, 2014, 10:57:53 par fouyas
Citation de: THG le Mars 10, 2014, 09:48:13
Les bugs ça ne se corrige pas en un coup de baguette magique, surtout quand il affecte peu d'utilisateurs et, donc, difficile à reproduire et à cerner.
C'est amusant comme remarque... si une boite comme Adobe n'arrive pas à corriger un problème de rafraichissement qui n'existait pas avant et dure depuis plus de 6 mois, il faut vraiment changer de développeurs. D'autres part, je ne pense pas que deux écrans de nos jours pour des outils tels que Photoshop et Lightroom soit si rare, c'est vraiment une fonctionnalité importante. Et pour la baguette magique, ils ont ce qu'il faut dans Photoshop  ;)

Malheureusement, c'est toute l'industrie de l'informatique et du logiciels qui part un peu en brioche depuis quelques années et fait de l'à peu près le plus naturellement du monde.

fouyas

#7
Mars 10, 2014, 12:33:40
Citation de: Youssef le Mars 10, 2014, 09:16:38
Je n'ai pas rencontré ce problème.
LR5.3 et OSX10.9
Ok, tant mieux :-) Moi ça a commencé par intermittence puis c'est devenu quasi permanent malgré une ré-installation. Un peu comme le soucis de Photoshop qui de temps en temps n'importe plus les images venant de LR et s'ouvre vide. ( Un post est ouvert là dessus par un autre utilisateur )

Samoreen

#8
Mars 10, 2014, 14:00:41
Citation de: fouyas le Mars 10, 2014, 10:51:33
C'est amusant comme remarque... si une boite comme Adobe n'arrive pas à corriger un problème de rafraichissement qui n'existait pas avant et dure depuis plus de 6 mois, il faut vraiment changer de développeurs. D'autres part, je ne pense pas que deux écrans de nos jours pour des outils tels que Photoshop et Lightroom soit si rare, c'est vraiment une fonctionnalité importante. Et pour la baguette magique, ils ont ce qu'il faut dans Photoshop  ;)

J'ai aussi ce problème, comme beaucoup d'autres utilisateurs. Je suis d'accord avec cette remarque car elle signale une fois de plus que chez Adobe, une des étapes du développement moderne n'est pas maîtrisée : les test de régression. Les méthodologies actuelles de développement permettent de déterminer facilement à quel moment un bug a été introduit, de revenir tout aussi facilement à l'état précédent et d'analyser dans le code les différences entre "avant" et "après". Encore faut-il utiliser les outils adéquats et admettre l'idée que le "temps perdu" à mettre ces méthodologies en oeuvre est très largement récupéré par la diminution du travail qui retombe sur le support utilisateurs et sur le temps passé à identifier les bugs tout en améliorant la qualité générale.

Il n'est pas nécessaire de faire partie de l'équipe de développement d'Adobe pour se rendre compte qu'Adobe n'utilise pas ces techniques. À chaque nouvelle version majeure, la succession rapide des mises à jour le démontre à l'évidence ainsi que quelques autres signes qui ne trompent pas le développeur ayant un minimum d'expérience.

L'inconvénient de cette lacune pour l'utilisateur est qu'au bout d'un moment, les développeurs se "découragent" et ne cherchent plus. Chez Adobe comme chez d'autres éditeurs, une fois qu'un bug a dépassé un certain âge et survit à une ou deux nouvelles versions majeures, il a de très grosses chances de passer dans la catégorie de ce que j'ai souvent appelé les "bugs permanents" qui ne seront jamais corrigés parce que personne ne cherche plus à les corriger. Lightroom possède déjà une belle collection de bugs permanents qui font maintenant partie de son histoire. Ce ne sont plus des bugs mais des marques de fabrique.

Espérons que ce ne sera pas le destin de ce bug particulier (qui soit dit en passant se reproduit aisément sur la plupart des machines auxquelles j'ai accès).
Patrick

fouyas

#9
Mars 10, 2014, 21:10:38
Citation de: Samoreen le Mars 10, 2014, 14:00:41
...Espérons que ce ne sera pas le destin de ce bug particulier (qui soit dit en passant se reproduit aisément sur la plupart des machines auxquelles j'ai accès).
J'espère vraiment également car c'est très pénible. Comme le niveau de flou n'est pas toujours très marqué, j'ai pensé pendant un moment manquer beaucoup de MAP, étant en 1:1 sur l'écran bis des fois, uhuhuh ...  ::)

titroy

#10
Mars 10, 2014, 23:09:28
Citation de: fouyas le Mars 10, 2014, 21:10:38
J'espère vraiment également car c'est très pénible. Comme le niveau de flou n'est pas toujours très marqué, j'ai pensé pendant un moment manquer beaucoup de MAP, étant en 1:1 sur l'écran bis des fois, uhuhuh ...  ::)
Bien d'accord avec toi.

THG

#11
Mars 11, 2014, 08:14:18
Citation de: fouyas le Mars 10, 2014, 10:51:33
C'est amusant comme remarque... si une boite comme Adobe n'arrive pas à corriger un problème de rafraichissement qui n'existait pas avant et dure depuis plus de 6 mois, il faut vraiment changer de développeurs. D'autres part, je ne pense pas que deux écrans de nos jours pour des outils tels que Photoshop et Lightroom soit si rare, c'est vraiment une fonctionnalité importante. Et pour la baguette magique, ils ont ce qu'il faut dans Photoshop  ;)

Malheureusement, c'est toute l'industrie de l'informatique et du logiciels qui part un peu en brioche depuis quelques années et fait de l'à peu près le plus naturellement du monde.

Dans ce cas, il ne faut pas hésiter à leur proposer ses compétences avec un CV :-)

fouyas

#12
Mars 11, 2014, 09:17:58
Citation de: THG le Mars 11, 2014, 08:14:18
Dans ce cas, il ne faut pas hésiter à leur proposer ses compétences avec un CV :-)
J'ai déjà donné dans le dev durant 10 ans ...  ;)

Samoreen

#13
Mars 11, 2014, 12:30:55
Citation de: THG le Mars 11, 2014, 08:14:18
Dans ce cas, il ne faut pas hésiter à leur proposer ses compétences avec un CV :-)

Le problème est que les décisions ne sont pas prises par les développeurs ou les responsables techniques en général. Il faut bien comprendre que le développement logiciel est confronté à 2 stratégies générales opposées :

- La première consiste à utiliser des outils de développement rapide qui permettent de sortir du code plus vite mais qui sont souvent incapables de mettre en œuvre une séparation efficace de l'interface et des traitements ainsi qu'une approche dite TDD (Test Driven Developement) qui permet des tests de régression efficaces. La conséquence est double : déport des tests chez l'utilisateur et augmentation du coût du support. En bref, on lâche un logiciel pas fini et on parie sur un faible nombre de bugs que l'utilisateur pourra supporter pendant un certain temps.

- La seconde consiste à passer plus de temps en développement en utilisant des technologies de test modernes réduisant considérablement le nombre de bugs à la sortie des versions initiales. La séparation stricte entre interface utilisateur et traitements internes permet également une évolution plus simple et une grande souplesse d'adaptation à différents environnements. Cette approche coûte plus cher en développement mais est largement amortie par des coûts de maintenance fortement diminués, une satisfaction client plus grande et une évolutivité des logiciels sans comparaison.

Le choix entre ces 2 approches n'est jamais fait par les développeurs ou les chefs de projet mais par les financiers. Et cela ne conernen pas que le software. J'ai enseigné ces méthodes pendant des années, j'ai convaincu des centaines de développeurs mais la mise en œuvre a toujours été bloquée par les financiers qui raisonnent à court terme au lieu de voir les bénéfices plus importants à long terme.
Patrick

THG

#14
Mars 11, 2014, 13:28:56
Citation de: Samoreen le Mars 11, 2014, 12:30:55
Le problème est que les décisions ne sont pas prises par les développeurs ou les responsables techniques en général. Il faut bien comprendre que le développement logiciel est confronté à 2 stratégies générales opposées :

- La première consiste à utiliser des outils de développement rapide qui permettent de sortir du code plus vite mais qui sont souvent incapables de mettre en œuvre une séparation efficace de l'interface et des traitements ainsi qu'une approche dite TDD (Test Driven Developement) qui permet des tests de régression efficaces. La conséquence est double : déport des tests chez l'utilisateur et augmentation du coût du support. En bref, on lâche un logiciel pas fini et on parie sur un faible nombre de bugs que l'utilisateur pourra supporter pendant un certain temps.

- La seconde consiste à passer plus de temps en développement en utilisant des technologies de test modernes réduisant considérablement le nombre de bugs à la sortie des versions initiales. La séparation stricte entre interface utilisateur et traitements internes permet également une évolution plus simple et une grande souplesse d'adaptation à différents environnements. Cette approche coûte plus cher en développement mais est largement amortie par des coûts de maintenance fortement diminués, une satisfaction client plus grande et une évolutivité des logiciels sans comparaison.

Le choix entre ces 2 approches n'est jamais fait par les développeurs ou les chefs de projet mais par les financiers. Et cela ne conernen pas que le software. J'ai enseigné ces méthodes pendant des années, j'ai convaincu des centaines de développeurs mais la mise en œuvre a toujours été bloquée par les financiers qui raisonnent à court terme au lieu de voir les bénéfices plus importants à long terme.

C'est un peu du blabla tout ça, surtout quand on sait que le problème a été rapporté et est bien connu par les concernés.

La réalité est bien plus simple que cela : les problèmes sont traités en fonction de leur priorité, et cette priorité est établie en fonction d'un certain nombre de critères :
- fréquence du problème
- étendue du problème
- capacité à pouvoir reproduire le problème
- impact éventuel du correctif sur d'autres portions du logiciel
- complexité du correctif, menant à la décision de le traiter à long terme, par exemple lors d'une révision majeure, si le risque potentiel sur le reste du logiciel et important

Bref, les histoires de financiers et autres calembredaines font partie des fantasmes des amateurs de théories de conspiration plus ou moins fumeuses, et fortement éloignées de la réalité, cette dernière étant bien plus terre à terre que tu ne le laisses entendre.

Samoreen

#15
Mars 11, 2014, 14:17:48
Citation de: THG le Mars 11, 2014, 13:28:56
Bref, les histoires de financiers et autres calembredaines font partie des fantasmes des amateurs de théories de conspiration plus ou moins fumeuses, et fortement éloignées de la réalité, cette dernière étant bien plus terre à terre que tu ne le laisses entendre.

Je n'ai pas l'habitude de trop la ramener sur mon passé professionnel mais sur ce sujet, il se trouve que j'ai une longue expérience de consultant développement, à l'international, des USA à l'Asie et auprès de sociétés bien plus importantes qu'Adobe. J'ai travaillé sur ou piloté des projets logiciels de loin plus complexes que Lightroom ou Photoshop. Je parle de ce que je connais, de ce que j'ai observé et des avis recueillis auprès des ingénieurs que j'ai formés aux méthodes de développement modernes, pas de fantasmes supposés. Ta compétence dans l'utilisation de Lightroom et d'autres produits logiciels ne te donne pas l'autorité nécessaire pour systématiquement contrer les opinions qui te déplaisent en dénigrant - sans arguments - leurs auteurs et en ressortant encore et toujours les mêmes vieilles scies qui commencent à lasser. En matière de développement, je n'ai pas l'intention de laisser dire que je propage des théories fumeuses et paranoïaques. Surtout pas par toi, tant que tu ne nous as pas parlé de tes compétences dans le domaine du développement logiciel.

Il me semblait que tu avais adopté une attitude plus courtoise et plus ouverte ces derniers temps mais voilà que tu rechutes. Dommage. Si les interventions de membres de ce forum sur des domaines que tu ne maîtrises pas te mettent sur la défensive et te donnent l'impression que l'on piétine ton pré carré, c'est sur toi qu'il faut réfléchir, pas accuser ces personnes de délirer ou de fantasmer. Tu devrais plutôt essayer de comprendre ce que l'on te dit et exercer ta curiosité plutôt que de rejeter. Beaucoup ici seraient prêts à répondre à tes questions.

Et si Adobe, comme tu le laisses entendre parce que tu es si bien informé de ce qui se passe dans l'équipe de développement, se contente de développer en mode "terre à terre" (au jour le jour si je comprends bien) sans mettre en place une stratégie d'évolution vers des méthodologies plus modernes et efficaces, cela ne fait que confirmer mon propos. Le bug signalé dans le post initial touche du monde, est apparu récemment et doit être simple à corriger mais il ne serait pas prioritaire alors que fonctionnellement il est pénalisant? Je pouffe.

Tout développeur ayant un sens de l'observation un rien supérieur à celui d'une huître se rend bien compte de la structure figée de logiciels comme Photoshop qui sont arrivés à un tel point de sclérose que le seul moyen de continuer à les rentabiliser est de forcer les clients à adopter un mode de distribution qui les rend prisonniers. J'ai la naïveté de croire que l'innovation serait plus efficace. Et on pourrait faire des remarques similaires à propos de Lightroom même si ce logiciel en particulier est pour le moment moins touché par l'âge.
Patrick

fouyas

#16
Mars 11, 2014, 14:33:35
Citation de: Samoreen le Mars 11, 2014, 12:30:55
Le problème est que les décisions ne sont pas prises par les développeurs ou les responsables techniques en général. Il faut bien comprendre que le développement logiciel est confronté à 2 stratégies générales opposées :

- La première consiste à utiliser des outils de développement rapide qui permettent de sortir du code plus vite mais qui sont souvent incapables de mettre en œuvre une séparation efficace de l'interface et des traitements ainsi qu'une approche dite TDD (Test Driven Developement) qui permet des tests de régression efficaces. La conséquence est double : déport des tests chez l'utilisateur et augmentation du coût du support. En bref, on lâche un logiciel pas fini et on parie sur un faible nombre de bugs que l'utilisateur pourra supporter pendant un certain temps.

- La seconde consiste à passer plus de temps en développement en utilisant des technologies de test modernes réduisant considérablement le nombre de bugs à la sortie des versions initiales. La séparation stricte entre interface utilisateur et traitements internes permet également une évolution plus simple et une grande souplesse d'adaptation à différents environnements. Cette approche coûte plus cher en développement mais est largement amortie par des coûts de maintenance fortement diminués, une satisfaction client plus grande et une évolutivité des logiciels sans comparaison.

Le choix entre ces 2 approches n'est jamais fait par les développeurs ou les chefs de projet mais par les financiers. Et cela ne conernen pas que le software. J'ai enseigné ces méthodes pendant des années, j'ai convaincu des centaines de développeurs mais la mise en œuvre a toujours été bloquée par les financiers qui raisonnent à court terme au lieu de voir les bénéfices plus importants à long terme.
Tout à fait d'accord, et c'est malheureusement la première approche qui est depuis (trop) longtemps le choix des dirigeants. Il faut sortir un maximum de version même si entre deux ou trois, rien de spécial à se mettre sous le mulot comme innovation.

C'est la même dérive pour le matériel avec une course effrénée vers on ne sait où, des processeurs dépassé dès qu'ils quittent la chaîne de production etc ...

Mais bon, on s'éloigne du sujet principal, revenons à notre Lightroom qui est vraiment un super produit mais avec quelques bugs récalcitrants qui j'ose esperer, seront résolu avant la version 6  ;D

( tiens, j'y pense, si j'essayais avec 3 écrans, ça marche peut être bien sur le 3eme  :D ,bon ça va ... )

Samoreen

#17
Mars 11, 2014, 16:26:52
Citation de: fouyas le Mars 11, 2014, 14:33:35
Mais bon, on s'éloigne du sujet principal, revenons à notre Lightroom qui est vraiment un super produit mais avec quelques bugs récalcitrants qui j'ose esperer, seront résolu avant la version 6  ;D

Je suis bien d'accord que Lightroom est un logiciel qui donne globalement satisfaction. Cela m'incline encore plus à être exigeant et à attirer l'attention sur les carences qui une fois éliminées amélioreraient encore plus sa qualité et la satisfaction des clients.

En ce qui concerne le bug en question, je suis toujours inquiet quand de tels défauts, bien que signalés dès leur apparition, arrivent à survivre à 3 ou 4 releases successives. Statistiquement, plus ils durent, plus ils ont de chances de persister.
Patrick

Samoreen

#18
Mars 11, 2014, 16:48:46
Patrick

fouyas

#19
Mars 11, 2014, 17:46:19
Bonne idée Samoreen, j'y go !

Dub

#20
Mars 11, 2014, 18:00:41
C'est fait ...

J'suis pas du genre "râleur" , mais je suis obligé de faire un aller et retour dans
le module biblio pour "charger" les photos et les avoir nettes dans le module développement ...

:-\

bugati590

#21
Mars 12, 2014, 15:29:44
bonjour

j'ai exactement le même problème que vous
et je suis sous seven !!

parfois l'image apparait nette puis elle devient floue ou alors elle reste floue et devient nette âpres quelques secondes  ???

grrrrr

Fab35

#22
Mars 12, 2014, 16:18:24
Citation de: bugati590 le Mars 12, 2014, 15:29:44
bonjour

j'ai exactement le même problème que vous
et je suis sous seven !!

parfois l'image apparait nette puis elle devient floue ou alors elle reste floue et devient nette âpres quelques secondes  ???

grrrrr

Je suis un newbee sur LR, encore en période d'essai de la version téléchargée chez Adobe. Je vais probablement acheter LR le mois prochain définitivement malgré quelques points agaçants par rapport à ma pratique précédente sous DPP de chez Canon (soft très perfectible mais qui va à l'essentiel).

Je travaille sous 7-64 et sur 2 écrans 24" en 1920x1200 chacun. Carte NVidia.

J'ai constaté un flou temporaire lors de l'affichage des photos, sur les 2 moniteurs, mais sauf erreur, c'est juste le temps nécessaire au dématriçage, donc quelques secondes après, c'est net et exploitable en visu 100%.
Donc ça ne semble pas être exactement le souci soulevé sur ce topic, qui ferait que le 2nd moniteur reste figé sur le flou...
Est ce qu'il pourrait y avoir un lien avec le proco graphique ?

fouyas

#23
Mars 12, 2014, 16:18:40
Citation de: bugati590 le Mars 12, 2014, 15:29:44
...parfois l'image apparait nette puis elle devient floue ou alors elle reste floue et devient nette âpres quelques secondes  ???...
Salut, si au bout de quelques secondes l'image apparait normalement, c'est peut être juste un soucis de performance de ta machine non ? le temps d'afficher un traitement dans LR peut être un peu long selon le cas, particulièrement si ta configuration est peu puissante ou si tu manques un peu de mémoire.

En fait, lors de la manifestation de ce bug, l'image reste perpétuellement flou.

fouyas

#24
Mars 12, 2014, 16:25:37
Citation de: Fab35 le Mars 12, 2014, 16:18:24
...J'ai constaté un flou temporaire lors de l'affichage des photos, sur les 2 moniteurs, mais sauf erreur, c'est juste le temps nécessaire au dématriçage, donc quelques secondes après, c'est net et exploitable en visu 100%.
Donc ça ne semble pas être exactement le souci soulevé sur ce topic, qui ferait que le 2nd moniteur reste figé sur le flou...

Est ce qu'il pourrait y avoir un lien avec le proco graphique ?
C'est exactement ça, le temps de traitement est parfois long et énervant. J'ai un i7 3,5Ghz avec 24 Go de RAM et ce n'est pas hyper fluide. J'attend souvent que l'image s'affiche correctement sur les deux écrans ( 27'' + 30'' ). Je ne sais pas, par contre, si le processeur graphique est utilisé dans les calculs. Sur DxO Optics Pro oui, mais LR franchement je n'en sait rien.
A++
Imprimer
En haut Pages1 2 3 4
Actions de l'utilisateur