DxO V6 : version aboutie ?

Démarré par titroy, Novembre 23, 2009, 20:30:55

« précédent - suivant »

titroy

J'ai cédé et j'ai acheté la mise à jour...
Installation : sans aucun problème, mais je n'en avais pas eu non plus avec la V5.

Je viens de traiter mes 20 premières photos :

- 1 plantage : "DxO ne répond plus" dans la phase de traitement aprés ...avoir traité 6 photos
- La mise à jour auto a des ratés ou les minutes n'ont pas la même durée : la prémière est réalisée aprés un laps de temps correspondant aux pref, les suivantes....???
- A 3 reprises, aprés avoir sauvegardé le projet, puis relancer DxO,...j'ai retrouvé l'état initial des feux
tricolores (c'est à dire positionnés à 'orange') - la 4ème fois, une image n' a pas la valeur adhoc.
- A l'ouverture du dit projet et sans autre manipulation : 49 fichiers laissés dans temp, 70 Megs, quand même !!!!!
Je sais, le script.....mais les développeurs travaillent comme des...chez DxO !!!!

- J'utilise 2 écrans : j'apprécie beaucoup le fait que l'on puisse détacher la fenêtre projet : un vrai plus. Je glisse également 'ma palette' sur le 2ème écran, le 1er écran étant réservé à l'image.
Lorsque je relance DxO, "ma palette" n'est affichée sur aucun des 2 écrans - remède : décocher/recocher la palette.

Pas convaincu par la V6......la V5.3.3 est "plus aboutie"  ;D 

stabilo60

Je travaille avec NX et j'ai voulu essayer DXo pour voir ce que ça donnait sur des photos de D3 à 5000 isos. Ça faisait pas 10 sec. que j'avais ouvert la première photo que le programme se plantait lamentablement.

Je n'étais pas convaincu avant d'essayer. Je le suis encore moins maintenant >:(

titroy


"- A 3 reprises, aprés avoir sauvegardé le projet, puis relancé DxO,...j'ai retrouvé l'état initial des feux"

Quelle horreur  :(

gerarto

J'ai la V6 quasiment depuis sa sortie, mais très peu de plantage :

1 une fois dans la phase de personnalisation, mais je n'ai rien perdu : hasard ou sauvegarde auto juste avant ?

Et 3 ou 4 fois le même message (DxO ne répond plus), mais à chaque fois c'était après la fin du traitement, donc pas de PB au final. Dans tous les cas pour ce plantage, je laissait DxO travailler et j'étais sur une autre application. Je ne sais pas si ça a un rapport...

Par contre 70 mégas dans temp pour une session de 20 photos, ça me paraît beaucoup : est tu sûr que tous les fichiers sont de DxO ?

fabco

Cela fait 15 jours que j'essai dxo v6 sans aucun plantage.Je développe des raw de 18Mo(a700) sortie en tiff ou jpeg.Je suis sous xp avec 1Go de mémoire proc x2 alors que dxo préconise plutôt 2Go de mémoire.

Peik

J'ai DxO V6 depuis sa sortie... et les plantages sont de retour comme au "bon vieux temps" de la sortie de la version 5 !
XP, 2Go

J'ai identifié un premier :

Le module objectif 300 F2.8 n'existe pas pour mon 5DII mais DxO me propose de force le 300 F4...
J'accepte donc pour "voir"..
Pas de plantage si la photo est à F4 ou supérieur, plantage sinon.
OK, c'était un test, donc pas significatif.  ;)

Je désinstalle donc le module...

Mais, à chaque utilisation, j'ai quand même au moins un ou deux plantage, surtout pendant les manips ou j'agrandis pour vérifier les effets de réduction de bruit et de netteté..
Depuis je sauve régulièrement à chaque modif de règlage !

Pas de plantage pendant le traitement par contre jusqu'à présent.


delbanof

Je confirme avoir exactement les mêmes plantages sur windows 7 64 bits. ;D
Fabrice

Labuzan

Pour les plantages en fin de traitement, n'oubliez pas de mettre un environnement couleur (ex :sRGB) dans le format de sortie (tout en bas de la fenêtre).
A défaut c'est plantage assuré, bien que les photos soient correctement exportées.
Cordialement.
Canon 6D-5DMkIII-5DMKIV

JMS

Aucun problème sous Vista 32 et XP...les plantages sont-ils liés à une certaine version de Windows ? Ce qui est amusant c'est quand il annonce 1 h de travail pour un batch et qu'il met en réalité deux fois moins de temps: on n'a pas le temps de finir l'apero  ;)

cagire

Citation de: JMS le Novembre 24, 2009, 10:36:20
Aucun problème sous Vista 32 et XP...les plantages sont-ils liés à une certaine version de Windows ? Ce qui est amusant c'est quand il annonce 1 h de travail pour un batch et qu'il met en réalité deux fois moins de temps: on n'a pas le temps de finir l'apero  ;)
C'est un peu la réflexion que je me faisais tous ces problèmes évoqués sont-ils imputables au logiciel ou à son propre ordi ?
V6 chez moi fonctionne sans souci, sous XP SP3.
J'ai l'impression que dans certains DD y'a profusion de fichiers d'applications multiples et de mises à jours Windows automatiques en conflits.

fabco

DXo demande beaucoup de ressource, aussi ces plantages sont-ils du aussi quand l'utilisateur essai de faire autre chose en même temps.Les os ne sont peut être pas à jour non plus.

gerarto

Citation de: Labuzan le Novembre 24, 2009, 09:37:46
Pour les plantages en fin de traitement, n'oubliez pas de mettre un environnement couleur (ex :sRGB) dans le format de sortie (tout en bas de la fenêtre).
A défaut c'est plantage assuré, bien que les photos soient correctement exportées.
Cordialement.

Pour moi, c'était bien renseigné (mais les plantages ont été rares).

Citation de: JMS le Novembre 24, 2009, 10:36:20
Aucun problème sous Vista 32 et XP...les plantages sont-ils liés à une certaine version de Windows ? Ce qui est amusant c'est quand il annonce 1 h de travail pour un batch et qu'il met en réalité deux fois moins de temps: on n'a pas le temps de finir l'apero  ;)

