DxO 5.2 Dominante chaude après traitement Raw

[gerarto]

Si Alexandre (SupportDxO) est passé par ici, il repassera peut-être par là, ce qui m'intéresserait assez, car je viens de faire une constatation curieuse liée à la colorimétrie... 

J'ai expliqué dans un autre fil que tous mes fichiers jpeg ou tiff issus de la V5.2 perdaient le profil intégré Adobe RGB 98 qu'avaient les raw d'origine :

______________________________

"Pourtant, mes raw (Sony Alpha 700) ont bien le profil Adobe intégré et un traitement par le logiciel Sony (IDC) me sort bien un jpeg Adobe...

Dans DxO, préférences, j'ai profil d'affichage : profil de l'écran (mon écran est étalonné). A priori, ça n'a pas de raison d'intervenir sur la sortie, mais je précise quand même au cas où.
Dans les paramètres de sortie, j'ai : profil ICC original. Si je force à Adobe RVB, j'ai quand même un résultat identique. (Pas de profil)

Les anciens fichiers issus de la 4.5 ont bien un profil Adobe avec des réglages identiques. Je ne peux malheureusement pas traiter les fichiers de mon boîtier actuel (Alpha 700) dans la 4.5 qui ne le supporte pas...

Par curiosité, j'ai retraité avec la 5.2.1 quelques fichiers de mon ancien boîtier, ils perdent aussi le profil dans la 5.2 alors qu'ils l'avaient dans la 4.5"

______________________________

Ma visionneuse est ACDSEE pro V8 qui gère l'affichage des profils. Dans propriétés de l'image, j'ai : profil couleur intégré "SO" (sans objet je suppose), alors que j'ai : profil couleur intégré "Adobe RGB (1998)" pour les fichiers autres que la 5.2.

Je viens de faire un test supplémentaire : j'ai demandé dans DxO 5.2, 3 sorties d'un même raw en changeant à chaque fois uniquement le profil ICC dans les options de sortie:
- Original
- Adobe RVB
- sRVB

Lorque je visualise dans ACDSEE, l'original et l'Adobe sont strictement identiques, mais pour le sRVB, les rouges deviennent effectivement outranciers.

Lorsque j'ouvre ces mêmes images dans Photoshop CS, où j'ai un espace de travail Adobe, à l'ouverture du fichier sRVB s'ouvre la boîte de dialogue de non concordance des profils qui m'informe que ce fichier à un profil incorporé sRVB. Et là, que je garde le sRVB ou que je convertisse en Adobe, les trois fichiers ont bien la même apparence...    Accessoirement, puisque je n'ai pas eu la même boîte pour les deux autres, c'est probablement que le profil Adobe est bien incorporé ! 

Alors pourquoi certains logiciels semblent reconnaître le profil incorporé et d'autres non (alors qu'il était reconnu avec la V4.5) ?

Et est-ce que ça n'aurait pas un rapport avec le fait que certains voient une dérive des rouges et d'autres non ?

[gerarto]

Pour aller dans le sens de la demande de cagire  un montage de copies d'écran de ce que j'obtiens avec ACDSEE :

A gauche le jpeg "adobe 98", à droite le jpeg "sRVB"

Même si ça a perdu un peu de caricatural à cause des redimensionnements et des compressions, la différence reste flagrante.

Alors qu'en affichage dans Photoshop CS, il n'y a pratiquement aucune différence, si ce n'est que le sRVB est à l'inverse un poil plus pâlot, ce qui me semble dans l'ordre normal des choses...

[MainSoft]

Question pratique : j'ai 5 ou 6 bug d'IHM à remonter sur la version 5.2. Ou peut-on trouver la dernière liste à jour des bugs connus ?

Bonjour,

http://forum.dxo.com/project.php?do=issuelist&projectid=3 (anglais)
http://forum.dxo.com/project.php?do=issuelist&projectid=2&issuetypeid=BugReport (français)

À noter que l'essentiel des rapports et des discussions se trouve sur le forum anglophone.

[MainSoft]

Tu répètes cela également sur un autre fil que tu as ouvert et j'aimerais comprendre où est le problème. Peux-tu poster comme je le fais ici, avec des rouges.

Bonjour,

