Petit essai des profils Cobalt

[Benaparis]

...c'est un problème d'opérateur. La gradation orange également.

Aucune différence ACR/LrC/C1/Phocus sur les HL en 2026.

Non c'est lié au moteur de développement, j'ai les dernières versions d'ACR/Lr et de C1 et ça n'a jamais changé, il y a une compression des HL de base dans le moteur ACR/Lr.

Ici à gauche Lr/ACR et à droite C1 ; en haut sans récupérations des HL et en bas avec recuperations des HL à fond dans les deux logiciels...je crois que c'est assez clair. 

[tenmangu81]

Ci dessous le Magenta dans le ciel de tenmangu81 (10 points de Mage).

Je suppose que c'est mesuré sur la capture d'écran que j'ai postée. Sur le RAW développé par Phocus, j'ai un peu plus de 8.

[Nokton58]

Non c'est lié au moteur de développement, j'ai les dernières versions d'ACR/Lr et de C1 et ça n'a jamais changé, il y a une compression des HL de base dans le moteur ACR/Lr.

Ici à gauche Lr/ACR et à droite C1 ; en haut sans récupérations des HL et en bas avec recuperations des HL à fond dans les deux logiciels...je crois que c'est assez clair. 

Curieux de visualiser la diff avec un module Repro de chez Cobalt ? Surtout que l'intérêt ici, dans ton exemple, c'est du réaliser ensuite sous Photoshop du "Halation" ... , le sujet s'y prête

[doppelganger]

Curieux de visualiser la diff avec un module Repro de chez Cobalt ?

Profils Cobalt ou pas, le problème n'est pas l'opérateur mais l'éditeur du logiciel.

[Nokton58]

Profils Cobalt ou pas, le problème n'est pas l'opérateur mais l'éditeur du logiciel.

Je ne suis pas d'accord avec toi Si vous avez des RAWs de D800E, D850, Z9 je peux encore faire les tests ... (pour pas longtemps, j'arrête C1 après 15 ans d'utilisation ...)

[Verso92]

Bon, il ne faut pas exagérer quand même, Phocus et moi corrigeons ça en 5 secondes, si nécessaire, ce qui est rare.

Oui, bien sûr... mais si je me suis intéressé aux profils, c'est pour ne pas avoir à faire ce genre de manip.

[Benaparis]

Curieux de visualiser la diff avec un module Repro de chez Cobalt ? Surtout que l'intérêt ici, dans ton exemple, c'est du réaliser ensuite sous Photoshop du "Halation" ... , le sujet s'y prête

C'est juste un exemple parlant, mais le profil Cobalt pourrait éventuellement améliorer les choses à la marge mais cela ne changerait pas le constat.

A une époque je faisais beaucoup de photos d'intérieurs pour des magazines, soit par moi soit en tant qu'assistant et d'ailleurs dans ce dernier cas j'ai obligé le photographe que j'assistais à passer sous C1 plutôt qu'ACR pour cette raison entre autre, quand je lui ai montré la différence il n'a pas hésité une seconde...mais il était sceptique au début...

[tenmangu81]

Curieux de visualiser la diff avec un module Repro de chez Cobalt ? Surtout que l'intérêt ici, dans ton exemple, c'est du réaliser ensuite sous Photoshop du "Halation" ... , le sujet s'y prête

J'ai fait un test sur mon exemple lampe/table précédent, en profil Repro. En jouant avec les curseurs et les masques dans Lr, on se rapproche un tout petit peu, après quelque travail, du développement fait par Phocus. Mais un petit peu seulement, et en y passant du temps.

[frmfrm]

Non c'est lié au moteur de développement, j'ai les dernières versions d'ACR/Lr et de C1 et ça n'a jamais changé, il y a une compression des HL de base dans le moteur ACR/Lr.

Ici à gauche Lr/ACR et à droite C1 ; en haut sans récupérations des HL et en bas avec recuperations des HL à fond dans les deux logiciels...je crois que c'est assez clair. 

Ben, c'est clair qu'il y a une différence, mais je crois que l'origine n''est pas celle que tu indiques .

J'ai l'impression que sur ton exemple, LR ne comprime pas le Gamut de la photo alors que C1 gère mieux le hors gamut. Sur LR, je pense que les canaux rouge et vert sont clippés. Le rouge au dessus de 255 et le vert à 0. C'est un problème de profil. ( et de compression de gamut non réalisée, pb souvent marqué/présent sur les sources de lumière artificielles , pas un pb de moteur de développement de LR )