En même temps, c'est peut-être voulu : on est content que ça aille plus vite : DxO ça dépote ! alors que si c'était l'inverse, on aurait râlé que, comme d'hab, DxO se traîne...  ;D ;D ;D

Trêve de plaisanterie : je viens de voir qu'on avait la possibilité de traiter jusqu'à 8 photos simultanément, même si c'est 2 qui est recommandé. Comme j'ai un "vrai faux" 8 cœurs, il va falloir que j'essaye !

titroy

#12
Citation de: JMS le Novembre 24, 2009, 10:36:20
Aucun problème sous Vista 32 et XP...les plantages sont-ils liés à une certaine version de Windows ? Ce qui est amusant c'est quand il annonce 1 h de travail pour un batch et qu'il met en réalité deux fois moins de temps: on n'a pas le temps de finir l'apero  ;)

Je suis aussi sous Vista 32 SP3 et j'ai eu un plantage au cours du 1er traitement de 20 nefs : aucune autre application ouverte.
Ma config : 2Go, Intel Duo 2*1,83, Carte Nvidia 512 Megs dédiés
Depuis, je n'ai plus eu de plantage, mais :
> Alors que la sauvegarde auto déclenche bien la sauvegarde, aprés plantage...retour à l'état initial : pas compris
> Perte du positionnement des feux tricolores lors du rappel d'un projet sauvegardé : retour à l'orange sur toutes les photos.
--> A noter : exemple : changement d'un feu, sauvegarde et rappel : le feu est bien positionné.
Arrêt/relance de DxO : retour à l'orange....
Cela m'ennuie beaucoup : je vais le signaler à DxO.
Pourriez vous faire un essai de votre coté ?