Comme je l'ai déjà annoncé, je ne participe plus à des discussions techniques sur DxO sur ce forum. Je continue de donner des références et des liens sur le site DxO où cette discussion se poursuit mais devant l'exaspération - certainement compréhensible pour de multiples raisons - provoquée chez certains par mes propos, j'ai choisi le retour au calme. Il se trouve qu'une fois encore, certains sont touchés par des bugs du produit et d'autres non. DxO a plutôt tendance à écouter les seconds. C'est comme ça depuis la sortie de DOP 5 et c'est probablement la caractéristique d'un produit instable.

Les forums DxO anglophone et francophone sont largement fournis en exemples de ce problème et nous sommes quelques-uns à avoir copieusement alimenté le forum et le site de DxO en échantillons divers.

http://forum.dxo.com/showthread.php?t=1935
http://forum.dxo.com/project.php?do=issuelist&projectid=3&issuetypeid=BugReport
http://forum.dxo.com/project.php?do=issuelist&projectid=2&issuetypeid=BugReport
http://forum.dxo.com/showthread.php?t=1970
http://forum.dxo.com/showthread.php?t=1918

Maintenant, il se trouve que DxO a déclaré hier sur le forum "Bug Reports" que ce n'était pas un bug et que nous utilisions mal le produit. Je constate donc un désaccord et l'absence de volonté de corriger un problème qui selon DxO n'existe pas. J'en prends acte. Cependant, comme disent Jean-Pierre Delmur et Saint Thomas, "Je crois ce que mes yeux voient".

Je ne vais pas leur faire un procès pour ça. Mais je ne vais pas non plus continuer à passer du temps à préparer des exemples, à expliquer en long, en large et en travers ce qui ne va pas alors que globalement, je fais ça, avec d'autres, depuis 9 mois et que cela n'a strictement aucune influence sur la manière dont DxO gère et développe ce logiciel. Je vais plutôt consacrer ce temps à photographier et je vais attendre calmement de voir comment DxO bouge. Mon sentiment est qu'ils vont continuer de s'enfoncer à cause de leur refus d'affronter la situation réelle. Si je me suis senti impliqué jusqu'à il y a quelques mois, ne serait-ce qu'à cause du prix que j'ai payé pour la licence et la mise à jour, là ce n'est vraiment plus mon problème.

Fatigué. Et maintenant occupé par les bugs d'impression de Lightroom 2 .

Cordialement.

[MainSoft]

Je constate donc un désaccord et l'absence de volonté de corriger un problème qui selon DxO n'existe pas. J'en prends acte. Cependant, comme disent Jean-Pierre Delmur et Saint Thomas, "Je crois ce que mes yeux voient".

Pour l'anecdote, l'attitude de DxO me rappelle une altercation avec l'entrepreneur qui a construit ma maison il y a 23 ans. La façade comporte 4 fenêtres disposées au carré, 2 au RdC, 2 à l'étage, l'une au-dessus de l'autre. Pas compliqué a priori pour un maçon. Je débarque sur le chantier et je constate que la fenêtre en bas à gauche est décalée sur la gauche par rapport à celle du dessus (à tel point que l'on ne peut pas ouvrir complètement le volet qui vient cogner sur le mur du garage) et que la fenêtre en haut à droite est décalée sur la droite par rapport à celle du dessous. Les 4 fenêtres au carré forment donc en fait un magnifique losange. Non respect évident du plan. À refaire.

Eh bien, le zigoto en question qui n'avait aucune envie de refaire la maçonnerie des fenêtres a passé une heure a m'expliquer que c'était plus beau comme ça et qu'il n'y avait aucun problème.

DOP, c'est pareil. Le logiciel n'est pas conforme aux pubs et au cahier des charges, il n'a jamais fonctionné comme sa documentation dit qu'il fonctionne mais DxO passe son temps à nous expliquer que l'on s'en sert mal, que tout va bien (ou ira mieux de toute façon) et que là où nous voyons toujours des bugs 9 mois après le lancement du produit, il n'y a qu'incompréhension de notre part. Ça finit par énerver et démotiver.

[Brainois]

Fatigué. Et maintenant occupé par les bugs d'impression de Lightroom 2 .

Comme quoi, des bug il y en partout !

[MainSoft]

Comme quoi, des bug il y en partout !

Oui, même dans les logiciels que j'écris, c'est dire . C'est inévitable vu la complexité des systèmes et le nombre de combinaisons de configurations possibles. La qualité du développement et du service est dans la mise en place d'un certain nombre de mécanismes:

- Outil de traçage et de débogage intégré.
- Méthodologie de développement empêchant ou limitant fortement les régressions (tests unitaires, TDD, Design Patterns, bonnes pratiques,...).
- Collecte des problèmes.
- Organisation (et réactivité) du support.
- Écoute du client.
- Rapidité de correction

Si les bugs sont acceptables à condition d'être corrigés en temps et en heure, les carences sur les points ci-dessus ne le sont pas. Chez les grands comptes comme Adobe ou Microsoft, la méthodologie est là mais l'écoute du client laisse parfois à désirer. L'avantage des petites structures (comme la mienne ou DxO), c'est que l'on peut réagir vite, appeler un client, etc. L'autre jour, j'avais au téléphone une cliente toute esbaudie de ne pas avoir affaire à une hot line avec robot intégré mais de parler à un être humain (qui a su la réconforter et lui expliquer que non, elle n'était pas nulle en informatique et que son problème allait être réglé  ).