Ceci dit,  avec. quel process de LR tu travailles . le 2010 ou le 2012 et si tu utilises le 2012, comment tu fais pour récupérer des HLs

[Benaparis]

Ben, c'est clair qu'il y a une différence, mais je crois que l'origine n''est pas celle que tu indiques .

J'ai l'impression que sur ton exemple, LR ne comprime pas le Gamut de la photo alors que C1 gère mieux le hors gamut. Sur LR, je pense que les canaux rouge et vert sont clippés. Le rouge au dessus de 255 et le vert à 0. C'est un problème de profil. ( et de compression de gamut non réalisée, pb souvent marqué/présent sur les sources de lumière artificielles , pas un pb de moteur de développement de LR )

Ceci dit,  avec. quel process de LR tu travailles . le 2010 ou le 2012 et si tu utilises le 2012, comment tu fais pour récupérer des HLs

Je comprends ton point de vue, mais c'est justement là que nos avis divergent : la gestion du hors-gamut ou de la reconstruction des canaux clippés est une fonction intrinsèque du moteur de développement. Si C1 et même Phocus dans l'exemple de Robert s'en sortent mieux de mon point de vue dans ce genre de situation, c'est précisément parce que leurs algorithmes respectent mieux la physique de la lumière.

Cependant, l'exemple de la lampe montre que le problème dépasse le simple "clipping" : sur cette image, les canaux ne sont pas brûlés, et pourtant Adobe décale systématiquement la teinte vers un orange/rouge artificiel là où C1 conserve un ambre fidèle. J'utilise d'ailleurs des profils sur mesure paramétrés de manière identique sur ces deux versions de la même photo, ce qui écarte définitivement l'hypothèse d'un simple défaut de profil générique.

Pour répondre à ta question, je travaille bien avec le Process 6 (version actuelle, Adobe a abandonné les dates au profit de numéro). Le problème n'est pas la méthode de récupération en soi, mais une constante de la Color Science d'Adobe : depuis toujours, elle privilégie la luminance et la recuperation/reconstruction à tout prix au détriment du rendu dans les hautes lumières, particulièrement sur les tons chauds. C'est de ce que j'ai observé depuis des années, une signature logicielle qu'aucun profil ne peut totalement gommer ; comme toujours ce sont des questions de compromis à chacun de choisir celui qui lui convient le mieux.

[frmfrm]

Houla

Je comprends ton point de vue, mais c'est justement là que nos avis divergent : la gestion du hors-gamut ou de la reconstruction des canaux clippés est une fonction intrinsèque du moteur de développement. Si C1 et même Phocus dans l'exemple de Robert s'en sortent mieux de mon point de vue dans ce genre de situation, c'est précisément parce que leurs algorithmes respectent mieux la physique de la lumière.

La récupération des HLs à partir d'un/des canaux non clippés est effectivement gérée par le logiciel de dématricage. Dans cet exercice, LR est clairement plus performant qu'Affinity photo , dcraw et DPP pour ne citer que les logiciels que j'utilise/connais un peu . Il existe plusieurs façons de faire et la qualité dépend de l'algo utilisé.

Je pense que la compression de Gamut est plutôt effectuée du coté de la gestion des profils. Il faut en général qu'un profil propose une intension de rendu perceptuelle. Les profils courants comme sRGB , AdobeRGB et Profoto n'ont pas cette possibilité et seule la conversion relative est disponible. Elle ne permet pas une compression de Gamut et une couleur hors gamut se retrouve clippée. ( C'est à ça qu'on reconnais une couleur Hors Gamut )

C'est aussi là où le travail est parfois à la charge de l'opérateur . Son travail est d'afficher les couleurs Hors Gamut avec l'outil d'épreuvage et de les faire rentrer dans le Gamut de l'espace de destination. Ce n'est pas simple et il existe près d'une 100 d'algo différents pour effectuer des compression de Gamut.

Cependant, l'exemple de la lampe montre que le problème dépasse le simple "clipping" : sur cette image, les canaux ne sont pas brûlés, et pourtant Adobe décale systématiquement la teinte vers un orange/rouge artificiel là où C1 conserve un ambre fidèle. J'utilise d'ailleurs des profils sur mesure paramétrés de manière identique sur ces deux versions de la même photo, ce qui écarte définitivement l'hypothèse d'un simple défaut de profil générique.