> Le flag 'traité' n'apparait pas sur toutes les images traitées lors du rappel d'un projet : génant également.
> Beaucoup trop de fichiers temp non supprimés : 2 à 3 fois plus qu'en V5 ou le nombre était fixe.
Ce n'est pas très compliqué pourtant : tabulation des fichiers créés, lookup de la table à la fermeture et del. (3 instructions !!!!!). Ces détails ne sont pas très admissibles, de mon point de vue.
Vous imaginez un traitement éxecutant, toutes les nuits, quelques milliers de process qui  laisseraient les serveurs dans un tel état ?
 
> Temps de traitement : RAS, très correct - me semble même un peu plus réactif qu'en V5 quant à l'affichage des ajustements : quasi immédiat.
> Détachement de la fenêtre 'projet' : un vrai plus avec un 2ème écran ! (signalé dans mon 1er post) ainsi que la sauvegarde de la configuration d'affichage.
> Qualité des images produites avec les mêmes paramètres : RAS, nickel
> Taille des fichiers Jpeg : en 200 isos, la taille du fichier est très proche de celle du....nef à 100% de compression - ce n'est pas un problème
> Plugin LR : fonctionne correctement.

Quel dommage de voir ces petits détails, génants voire trés génants, ternir un outil aussi performant dans son traitement. C'est mon avis....
Question : (j'en profite...) dans quel cas, le nom du projet est il suivi d'un '*' ?
Merci pour vos retours
Michel

Edit : pour illustrer :
DSC_2193 : feu positionné à 'rouge' - tous les autres positionnés à 'vert' : tous sont revenus à l'orange.
Flag traitement : positionné sur le 2194, n'apparait plus sur les autres.
Ne pas tenir compte de la 'qualité' : photos prises pour essai V6  ;)

John Lloyd

Je n'ai jamais eu le moindre souci avec DXO, aucun plantage. Seul bémol, les demandes de réactivation des versions 4 et FilmPack 1 après avoir nettoyé mon PC avec Registry Mechanic et CCleaner. Mais du point de vue fonctionnement et "fiabilité" de DXO, no soucy pour moi  ;)

Phoebe

Citation de: titroy le Novembre 24, 2009, 11:41:33
Question : (j'en profite...) dans quel cas, le nom du projet est il suivi d'un '*' ?

Je n'ai pas ma machine DxO sous la main pour vérifier mais ce ne serait pas quand il est modifié et pas enregistré ?

Philippe

Labuzan

Citation de: JMS le Novembre 24, 2009, 10:36:20
Ce qui est amusant c'est quand il annonce 1 h de travail pour un batch et qu'il met en réalité deux fois moins de temps: on n'a pas le temps de finir l'apero  ;)
Chez moi c'est le contraire, il met le double de temps qu'annoncé (~1mn15s par photo de 50D), ça m'oblige à prendre 2 apéros  :D

Plus sérieusement, je confirme que dans les traitements/options avancées, je ne peux pas laisser "Original" sous peine de plantage. Je lui rentre sRGB et tout va bien.
Canon 6D-5DMkIII-5DMKIV

titroy

#16
Citation de: Labuzan le Novembre 24, 2009, 14:30:37
Chez moi c'est le contraire, il met le double de temps qu'annoncé (~1mn15s par photo de 50D), ça m'oblige à prendre 2 apéros  :D

Plus sérieusement, je confirme que dans les traitements/options avancées, je ne peux pas laisser "Original" sous peine de plantage. Je lui rentre sRGB et tout va bien.

:D :D :D
J'ai bien noté : 2 apéros, et sRGB et tout va mieux.
Utilisant DxO en plusieurs fois pour une même série, par faute de temps, ce nombre impressionnant de fichiers temp m'interroge...combien si je développe une centaine ?
Ce n'est pas tant de les supprimer (ccleaner, script..), quoi que...., je n'ai pas très envie d'avoir à défragmenter le disque 'c', c'est toujours un peu 'chaud'....
Si on pouvait assigner ces fichiers à un DD externe...

