Pixels bonus (D4s)

[Phil_C]

Je ne sais pas si ce sujet a déjà été abordé, dans ce cas, c'est simplement un rappel.
Le D4s dispose de 16.1 Mp, soit une résolution native en pixels de 3280x4928.
Cela dit, avec DxO PhotoLab, à partir d'un RAW, la fonction recadrage est surprenante: il semblerait que l'image soit un peut plus large, car la partie supérieur de l'image (noire) semble contenir de l'information.
En faisant un recadrage personnalisé, surprise, on peux faire apparaitre une bande de 81 pixels par 3280, et obtenir une image de 3280x5009 pixels, soit 16.4 Mp, un peu plus que la spécification du D4s.
Ce n'est pas extraordinaire, mais sur ma photo, cela à permis de dégager le sommet de l'obélisque. Est-ce propre au D4s, est-ce un bonus qu'accorde DxO? En tout cas, il est certain que le capteur dispose de plus de pixels que spécifié, difficile de croire que c'est une interpolation, car cela rajoute de l'information.

[salamander]

Je ne suis pas allé vérifier, mais est-ce que ça ne serait pas lié au recadrage effectué suite aux corrections optiques lors de l'application du profil objo à l'ouverture du raw ?

[ChatOuille]

Je crois que c'est un « défaut », bien que parfois utile. Une chose est sûre : le capteur a plus de pixels que les nominaux. Une partie de ces pixels latéraux est utilisée pour certaines fonctions, comme pour l'autofocus et autres services. Il se pourrait bien qu'une partie de ces pixels prenne aussi des données de la photo elle-même, mais par la suite, le logiciel de traitement coupe généralement afin d'obtenir le format standard. Il se pourrait donc que DxO laisse « voir » ces pixels. Je parle par expérience, car le premier contact que j'ai eu avec le format Raw, l'image montrait des barres rouges latérales avec un logiciel ancien. Lorsque je suis passé à une version plus récente (pour l'époque), ces bandes ont disparues, en réalité ont été coupées.

[Phil_C]

Je ne suis pas allé vérifier, mais est-ce que ça ne serait pas lié au recadrage effectué suite aux corrections optiques lors de l'application du profil objo à l'ouverture du raw ?

Cela semble être la bonne raison, si je désactive la correction de distorsion, je n'ai plus cette bande de pixels supplémentaires. Ce qui est étrange, c'est que cette bande ne soit que sur la largeur de l'image (Hauteur en portrait), on devrait retrouver ce résidu de correction géométrique sur les deux axes.
Mais comme le signale ChatOuille, le capteur doit disposer de pixels supplémentaire à des fins de réglage, tests et calibration, que DxO laisserait voir sous certaines conditions.
Merci pour vos réponses

[Greenforce]

Une partie de ces pixels latéraux est utilisée pour certaines fonctions, comme pour l'autofocus et autres services.

Sur un hybride d'accord, mais sur un reflex?

[salamander]

Cela semble être la bonne raison, si je désactive la correction de distorsion, je n'ai plus cette bande de pixels supplémentaires. Ce qui est étrange, c'est que cette bande ne soit que sur la largeur de l'image (Hauteur en portrait), on devrait retrouver ce résidu de correction géométrique sur les deux axes.
Mais comme le signale ChatOuille, le capteur doit disposer de pixels supplémentaire à des fins de réglage, tests et calibration, que DxO laisserait voir sous certaines conditions.
Merci pour vos réponses

Je pense que ça dépend du type de correction (coussinet, barillet...)

[Verso92]

Les capteurs disposent effectivement de pixels supplémentaires, pour les mesures.

Mais cela n'a strictement rien à voir avec l'image.


Ce que tu as observé c'est juste l'image avec/sans correction (quelquefois, je suis obligé de dévalider la correction de la distorsion pour ne pas avoir l'image rognée)...

[LViatour]

Le capteur image est recadré par la plupart des logiciels pour correspondre aux données Nikon.
Sur tous mes boîtiers Nikon avec mon logiciel libre darktable j'ai toujours eu plus de pixels que les chiffres officiels Nikon et ce aussi avec mon ancien D4S.
Exemple avec le Z7 qui fait officiellement "Zone d'image FX (L) 8256 x 5504 (45,4 millions)" moi j'ai des images de 8288 x 5520 (45,7 millions)
Bien entendu quand j'active une correction optique il y a un recadrage.

[Rami]

Il serait intéressant de regarder s'il y a des différences (et quelles sont-elles) entre l'image vue dans le viseur optique, celle vue en Liveview et celles obtenues après post-traitement.

[Verso92]

Il serait intéressant de regarder s'il y a des différences (et quelles sont-elles) entre l'image vue dans le viseur optique, celle vue en Liveview et celles obtenues après post-traitement.

Fort heureusement, il n'y en a pas (aux pouillèmes près), sauf si on active la correction de la distorsion.

[ChatOuille]

Ne mélangeons pas la correction de la distorsion et ces pixels supplémentaires. Perso, lorsqu'une image est très (trop) serré je supprime la correction de la distorsion, lorsque le sujet le permet, pour gagner un peu de terrain. Dans ce cas c'est plutôt pour ne pas en perdre, car je ne gagne rien.
Je ne serais pas aussi affirmatif que Verso en disant que ces pixels supplémentaires n'enregistrent jamais d'information de l'image. Je ne le sais pas, mais si Phil et aussi Viatour affirment qu'ils ont obtenu plus de pixels que les standard 24x36, je dois les croire. Je ne possède pas la vérité absolue. Je pense bien que la plupart des logiciels coupent l'image au format standard, cela avec ou sans correction de la distorsion. Ce n'est pas exclu que certains permettent la récupération de ces pixels perdus, comme il semble être le cas avec Photolab et Darktable.

Pour répondre à Phil et à Greenforce en même temps, je leur dirait que lorsque j'ai constaté cette barre rouge, elle était bien du côté latéral (droit, je crois) en format paysage, et cela avec mon D800 (donc bien un reflex).

Il serait intéressant de regarder s'il y a des différences (et quelles sont-elles) entre l'image vue dans le viseur optique, celle vue en Liveview et celles obtenues après post-traitement.

Fort heureusement, il n'y en a pas (aux pouillèmes près), sauf si on active la correction de la distorsion.

Non, ce n'est pas le bon exemple, car le viseur ainsi que le LV vont montrer le pourtour de l'image finale (bien que probablement sans correction géométrique). C'est normal, car s'ils montraient plus (au cas que ça existe), on serait déçu lors qu'on fait le traitement, car on aurait vu plus de pixels que le résultat final.
Ce qu'il faudrait faire est de comparer le contenu du raw pur avec l'image finale (sans correction). Je crois que Verso dispose d'un logiciel qui permet de visualiser le contenu du raw (sans dérawtiser, bien entendu). Comme ça on aurait le cœur net et on pourrait mourir moins bête.

[LViatour]

Ne mélangeons pas la correction de la distorsion et ces pixels supplémentaires. Perso, lorsqu'une image est très (trop) serré je supprime la correction de la distorsion, lorsque le sujet le permet, pour gagner un peu de terrain. Dans ce cas c'est plutôt pour ne pas en perdre, car je ne gagne rien.
Je ne serais pas aussi affirmatif que Verso en disant que ces pixels supplémentaires n'enregistrent jamais d'information de l'image. Je ne le sais pas, mais si Phil et aussi Viatour affirment qu'ils ont obtenu plus de pixels que les standard 24x36, je dois les croire. Je ne possède pas la vérité absolue. Je pense bien que la plupart des logiciels coupent l'image au format standard, cela avec ou sans correction de la distorsion. Ce n'est pas exclu que certains permettent la récupération de ces pixels perdus, comme il semble être le cas avec Photolab et Darktable.

Pour répondre à Phil et à Greenforce en même temps, je leur dirait que lorsque j'ai constaté cette barre rouge, elle était bien du côté latéral (droit, je crois) en format paysage, et cela avec mon D800 (donc bien un reflex).
Non, ce n'est pas le bon exemple, car le viseur ainsi que le LV vont montrer le pourtour de l'image finale (bien que probablement sans correction géométrique). C'est normal, car s'ils montraient plus (au cas que ça existe), on serait déçu lors qu'on fait le traitement, car on aurait vu plus de pixels que le résultat final.
Ce qu'il faudrait faire est de comparer le contenu du raw pur avec l'image finale (sans correction). Je crois que Verso dispose d'un logiciel qui permet de visualiser le contenu du raw (sans dérawtiser, bien entendu). Comme ça on aurait le cœur net et on pourrait mourir moins bête.

Je sort très régulièrement des photos plus grandes que ce qu'il est en théorie possible avec mon Z7 et ce sans interpolation venant du fichier raw.  Par contre en jpg j'ai toujours au maximum ce qui est indiqué dans la fiche technique de Nikon. Et sur l'image il y a clairement un cadrage un rien plus large sur le raw que le jpg natif du boitier.
exemple ici un fichier plus grand issu du raw exporté de darktable:
https://lucnix.be/upload/2021/08/24/20210824190924-0ecd2c33.jpg

[Bernard2]

Je ne serais pas aussi affirmatif que Verso en disant que ces pixels supplémentaires n'enregistrent jamais d'information de l'image. Je ne le sais pas, mais si Phil et aussi Viatour affirment qu'ils ont obtenu plus de pixels que les standard 24x36, je dois les croire. Je ne possède pas la vérité absolue.

La fonction de dématriçage qui permet de déterminer la luminosité et la couleur de chaque pixel utilise les informations d'un certain nombre de pixels voisins.
Le système de calcul utilise alors les photosites supplémentaires extérieurs pour disposer de suffisamment de références pour cette opération  pour les pixels situés à l'extrême bord de la partie image du capteur.
ci joint le capteur du Nikon D1 (dans le cas du D1 l'interpolation de basait sur une matrice de 12x12 photosites)
Le cadre noir masque une autre zone de pixels utilisés pour avoir une réference du signal de"noir"des photosites.
Document Nikon

[Bernard2]

Quant à savoir si ces photosites surnuméraires peuvent apparaitre dans les images...
Ils sont forcément dans les fichiers RAW puisque nécessaires au dématricage.
Mais par principe ils ne peuvent être correctement interpolés puisqu'ils ne disposent pas de la matrice complète nécessaire.
Et si pour une raison ou une autre ils apparaissaient ils seraient certainement affectés de dérives en couleur et luminosité.

[LViatour]

Et si pour une raison ou une autre ils apparaissaient ils seraient certainement affectés de dérives en couleur et luminosité.

Voici une image ou j'ai plus de pixels que ce qu'annonce Nikon 45.7MP au lieu de 45.5MP.
Je ne vois aucune dérive sur les bords et je n'en ai jamais vu.
https://lucnix.be/upload/2021/08/24/20210824211849-ad11f8ef.jpg

[Verso92]

J'ai ouvert un RAW de D850 avec Iris (RAW "brut", non dématricé, donc).

L'image fait 8 288 x 5 520 pixels, au lieu des 8 256 x 5 504 "officiels"...

[LViatour]

J'ai ouvert un RAW de D850 avec Iris (RAW "brut", non dématricé, donc).

L'image fait 8 288 x 5 520 pixels, au lieu des 8 256 x 5 504 "officiels"...

C'est exactement la taille des images dématricées de mon z7 en sortie de darktable. 

[ChatOuille]

J'ai ouvert un RAW de D850 avec Iris (RAW "brut", non dématricé, donc).
L'image fait 8 288 x 5 520 pixels, au lieu des 8 256 x 5 504 "officiels"...

Et voilà, on est fixé. Merci d'avoir fait le test que je t'ai proposé.  On ne peut jamais dire « je sais ». Tout ce que je sais est que ne sais rien.

Et je dirais à Bernard que cela dépend. Car les tests des intervenants montrent plutôt le contraire. Évidemment ils seraient « moins fiables » et peuvent dépendre de chaque image. Cela dit, il faut bien comprendre que ces pixels supplémentaires dépendent de chaque capteur et que ce n'est pas une obligation que certains capteurs peuvent ne pas avoir.

[restoc]

Et voilà, on est fixé. Merci d'avoir fait le test que je t'ai proposé.  On ne peut jamais dire « je sais ». Tout ce que je sais est que ne sais rien.

Et je dirais à Bernard que cela dépend. Car les tests des intervenants montrent plutôt le contraire. Évidemment ils seraient « moins fiables » et peuvent dépendre de chaque image. Cela dit, il faut bien comprendre que ces pixels supplémentaires dépendent de chaque capteur et que ce n'est pas une obligation que certains capteurs peuvent ne pas avoir.

Ces pixels supplémentaires  sont imposés par le principe de dématriçage imposé lui même par la matrice de Bayer, par les algos de débruitage mais également aux différents effets de bords indésirables possibles que l'electronique, les maths et la physique prennent en compte. Dans le cas d'un Foveon probablement le nb de pixels excédentaires est réduit.

Nikon, tous les constructeurs et les éditeurs commerciaux ( attaquables en cas d'anomalies) ont raison contractuellement de limiter la surface utilisable à 100% de pixels garantis sans anomalies pour les raisons explicitées par Nikon dés le D1 et retracées par Bernard.

Le cas des images présentées ci dessus sans défaut apparent est justement un cas trés particulier favorable où le dématriçage ne peut guère être pris en défaut : demi-teintes, homogènes et progressives ( ciel homogène, bokeh trés lourd etc.), peu ou pas de bruit etc. : le dematriceur affecte une valeur au pixel calculé ...qui ressemble exactement au pixel d'à côté qui ressemble etc etc. Sûrement pas représentatif des exigences de la clientèle de la photo technique.

Les constructeurs savent que des milliers de photographes ( ou leurs concurrents)  vont tester à fond les bords avec des motifs tramés de tous type et à fort contraste et ensuite en plus pousser les algos de PT ( filtres détecteurs de points, de contours d'accentuation etc.)   pour tester la surface utile garantie ( reproduction, architecture, photo technique etc. etc.). Le tout pour ne gagner qu' environ 350 Kpixels sur un D850 ou Z7. Juste un écran vga !

Entre pixels "possibles" et engagement de pixels garantis il y a contractuellement une grosse différence en terme d'emm... sans fin pour les constructeurs et éditeurs commerciaux.Les logiciels libres à engagement limité non commercial n'ont pas les contraintes de faire du 100% fiable.

En photo il ne faut se fier ni à ce qu'on voit ni à ce qu'on en déduit...( Copyright D. Raoult )
Si non on va dire que le photographe a mal cadré et doit récupérer des pixels pour sauver le travail ...

[Verso92]

Et voilà, on est fixé. Merci d'avoir fait le test que je t'ai proposé.  On ne peut jamais dire « je sais ». Tout ce que je sais est que ne sais rien.

Et je dirais à Bernard que cela dépend. Car les tests des intervenants montrent plutôt le contraire. Évidemment ils seraient « moins fiables » et peuvent dépendre de chaque image. Cela dit, il faut bien comprendre que ces pixels supplémentaires dépendent de chaque capteur et que ce n'est pas une obligation que certains capteurs peuvent ne pas avoir.

Comme expliqué précédemment, tous les APN ont des pixels supplémentaires, et comme expliqué aussi précédemment, ces pixels ne sont pas 100% exploitables.


Par contre, l'exemple proposé par Phil_C en début de fil m'étonne, quand même (à savoir ces pixels supplémentaires "visibles" avec DxO PhotoLab). Il faudra que je fasse l'essai...

[LViatour]

Par contre, l'exemple proposé par Phil_C en début de fil m'étonne, quand même (à savoir ces pixels supplémentaires "visibles" avec DxO PhotoLab). Il faudra que je fasse l'essai...

Il y a 10 ans j'étais je pense au D300 et déjà à l'époque j'avais ce surplus de pixels (avec le logiciel Bibble) il y a déjà eu une discussion à l'époque sur ce sujet sur un forum. Cela fait donc au moins 10 ans que j'ai cela et je n'ai jamais vu le moindre défaut sur ce bord supplémentaire et ce sur D300, D3s, D4, D4s, D5 et maintenant Z7.
C'est certainement une zone de sécurité. Il me semble aussi me souvenir qu'un utilisateur du logiciel Bibble avait par moment une fine zone noire sur une moitié  d'un bord de son cadrage lié au cadrage plus large du  logiciel.

[Verso92]

Il y a 10 ans j'étais je pense au D300 et déjà à l'époque j'avais ce surplus de pixels (avec le logiciel Bibble) il y a déjà eu une discussion à l'époque sur ce sujet sur un forum. Cela fait donc au moins 10 ans que j'ai cela et je n'ai jamais vu le moindre défaut sur ce bord supplémentaire et ce sur D300, D3s, D4, D4s, D5 et maintenant Z7.
C'est certainement une zone de sécurité. Il me semble aussi me souvenir qu'un utilisateur du logiciel Bibble avait par moment une fine zone noire sur une moitié  d'un bord de son cadrage lié au cadrage plus large du  logiciel.

J'avoue ne pas bien comprendre comment se fait le dématriçage sur les bords de l'image... ou, du moins, ça doit complexifier (inutilement ?) l'algo.


En tout cas, rien de tel avec DxO PhotoLab, c'est sûr :

[salamander]

En tout cas, rien de tel avec DxO PhotoLab, c'est sûr :

Phil C ne parle pas de taille à l'export, mais d'une marge visible lorsqu'il ouvre l'outil recadrage

[Bernard2]

Pour ma part DxO me donne une taille de fichiers Z7 conforme aux spécifications, pas 1 pixel de plus.

[Verso92]

Phil C ne parle pas de taille à l'export, mais d'une marge visible lorsqu'il ouvre l'outil recadrage

Rien de tel chez moi...

[salamander]

J'ai pas essayé de mon côté....

[LViatour]

Pour ma part DxO me donne une taille de fichiers Z7 conforme aux spécifications, pas 1 pixel de plus.

J'ai systématiquement à l'import de mes raw des images 8288 x 5520 soit 45.749.760 pixels
Sur la fiche technique Nikon France:
Nikon annonce pour le Z7 45,7 MP effectifs (dans le titre d'annonce du Z7).
Mais annonce aussi "Nombre total de pixels 46,89 millions"
et aussi : Zone d'image FX (36x24), (L) 8256 x 5504 (45,4 millions)

Donc sur le site de Nikon ils passent  par trois valeurs différentes sur le nombre de pixels de 45,7 à 45,4......

Un fichier raw travaillé avec un logiciel Nikon sans correction optique et sans recadrage fait 45.441.024 pixels
Soit 308.736 pixels disparus par rapport à mon logiciel raw.....

Dans le viseur c'est le format jpg qui est affiché donc recadré au format Nikon.

[Bernard2]

Donc sur le site de Nikon ils passent  par trois valeurs différentes sur le nombre de pixels de 45,7 à 45,4......

Un fichier raw travaillé avec un logiciel Nikon sans correction optique et sans recadrage fait 45.441.024 pixels
Soit 308.736 pixels disparus par rapport à mon logiciel raw.....

Dans le viseur c'est le format jpg qui est affiché donc recadré au format Nikon.

Je ne dis pas le contraire
Ces pixels supplémentaires existent bien dans les RAW puisqu'ils ont une utilité pour le dématriçage, mais ne sont pas "normalement" visibles une fois les images ouvertes dans un logiciel.
Après que dans des conditions particulières et dans un logiciel particulier ils puissent apparaitre... c'est autre chose.

[LViatour]

Je ne dis pas le contraire
Ces pixels supplémentaires existent bien dans les RAW puisqu'ils ont une utilité pour le dématriçage, mais ne sont pas "normalement" visibles une fois les images ouvertes dans un logiciel.
Après que dans des conditions particulières et dans un logiciel particulier ils puissent apparaitre... c'est autre chose.

Ce qui est étonnant, c'est que j'ai beau chercher dans un grand nombre d'images de types différentes, haut iso, structures, dégradés, optiques différentes, je ne trouve aucun défaut sur le bord supplémentaire.

J'ai aussi testé les différentes manières de dématricage et aucune ne donne d'artefact sur les bords.

[Verso92]

Ce qui est étonnant, c'est que j'ai beau chercher dans un grand nombre d'images de types différentes, haut iso, structures, dégradés, optiques différentes, je ne trouve aucun défaut sur le bord supplémentaire.

Il suffit que l'algo de dématriçage en tienne compte (mais ça doit bien le complexifier -pour rien- j'imagine ?)...

[Rami]

On doit surtout perdre les possibilités de traitement parallèle massif, ce qui fait que c'est plus facile à faire par la suite dans un logiciel sur PC que dans le boitier lui-même.

[LViatour]

Il suffit que l'algo de dématriçage en tienne compte (mais ça doit bien le complexifier -pour rien- j'imagine ?)...

Je n'ai pas de ralentissement particulier, il y a même des algorithmes de dématriçage comme PPG qui sont extrêmement rapides comparé à AMAZE par exemple et même avec PPG je ne vois rien comme défaut. J'ai même fait des sorties interpolées à 200% et même là je ne vois aucun effet de bord.
Par contre je me demande si la taille capteur utile de 24x36mm est avec ou sans ce bord de "sécurité". Peut-être que ce bord est extérieur au format 24x36 et que donc pour certaines optiques cela peut jouer sur la correction (même si je n'y crois pas trop vu la finesse du bord).

Je viens aussi de regarder avec mes logiciels de dématriçage en astronomie et là aussi le fichier est plus grand identique à ce que donne par défaut darktable.

[LViatour]

On doit surtout perdre les possibilités de traitement parallèle massif, ce qui fait que c'est plus facile à faire par la suite dans un logiciel sur PC que dans le boitier lui-même.

à mon avis c'est la piste la plus probable, mais alors c'est quand-même dommage de ne pas utiliser ce bord avec les logiciels sur PC, probablement pour unifier le résultat entre jpg et raw....

[luistappa]

Attention ce n'est pas parce qu'un algorithme est plus complexe à écrire et à adapter aux différents capteurs qu'il va systématiquement être plus long à être exécuter de manière significative.

Par contre il tiendra plus de place en mémoire.

La dérive de teinte et de luminosité n'est pas évidente à mettre en évidence car ou dans la bande de pixels supplémentaires tu as quelque chose de similaire à ce qui est dans les bords officiels et dématricer « partiellement «  ne se verra pas ou il y a quelque chose de différent et là tu n'auras pas de comparaison possible.

Imaginons un fil noir dans le ciel pile dans la bande des pixels complémentaires, il sera dématricé en tenant compte des pixels du ciel, il sera donc un peu moins noir et un peu plus bleuté mais comment pourrais-tu t'en rendre compte sauf à avoir une autre image de comparaison avec ce fil dans la zone « officielle ».

[jdm]

...
Et si pour une raison ou une autre ils apparaissaient ils seraient certainement affectés de dérives en couleur et luminosité.

Oui, je pense aussi, mais ce peut et doit être relativement imperceptible, comme le signale Luc.

Après pour une question de résultat homogène, je ne vois que la méthode de "marge perdue" qui soit 100% "bio" ... 

[restoc]

Je ne sais pas si ce sujet a déjà été abordé, dans ce cas, c'est simplement un rappel.
Le D4s dispose de 16.1 Mp, soit une résolution native en pixels de 3280x4928.
Cela dit, avec DxO PhotoLab, à partir d'un RAW, la fonction recadrage est surprenante: il semblerait que l'image soit un peut plus large, car la partie supérieur de l'image (noire) semble contenir de l'information.
En faisant un recadrage personnalisé, surprise, on peux faire apparaitre une bande de 81 pixels par 3280, et obtenir une image de 3280x5009 pixels, soit 16.4 Mp, un peu plus que la spécification du D4s.
Ce n'est pas extraordinaire, mais sur ma photo, cela à permis de dégager le sommet de l'obélisque. Est-ce propre au D4s, est-ce un bonus qu'accorde DxO? En tout cas, il est certain que le capteur dispose de plus de pixels que spécifié, difficile de croire que c'est une interpolation, car cela rajoute de l'information.

Tout çà pour çà :

Dans DXO DPL4 le seul mode affichant le contenu natif du fichier dans ses dimensions totales  est effectivement le mode recadrage sans contrainte. Ce qui est ta deuxième image et aurait dû être ton image de référence pour compter les pixels... Certes DXO est trompeur sur ce point : le recadrage par défaut  proposé  respecte un format de sortie logiquement mais du coup ne montre pas forcémment la totalité des pixels officiels.
Tous les autres modes sous contraintes coupent ou compressent selon le but à atteindre.

Donc RAS !   :  DXO DPL4 est un logiciel commercial respectueux du format originel du constructeur ... et ne va pas gratter des pixels cachés !!

[restoc]

Du coup j'ai vérifié pour D5 D6, D850 Z6 Z7. 

DXO DPL4 respecte exactement le format image officiel Nikon de tous ces capteurs dans le mode de recadrage sans contrainte.  Celui ci mériterait d'être appelé "natif" çà éviterait les pertes de temps. Tous les autres sont des modes dégradés en contenu de l'image, avec ou sans corrections géométriques. L'affichage de taille de l'image  est aussi un peu trompeur puisqu'il suffit de ne pas être dans le bon mode pour croire qu'on a récupéré des pixels ... aussi cachés que les résultats de l'hydroxychloroquine.

Il  faudrait juste suggérer à DXO de prévoir une préférence pour démarrer une session : format natif du capteur ou format contraint et donc souvent rogné ou interpolé.

[egtegt²]

Aprés les enc. de mouche, les compteurs de pixels 

C'est bon, je sors, pas la peine de me bousculer

[restoc]

Oui, je pense aussi, mais ce peut et doit être relativement imperceptible, comme le signale Luc.

Après pour une question de résultat homogène, je ne vois que la méthode de "marge perdue" qui soit 100% "bio" ... 

Impreceptible ... çà dépend du contenu de l'image.
Voici d'ailleurs ce que dit en bref Rawtherappe  avec sa liste de 20 ou 30 démosaiqueurs !! et  permet aussi jouer avec les bords.

Borders :

La plupart des convertisseurs raw retranchent ainsi quelques rangs et colonnes de la périphérie de l'image, comme le fait RawTherapee par défaut. Cependant, vous pouvez forcer le non rognage de ces pixels périphériques en modifiant la valeur de "Bord". La fixer à "0" signifie qu'aucun rognage n'est réalisé, et RawTherapee fera ce qu'il peut pour dématricer les pixels en bordure, mais des artéfacts peuvent apparaître !

La réponse définitive est donc encore une fois : c'est possible mais pas garanti et çà fait toute la différence sur un plan opérationnel et commercial.

[jdm]

je dirais même plus, imputrescible ... 

[Verso92]

à mon avis c'est la piste la plus probable, mais alors c'est quand-même dommage de ne pas utiliser ce bord avec les logiciels sur PC, probablement pour unifier le résultat entre jpg et raw....

Après, les solutions rigolotes/exotiques ont le mérite d'exister.

De là à regretter que les solutions sérieuses ne les adoptent pas, il y a un pas...

[LViatour]

De là à regretter que les solutions sérieuses ne les adoptent pas, il y a un pas...

Quelle condescendance!  "solutions sérieuses " comme si darktable ne l'était pas.... darktable est un logiciel des plus sérieux et n'a rien à envier aux solutions propriétaires qui ont pignon sur rue. De nombreuses options notamment sur le dématriçage ne sont tout simplement pas disponibles sur la plupart des logiciels.

Personne n'oblige son utilisation mais avant de le considérer comme "non sérieux" il faudrait quand-même au moins l'étudier et le connaitre pour en avoir un avis aussi tranché. Et encore une fois le surplus de pixels ne donne aucun artefact, je n'en ai trouvé aucun sur les centaines de milliers de photos que j'ai traitées avec ce logiciel.
ET personnellement ce petit surplus de surface n'est pas négligeable surtout avec les corrections optiques qui recadre les les images.

[Verso92]

Quelle condescendance!  "solutions sérieuses " comme si darktable ne l'était pas.... darktable est un logiciel des plus sérieux et n'a rien à envier aux solutions propriétaires qui ont pignon sur rue.

Les logiciels propriétaires des fabricants (qui connait mieux qu'eux le hardware ?), LR, Capture One, DxO, etc, n'utilisent pas cette possibilité... tous les logiciels sauf un : ils seraient donc tous dans l'erreur ?

De nombreuses options notamment sur le dématriçage ne sont tout simplement pas disponibles sur la plupart des logiciels.

Heureusement.

Personne n'oblige son utilisation [...]

Heureusement (bis).

ET personnellement ce petit surplus de surface n'est pas négligeable surtout avec les corrections optiques qui recadre les les images.

Quand on est mauvais...

[LViatour]

Les logiciels propriétaires des fabricants (qui connait mieux qu'eux le hardware ?), LR, Capture One, DxO, etc, n'utilisent pas cette possibilité... tous les logiciels sauf un : ils seraient donc tous dans l'erreur ?

Heureusement.

Tu as raison, je ne vais pas continuer la discutions qui n'as aucun intérêt ici. 

[Verso92]

Tu as raison, je ne vais pas continuer la discutions qui n'as aucun intérêt ici.

Et en français, ça donnerait quoi ?

[LViatour]

Et en français, ça donnerait quoi ?

ça donne que tu me casses les couilles avec ta condescendances point final.

[Verso92]

ça donne que tu me casses les couilles avec ta condescendances point final.

C'est plutôt bon signe (le français n'est pas ta langue maternelle, visiblement ?).


Franchement... photographiquement parlant, quel est l'intérêt de disposer de plusieurs algos de dématricage ? c'est un logiciel pour geeks, principalement...

[agl33]

Et hop un ami de plus pour v92 

[LViatour]

Franchement... photographiquement parlant, quel est l'intérêt de disposer de plusieurs algos de dématricage ? c'est un logiciel pour geeks, principalement...

les différents alogs de dématriçage ont chacun des défauts et des qualités, par exemple certains sont bien meilleurs sur des hauts isos et moins bons dans dans d'autres situations, certains sont rapides d'autres très lents, etc...

Une étude de la NASA sur les différents algorithmes limites et avantages de chaque mode est intéressant.
https://www.mdpi.com/2079-9292/8/3/308/htm

Dans darktable je n'utilise pas le même système de dématriçage en fonction des isos utilisés mais aussi pour certains travaux j'utilise des alogs plus rapide. 

[Verso92]

les différents alogs de dématriçage ont chacun des défauts et des qualités, par exemple certains sont bien meilleurs sur des hauts isos et moins bons dans dans d'autres situations, certains sont rapides d'autres très lents, etc...

Une étude de la NASA sur les différents algorithmes limites et avantages de chaque mode est intéressant.
https://www.mdpi.com/2079-9292/8/3/308/htm

OK... mais avoue quand même qu'on est, dans ce cas, dans un monde très "technique", limite "technophile" (je n'ai rien contre Darktable, hein, même si le "geek" que j'ai employé était un peu moqueur...).

Dans darktable je n'utilise pas le même système de dématriçage en fonction des isos utilisés mais aussi pour certains travaux j'utilise des alogs plus rapide.

Pour moi, il y a tellement de paramètres bien plus importants quand on développe une image... déjà, choisir judicieusement la BdB (souvent, je me fais tirer les oreilles sur ce critère).

[jenga]

les différents alogs de dématriçage ont chacun des défauts et des qualités, par exemple certains sont bien meilleurs sur des hauts isos et moins bons dans dans d'autres situations, certains sont rapides d'autres très lents, etc...

Une étude de la NASA sur les différents algorithmes limites et avantages de chaque mode est intéressant.
https://www.mdpi.com/2079-9292/8/3/308/htm

Dans darktable je n'utilise pas le même système de dématriçage en fonction des isos utilisés mais aussi pour certains travaux j'utilise des alogs plus rapide.

Merci pour ce lien très intéressant!

Bien sûr, des compromis doivent être faits entre des propriétés incompatibles comme l'exactitude photométrique, le rendu des transitions fines, l'évitement du moiré, la réjection du bruit, la largeur des bandes mortes introduites sur les bords, la charge de calcul, etc.; un filtre quasi idéal pour l'une de ces propriétés sera très mauvais pour les autres, le meilleur compromis (et donc le choix du filtre de dématriçage) dépend donc du type de photo concerné.

Heureux de ton retour!

[jdm]

 Dans Darktable clairement le « dématriçage » standard fonctionne parfaitement et très rapidement, les spécifiques sur 5 passes font la différence en haut ISO.

Aussi bien les algorithmes Nikon ne sont pas forcément les mêmes selon les ISO sauf que ça n'apparaît pas dans la chaîne de traitements... pas de quoi en faire un plat.

[Verso92]

Aussi bien les algorithmes Nikon ne sont pas forcément les mêmes selon les ISO sauf que ça n'apparaît pas dans la chaîne de traitements... pas de quoi en faire un plat.

Il est fort probable, en effet, que les algos mis en œuvre ne soient pas les mêmes en fonction des circonstances (sensibilité, notamment).

C'est le contraire qui serait surprenant.

[ChatOuille]

Comme expliqué précédemment, tous les APN ont des pixels supplémentaires, et comme expliqué aussi précédemment, ces pixels ne sont pas 100% exploitables.

Par contre, l'exemple proposé par Phil_C en début de fil m'étonne, quand même (à savoir ces pixels supplémentaires "visibles" avec DxO PhotoLab). Il faudra que je fasse l'essai...

Comme d'hab, tu veux toujours avoir raison. Ici il y a ceux qui savent et ceux qui cherchent la vérité, comme moi. Je ne sais pas ce que « 100 % exploitables » veut dire. Comme ça, tus auras toujours raison car on peut interpréter comme on veut. Pourtant, les messages de Viatour indiquent le contraire.

Et j'ajoute : je n'exclue pas qu'à côté de ces pixels « en prime », il y en aurait d'autres totalement cachés (donc jamais visibles), et qui pourraient être utilisés pour le dématriçage. Je ne le sais pas, mais je ne nie pas tout d'emblée.

Ce qui est étonnant, c'est que j'ai beau chercher dans un grand nombre d'images de types différentes, haut iso, structures, dégradés, optiques différentes, je ne trouve aucun défaut sur le bord supplémentaire.

J'ai aussi testé les différentes manières de dématricage et aucune ne donne d'artefact sur les bords.

[agl33]

Comme d'hab, tu veux toujours avoir raison. Ici il y a ceux qui savent et ceux qui cherchent la vérité, comme moi. Je ne sais pas ce que « 100 % exploitables » veut dire. Comme ça, tus auras toujours raison car on peut interpréter comme on veut. Pourtant, les messages de Viatour indiquent le contraire.

Et j'ajoute : je n'exclue pas qu'à côté de ces pixels « en prime », il y en aurait d'autres totalement cachés (donc jamais visibles), et qui pourraient être utilisés pour le dématriçage. Je ne le sais pas, mais je ne nie pas tout d'emblée.

[Verso92]

Comme d'hab, tu veux toujours avoir raison.

Mais tu fais comme tu le sens.

Ces pixels supplémentaires, sauf exception (Darktable), ne te seront pas accessibles, de toute façon...

[restoc]

Rawtherappe fait çà depuis 10 ou 15 ans bien avant Darktable:  une option à cocher pour accéder à ces pixels : le but est d'aider les développeurs à ... évaluer le comportement de leur dématriceurs sur les bords qui restent la plaie du développeur notamment dans les angles. L'option n'est pas vraiment destinée au photographe lambda.
Ces deux logiciels sont Open Source et donc sans obligation de résultat. Ceci explique cela.

Les dématriceurs commerciaux eux sont volontairement garantis sur le format utile déclaré par le constructeur. Ils subissent une batterie de protocoles de tests : ligne de 1 pixel sur le bord puis concentriques vers le centre et en passage de 0 à 16384 pour un raw 14 bits, sur le rouge puis le bleu etc puis dématriçés, puis des trames obliques , des pointillés proches de Nyquist, puis des matrices 3*3 puis  l'examen de pièges dans les angles etc etc .

Bref les logiciels commerciaux assurent, les logiciels Open Source permettent de jouer "border line". A chacun de voir

PS en principe la première leçon au photo club est bien d'apprendre à cadrer dans le viseur pas dans les pixels cachés ? .

[jdm]

...
PS en principe la première leçon au photo club est bien d'apprendre à cadrer dans le viseur pas dans les pixels cachés ? .

Oui, et point de vue marge d'erreur rien de mieux que les viseurs 100% des reflex aux tolérances trop larges pour se planter ...

[ChatOuille]

Mais tu fais comme tu le sens.

Ces pixels supplémentaires, sauf exception (Darktable), ne te seront pas accessibles, de toute façon...

Mais nous l'avons tous dit (en tous cas moi) : ces pixels sont en prime et ni aucun constructeur ni aucun développeur est obligé de permettre leur utilisation. Tu pourras les lire seulement si tu utilises un logiciel qui le permet. Et si tu es sage ! 

D'ailleurs, ces pixels n'ont même pas l'obligation d'exister. Cela dépend du constructeur des capteurs. N'oublie pas que tu disais au départ que les pixels supplémentaires ne contenaient pas d'information image (faux !). Puis pour arranger les choses tu as dit qu'ils n'étaient pas 100 % fiables. Cela n'a rien à voir avec le rapport de fiabilité. D'après les expériences que je lis ici, s'ils existent et peuvent être lus par le logiciel, ils sont fiables. Donc pas de pourcentage !

[Verso92]

Mais nous l'avons tous dit (en tous cas moi) : ces pixels sont en prime et ni aucun constructeur ni aucun développeur est obligé de permettre leur utilisation. Tu pourras les lire seulement si tu utilises un logiciel qui le permet. Et si tu es sage ! 

D'ailleurs, ces pixels n'ont même pas l'obligation d'exister. Cela dépend du constructeur des capteurs. N'oublie pas que tu disais au départ que les pixels supplémentaires ne contenaient pas d'information image (faux !). Puis pour arranger les choses tu as dit qu'ils n'étaient pas 100 % fiables. Cela n'a rien à voir avec le rapport de fiabilité. D'après les expériences que je lis ici, s'ils existent et peuvent être lus par le logiciel, ils sont fiables. Donc pas de pourcentage !

C'est étonnant cette façon de distordre sans arrêt mes propos... quel que soit l'APN, il y a des pixels qui ne sont pas accessibles/visibles.

Où alors, il faudra que tu m'expliques comment afficher les 46,89 MPixels du D850, par exemple...


Après, effectivement, n'ayant jamais utilisé DarkTable ni RawTherapee, je ne savais pas qu'on pouvait exploiter les pixels qui servent habituellement au dématriçage de la périphérie des zones de l'image (honte sur moi !).

[luistappa]

Tous ceux qui un jour ont dû écrire un algorithme dans un monde fini ont été confrontés aux effets de bords. Le moyen le plus simple pour pouvoir utiliser un seul et même algorithme est d'utiliser un monde fini pour les calculs qui est un peu plus grand que le monde fini accessible à l'utilisateur.

La même chose existe dans les mondes virtuels des jeux vidéos, les bords des mondes sont plus loin que là où l'on peut accéder.

A noter que les effets de bords ne sont pas réservés « aux mondes » virtuels mais existent dans les phénomènes physiques.

Exemple, dans un écoulement de liquide, celui-ci n'a pas le même comportement au milieu de l'écoulement que sur les bords.
Un cas concret est la rade de Brest, à marée descendante le courant est de mémoire dans les 5 nœuds, difficile de rentrer à la voile si le vent et faible. Pourtant si tu as un faible tirant d'eau, je sais te faire rentrer même sans la voile
Grâce aux effets de bords, il y a un contre courant sur une faible largeur tout au long des bords de la rade.
Comme ici il faut toujours tout préciser, ce n'est pas que dans les bouquins, je l'ai perso souvent utilisé pour rentrer au port de moulin-blanc.

Mais tout cela n'est pas toujours très calme
Perfect storm by luis tappa, sur Flickr
Non il ne pleut pas ce sont les vagues qui déferlent sur le pont...

[Roland29]

...
Non il ne pleut pas ce sont les vagues qui déferlent sur le pont...

Inutile de le préciser, il ne pleut (presque) jamais à Brest ! 

(Je confirme tes phrases qui précèdent !)

[Verso92]

Inutile de le préciser, il ne pleut (presque) jamais à Brest ! 

Et puis, quand il pleut, le soleil arrive souvent derrière...  ;-)

[Roland29]

Et puis, quand il pleut, le soleil arrive souvent derrière...  ;-)

Et réciproquement !

[Verso92]

Et réciproquement !

Oh oui !!!

;-)

[ChatOuille]

C'est étonnant cette façon de distordre sans arrêt mes propos... quel que soit l'APN, il y a des pixels qui ne sont pas accessibles/visibles.
Où alors, il faudra que tu m'expliques comment afficher les 46,89 MPixels du D850, par exemple...

Pour me faire comprendre, je parlais des pixels supplémentaires « image ». Tous les capteurs ont bien des pixels supplémentaires avec des fonctions différentes. Mais le constructeur n'est pas obligé de les révéler ni les développeurs de software sont obligés de les rendre visibles et exploitables.

Après, effectivement, n'ayant jamais utilisé DarkTable ni RawTherapee, je ne savais pas qu'on pouvait exploiter les pixels qui servent habituellement au dématriçage de la périphérie des zones de l'image (honte sur moi !).

J'accepte tes excuses. C'est en ton honneur ! Pas de honte, mais il ne faut pas être catégorique sans savoir.