Un profil dcp comporte 3 composantes principales.

- De quoi calculer une matrice qui permet de passer de l'espace de l'APN à l'espace XYZ.
- Une LUT 3D qui permet d'appliquer un Look au développement.
- Une TRC qui détermine la gradation du tirage.

L'espace de travail de LR utilise les primaires du Prophoto. Le passage de l'espace XYZ à l'espace RGB Melissa peut clipper le Gamut mais cela doit être assez rare. ( A part pour certaines sources de lumières artificielles)

Je pense que le gros du rendu du développement se passe dans la LUT de Look. Les différents profils DCP fournis par LR pour mes APN Canon ne diffèrent que par la LUT  C'est une LUT HSL avec une contrainte sur l'axe des gris, mais elle permet de faire pas mal de chose. Elle doit permettre d'effectuer une compression de Gamut vers un espace plus petit que le Melissa. Suffit juste de le vouloir/savoir faire

Maintenant, Adobe propose un logiciel pour modifier les profils dcp. Tu sais comment faire pour linéariser la TRC, mais on peut aussi jouer sur la LUT 3D.

Si tu trouves que le bleu du ciel tire vers le magenta, soit tu corriges le profil avec cet outil pour obtenir ce que tu veux, soit tu craques ta thune dans un profil Cobalt ou un autre logiciel

Pour répondre à ta question, je travaille bien avec le Process 6 (version actuelle, Adobe a abandonné les dates au profit de numéro). Le problème n'est pas la méthode de récupération en soi, mais une constante de la Color Science d'Adobe : depuis toujours, elle privilégie la luminance et la recuperation/reconstruction à tout prix au détriment du rendu dans les hautes lumières, particulièrement sur les tons chauds. C'est de ce que j'ai observé depuis des années, une signature logicielle qu'aucun profil ne peut totalement gommer ; comme toujours ce sont des questions de compromis à chacun de choisir celui qui lui convient le mieux.

Le process 2012 n'a pas de curseur de récupération des HLs. C'est fait d'office lors du développement. Pour utiliser la même TRC adobe standard ou les profils perso. LR utilise une curbe avec du Knee. Ci-dessous un développement linéaire en process 2010 et 2012. On voit la compression des HLs récupérées en process 2012

[Nokton58]

Quand on expose correctement, on ne crame pas ses HL à la prise de vue

[doppelganger]

Il est question de récupération des HLs non clippees... ce que Lr fait manifestement mal.

[Benaparis]

Houla

La récupération des HLs à partir d'un/des canaux non clippés est effectivement gérée par le logiciel de dématricage. Dans cet exercice, LR est clairement plus performant qu'Affinity photo , dcraw et DPP pour ne citer que les logiciels que j'utilise/connais un peu . Il existe plusieurs façons de faire et la qualité dépend de l'algo utilisé.

Je pense que la compression de Gamut est plutôt effectuée du coté de la gestion des profils. Il faut en général qu'un profil propose une intension de rendu perceptuelle. Les profils courants comme sRGB , AdobeRGB et Profoto n'ont pas cette possibilité et seule la conversion relative est disponible. Elle ne permet pas une compression de Gamut et une couleur hors gamut se retrouve clippée. ( C'est à ça qu'on reconnais une couleur Hors Gamut )

C'est aussi là où le travail est parfois à la charge de l'opérateur . Son travail est d'afficher les couleurs Hors Gamut avec l'outil d'épreuvage et de les faire rentrer dans le Gamut de l'espace de destination. Ce n'est pas simple et il existe près d'une 100 d'algo différents pour effectuer des compression de Gamut.

Un profil dcp comporte 3 composantes principales.

- De quoi calculer une matrice qui permet de passer de l'espace de l'APN à l'espace XYZ.
- Une LUT 3D qui permet d'appliquer un Look au développement.
- Une TRC qui détermine la gradation du tirage.

L'espace de travail de LR utilise les primaires du Prophoto. Le passage de l'espace XYZ à l'espace RGB Melissa peut clipper le Gamut mais cela doit être assez rare. ( A part pour certaines sources de lumières artificielles)