J'ai lancé la V5, ce midi sur les mêmes images : la V5 génère bien 5 fois moins de fichier temp (controlé en cours d'execution).
Donc, la V6 a bien changé le traitement, et en profondeur. !

De même le GPU est moins 'sollicité' dans la phase de traitement. Cela me parait net.
J'ai aussi controlé : la valeur des feux tricolores est bien sauvegardée en V5. (un fait est toujours mieux qu'une impression...)

Pat91

Bonjour,

Mis à part les pbs de gestion mémoire liés au volume des données à traiter (et en particulier la gestion de la taille de la pile sous .Net), je pense qu'il ne faut pas négliger dans ces problèmes d'instabilité la part prise par PACE Interlok (surtout pour les plantages au démarrage). Son comportement anarchique selon les systèmes peut expliquer que certains ne soient jamais gênés et d'autres si.

Je ne comprends vraiment pas l'obstination de DxO à utiliser ce système connu des développeurs pour être plus que calamiteux. Le passage à la V6 était une occasion unique de passer à un autre système de protection. Raté. Voilà 2 ans que le pb des fichiers temporaires générés par PACE Interlok a été signalé et qu'aucune solution n'a été mise en place. Pire, la taille des fichiers est maintenant encore plus importante.

En outre, la V6 continue d'être une application mixte et pas une application .Net pure. Elle utilise les mécanismes de .Net Interop pour certaines (toutes les?) opérations graphiques. C'est-à-dire qu'elle mélange les mécanismes de .Net et les mécanismes Win32 (appels directs à l'API système). C'est un point de vue personnel mais j'ai toujours prétendu dans mes cours que cette approche ne pouvait être que transitoire car elle présente de graves inconvénients.

Pour faire simple:

Un programme purement .Net permet à tout moment de garder le contrôle et de traiter dans des conditions optimales les erreurs qui peuvent se produire pendant l'exécution du code. Dès que l'on utilise le mécanisme Interop d'accès direct aux APIs système (ce que fait donc toujours la V6), on sort de cette "coquille protectrice". Toute erreur qui se produit pendant l'exécution du code "non .Net" ne peut pas être détectée par le code appelant, traitée et à plus forte raison récupérée. La seule issue possible est le plantage du programme qui a perdu la main, l'erreur se trouvant dans une partie du code hors de son contrôle. Et ces problèmes sont d'autant plus difficiles à identifier et à résoudre qu'il est quasiment impossible de déboguer le code exécuté à l'extérieur de l'environnement .Net. D'où l'absence chronique de réponse de la part de DxO sur ce type de bugs.

DxO dispose d'une compétence reconnue dans le traitement d'image et gâche sa réputation en traitant certaines parties du développement de DOP de manière peu professionnelle. C'est vraiment du masochisme.

Je reste donc sur mes jugements précédents concernant la V5 (malgré les progrès évidents de la V6 sur certains points). Je l'avais dit lors des discussions homériques sur la V5: tant que ces problèmes de conception n'auront pas été résolus, les problèmes d'instabilité et de plantages aléatoires persisteront. La V6 ne change pas fondamentalement la donne sur ces points, me semble-t-il. Cela ne veut pas dire que l'application est inutilisable mais il y a ceux pour qui ça se passera bien et ceux qui se seront perpétuellement ennuyés par ces plantages. Cela sera lié à la configuration de leur système, à la manière dont ils utilisent DOP et aux quantités de données qu'ils traitent simultanément.

Mon grain de sel...

PS: Cela ne veut pas dire que je ne ferai pas la mise à jour: les progrès spectaculaires en matière de traitement du bruit vont m'éviter de remplacer mon Canon G10 par un G11.
Patrick

Pat91

Citation de: titroy le Novembre 24, 2009, 14:47:41Si on pouvait assigner ces fichiers à un DD externe...

On peut toujours personnaliser l'endroit où se trouve le dossier TEMP personnel: Panneau de configuration => Système => Avancé => Variable d'environnement. Modifier TEMP et TMP pour l'utilisateur concerné. Créer les dossiers au préalable.