On m'a souvent reproché de trop râler après DxO mais les efforts que je fais moi-même pour mes clients grand public pour un logiciel vendu 23 euros TTC avec une licence perpétuelle, DxO ne les fait pas pour des clients ayant payé une licence 10 fois plus élevée et renouvelable. Ça me met fondamentalement de mauvaise humeur. Et ce sont les clients exigeants qui font avancer les choses, pas ceux qui se contentent de demi-mesures.

[SupportDxO]

Bonjour,

Voici quelques éléments de réponse pour cagire, gerarto et Philippe sur les profils d'affichage ICC.

Les profils couleur sRVB et AdobeRVB étant très courants, ils ne sont pas embarqués dans l'Exif de l'image (d'où le champ Exif « Color space » renseigné à la valeur « uncalibrated »). L'indication d'utilisation de l'un ou l'autre de ces deux profils se fait par contre au niveau du remplissage du champ Exif « Interoperability Index » de l'image. Pour info, renseigner ce champ à la valeur « R98 » signifie que l'image est en sRVB, et « R03 » signifie que l'image est en AdobeRVB. Ce choix n'est pas un choix arbitraire de DxO, mais une convention de l'Exif (cf. par exemple http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html pour une description des champs Exif). Les images RAW comme JPG sorties des boîtiers (dont le Sony Alpha 700) appliquent cette convention, et nous nous y conformons aussi pour produire les images corrigées par DxO.

ACDSee n'arrive effectivement pas à reconnaître le profil couleur AdobeRVB de l'image sortie par Optics Pro. Nous avons aussi fait un autre test : il n'arrive pas non plus à reconnaître le profil couleur d'une image JPG prise en AdobeRVB directement sortie par le boîtier (le Sony Alpha 700 par exemple). Notre logiciel n'est donc pas à l'origine du problème constaté avec ACDSee. Par contre, nous avons essayé avec Optics Pro v4.5.1 de traiter une image JPG issue du Sony Alpha 700 prise en AdobeRVB (les RAW de ce boîtier ne sont pas supportées par la 4.5.1 ...) et sortie par le logiciel en profil « as shot » (donc AdobeRVB) : l'image corrigée ouverte dans ACDSee  n'est pas non plus interprétée correctement au niveau du profil couleur. Du coup, nous ne comprenons pas bien pourquoi vous dites que le profil est correctement interprété pour les fichiers issus de la v4.5, mais plus avec la v5...

Reste que les couleurs interprétées « correctement » (c'est à dire vis à vis de l'Exif) sont celles vues quand le fichier est affiché dans Optics Pro (ou Photoshop, ou tout autre logiciel reconnaissant que l'image est bien en AdobeRVB), et pas ACDSee. Ce qui veut dire que si vous préférez celles affichées dans ACDSee, avec son bug d'affichage, c'est que le rendu couleur obtenu dans Optics Pro ne vous convient pas. Dans ce cas, vous pouvez facilement faire un preset changeant le rendu couleur (palette d'outil « Couleur - Rendu des couleurs », en choisissant par exemple « Boitier \ Neutre », qui propose en général un rendu couleur moins clinquant, ou bien alors baisser la valeur du curseur de « Vibrance » si vous trouvez nos images par défaut trop saturées en terme de couleur ...).

Très important, on peut enfin rappeler à cette occasion que pour avoir un affichage correct des couleurs dans Optics Pro, il faut effectivement régler dans le menu "Edition - Préférences" la combo « Profil ICC de l'affichage » à la valeur « Profil de l'écran » pour ceux qui disposent d'un écran calibré, et laisser à « sRVB » pour les autres. Ne surtout pas choisir l'entrée « AdobeRVB » dans ce cas, car un écran, même non calibré, a en général un comportement se rapprochant davantage du sRVB que du AdobeRVB, et les couleurs apparaîtraient alors dans Optics Pro plus ternes qu'elles ne le seront au final (par exemple une fois l'image corrigée affichée dans Photoshop, ou imprimée). Il arrive que certains utilisateurs, pensant (à tort) régler l'espace couleur de travail du logiciel, utilisent la valeur AdobeRVB pour ce champ : ceux là font leur réglages dans Optics Pro avec des couleurs mal affichées et obtiennent effectivement des couleurs différentes une fois l'image corrigée ouverte dans Photoshop.