Je pense que le gros du rendu du développement se passe dans la LUT de Look. Les différents profils DCP fournis par LR pour mes APN Canon ne diffèrent que par la LUT  C'est une LUT HSL avec une contrainte sur l'axe des gris, mais elle permet de faire pas mal de chose. Elle doit permettre d'effectuer une compression de Gamut vers un espace plus petit que le Melissa. Suffit juste de le vouloir/savoir faire

Maintenant, Adobe propose un logiciel pour modifier les profils dcp. Tu sais comment faire pour linéariser la TRC, mais on peut aussi jouer sur la LUT 3D.

Si tu trouves que le bleu du ciel tire vers le magenta, soit tu corriges le profil avec cet outil pour obtenir ce que tu veux, soit tu craques ta thune dans un profil Cobalt ou un autre logiciel

Le process 2012 n'a pas de curseur de récupération des HLs. C'est fait d'office lors du développement. Pour utiliser la même TRC adobe standard ou les profils perso. LR utilise une curbe avec du Knee. Ci-dessous un développement linéaire en process 2010 et 2012. On voit la compression des HLs récupérées en process 2012

Merci pour tes explications techniques. On peut se perdre dans la sémantique technique, mais le constat reste visuel : là où certains logiciels font "respirer" la couleur et les valeurs, Adobe les tasse et les sature sans nuance.

L'exemple de Robert avec son Hasselblad est d'ailleurs le montre très bien : entre Phocus et Lightroom, la différence ne vient pas d'un profil, mais bien de la capacité du moteur à interpréter la transition physique de la lumière. Ce que j'appelle "compression" est ce rendu spécifique à Lr/ACR qui, peu importe le processus ou le bidouillage de profil, garde cette signature numérique que d'autres, comme C1 comme je l'ai illustré après  évitent nativement.

Au final et je ne suis pas le seul, je préfère un outil qui me donne ce rendu organique d'emblée plutôt qu'une solution de "maintenance" où l'on doit faire des acrobaties (et encore je demande à voir) pour essayer de corriger un moteur qui dans le cas évoqué ne fait pas le travail attendu.

[Nokton58]

Tout ce qui dépasse L*=97 est : non imprimable ! c'est le blanc de ton papier à L*=97/98,

et je me répète : quand on expose correctement, on ne crame pas ses HLs à la prise de vue.

Je n'ai jamais besoin de toucher au curseur des HLs ... sous C1 ou ACR

[Benaparis]

Tout ce qui dépasse L*=97 est : non imprimable ! c'est le blanc de ton papier à L*=97/98,

et je me répète : quand on expose correctement, on ne crame pas ses HLs à la prise de vue.

Je n'ai jamais besoin de toucher au curseur des HLs ... sous C1 ou ACR

Ce n'est pas le sujet ; par ailleurs en photographie c'est normal d'avoir des hautes lumières qui respirent et pas des valeurs tassées avec des couleurs saturées sans nuances:)

[Nokton58]

entièrement ok avec cela, l'un n'empêche pas l'autre

juste une remarque : en dessous de L*=3 et au dessus de L*=97, tu as l'encre noir, à 3 , et le papier à 97

imprimez vos images ...

[frmfrm]

Quand on expose correctement, on ne crame pas ses HL à la prise de vue

Ben, avec un capteur couleur, on peut tenter de récupérer quelques infos d'un canal clippé/cramé. Avec un capteur monochrome, faut faire gaffe

[frmfrm]

Merci pour tes explications techniques. On peut se perdre dans la sémantique technique, mais le constat reste visuel : là où certains logiciels font "respirer" la couleur et les valeurs, Adobe les tasse et les sature sans nuance.

L'exemple de Robert avec son Hasselblad est d'ailleurs le montre très bien : entre Phocus et Lightroom, la différence ne vient pas d'un profil, mais bien de la capacité du moteur à interpréter la transition physique de la lumière. Ce que j'appelle "compression" est ce rendu spécifique à Lr/ACR qui, peu importe le processus ou le bidouillage de profil, garde cette signature numérique que d'autres, comme C1 comme je l'ai illustré après  évitent nativement.

Au final et je ne suis pas le seul, je préfère un outil qui me donne ce rendu organique d'emblée plutôt qu'une solution de "maintenance" où l'on doit faire des acrobaties (et encore je demande à voir) pour essayer de corriger un moteur qui dans le cas évoqué ne fait pas le travail attendu.

