Plantages avec la verison 5.1 ?

[estebanj]

Effectivement la version 4.5 est stable et fonctionne parfaitement.
La version 5.0 était elle totalement inutilisable, en attendant j'étais reparti sur la 4.5.
Mais le travail que j'ai déjà réalisé avec la 5.1, et ce malgrès les plantages et le temps perdu, laisse présager un excellent outil. J'ai un 20D je ne suis donc pas obligé de travailler avec 5.1, mais depuis que je l'utilise j'en apprécie de nombreuses qualités. Il ne faut donc pas l'enterrer. Le bébé est prometteur même si ses défauts de jeunesse restent inacceptables.
J'en profite pour dire que le bouquin de JMS est un très bon manuel,  pratique, simple et agréable à utiliser il met bien les choses au clair, même pour un ancien utilisateur de DXO (j'ai débuté avec 3.0).

[MainSoft]

Non je ne suis pas informaticien, mais par contre je suis chimiste...

Pas de souci. Moi, je suis un ancien chimiste, devenu physico-chimiste, puis physicien des solides, puis informaticien industriel puis consultant en informatique .

[MainSoft]

Dans un premier temps, cette belle formule, qui colle bien à mon expérience avec DXO 5.x, me fait sourire     ...
Mais je me demande avec inquiétude, si cette méthode de classer a priori les éventuels bugs de la 5.1 comme des exceptions, laisse présager des versions ultérieures vraiment stables ...
Une façon de laisser entendre par DXO que les crashes qui restent sont plutôt dûs à la configuration de l'utilisateur, et non au prog lui-même ... un dédouanement facile en sorte.

Bonjour,

Je suis d'accord. En tant que développeur (néanmoins faillible ), j'ai déjà exprimé un avis assez tranché sur la question. Cet avis est basé sur ce que j'ai observé de la V5, des entretiens téléphoniques et échanges que j'ai eus avec le support DxO et sur ma propre expérience de conseil et de développeur. Je pense que les problèmes dont souffre la V5 sont fondamentalement liés à un design déficient et conçu dans la hâte. Cela se voit aux erreurs grossières dans l'interface et à des détails comportementaux assez significatifs (mais je ne vais pas encore une fois entrer dans les détails techniques). Tant que ce design ne sera pas revu, nous verrons apparaître des versions avec pansements et prothèses mais rien de solide.

DxO a cumulé pour le développement de la V5 plusieurs contraintes simultanées:

- Modification des algorithmes de traitement (il semble que ça au moins ait été réussi).

