Dur dur les commentaires sur DXO

[frede]

Je m'explique:
J'ai téléchargé la version d'essai 14 jours 5.2.1 build 7024. Aucun pb. Je l'ai installé sans problème.Depuis 8 jours elle tourne toujours sans pb et les résultats sont satisfaisants  (du moins pour ce qui est visible des formats 40X60). Les fichiers RAW ou JPEG de mon D300 me paraissent correctement traités pour ce qui de la géometrie , lumière , couleurs. Bilan satisfaisant.

J'en suis à me demandé si je ne vais pas l'acheter (demander la clé numérique du moins).
Par acquis de conscience , je fais un tour sur les fils dédiés à DXO et là je ne vois que des utilisateurs déçus.
Ou j'ai du bol ou les autres versions étaient vraiment pourries.
Qu'en est-il ? Ca vaut le coup ?

PS/ J'utilise aussi pour l'instant PS element et Capture NX (très long par contre).

[cagire]

Par acquis de conscience , je fais un tour sur les fils dédiés à DXO et là je ne vois que des utilisateurs déçus.

T'exagères un poil quand même. 

Est-ce que ça vaut le coup ? La réponse t'appartient, puisque tu l'as essayé.

[Verdi]

J'ai la dernière version de DxO et dois avouer n'avoir aucun problème. J'en suis trés satisfait.
(Je suis sur Mac)

[frede]

J'espère quand même que lorsque j'aurai saisi la clé (s'il n'y a que ça à faire) rien ne serait chambouler.
Par contre je ne comprends pas ceci: DXO autorise l'installation sur 2 postes or une fois que j'ai la clé et la version d'essai, rien ne m'empêche d'installer sur plus de 2 postes.
Le fait de payer la licence n'autorise qu'à utiliser le logiciel et pour la notice ? Un CD ? A moi donc de graver le logiciel donc et d'imprimer toute la notice ...

[IMAK]

A mon avis pas possible de l'installer sur plus de 2 postes à la fois car contrôle par internet.
C'est vrai qu'on peut installer sur une poste non connecté mais je présume qu'il y alors une autre procédure de validation de la clé (je sais pas laquelle car mes ordinateurs ont tous accès à Intertnet).
A propos, je suis rassuré que d'autres que moi semblent trouver DXO satisfaisant (et même plus); je me demandais si certaines choses m'échappaient car je n'ai jamais (client depuis la version 3.5) rencontré de problèmes majeurs.
Bonne découverte de DXO.
Pour ce qui est de la notice, effectivement il faut l'imprimer soi-même.
Pourquoi veux-tu graver un CD? Tu sais toujours aller rechercher le programme chez DXO.

[MainSoft]

Le fait de payer la licence n'autorise qu'à utiliser le logiciel et pour la notice ?

Bonjour,