Ben, le problème de compression de Gamut est à prendre en compte avec tous les APN qui ont généralement un Gamut très étendu.

Perso, je développe avec Affinity en Prophoto et applique une LUT 3D de compression de Gamut qui me ramène à un Gamut sRGB. J'ai utilisé l'algo est utilisé par l'ACES. La page suivante montre les pbs rencontrés avec les Gamuts étendus et l'intérët d'utiliser une compression de Gamut et pas une troncation.

https://docs.acescentral.com/rgc/guides/rgc-user/#3d-lut-implementation

Maintenant, perso je ne sais pas vraiment comment vous avec obtenus vos exemples et ce qu'il faut y voir

Tu as développé tes tofs avec LR et tu as fait une sortie sRGB pour poster/montrer le résultat ?

[doppelganger]

Tout ce qui dépasse L*=97 est : non imprimable ! c'est le blanc de ton papier à L*=97/98,

et je me répète : quand on expose correctement, on ne crame pas ses HLs à la prise de vue.

Je n'ai jamais besoin de toucher au curseur des HLs ... sous C1 ou ACR

Je vais alors me répéter aussi. Il est question ici de ce qui peut être récupéré. Et force est de constater que le résultat dans Lr n'est pas satisfaisant, pour ma part. Et j'ai pas attendu les exemples postés ici (et on ne peut plus parlant soi dit en passant) pour en être convaincu.

Que toi, tu n'ai rien besoin de récupérer ne change rien au problème d'une très grande majorité d'utilisateur qui se contente de ce que leur logiciel leur propose en standard.

ps : on parle ici du curseur des HLs mais c'est valable pour bon nombre de paramètre. Leur manipulation n'ayant pas le même effet, suivant le logiciel employé.

[Benaparis]

Ben, le problème de compression de Gamut est à prendre en compte avec tous les APN qui ont généralement un Gamut très étendu.

Perso, je développe avec Affinity en Prophoto et applique une LUT 3D de compression de Gamut qui me ramène à un Gamut sRGB. J'ai utilisé l'algo est utilisé par l'ACES. La page suivante montre les pbs rencontrés avec les Gamuts étendus et l'intérët d'utiliser une compression de Gamut et pas une troncation.

https://docs.acescentral.com/rgc/guides/rgc-user/#3d-lut-implementation

Maintenant, perso je ne sais pas vraiment comment vous avec obtenus vos exemples et ce qu'il faut y voir

Tu as développé tes tofs avec LR et tu as fait une sortie sRGB pour poster/montrer le résultat ?

Ton explication sur l'ACES et la compression de gamut est passionnante d'un point de vue théorique, mais elle confirme précisément mon point : si l'on doit en arriver à appliquer manuellement des LUTs 3D de compression pour obtenir un résultat naturel, c'est bien que le moteur du logiciel échoue là où d'autres réussissent nativement. Et puisque tu parles de cinema, je me souviens à une époque certaines séries ou films ou tu voyais clairement lorsqu'il y avait des teintes chaudes ou des illuminants tungstène que le moteur Adobe était passé par là pour l'étalonnage. :-)

Ce que je demande à un logiciel de développement, ce n'est pas de m'obliger à devenir ingénieur en colorimétrie pour corriger une lampe ambre qui vire au saumon ou une mauvaise gestion du « hors gamut » dans les HL, mais d'offrir un outil qui "comprend" la transition organique des hautes lumières tant au niveau tonal que chromatique. Si Phocus ou Capture One gèrent cela sans que l'opérateur ait à se soucier de l'algorithme de compression de gamut utilisé, c'est que leur interprétation des données brutes est supérieure pour le rendu photographique.

Je pense que les exemples fournis par Robert et moi même sont suffisamment parlant pour tout le monde; à chacun de voir si pour lui c'est un problème ou non, pour moi comme pour d'autres ça l'a toujours été et des exemples j'en ai eu des centaines surtout à l'époque où je faisais principalement de la couleur et que j'avais plus spécifiquement à photographier des intérieurs pour des magazines ou que je faisais de la post-prod pour d'autres, ce qui m'arrive encore d'ailleurs. :-)

