Plantages avec la verison 5.1 ?

[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]

[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!.

[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.

[Yves2b]

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.

Personnellement, cela ne m'a procuré aucun plaisir de rapporter les pbs rencontrés avec les différentes versions de DOP 5.0.x
J'aurais préféré, et de loin, n'avoir que des louanges à lui adresser.

Je reconnais volontiers que la 5.1 est une réelle avancée dans l'histoire de cette version 5.
Quant à la "rapidité pour régler la situation" ... je rappelle tout de même à vuleria73 que cette saga a commencé il y a plus de 6 mois !  Amha, cette 5.1 aurait dû être la 5.0.1   ...



Cordialement
Yves

[Phoebe]

- Les plantages répétés : pour faire fonctionner DXO 5.01 "correctement", j'ai du mettre à jour ma carte nVidia. ...

On est à la limite entre le logiciel et le matériel.

Ce que je disais ....

Car je reste persuadé que la disparition des plantages chez certains n'est pas lié au changement de machine mais à un système "propre".

... reste donc valable sauf que j'aurais du dire "à une machine plus puissante".

A moins que quelqu'un ait une expérience de DxO plantant, puis ne plantant plus simplement après augmentation de la mémoire ou changement de processeur  ?