Il y a un fichier PDF (qui vaut ce qu'il vaut). On ne va quand même pas blâmer les éditeurs de soft de ne plus gaspiller des tonnes de papier à imprimer des manuels qui seront obsolètes dès la prochaine version. Il est vrai qu'avec DxO, le manuel est obsolète dès le départ (non, pas taper - mais bon, c'est vrai quand même, non?).

DOP est un logiciel "self-explanatory". C'est tellement simple et évident à utiliser qu'un manuel détaillé et précis est de toute façon totalement superflu .

Quant à la pertinence d'un achat, chacun voit midi à a fenêtre. Il y a 2 catégories d'utilisateurs de la version 5: ceux pour qui le logiciel présente un nombre de bugs trop élevé et montre un comportement aléatoire et instable de version en version et ceux qui sont satisfaits. Les premiers ne sont pas heureux, surtout quand ils ont payé la mise à jour en se basant sur la qualité de la version 4, et ils le font savoir (je fais partie de cette catégorie "tapedur"). Les autres se manifestent évidemment moins souvent. Logique.

Les raisons qui font que l'on se trouve dans une ou l'autre de ces 2 catégories - on peut en changer en cours de route - sont liés à plusieurs facteurs:

- la manière dont on utilise le logiciel
- le fait que l'on utilise ou non certaines fonctions
- la nature et la quantité des images traitées
- la configuration du système utilisé
- son appréciation personnelle de certains choix techniques de DxO
- ce que l'on est prêt ou non à excuser en matière de technique et de méthodologie de développement
- ce que l'on est prêt ou non à excuser en matière d'ergonomie et d'interface utilisateur

Il y aussi la faiblesse de la documentation (vous n'aurez rien de plus que ce qui vient avec la version d'essai) et la déficience chronique de DxO en matière de communication avec leurs clients et la lenteur extrême avec laquelle certains problèmes connus depuis le lancement sont (ou ne sont pas) corrigés. Et encore, il y a eu une très légère amélioration, c'est dire à quel degré d'insatisfaction nous nous trouvions au lancement de la version 5.

Voilà. Si ça fonctionne pour vous, dans votre contexte, avec les résultats attendus, pour votre/vos boîtier(s) et vos objectifs, alors pourquoi pas?

[JMS]

"je ne vois que des utilisateurs déçus"....
...ceux qui sont contents sont las de polémiquer sur Chassimage !


Plus sérieusement, il y a eu des bugs sévères au début de la v5 et cela donne une mauvaise réputation, comme pour l'électronique des Renault 25, même si la plupart ont été corrigés par des mises à jours depuis. Maintenant je partage l'analyse de Mainsoft sur le fait que certains problèmes ont beaucoup gêné certains utilisateurs (par exemple les batch qui bloquaient après 300 RAW) et pas beaucoup d'autres (ceux qui trient leurs images avant traitement et fond des petits dossiers pour appliquer un preset à chacun...sans être trop pressés) et que certaines fonctions géniales (les presets très personnalisables) sont beaucoup trop complexes et mal documentés.

Quant à la façon dont est développé le logiciel, si ma Ford ne tombe pas en panne cela m'importe peu que le bloc moteur soit en fonte ou en alu, et que les ingénieurs utisent Catia ou une règle à calcul...

[MainSoft]

Quant à la façon dont est développé le logiciel, si ma Ford ne tombe pas en panne cela m'importe peu que le bloc moteur soit en fonte ou en alu, et que les ingénieurs utisent Catia ou une règle à calcul...

Bonjour Jean-Marie,

Stricto sensus, d'accord. Mais ce que l'utilisateur doit également comprendre, c'est que l'utilisation ou non de certaines technologies de développement va ou non faciliter la maintenance, la mise à jour, la non régression et l'évolutivité du logiciel. C'est la différence avec le hardware. Quand je paie une licence, je paie aussi pour un engagement de l'éditeur à maintenir et à faire évoluer son logiciel correctement et de manière stable. Ce n'est pas tout à fait le cas d'une voiture.

Et c'est là où je suis convaincu que DxO a un très gros problème. Par exemple, comment corriger efficacement les bugs (surtout aléatoires) si le logiciel ne fournit même pas les informations nécessaires au débogage chez l'utilisateur? Y a-t-il un système de traçage dans DOP? Non. C'est une grosse erreur. Et s'il n'avait pas été prévu au départ, ils pouvaient l'ajouter assez vite après la cata des premières versions. Conseil que je me suis permis de leur donner. Sans effet, bien évidemment.

J'ai enseigné ces différents points pendant des années. Dans le logiciel, il est extrêmement facile de "s'auto-coincer" et de créer des situations dont on ne peut se sortir que difficilement si certaines précautions n'ont pas été prises au départ. Mon expérience avec la v5 et mes échanges avec le support montrent que DxO n'a pas pris ces précautions. Têtu comme je suis, la tête sur le billot, je ne changerai pas d'avis sur ce point.

Le problème de la qualité du développement devient progressivement une préoccupation majeure. Pendant les 15 dernières années, j'ai vu l'évolution des développeurs que j'avais en formation. Nous sommes passés du besoin de comprendre et de produire du code stable à la nécessité de produire vite pour tenir le marché. Ceux qui croient que les grandes pannes logicielles des systèmes de réservation, chez les opérateurs téléphoniques, la distribution d'énergie et progressivement dans l'aviation civile relèvent du hasard sont extrêmement naïfs. C'est de la pure logique et nous n'avons pas encore vu le pire. Simplement, les têtes d'œuf du marketing ont calculé qu'un jour de panne sur un système de résa ou chez un opérateur téléphonique coûtait moins cher que l'investissement nécessaire à la production de logiciels de qualité. À partir de là, on dérape... C'est une question de valeurs. Un jour (à mon avis, c'est déjà arrivé chez certaines compagnies), on calculera qu'un crash aérien de temps en temps coûte moins cher qu'une maintenance régulière et correcte.

Mais la photographie est moins risquée, bien sûr . Quoique la notion de risques associés aux composants insérés dans nos gadgets high-tech demanderait elle aussi quelques développements. J'ai quelques exemples bien concrets en tête.

[gribou]

Utilisateur de la 3.5, j'ai zappé toutes les versions jusqu'à celle-ci, la 5.2.
Toujours été satisfait excepté pour la lenteur de traitement ; +/- 30 sec/photo. Mais mon PC n'est plus de toute première jeunesse.
Pour le mode d'emploi, j'ai acheté le livre de JMS qui est super didactique et explicite de façon claire toutes les arcanes du soft.

[gerarto]

Mon avis sur le sujet, en réponse à une question posée sur un fil spécifique à Sony (ça concernait au départ plus le Sony Alpha 700 que DxO) :

http://www.chassimages.com/forum/index.php/topic,23010.msg358649.html#msg358649

En complément :  chez moi c'est aussi un peu lent, mais les résultats sont très bons, et les seuls (rares) plantages que j'ai surviennent lors de la visualisation des résultats après traitement, donc à vrai dire, ça ne me prends pas plus la tête que ça...

[JMS]

Mainsoft, je comprends ton point de vue, tu te dis "si c'est moi qui...j'aurais fait autrement" et c'est tout à fait compréhensible vu ton métier. Mais du point de vue du photographe plusieurs bugs réels et signalés des versions précédentes me sont toujours apparus assez véniels, car on sait les contourner.
Sur le manque de traçage des bugs, peut-être en effet faudrait-il comme sur d'autres logiciels un "rapport automatique" qui envoie le problème au support...comme j'ai cela dans Nikon view qui s'obstine à craquer si par erreur je clique sur un répertoire avec des NEF de D3...Bon, je sais bien que seul View NX peut les lire mais il devrait afficher une vignette format non supporté et pas planter.

[Lictor]

Stricto sensus, d'accord. Mais ce que l'utilisateur doit également comprendre, c'est que l'utilisation ou non de certaines technologies de développement va ou non faciliter la maintenance, la mise à jour, la non régression et l'évolutivité du logiciel.

Assez d'accord, mais je ne parlerais pas de technologies, mais, au sens plus large, de méthodologies... Par exemple l'utilisation de Design Patterns (et la connaissance des anti-patterns) qui permet d'éviter les grosses catastrophes. De même qu'un management qui ne marche pas sur la tête aide aussi les choses. A la limite, les technologies ne sont utiles que si elles viennent supporter ces méthodologies...

J'ai enseigné ces différents points pendant des années. Dans le logiciel, il est extrêmement facile de "s'auto-coincer" et de créer des situations dont on ne peut se sortir que difficilement si certaines précautions n'ont pas été prises au départ.

Ce qui est tout de même un énorme paradoxe... Parce qu'il n'y a jamais eu autant d'outils, au sens large, pour aider les développeurs que maintenant! Les gens qui après avoir codé en C sont passés au C++ puis à des langages comme Java ou C# on pu mesurer l'ampleur des progrès! De même, au niveau méthodologie, on a la révolution des design patterns, les approches agiles, le test-driven development... De même, on a maintenant une énorme quantité d'API fiables pour faire tout et n'importe quoi : du réseau, des collections, du graphismes... Je me rappelle quand il fallait encore gérer ses listes à la main ou gérer ses évènements à l'ancienne sous Motif ou Win32 (sans MFC)...

On a jamais eu autant d'outils pour faire du logiciel de qualité qu'aujourd'hui!

Le problème de la qualité du développement devient progressivement une préoccupation majeure. Pendant les 15 dernières années, j'ai vu l'évolution des développeurs que j'avais en formation. Nous sommes passés du besoin de comprendre et de produire du code stable à la nécessité de produire vite pour tenir le marché.

Très d'accord la dessus...
Avant, c'était une affaire de passionnés, avec de bons projets et des salaires très corrects.
Maintenant, c'est une affaire de losers qui n'ont pas pu entrer en école de commerce, avec des projets foireux et des salaires en berne.
Ça n'attire clairement pas la même population... Ceux qui sont encore motivés font tout pour se casser du monde de l'entreprise lambda et pour se mettre à leur compte, faire de l'Open Source ou aller dans des boites "fun"... Encore que de ce point de vue, on peut considérer que DxO attire plutôt une certaine élite, ce n'est clairement pas le développeur lambda qui va aller bosser chez DxO au lieu de finir chez un viandeur...

Un jour (à mon avis, c'est déjà arrivé chez certaines compagnies), on calculera qu'un crash aérien de temps en temps coûte moins cher qu'une maintenance régulière et correcte.

Je pense que c'est déjà très clairement le cas dans certaines compagnies dans les pays pauvres...
En Europe, ça doit être le cas en interne, dans 20 ans, on aura les documents, comme on les a eu pour l'industrie du tabac...

[MainSoft]

Assez d'accord, mais je ne parlerais pas de technologies, mais, au sens plus large, de méthodologies...

Complètement d'accord. J'ai raccourci. Mais dans les enseignements dont je parlais, il est bien question de Design Patterns, de Bonnes Pratiques, de Test Driven Development (TDD), de Tests Unitaires, etc. Mais pour prendre un exemple typique, l'utilisation de la méthodologie TDD, mal comprise, fait croire à certains qu'ils vont perdre du temps à préparer les tests, à tester les non régressions à chaque modif, etc. J'ai très souvent entendu la remarque réflexe: mon patron ne me laissera jamais faire ça. Alors qu'au final, sur l'ensemble du projet, le gain de temps est considérable et la fiabilité du logiciel accrue. Est-ce que ce n'est pas aussi au développeur de convaincre son management?

Mais il n'y a pas encore si longtemps que cela que j'ai croisé des chefs de projets dans de grandes entreprises qui mesuraient la productivité de leurs développeurs au nombre de lignes pondues dans la journée...

[Lictor]

Mais pour prendre un exemple typique, l'utilisation de la méthodologie TDD, mal comprise, fait croire à certains qu'ils vont perdre du temps à préparer les tests, à tester les non régressions à chaque modif, etc.

Dans un premier temps, c'est vrai: on perd du temps. Tout comme travailler le plus possible en binôme (XP) est perçu comme une perte de salaire. Enfin, jusqu'au jour où un salarié indispensable claque la porte et que c'est la catastrophe pour récupérer ce qu'il faisait...
J'ai vécu ça récemment sur un projet... Un développeur PHP (dix ans d'expérience tout de même) se posait des questions sur comment coder en objet l'accès à la base de donnée. On s'est mis à deux pour lui expliquer l'architecture en 3-tiers, la notion de DAO, les anti-patterns à éviter... Au final, il nous a expliqué qu'on lui laisserait jamais le temps de faire tout ça, et qu'il allait coder directement les requêtes dans la génération des pages... C'est typique... Il pond dix projets comme ça par an, et en 10 ans de boite, il n'a *jamais* eu le temps de faire un design correct.

J'ai très souvent entendu la remarque réflexe: mon patron ne me laissera jamais faire ça.

C'est une remarque cynique, mais hélas très réaliste...

Alors qu'au final, sur l'ensemble du projet, le gain de temps est considérable et la fiabilité du logiciel accrue. Est-ce que ce n'est pas aussi au développeur de convaincre son management?

Le "secret", c'est que la plupart des boîtes n'ont aucune vision à long terme. Ni même à moyen terme. En fait, beaucoup de boîtes n'ont même pas la notion d'investissement et ne cherchent même pas à former leurs équipes ou à investir dans des outils plus performants.
Quand au boulot du développeur de convaincre son management, c'est souvent peine perdue. A dialoguer avec un mur, on se ruine rapidement la santée. Les plus motivés finiront tôt ou tard par aller voir ailleurs (à leur compte, formateur, à l'étranger, dans les boîtes d'élite), les autres se résigneront et se conteront de toucher leur chèque à la fin du mois.

L'un des (nombreux) aspects intelligents d'XP, c'est la notion de respect et de partage des compétences, notamment reconnaître l'expertise du développeur dans son propre domaine d'expertise. C'est aussi un aspect complètement impossible à comprendre pour la majorité du management en France...

Mais il n'y a pas encore si longtemps que cela que j'ai croisé des chefs de projets dans de grandes entreprises qui mesuraient la productivité de leurs développeurs au nombre de lignes pondues dans la journée...

Ça ne va effectivement pas aider l'adoption de pratiques comme le refactoring, j'imagine la tête des chefs de projets quand un développeur sort un score négatif pour sa journée de travail... Enfin, avec le temps, j'en suis de plus en plus à m'interroger sur l'utilité réel de beaucoup de "chefs de projet". Je trouve plus saine l'aproche d'XP qui éclate leur rôle entre plusieurs entités:  "coach", "client", "guru"...
Mais c'est à peine choquant : certains grands cabinets d'audit mesurent la performance des journalistes avec la même métrique...

[hyucca]

à MainSoft et Lictor....

Votre dialogue va nous foutre le bourdon ! Et des complexes: faut'y qu'on soient cons pour y trouver notre bonheur !

Pour ma part j'ai "misé" sur DxO, et pas mal cotisé aussi depuis le début de leur aventure, car je l'ai vécu comme cela...., et je trouve aujourd'hui que le niveau atteint n'est pas si mal.

Et si j'osais, je dirais que je préfère qu'ils restent à ce stade car le jour où ils auront la "qualité Adobe", et le tarif, ce ne sera plus pour moi...et pour beaucoup !

Je crois que dans le domaine de la "photo passion", même si c'est aussi un job pour certains, DxO est un logiciel à part, dans la mesure où il n'a pas de vrai concurrent. On peut s'en passer en utilisant des combinaisons de fonctions de logiciels, mais il est le seul à faire ce qu'il fait, et c'est difficile de lui pardonner de ne pas être parfait alors qu'on a envie de l'aimer.
C'est peut-être exaspérant, mais il faut relativiser, et l'utiliser comme le suggère JMS, pour ses qualités, en évitant de lui demander ce que l'on sait être source d'échec.

Ce serait un vrai bonheur de vivre avec, sans qu'il bogue au mauvais moment, alors qu'il serait si agréable que.....si j'osais je dirais que cela me rappelle des choses!......

Je crois que sous couvert de méthodologie et de technologie vous mettez beaucoup d'affectivité dans vos relations avec DxO et que cela va finir par vous gâcher la vie !

Je me trompe ?...ne m'en voulez pas, je ne suis pas parfait...non plus 

PS: Je me trompe peut-être encore, j'ai cru lire un post où tu disais prendre un peu de recul, MainSoft, et ne plus "taper" sur DxO?....cela serait bien....    

[MainSoft]

PS: Je me trompe peut-être encore, j'ai cru lire un post où tu disais prendre un peu de recul, MainSoft, et ne plus "taper" sur DxO?....cela serait bien....

J'ai surtout indiqué que je ne discuterai plus ici du sujet "sursaturation des rouges".

Pour le reste, je dirais: "Qui aime bien, châtie bien". Quand vous exprimez le souhait "qu'ils en restent où ils en sont", si DxO ne corrige pas ses pratiques, ils ne pourront que régresser. Désolé si la discussion est devenue technique mais en matière de logiciel, on avance ou on régresse. Il n'y a pas d'état stable parce que l'environnement n'est pas stable. Pour pouvoir s'adapter à cette évolution externe, il faut mettre en œuvre des méthodologies adéquates. Ce que DxO ne fait pas (vu par des gens de la partie). Et s'ils persistent, votre rêve partira en fumée.

C'est juste cela que Lictor et moi-même essayons de faire comprendre.

[Lictor]

Pareil pour moi... Je suis utilisateur de DxO depuis les débuts de la v4, j'ai payé ma licence v5 et j'utilise toujours DxO de temps en temps, même si je dois avouer utiliser Capture NX2 de plus en plus...

A vrai dire, en temps que développeur, si on me proposait de travailler chez DxO, je considérerais tout de même sérieusement l'offre - tout en sachant que je risquerais de m'en mordre les doigts. Parce que, malgré les nombreux défauts de cette entreprise, il y a tout de même une ambition et une maitrise qui sont indéniables.

Je pense que c'est un peu ce qui cause une certaine désolation chez MainSoft et moi. On a là une boite française, qui a eu une idée révolutionnaire, qui s'est donné les moyens de sortir quelques chose qui marchait plutôt pas mal et qui a un vrai potentiel d'avenir... L'idée s'est banalisé, mais le concept de corriger logiciellement la plupart des défauts d'une optique est tout de même un concept révolutionnaire - au moins autant que le zoom ou la chambre reflex.
Mais elle donne ne même temps l'impression de se saborder à coup d'erreurs de communication, d'erreurs de management et, il faut le dire, d'ambitions qui semblent revues à la baisse...
Quand on a suivi l'informatique depuis un bon moment, on a vu pas mal d'entreprises ou de projets qui auraient dû briller au firmament pour leurs visions révolutionnaires se casser la gueule: NeXT, Amiga, Atari, OS/2, le Lisa d'Apple, Palm... Ça serait un peu désolant de voir DxO suivre le même chemin...

[hyucca]

c'est sûr que vous avez raison....mais bon !

c'est vrai que retomber régulièrement sur des bogues non corrigés, c'est exaspérant....

c'est vrai que lorsqu'on fait du développement, voir toujours les même co...ries refaites....c'est irritant...

Je comprends tout cela d'autant mieux que j'ai commencé l'informatique en 68 (assembleur) et que j'ai beaucoup travaillé sur les méthodologies, 15 ans d'efforts pour convaincre de la nécessité de la rigueur, là comme ailleurs.

Je n'ai pas envie qu'ils régressent, pas plus qu'ils ne stagnent (j'ai écrit: si j'osais...), mais je peux m'accommoder de quelques défauts, parce que je trouve DxO génial.

J'ai aussi appris dans ma longue vie professionnelle que le perfectionnisme peut couler un projet!

Tout cela n'est qu'équilibre et mesure.

Pour finir, c'est dommage de faire peur à ceux qui s'intéressent au produit et qui en seront sûrement satisfaits.

Bonnes photos 

[JMS]

Lictor et Mainsoft, on comprend votre passion, mais il n'est pas certain que de dire tous les jours que c'est de la daube soit la meilleure façon pour améliorer la réputation d'un produit !

[MainSoft]

il n'est pas certain que de dire tous les jours que c'est de la daube soit la meilleure façon pour améliorer la réputation d'un produit !

Bonsoir Jean-Marie,

Non, on ne dit pas que c'est de la daube. Mais est-ce que quelqu'un connaît la façon de faire évoluer DxO et son produit dans le bon sens? Voilà 9 mois qu'on cherche. On attend que ça se passe tout seul en croisant les doigts et en regardant ailleurs? Ou bien on continue les rapports de bugs, les observations sur les manquements du logiciel, etc. J'ai participé à un programme chez Microsoft où ils nous demandaient, à nous professionnels, de leur taper dessus et de critiquer leurs produits. Ça s'appelle collecter le retour utilisateur. Ça ne rend pas les produits parfaits mais ça aide à progresser. Si une majorité d'utilisateurs annonce à DxO que "bon, d'accord, il y a pas mal de choses qui fonctionnent mal mais on va s'en accommoder", pourquoi feraient-ils l'effort de corriger?

Et je n'ai absolument pas pour mission de sauvegarder la réputation de DOP. Je m'accorde le droit, en tant que client payant et professionnel de l'informatique, de donner un avis sur les problèmes liés à ce soft. Ça ne m'empêche pas de dire à ceux à qui je parle du produit que l'idée de base est excellente et que DxO possède très certainement une technologie sans vraie concurrence. Voir le dernier message de Lictor.

Critiquer et rapporter des bugs de manière continue depuis 9 mois est très certainement profondément ennuyeux pour les abonnés à ce forum, pour les utilisateurs en général, pour DxO en particulier et pour ceux qui se donnent la peine de remonter ces rapports. Le jour où je m'arrêterai, c'est que le produit ne m'intéressera plus.

Le message est surtout adressé à DxO. Les utilisateurs, on l'a vu, se font leur opinion eux-mêmes. Est-ce que j'ai dit une seule fois "N'achetez pas" ou "C'est de la daube"?

[MainSoft]

Je m'accorde le droit, en tant que client payant et professionnel de l'informatique, de donner un avis sur les problèmes liés à ce soft.

Tiens, un autre exemple tout frais.

http://forum.dxo.com/project.php?issueid=330#note1693

Certains diront que c'est un bug mineur et il est vrai que l'on peut effectivement vivre avec si on fait attention mais si on se fait piéger, on peut traiter des images sans le vouloir. Mais il démontre clairement que la gestion de la souris dans le code de l'interface utilisateur de DOP est totalement anarchique. Ce sont des erreurs de débutants. Au prix de la licence, je ne suis pas près de l'accepter sans rien dire.

[jldallem]

Je m'explique:
J'ai téléchargé la version d'essai 14 jours 5.2.1 build 7024. Aucun pb. Je l'ai installé sans problème.Depuis 8 jours elle tourne toujours sans pb et les résultats sont satisfaisants  (du moins pour ce qui est visible des formats 40X60). Les fichiers RAW ou JPEG de mon D300 me paraissent correctement traités pour ce qui de la géometrie , lumière , couleurs. Bilan satisfaisant.

J'en suis à me demandé si je ne vais pas l'acheter (demander la clé numérique du moins).
Par acquis de conscience , je fais un tour sur les fils dédiés à DXO et là je ne vois que des utilisateurs déçus.
Ou j'ai du bol ou les autres versions étaient vraiment pourries.
Qu'en est-il ? Ca vaut le coup ?

PS/ J'utilise aussi pour l'instant PS element et Capture NX (très long par contre).

Bonjour.

Utilisateur de nikon capture NX2 et de DXO 5.2.1 build 7024, mon avis est le suivant sur ces deux produits.
Adepte de DxO depuis la version 3, j'ai décidé de ne plus utiliser ce produit en version 5.1. Possesseur d'un D70 et d'un D300 je me suis donc tourné vers Nikon Capture NX puis NX2.
Dès la sortie de la version 5.2.1 de DxO, j'ai acheté la licence et utilise désormais les deux produits.
En termes de performances, Nikon Capture NX est sensiblement plus exigent que DxO. 2G0 de RAM sont un minimum afin que Capture NX2 puisse travailler normalement. Dans ce même espace mémoire, DxO semble s'exécuter de manière beaucoup plus fluide (Remarque. J'utilise assez peu le mode batch).
Sur le plan de la stabilité, les deux produits me semblent de qualité. Il peut y avoir des "plantage" quelquefois mais c'est assez rare.
Sur le plan du bruit et du piqué, DxO est incontestablement supérieur.
Relativement au travail de la lumière, les approches de DxO et de Nikon Capture NX2 sont assez différentes. On ne peut pas dire que l'une soit meilleure que l'autre. Néanmoins , concernant les hautes lumières, capture NX2 a tendance à aller chercher de l"information dans des intensités lumineuses écrêtées ce qui peut faire apparaitre des ciels "blancs" de couleur grise.
Concernant le traitement des basses lumières (DxO lighting ou D-lighting chez Nikon), DxO semble plus subtil avec ses notions luminosité (gamma), de rayon des ombres, de contraste local et global. Un fois maitrisés ces outils sont très puissants et permettent de sortir l'information d'un "noir profond". Capture NX2 le fait aussi, mais d'une manière plus globale.
Je ne parle pas des spécifités de Nikon (U-points et outils agissant sur les couleurs car ils sont particuliers à ce produit).
Concernant la distorsion la solution DxO est très élégante mais reste "bridée" par le nombre de boitiers et d'objectifs en pleine évolution et toujours plus nombreux. La traitement de la distorsion est implémenté dans Nikon Capture NX2 mais manuellement ()
Bien que considérant la distorsion comme étant "anecdotique", avec Nikon Capture NX2 j'utilise PTlens . Ceci s'apparente à ce que fait DxO.
Sur un plan plus global, une image traitée avec Nikon Capture NX2 peut sembler plus flatteuse. Par contre elle est moins réaliste (moins proche de ce que l'on voit vraiment). Dans une photo de paysage un ciel bleu est souvent "trop" bleu.
Mais là, nous abordons le thème de la balance des blancs. Se pose alors aussi le problème du subjectif car, au final, le goût de chacun peut faire incliner vers l'un ou l'autre produit.
Personnellement, je trouve qu'il est difficile de décider.

[JMS]

Sur la dernière intervention de Mainsoft...oui c'est un bug mineur quoiqu'étrange. Parce que si la boîte de dialogue demande si on veut vraiment charger deux fois la même photo, il devrait suffire de cliquer non. Mais si l'on va par là il y a le même bug sous Explorer, car ici sur Chassimage si je clique dans la barre de défilement à droite en dehors du curseur, mon affichage bouge. Normalement on ne devrait pouvoir cliquer que sur le curseur ou sur les flèches hautes et basses, ce n'est pas le cas !

Je pense que la dénonciation anti-bug aboutit à mettre tous les bugs sur le même plan de gravité même si tout le monde préférerait un logiciel garantit zero bug avec toutes les configurations matérielles et logicielles !

[MainSoft]

car ici sur Chassimage si je clique dans la barre de défilement à droite en dehors du curseur, mon affichage bouge. Normalement on ne devrait pouvoir cliquer que sur le curseur ou sur les flèches hautes et basses, ce n'est pas le cas !

Totalement inexact, Jean-Marie. Le clic dans la zone intermédiaire entre le curseur de défilement et les flèches haute et basse est normal, prévu et standard. C'est par défaut la même chose que PgDn / PgUp.

Ce qui n'est pas normal: un (double) clic dans la barre (sur le curseur, au-dessus, en-dessous ou sur les flèches) génère un message qui est adressé à la barre qui est en fait une fenêtre à elle toute seule. En aucun cas ce message ne devrait atteindre la fenêtre principale directement et surtout y provoquer un traitement qui n'a rien à voir avec le défilement. Le bug est mineur mais ce qu'il indique sur le codage de DOP ne l'est pas.

[JMS]

En effet, j'ai vérifié le bug existe bien. Mais il faut être vicieux pour faire un double clic dans la barre de défilement, même quand on ne connaît pas ses standarts Microsoft (comme moi). Si on clique une fois selon tes bonnes indications, aucun bug.