La 5.2 est annoncée...

[MainSoft]

... mais attendez un peu: le downloader qui vous dit qu'il va installer la 5.2 vous réinstalle la 5.1. Comme la dernière fois, le serveur, les annonces de DxO et le downloader ne sont pas synchrones. Ils n'apprendront jamais.

[Phoebe]

Errare humanum est.
Perseverare DxO est.

Et après, on s'étonne que certains diabolisent DxO 

[TAF]

>Convertisseur RAW époustouflant pour les images à très fort ISO

put... ca fait peur une telle phrase... Cela me rappelle le "DXO5 ira 4 fois plus vite que l'ancienne version...) On a vu le résultat dérrière...

[MainSoft]

... mais attendez un peu

Vous pouvez y aller, les serveurs sont enfin synchrones. Le downloader voit une 5.2 et miracle, il y a vraiment une 5.2 sur les serveurs .

Le download du package Update est plus court mais a tendance à planter. Le Full Download est plus long à télécharger mais ne semble pas planter en cours de route. Au niveau installation, le package Update insiste toujours pour installer la Runtime Microsoft alors que cela ne sert à rien puisqu'elle est déjà là. Et vu le temps que ça prend, on pourrait nous épargner cette contrainte.

Reste donc à tester...

On voit déjà qu'il y aura une 5.3 puisque les erreurs d'ergonomie dont nous parlons depuis longtemps et qui sont reconnues par DxO (en particulier dans la zone DxO Lighting) sont toujours là. Le problème des fichiers temporaires non supprimés également. Il paraît que cela dépend de PACE Interlok mais rien n'empêche les codeurs de DxO de s'occuper de cette suppression eux-mêmes. Ou de passer à un autre système de protection.

[Phoebe]

Dommage pour les déçus par la démo des versions précédentes

[flitter]

5.2 pour windows seulement on dirait ??

[poloox]

5.2 installé sans problème. Cette version a l'air de marcher... au moins aussi bien que la 5.1  . Je n'ai pas vu beaucoup de différences pour l'instant, mais j'ai juste fait un petit essai rapide.

Ils ont corrigé le problème de distance non renseignée pour les Canon: maintenant la distance est mise à l'infinie par défaut et il n'y a plus de message d'erreur. Je pense que c'est mieux comme ça.

Toujours est-il que maintenant DXO est tout à fait fonctionnel et sympa à utiliser, du moins sur mon PC et malgré encore pas mal de détails à regler. Il leur a tout de même fallu 7 mois pour sortir une version correcte depuis la 5.0 donc j'imagine que le nombre de bugs devait être colossal. Ils se sont précipité pour sortir une nouvelle version pour noël 2007 mais je crois qu'elle sera nickel pour noël 2008. Ha markéting quand tu nous tiens! 

[Giorgio]

Après un premier test rapide, je n'ai vu aucune différence avec une image à 800 iso issue d'un D80.
Peut-être faut-il un boîtier permettant de monter plus haut ?

[Crazy Chris]

Je viens de réaliser un batch d'environ 450 nef 14 bit de d300 et 50 nef de d200 et c'est passé comme une lettre à la poste. Je ne peux pas vraiment comparer avec la 5.1 que j'ai peu essayée...
Par contre, est-ce normal que seules 2 images soient traitées à la fois sur mon Q6700 ?

[Phoebe]

Par contre, est-ce normal que seules 2 images soient traitées à la fois sur mon Q6700 ?

Ca dépend de la mémoire que le programme peut allouer à chaque traitement.
http://help.dxo.com/faq/index.php?action=artikel&cat=1820&id=18200020&artlang=fr

[Crazy Chris]

Ah ok, ce n'est donc pas vraiment le nombre de cœurs qui définit cela alors... Pourtant j'ai bcp de ram !

[Philippe Boulet]

Je pense que le nombre de coeurs définit le nombre maximum de photos traitées simultanément.
Ca n'aurait pas de sens de traiter 2 photos en // si le temps de traitement de chacune était doublé (et même plus)