Cordialement,
Alexandre

[cagire]

Merci Alexandre. Désormais, suite à vos conseils c'est maintenant parfait chez moi.

[gerarto]

Bonjour,

Voici quelques éléments de réponse pour cagire, gerarto et Philippe sur les profils d'affichage ICC.

Bonjour Alexandre, et merci pour la réponse.

En fait la situation est un peu plus compliquée, je m'explique :

J'ai bien un écran calibré et profil ICC de l'affichage à « profil de l'écran » dans les préférences.
Jusque là, je n'avais pas constaté de problème particulier de dérive des rouges, et l'affichage j'ai dans DxO me convient sans problème...
L'affichage des couleurs est strictement identique dans DxO et dans Photoshop, ce qui semble normal.
De même, l'affichage que j'ai dans ACDSee pro v8 est en tout point identique.  La réponse m'ouvre un début de solution : il est effectivement possible qu'ACDSee ne reconnaisse pas l'Adobe RVB, mais comme j'avais mis Adobe RVB dans ACDSee comme profil d'entrée par défaut (si pas de profil intégré) cela expliquerait que, :
- les sorties DxO « original » et « Adobe RVB » s'affichent correctement
- la sortie DxO « sRVB » s'affiche avec des couleurs incorrectes (rouges trop fluo). 
C'est bien la bonne piste car effectivement, lorsque je force le profil d'entrée par défaut à sRVB, ACDSee affiche cette fois ci correctement la sortie sRVB, et incorrectement (couleurs trop ternes) l'Adobe RVB.
Donc conclusion :  ACDSee ne reconnaît pas les profils intégrés des sorties de DxO 5.2.1 (ou le champ « Interoperability Index »  de l'exif ?)

Du coup, nous ne comprenons pas bien pourquoi vous dites que le profil est correctement interprété pour les fichiers issus de la v4.5, mais plus avec la v5...

C'est précisément là où ça ce complique :

Pour tous les fichiers issus de la v4.5, ACDSee m'indique dans les propriétés du fichier, profil couleur intégré : « Adobe RGB (1998) ». Ces fichiers sont ceux de mon précédent boîtier : Konica-Minolta D5D. Lorsque je retraite un de ces fichiers dans la v5.2.1, ACDSee ne reconnaît manifestement plus le profil intégré puisqu'il indique « SO ».

Concernant maintenant les fichiers du Sony Alpha 700, je viens de faire le test comparatif v4.5/v5.2 avec un jpeg (... mais pourquoi n'y ai-je pas pensé plus tôt ? ...probablement parce que je ne fais que des raw !).
Résultat : effectivement ACDSee ne reconnaît pas le profil intégré dans le jpeg original issu du boîtier (profil intégré SO).
J'ai ensuite traité ce même fichier original jpeg dans la v5.2.1  et dans la v4.5.1 :
ACDSee donne comme profil intégré SO pour le fichier de la 5.2, mais trouve bien Adobe  RVB 98 pour le fichier de la 4.5 ! (Voir les copies d'écran).
Maintenant, je n'ai ni la compétence, ni les outils pour savoir si ACDSee « interprète » correctement le profil qu'il affiche avoir trouvé...

Donc s'il est clair, et maintenant pour moi c'est évident, qu'il y a un bug dans ACDSee, il n'en persiste pas moins qu'à partir d'un même fichier, les versions 4.5 et 5.2 de DxO « semblent » ne pas se comporter exactement de la même manière dans les infos qu'elles transmettent concernant le profil!

[gerarto]

Petite précision supplémentaire concernant les copies d'écran (je m'en suis rendu compte après avoir posté):

Si les tailles des fichiers jpeg de la 4.5 et de la 5.2 sont (si) différentes, c'est tout simplement parce que le taux de compression jpeg n'est pas réglé de la même manière dans les deux versions 

Ceci dit pour couper court à toute tentative d'alimenter une polémique sur ce point entre 4.5 et 5.2