- Changement de technologie de développement (Win32 vers .Net - mais en continuant de traîner les problèmes de Win32 que .Net est censé éviter: DOP V5 n'est en effet pas une application .Net pure mais une application mixte Win32 / .Net qui est donc toujours soumise aux aléas de Win32).

- Changement de design, d'interface utilisateur et de système de gestion des projets.

Tout cela en même temps, en étant visiblement pressé par les gens du marketing, avec des ressources dont on comprend de jour en jour qu'elles sont très réduites et sans la mise en place préalable des outils qui auraient permis d'assurer un niveau de qualité correct (version debug, méthodologie de développement basée sur les tests pour éviter les régressions, journal d'exécution,...). C'est extrêmement présomptueux et si un de mes clients se lançait dans ce genre de manœuvre, je ferais tout pour l'en dissuader.

Donc, effectivement, je ne m'attends pas du tout à une amélioration spectaculaire (même si encore une fois la 5.1 est un réel progrès - mais pas pour tout le monde) mais à une série continue de replâtrages successifs jusqu'à l'annonce de la V6. C'est un peu la répétition de la vieille histoire du DOS 5 chez IBM qui a fini par crever tout seul tellement chaque nouvelle version ajoutait sa couche de bugs à un design totalement pourri dès le départ - le comble étant que lorsque l'on est arrivé à une version stable, elle ne servait plus à rien car elle occupait toute la mémoire disponible (640K en ce temps là) et on ne pouvait pratiquement plus charger d'applications (j'ai bien connu cette histoire vu que j'étais chez Big Blue à l'époque).

Voilà. On peut contester cette vision des choses et en tant que bêta-testeur payant, j'espère me tromper. Mais je ne crois pas... Comme d'autres, je vois plutôt l'avenir de DxO en tant que plugin Photoshop / Lightroom. C'est une voie que DxO ferait bien d'explorer rapidement.

[estebanj]

Sinon en clair:
Est-ce intéressant de télécharger la version 6814 ou c'est du pareil avec 6813?

[JMS]

"La version 5.0 était elle totalement inutilisable"...
...quand je pense que j'ai utilisé six mois sur deux machines une version totalement inutilisable ...



Sinon merci pour tes compliments Estebanj...je n'ai pas chargé la 6814 parce que j'étais sur un autre chantier, mais la 5.1 6813 marche chez moi comme les 5.03 et 5.04 c'est à dire très bien, mais avec une plus grande capacité aux gros batchs.


J'ai dit "chez moi" parce que je n'ignore nullement que sur certaines configuration..."y'en a qui ont essayé, ils ont eu des problèmes" comme disait Laspallès...

[Yves2b]

"La version 5.0 était elle totalement inutilisable"...
...quand je pense que j'ai utilisé six mois sur deux machines une version totalement inutilisable ...

[mode ironic on]
on se demande même pourquoi DXO s'acharne depuis 6 mois à développer d'autres versions     
quand on sait qu'il est toujours risqué de changer un programme qui marche, cela parait vraiment audacieux !
[mode ironic off]

[JMS]

Tout simplement pour améliorer le programme, et ajouter deux ou trois fonctions oubliées sur la première 5, comme le clipping des hautes lumières. De plus il fallait à juste titre clarifier le fonctionnement des presets, complexe voire obscur en version 5.0. Mais quand on avait compris comment çà fonctionnait, çà fonctionnait quand même.

Quand à changer un programme qui marche...évidemment si personne ne changeait un programme qui marche vous auriez peut-être Photoshop 1 sur Windows 3 sur toutes les machines ...

[Phoebe]

"En comparaison des versions 5.0.x antérieures, la 5.1 apporte aux utilisateurs Windows des améliorations considérables de stabilité et des fonctionnalités supplémentaires dont une protection Pace Interlok plus souple, ne nécessitant pas l'installation de driver Interlok"

C'est dans le dernier mail de pub.

[MainSoft]

ajouter deux ou trois fonctions oubliées sur la première 5, comme le clipping des hautes lumières.

Jean-Marie,

Très franchement, un peu de bon sens, comment pouvaient-ils oublier ça? Voilà plusieurs commentaires que je lis (reflétant la position officielle de DxO puisqu'ils viennent de personnes en contact direct avec eux?) faisant un état d'un oubli à propos des fonctions présentes dans la 4.x et absentes de la 5.0. Il ne faudrait quand même pas prendre les enfants du Bon Dieu pour des canards sauvages.

C'est juste le signe d'un développement fait à la va-vite avec un cahier des charges rédigé sur un coin de table. De deux choses l'une: ou bien ces fonctions étaient décrites dans le cahier des charges et il était impossible de les oublier - si on travaille normalement - ou bien elles ne l'étaient pas (tout simplement parce que le cahier des charges n'en était pas un). Personne ne fera avaler à un professionnel du développement que l'on peut tout simplement oublier des fonctions aussi essentielles dans un logiciel de dématriçage moderne. C'est du roman. Ou alors c'est le signe d'une désorganisation totale (ce qui est mon sentiment, comme exprimé plus haut).

L'insistance de DxO à vouloir nous faire avaler des couleuvres (oubli de fonctions, rejet des problèmes du logiciel sur le framework .Net, configurations atypiques des utilisateurs - qu'est-ce qu'une configuration typique, au fait? -, ...) plutôt que de jouer franc jeu devient un rien irritante. Excuser les bugs (y compris les miens), c'est tout à fait normal. La mauvaise foi, sûrement pas.

Je n'avais jamais entendu ça: une fonction qui disparaît d'une version à l'autre par oubli. Vraiment, comme diraient les cousins, c'est le diable aux vaches, ciboire électrique!

[jmaa]

  Via le dernier mail de DXO, j'ai vu que le 1DS3 est enfin supporté , ainsi que la plupart de mes objectifs ( dont le 28-135IS).

  Je vois donx enfin pouvoir achter un 1DS3 , afin de donner à mon 28-135 l'appareil qu'il mérite!.

[JMS]

Mainsoft, au début des essais de la 5 comme je n'utilise quasiment jamais le clipping je ne m'étais pas aperçu qu'il manquait !



Maintenant si le terme oubli te choque disons "omission" dans les premières versions 5...

[Lictor]

Dans DOP, il y a 2 parties: une partie écrite en .Net et qui concerne principalement l'interface utilisateur et une partie Win32 classique concernant plus directement les traitements. Les 2 parties communiquent via un mécanisme appelé Interop. La partie .Net ne peut pas fuir: c'est inhérent à la technologie.

Euh, si c'est comme Java, si, ça peut fuir... C'est certes nettement plus difficile à faire qu'en C++, mais on y arrive quand même! Il suffit d'avoir quelques objets globaux qui possèdent avec plus ou moins d'indirections des grappes d'autres objets qui eux-mêmes possèdent... Un cache mal géré peut très bien entraîner ce genre de choses. Techniquement, on est pas vraiment dans le cas d'une fuite - on a toujours une référence quelque part sur le paquet de machin qui traîne en mémoire, mais au niveau résultat final, ça se comporte pareil...
Il peut aussi y avoir des fuites lorsqu'on descend à des niveaux proches de l'OS, par exemple pour allouer des objets système - par exemple quand on joue avec JNI en Java. J'imagine qu'on peut faire la même chose en .NET, par exemple avec DirectX.
Enfin, il me semble que C# supporte un mode non managé, où le programmeur renonce à l'essentiel des sécurités de .NET (GC, vérification des bornes...) pour faire les choses à l'ancienne (et plus efficacement). Là encore, on a toute la liberté pour faire des fuites...

Cependant, une augmentation de la mémoire utilisée n'indique pas nécessairement une fuite. Sous .Net, les objets sont alloués en mémoire au fur et à mesure des besoins et ils sont libérés par un mécanisme automatique (indépendant des erreurs du développeur et sans intervention de sa part) appelé le Garbage Collector qui n'intervient que lorsque l'application a vraiment besoin de mémoire complémentaire.

C'est effectivement le plus probable... Après, il est possible (et souhaitable) de programmer tout de même en tenant compte du Garbage Collecting. Par exemple, en "rendant" systématiquement les références dès qu'elles ne sont plus utiles ou en évitant les grosses grappes globales avec des références fortes.
Bref, il y a tout de même une marge au niveau architecture, qui, GC ou pas, fait la différence entre une bonne gestion mémoire ou pas.

Mais effectivement, un programme .NET ou Java qui grossit au fur et à mesure de son cycle de vie n'a rien de choquant, c'est une stratégie saine du GC tant que ça ne compromet pas le reste du système (il reste de la mémoire libre) ou le comportement de l'application (ralentissements, erreurs OutOfMEmory...).

[Lictor]

C'est juste le signe d'un développement fait à la va-vite avec un cahier des charges rédigé sur un coin de table. De deux choses l'une: ou bien ces fonctions étaient décrites dans le cahier des charges et il était impossible de les oublier - si on travaille normalement - ou bien elles ne l'étaient pas (tout simplement parce que le cahier des charges n'en était pas un). Personne ne fera avaler à un professionnel du développement que l'on peut tout simplement oublier des fonctions aussi essentielles dans un logiciel de dématriçage moderne. C'est du roman. Ou alors c'est le signe d'une désorganisation totale (ce qui est mon sentiment, comme exprimé plus haut).

Troisième option: c'était bien dans le cahier des charges, mais on a arraché la version en cours à l'équipe de développement alors qu'elle était encore en train de bosser dessus, parce que le marketing a fixé la date de sortie trop tôt. La personne chargée de recetter cette version n'a pas eu le temps de faire son boulot, était incompétente, n'a pas été écoutée ou n'existe pas.

Soit dit en passant, on arrive à se passer de cahier des charges (certains clients sont incapables d'en produire un) et à conserver un niveau de qualité correct. Par contre, ça demande pas mal d'organisation, de méthodologie et un haut niveau de compétence de l'équipe. Ce n'est clairement pas le cas ici...

[MainSoft]

Enfin, il me semble que C# supporte un mode non managé, où le programmeur renonce à l'essentiel des sécurités de .NET (GC, vérification des bornes...) pour faire les choses à l'ancienne (et plus efficacement). Là encore, on a toute la liberté pour faire des fuites...

Oui. Mais à partir du moment où on utilise Interop, comme le fait DOP 5, on est déjà dans cette problématique. Je suppose et j'espère que la partie .Net de DOP est écrite en mode managé.

Après, il est possible (et souhaitable) de programmer tout de même en tenant compte du Garbage Collecting. Par exemple, en "rendant" systématiquement les références dès qu'elles ne sont plus utiles

Attention, nuance: je ne sais pas si tu as regardé le fonctionnement interne du GC mais rendre une référence ne provoque pas nécessairement la récupération de la mémoire par le GC. L'objet est simplement marqué comme destructible. La caractéristique du GC de .Net est d'être non déterministe. Le développeur a très peu de possibilités, même en provoquanf un GC collect manuel, d'influer sur le moment exact où une allocation mémoire sera libérée. Mais tu as raison sur un point: plus l'objet a été alloué tôt (plus il est global), c-à-d plus il appartient à une "génération" ancienne dans le GC, moins il a de chance d'être détruit rapidement, sauf en cas de déficit mémoire prononcé. Donc si le développeur ne respecte pas la règle qui consiste à allouer les objets le plus tard possible quand on en a besoin et à les "libérer" dès qu'ils ne sont plus utiles, il y a des risques non pas de fuite mais d'encombrement mémoire prolongé et inutile. Et malheureusement, c'est une sale habitude que je constate assez souvent chez mes stagiaires, surtout ceux qui viennent du monde Visual Basic (mais pas seulement ).

J'arrête là, sinon je vais vraiment être hors-sujet et provoquer des crises allergiques bien justifiées .

Mais pour revenir à la question initiale, nous sommes d'accord, ce qui est observé n'est pas nécessairement le signe d'une fuite mémoire. Il est probable que cela est dû au comportement normal du gestionnaire de mémoire de .Net.

[midero]

Pour ma part, je ne fais jamais de gros batch.
Je fais un premier tri avant de développer.

Ce matin, sur 5.1, j'ai traité 48 photos (des CR2 de 12.4 MB) en 14 minutes. Pas de plantage évidement.

Parfait.

[Phoebe]

Bon, maintenant tu montes à 512 Mo et tu fais un nouveau test, puis 1 Go...etc

Finalement, j'ai suivi cette suggestion et remplacé l'hôte précédent (Mono-core AMD Sempron 2800+, 1Go mémoire) par un Asus Asus V1S (Core 2 duo T7500 2,2 GHZ - 2Go).
La machine virtuelle est restée la même mais je lui ai royalement attrribué 512 Mo et un coeur pour elle toute seule.
Les 711 photos ont été traitées en 7h30, sans aucun problème.
Pas très rapide mais compte tenu du fait que l'impact sur la bureaurtique/Internet/Echecs en ligne était nul c'est extrèmement satisfaisant.

[estebanj]

Mea culpa...mea culpa
Pour toutes les infamies que j'ai dites au sujet de DXO 5.1 sur ce forum.
Ce logiciel tourne très bien j'ai traité cet après midi un projet de 600 photos en 1h45, sans le moindre incident...
Mais je ne vous dis pas tout.
Je viens surtout de racheter une unité centrale avec Core 2 quad, 3 Go de mémoire vive, 500 Go de disque dur etc...
Je ne suis pas informaticien, je ne vous dirai pas comment ça marche, mais j'ai bien compris que pour faire correctement tourner cette bête (DXO 5.1) qui vaut 250 € il faut inverstir 800€ dans la bécane et ça ce n'est pas dit dans la chanson, sinon ils vendraient sans doute moins de logiciels. Mon Pentium4 avec ses 2,8 GHz et son petit Go de mémoire vive était à bout de souffle.
Cela dit le travail avec la version 5.1 en un régal de photographe, par sa souplesse et son ergonomie . Encore merci JMS.

[Yves2b]

...
Je viens surtout de racheter une unité centrale avec Core 2 quad, 3 Go de mémoire vive, 500 Go de disque dur etc...
Je ne suis pas informaticien, je ne vous dirai pas comment ça marche, mais j'ai bien compris que pour faire correctement tourner cette bête (DXO 5.1) qui vaut 250 € il faut inverstir 800€ dans la bécane et ça ce n'est pas dit dans la chanson, ...

Dès que j'aurai un peu de monnaie, je crois que je ferai la même chose : nouvelle carte mère, nouveau processeur, avec la mémoire et la carte graphique qui vont avec ....
J'espère que cela aidera Dxo 5.1

Ceci étant dit, je reconnais que depuis mon premier crash en essayant cette version 5.1, j'ai pu traiter qqs centaines d'autres photos sans autre problème ! Et en particulier la fonction de la pipette pour régler la BdB est maintenant exempte de bug ...

Pourvu que çà dure

Yves

[Phoebe]

Le manque de puissance n'est pas une explication satisfaisante aux plantages.
Par contre, en changeant de machine, on repart d'une situation matérielle mais surtout logicielle différente.
Entre autre, les différents patchs, les logiciels installés etc ...
Et dans le cas de la version 5.1, il y a aussi les drivers Interlock qui sont plus installés alors qu'ils restent si on passe d'abord par la 5.0.4.
Bref, ca marche sur ma machine virtuelle même avec 512Mo mais peut-être parce qu'il n'y a rien d'autre d'installé.

[Hawkeye]

Qu'il y ait quelques bugs, je n'en disconviens pas, mais de là à monter tous ces fils contre un soft français plutôt innovant et donnant des résultats que je trouve remarquables, c'est se tirer une balle dans les pieds (des développeurs français).
J'ai changé de machine il y a 4 semaines, j'ai pu refaire l'installation et réactiver DXO en moins de deux, suivi d'un batch de 270 photos sans aucun problème.
Je n'en avais pas beaucoup non plus avec mon ancien PC, il est vrai que je ne joue pas non plus à DXO avec un 486 à 66 Mhz et 32 MB ...

[estebanj]

Bonjour,
je confirme mes écrits du 21 juin au sujet de DXO 5.1.
Après le traitement de 3 projets avec de 400 à 570 images, sur mon nouveau PC, c'est une réussite.

Le traitement est très rapide moins de 2h pour le plus gros dossier, quand au résultat...allez voir sur mon site mes photos de théâtre 2008, je précise que je travaille avec un "vieux" 20D à 1600ISO. Dans des conditions d'éclairage complexes (les metteurs en scène adorent mixer les lumières et je n'est évidemment pas mon mot à dire).

La qualité du résultat obtenu avec DXO 5.1 est remarquable étant donné les conditions de prise de vue, bien que certaines fonctions ne soient pas opérationnelles (diaporama...), je reste satisfait en attendant la version 5.2 avec tout qui marche...

Allez le DXO team encore un effort!!!!!!!!!!

[Phoebe]

A la relecture de ce fil, on peut donc en conclure que la 5.1 ne plante plus.

Car je reste persuadé que la disparition des plantages chez certains n'est pas lié au changement de machine mais à un système "propre".
Par exemple débarassé des drivers Interlock restant de la 5.0x
On pourrait d'ailleurs se demander pourquoi, sinon, DxO aurait viré cette protection indispensable (sic)

Donc, à moins d'avoir besoin d'un pretexte , avant de changer de PC, je conseille de réinstaller Windows.

[ryb]

...allez voir sur mon site mes photos de théâtre 2008, je précise que je travaille avec un "vieux" 20D à 1600ISO. Dans des conditions d'éclairage complexes (les metteurs en scène adorent mixer les lumières et je n'est évidemment pas mon mot à dire).

La qualité du résultat obtenu avec DXO 5.1 est remarquable étant donné les conditions de prise de vue

Bonjour,
Belles photos !!
Pourriez-vous mettre en ligne un crop comparé avant-après ?
Merci par avance !

[Nef]

Bonjour,
Je partage l'agacement, voire la colère de certains sur ce qui se passe et passé avec DXO. Mais là où je suis moins, pourquoi seulement DXO subit-il les foudres des uns et des autres ?
MainSoft, j'ai bien suivi tes explications, mais juste 2 exemples :
- Les fichiers temporaires qui traînent sur le disque dur : si tu utilises Carpture NX, c'est du même tonneau
- Les plantages répétés : pour faire fonctionner DXO 5.01 "correctement", j'ai du mettre à jour ma carte nVidia. Là c'est le diaporama View NX qui ne marcahait plus... Attente d'une nouvelle m-à-j et là multiples plantages. Quelques jours après, nouvelle release... écrans noirs... puis encore une autre quelques semaines après : figeages sous DXO même avec la 5.1, et parfois sous d'autres appli. Enfin une autre m-à-j est sortie, et là : miracle !! Plus de plantage, les diaporamas refonctionnent et je peux même utiliser la fonction accélération GPU (case cochée dans paramètres), fonction à laquelle j'avais renoncé dès le début et qui change vraiment la rapidité d'affichage.
Je précise, BIOS à jour, tous les pilotes à jour, 2 Go RAM, Dual 3. 0 GHZ, nVidia 6200, .net framework réinstallés... bref si DXO est à montrer du doigt pour sa gestion de la 5.x, ses petits camarades de renom ne font pas mieux !
Cordialement
Bruno

[vuleria73]

je confirme que bien évidemment il est plus qu'agaçant d'utiliser un logiciel qui plante plus souvent qu'à son tour.
par contre, je tiens à dire que ce soft (français pour une fois!) est vraiment efficace et donne de superbes photos.
son travail en automatique est le plus souvent impeccable, le recours aux réglages manuels étant très réduit pour la plupart des photos. par le passé j'ai utilisé différents dématriceurs (rawshooter, bibble, nX...) mais j'ai re-traité toutes mes photos avec dxo car c'est lui qui me donne les meilleurs résultats.
alors, à l'heure ou beaucoup se font un plaisir d'étriller ce logiciel, j'avais envie de "dédramatiser" un peu la situation dont je pense qu'elle sera réglée rapidement par l'équipe dxo.