Pour ma part, je limite le traitement sur un cœur (j'ai un dual core) ce qui permet de ne pas pénaliser du tout les autres actions simultanées: Internet, bureautique, jeu d'Echecs en ligne (pour les analyses, j'attribue toute la puissance au programme).

[Verdi]

Je suis enthousiasmé par cette nouvelle mouture de DxO. Seul petit reproche, toujours lent, mais je pardonne au vue des résultats

[Bartje]

Et oui, je viens d'acheter la version 5.2 pour mac mais oh suprise : malgré les bons modules installées, il ne reconnaît pas mon Pentax k20D ni l'objectif qui va avec (Pentax 16-50) donc impossible de traiter des images raw. Ce n'est pas la faute à mon boitier car les info's EFIX sont parfaitement visibles sur Photoshop. Par ailleurs il ne reconnaît pas le format DNG, seulement le format propriétaire Pentax. Et pour pour ne rien gâcher le plugin Photoshop CS3 fait crasher Photoshop. Je viens de dépenser une jolie somme pour un logiciel qui ne me sert à rien pour le moment. J'espère que ça s'arrangera

[photix]

Bien de la chance pour les utilisateurs satisfaits ! Je rencontre (sur Mac) toujours le même problème, que ce soit avec la 5.1 ou la 5.2: impossible d'appliquer un traitement à mes NEF, individuellement ou en traitement par lot... Un message s'affiche: "ECHEC DU TRAITEMENT: une erreur est intervenue lors du traitement de l'image (can't create full image)" (sic)...

[Verdi]

Bien de la chance pour les utilisateurs satisfaits ! Je rencontre (sur Mac) toujours le même problème, que ce soit avec la 5.1 ou la 5.2: impossible d'appliquer un traitement à mes NEF, individuellement ou en traitement par lot... Un message s'affiche: "ECHEC DU TRAITEMENT: une erreur est intervenue lors du traitement de l'image (can't create full image)" (sic)...

Je ne comprends pas ce qu'il t'arrive, je suis aussi sur Mac I.mac et j'ai aussi un Nikon (D3) et je dois avouer, tout fonctionne correctement. Fais-en part à DxO et réinstalle-le à nouveau !

[Olivier_G]

J'ai l'impression que la réduction du bruit a atteint un très bon niveau, même si Neat-Image est encore légèrement meilleur sur le bruit de fréquence très basse.

Par contre DxO Optics Pro pèse 600Mo avec son .Net Framework, a une ergonomie médiocre et une interface lente (effets graphiques lourds, cache mal optimisé...).
C'est vraiment dommage, car le coeur du programme (corrections de Distortion, AC, Piqué, Vignétage) est superbe.

Vous savez comment réduire la taille occupée par ce .Net Framework à la noix? (quels fichiers supprimer?) Et s'il est possible d'enlever des effets inutiles de l'interface?

[jmaa]

Vous savez comment réduire la taille occupée par ce .Net Framework à la noix?

A priori ce n'est pas négociable: c'est une librairie système qui vient en un seul tenant. Le bon coté de la chose est qu'il ne sera pas nécessaire de la recharger lorsque'une autre application en aura besoin.

[MainSoft]

Vous savez comment réduire la taille occupée par ce .Net Framework à la noix? (quels fichiers supprimer?)

Bonjour,

C'est une requête sans objet a priori . Si vous vous basez sur ce qu'annonce le Gestionaire de Tâches pour dire que le programme occupe 600 MB, sachez c'est une indication qui peut induire en erreur. En effet, le framework .Net utilise un gestionnaire de mémoire (dit Garbage Collector ou GC) qui fonctionne suivant des algorithmes relativement complexes mais qui est basé sur un principe simple: afin d'éviter une activité trop gênante et trop perturbante du Garbage Collector comme c'est le cas avec d'autres technologies, ce dernier n'intervient pour récupérer de la mémoire que lorsque cela est vraiment nécessaire.

Pour faire simple: l'application alloue des blocs mémoire pour certains objets quand elle en a besoin. Quand ces objets ne sont plus utilisés par l'application, le GC le détecte automatiquement et inscrit ces blocs mémoire comme potentiellement destructibles. Mais ils ne seront réellement récupérés que si le système a effectivement besoin de cette mémoire. Donc à l'instant T, Windows peut indiquer une mémoire utilisée nettement plus importante que celle dont le programme a besoin mais c'est sans importance car on sait que cette mémoire sera vraiment libérée au moment opportun. Cette manière de faire présente d'autres avantages dont j'éviterai la description à un non développeur.

Donc pour résumer, les applications .Net donnent toujours l'impression de consommer plus de mémoire qu'elles n'en mobilisent en réalité.

Par ailleurs, il est hors de question de modifier quoi que ce soit au framework car c'est une ressource commune partageable entre applications. Supprimer des fichiers ne servirait également à rien car tant que le framework .Net n'a pas besoin d'un module, ce dernier ne consomme aucune ressource sauf de l'espace disque. Demême, quand aucune application .Net ne tourne, aucun module du framework .Net n'est actif dans le système et il n'y a donc aucun impact sur les performances ou l'occupation mémoire.

En espérant avoir été clair...

[Olivier_G]

Merci pour ces réponses.

Les 600Mo de DxO+Framework dont je parlais sont pour l'espace disque occupé après installation (pas la RAM). On est quand même déjà largement dans le domaine du bloatware.

Pour info, j'ai un Windows XP que j'ai optimisé en retirant les services et fichiers inutiles et qui tourne au top depuis 5 ans. Je choisis des applications qui font leur travail proprement et simplement (ex: je n'utilise pas Photoshop mais Picture Window Pro). J'ai plus de 150 applications installées sur mon PC et aucune - bien entendu - n'utilisait Net Framework. Quand je vois que ce Framework installe plusieurs dizaines (centaines?) de Mo de fichiers en double exemplaire, je me dis qu'il doit être possible de faire le ménage (un peu comme avec Windows).

Pour finir: j'ai pas mal contribué pour essayer d'améliorer XnView (pas parfait... mais l'auteur est tout seul) et quand je vois Optics Pro... je me dis qu'il y a de quoi faire (même sous .Net  ).

[MainSoft]

Les 600Mo de DxO+Framework dont je parlais sont pour l'espace disque occupé après installation (pas la RAM). On est quand même déjà largement dans le domaine du bloatware.

Bonjour,

Nous n'allons pas entrer ici dans une discussion technique approfondie sur .Net mais si effectivement l'installation du framework coûte un peu d'espace disque (environ 30 MB pour le runtime .Net, pas 600 - le reste vient de chez DxO) il faut prendre en compte le volume que les applications .Net n'auront pas besoin d'installer puisqu'elles utilisent toutes ce même tronc commun. Quelques remarques cependant:

- Il n'y a pas encore beaucoup d'applications .Net mais cela va devenir progressivement le seul moyen de programmer efficacement sous Windows, notamment sous les nouvelles versions. En outre, Microsoft ne fournit plus qu'un seul outil pour programmer avec autre chose que .Net: le C++.

- À mes yeux (ce n'est qu'un avis mais il est partagé par de nombreux développeurs), .Net représente l'évolution la plus marquante en termes d'outils de développement depuis l'arrivée de la programmation orientée objet. C'est probablement l'environnement de développement le plus moderne disponible à ce jour. À tel point que même les opposants chroniques à Microsoft dans le monde du libre ont mis en œuvre .Net sur d'autres plates-formes que Windows et en particulier sous Linux (projets Mono et DotnetGNU). On pourrait donc, moyennant un effort relativement modeste de DxO, disposer d'une version de DOP sous Linux.

- Si certains fichiers du framework sont apparemment dupliqués c'est que .Net permet l'utilisation simultanée de plusieurs versions d'un même composant ce qui évite de nombreux problèmes.

- Le framework .Net demande aux développeurs un apprentissage relativement long et suppose déjà maîtrisées certaines disciplines comme la programmation orientée objet (sur laquelle la France possède un déficit culturel important et qui se comble trop lentement), les méthodologies de conception objet (idem), les méthodes de test modernes (TDD - idem), XML, techniques de débogage ... Mal utilisé, .Net peut donner des résultats peu convaincants. Et c'est là que je reviens sur mes constatations initiales: DOP présente de manière évidente des défauts de conception et est totalement déficient en termes de procédures de test et de débogage. À mon humble avis, DxO devrait d'ores et déjà s'attaquer à une réécriture car la version 5 restera probablement un long chapelet de mises à jour amenant avec chaque release son lot de corrections et de régressions sans corriger les instabilités fondamentales.

- Enfin, notons que .Net fournit normalement tous les outils pour contrôler les crashes de l'appli et reprendre la main sans dommages pour l'utilisateur. Cependant, DOP n'est pas une application purement .Net mais une application mixte mélangeant à la fois du code .Net et du code Win32 classique via un mécanisme nommé Interop. C'est à mon avis un des points cruciaux à l'origine des problèmes rencontrés. .Net protège naturellement les applications contre les fuites mémoire et les crashes mais si ceux-ci se produisent pendant que l'on est en train d'exécuter du code Win32 standard, le framework .Net ne voit rien et ne peut pas reprendre le contrôle en cas de crash. Toute application utilisant Interop perd automatiquement le bénéfice d'une bonne partie des avantages de .Net. Je suppose que DxO a fait ce choix car ils n'ont pas voulu ou pas pu porter certains traitements graphiques sous .Net.

Cordialement.

[Olivier_G]

Merci, c'est très intéressant.

Je ne suis pas complètement fermé à .Net (même si Wikipedia indique "Certains développeurs sont dérangés par la taille importante du framework (environ 54Mo pour le .NET 3.0 et 197Mo pour la version 3.5)" et que je vois 150Mo dans Program Files>DxO et 400Mo dans Windows>Assembly+Microsoft.NET) et surtout DxO Optics Pro m'intéresse toujours beaucoup.

Mais j'aime bien les applis en C++, moi...
J'ai réessayé RawShooter... et ça c'est un modèle d'optimisation! (<10Mo sur le disque, très léger en RAM, réactivité immédiate...). En bref, j'aimerais les corrections de Optics Pro dans RawShooter...