Pour répondre à ta question : oui, ce sont des exports sRGB, car c'est le standard de diffusion web et cela ne change rien à l'observation initiale. Mais le problème ne vient pas du "contenant" final, il vient du trajet pour y arriver.

Au final, on en revient à une question de philosophie : je préfère un outil qui fourni un résultat satisfaisant à mes attentes naturellement plutôt qu'un système qui impose sa maintenance technique pour un résultat qui devrait être une évidence dès le départ.

[Benaparis]

Voici encore 2 exemples rien de fou dans les conditions de prises de vue, Lr/ACR rajoute systématiquement un "jus" rouge dans les teintes chaudes là où il n'y en a pas besoin...

[Benaparis]

Là aussi pas besoin de rajouter du "rouge" sur la façade...et me dites pas "c'est à cause de la lumière du soleil", j'y étais 

[frmfrm]

Ton explication sur l'ACES et la compression de gamut est passionnante d'un point de vue théorique, mais elle confirme précisément mon point : si l'on doit en arriver à appliquer manuellement des LUTs 3D de compression pour obtenir un résultat naturel, c'est bien que le moteur du logiciel échoue là où d'autres réussissent nativement. Et puisque tu parles de cinema, je me souviens à une époque certaines séries ou films ou tu voyais clairement lorsqu'il y avait des teintes chaudes ou des illuminants tungstène que le moteur Adobe était passé par là pour l'étalonnage. :-)

Ce que je demande à un logiciel de développement, ce n'est pas de m'obliger à devenir ingénieur en colorimétrie pour corriger une lampe ambre qui vire au saumon ou une mauvaise gestion du « hors gamut » dans les HL, mais d'offrir un outil qui "comprend" la transition organique des hautes lumières tant au niveau tonal que chromatique. Si Phocus ou Capture One gèrent cela sans que l'opérateur ait à se soucier de l'algorithme de compression de gamut utilisé, c'est que leur interprétation des données brutes est supérieure pour le rendu photographique.

Je pense que les exemples fournis par Robert et moi même sont suffisamment parlant pour tout le monde; à chacun de voir si pour lui c'est un problème ou non, pour moi comme pour d'autres ça l'a toujours été et des exemples j'en ai eu des centaines surtout à l'époque où je faisais principalement de la couleur et que j'avais plus spécifiquement à photographier des intérieurs pour des magazines ou que je faisais de la post-prod pour d'autres, ce qui m'arrive encore d'ailleurs. :-)

Pour répondre à ta question : oui, ce sont des exports sRGB, car c'est le standard de diffusion web et cela ne change rien à l'observation initiale. Mais le problème ne vient pas du "contenant" final, il vient du trajet pour y arriver.

Au final, on en revient à une question de philosophie : je préfère un outil qui fourni un résultat satisfaisant à mes attentes naturellement plutôt qu'un système qui impose sa maintenance technique pour un résultat qui devrait être une évidence dès le départ.0

Ben, tu prends l'outil que tu veux ça ne me dérange pas

J'interviens juste pour dire que ce que tu montres n'est pas forcement un pb de HLs mais de Gamut  ( et que le process 2012 de LR n'utilise pas le curseur Highlight pour récupérer les canaux clippés à la prise de vue )

Ton exemple, coté Adobe montre que le profil de travail de LR a un Gamut large ( profoto) et que passer directement en sRGB avec une simple intention de rendu relative produit un résultat pas terrible. Je crois que tout le monde le savait . Ce qui est plus compliqué, c'est de faire la conversion proprement avec les outils à disposition et là, je pense que c'est un métier que je ne connais pas . J'suis pas spécialiste du prépresse

Ton exemple coté C1 montre que cette image a subi une compression de Gamut, mais on ne sait pas forcement plus. Le profil de travail de C1 est il plus petit ou le passage du profil de travail de C au profil sRGB se fait-il avec un algo plus complexe qu'une simple conversion avec intention relative

Imagine que le profil de travail de C1 soit proche de l'adobeRGB et que ton néon soit vert, comment serait la photo sRGB issue de C1 comprimée ou tronquée

[Verso92]

juste une remarque : en dessous de L*=3 et au dessus de L*=97, tu as l'encre noir, à 3 , et le papier à 97

imprimez vos images ...

Rhôôôô... et que crois-tu que nous faisons, cher ami (moi en m'arrachant quelquefois les cheveux, et Benjamin avec brio...  ;-) ?