Attention, il faut que le dossier soit dispo en permanence, ce qui implique que le DD externe tourne dès le démarrage.
Patrick

titroy

Citation de: Pat91 le Novembre 24, 2009, 14:58:16
On peut toujours personnaliser l'endroit où se trouve le dossier TEMP personnel: Panneau de configuration => Système => Avancé => Variable d'environnement. Modifier TEMP et TMP pour l'utilisateur concerné. Créer les dossiers au préalable.

Attention, il faut que le dossier soit dispo en permanence, ce qui implique que le DD externe tourne dès le démarrage.

Merci Pat, mais je connaissais. J'aurais aimé le faire uniquement pour DxO....
Je peux créer un compte....je vais voir de ce coté (allergique à la défragmentation du disque système, même avec image disque préalable...)

Pat91

Citation de: titroy le Novembre 24, 2009, 15:09:51
Merci Pat, mais je connaissais. J'aurais aimé le faire uniquement pour DxO....

C'est possible en utilisant le script que j'ai proposé. Un processus lancé via une console ou un autre processus hérite de l'environnement du processus "lanceur" (je ne dis pas "parent", ce n'est pas de l'Unix). Il suffit donc d'ajouter la modification concernant les variables TEMP et TMP avant la ligne qui lance DOP. Pour les 2 exemples que j'ai proposés le script deviendrait donc

Solution 4NT:

[at] echo off
set temp=c:\poubelle
set tmp=c:\poubelle
"C:\Program Files\DxO Labs\DxO Optics Pro v6\DxOOpticsPro6.exe"
delay 30
del %temp%\pil*.tmp
del %temp%\ptm*.tmp
del %temp%\t*.tmp
del /sxyz %temp%\AjBTBe18\
del /sxyz %temp%\sQCbDSIce\

Solution Windows PowerShell

c:
cd "C:\Program Files\DxO Labs\DxO Optics Pro v6\"
$env:temp = "c:\poubelle"
$env:tmp = "c:\poubelle"
Invoke-Item "DxOOpticsPro6.exe"
sleep 30
del $env:temp\pil*.tmp
del $env:temp\ptm*.tmp
del $env:temp\t*.tmp
del -force -recurse $env:temp\AjBTBe18\
del -force -recurse $env:temp\sQCbDSIce\

1. Il est important de modifier TEMP et TMP. Visiblement DOP se sert de TEMP et PACE de TMP. Bonjour la cohérence. Mais habituellement, TEMP et TMP pointent sur le même dossier. C'est pour cela que mon script précédent fonctionne.

2. Modifier les variables TEMP et TMP dans le script n'affecte pas leur valeur au niveau système. Les autres programmes ne seront pas affectés.

J'ai testé, ça fonctionne.
Patrick

titroy


barbozaure

Citation de: titroy le Novembre 24, 2009, 11:41:33
Question : (j'en profite...) dans quel cas, le nom du projet est il suivi d'un '*' ?
signifie qu'une modif. a été effectuée sur le projet
l'étoile disparaît dès sauvegarde (ou enregistrement) du projet
et réapparaît si nouvelle modif. ...   ;)

titroy

Citation de: barbozaure le Novembre 24, 2009, 21:13:16
signifie qu'une modif. a été effectuée sur le projet
l'étoile disparaît dès sauvegarde (ou enregistrement) du projet
et réapparaît si nouvelle modif. ...   ;)

Vu, Barbozaure, merci.

titroy

Pour info (dans l'accusé de réception DxO)

IMPORTANT: Notre service d’activation est temporairement indisponible. Dans le cas ou vous n’arriviez pas à activez immédiatement votre licence, sachez que vous pouvez provisoirement lancer la version d’essai (complètement fonctionnelle) du logiciel depuis l’écran d’activation.
Nous vous préviendrons par email dès que le service d’activation sera fonctionnel.
Veuillez nous excuser pour la gêne occasionnée