Re: gestion des images > 8 bits
Pourquoi faire des télé de 56pouce alors qu'une vieille 10 pouce est largement suffisante pour regarder la starac ?
Vois pas le rapport.
Ce n'est [pas] parce que toi tu n'en as pas besoin qu'il faut limiter les autres et une précision supérieure a 8bits est indispensable à beaucoup de personnes, pas que les photographe pros mais aussi les amateurs.
Encore une fois, il ne s'agit pas de moi et ne mélange pas tout. J'ai posté plusieurs messages ici-même comme quoi il en va autrement du *traitement* par rapport à la *représentation*.
Récapitulons.
En ce qui concerne la *représentation* des images, les analyses et les études réalisées au début du siècle, ce n'est pas moi qui l'ai inventé, ont démontré que 200 nuances [par canal] étaient suffisantes.
En ce qui concerne le *traitement*, il est évident qu'il faut plus de 8 bits. Une image peut très bien subir un ensemble de traitements qui nécessitent plus de 8 bits par canal, 16 par exemple, afin d'améliorer la précision du traitement.
Mais en finalité, la *représentation* d'une image en couleurs comprenant 8 bits par canal est largement suffisante. Pour tout le monde. Et encore une fois, ce n'est pas moi qui l'ai inventé.
Et je rappelle que la question posée par PMA, à laquelle j'ai répondu, avant que ce troll ne dégénère était la suivante:
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
La seule précision qui manquait était de distinguer *représentation* et *traitement*. Mais cela a été précisé et re-précisé plusieurs fois par la suite. Il suffit de lire *tous* les commentaires que j'ai postés ici-même.
Une précision de plus de 8 bits est absurde dans le cas de la *représentation d'une image. N'oublie pas non plus que la largeur du canal a une répercussion sur la taille des fichiers images. Autant conserver une taille modeste pour le stockage pour n'augmenter la largeur de chaque canal que pour le traitement de l'image, le résultat étant sauvegardé sur 8 bits par canal après conversion. Une largeur de 32 bits par canal, puisque c'est la question initiale portait là-dessus, ne ferait qu'alourdir considérablement et inutilement chaque fichier image.
En d'autres termes, mon raisonnement ne portait que sur la *représentation* d'une image en couleurs sur 32 bits par canal. Rien d'autre. Et 32 bits c'est 16 millions de fois plus précis que ce que l'œil humain est et sera sans doute jamais capable de distinguer...
Toujours aussi catégorique?
[ Répondre ]
Re: gestion des images > 8 bits
Tout simplement par ce que 32 bits c'est une taille qui plait beaucoup au processeurs actuellement...
32bits ça permet d'avoir une précision suffisante pour la majoritée des traitement actuels, seul des cas spécifiques tels que certaines imageries médicales ou autre truc très spécifiques demandent plus
32bits si tu utilise des float ça te permet d'avoir une dynamique quasiment illimitée dans ton images donc c'est cool...
32 bits en float ça te permet coder très éfficacement les opération sur les machine qui supporte des instruction vectorielles c'est-à-dire quasiment tous les ordis disponibles actuellement.
Bref c'est le meilleur compromis actuellement entre performance, occupation mémoire et qualité.
Ce n'était pas la peine de me donner un cours d'informatique. J'ai exagéré avec un exemple absurde sur une idée que, moi, je trouve absurde -- encore une fois ce n'est que mon avis et les avis... Ce n'était pas à prendre au premier degré. C'était juste de l'ironie.
[ Répondre ]
Re: gestion des images > 8 bits
Si tu prends 2 photos raw en 14bits, t'est déjà à 28bits... Si t'en prends 3, t'es au delà des 32 bits... Donc 32 bits, c'est pas superflu, suivant l'usage...
Tant pis si je me fais moinsser mais dans ce cas pourquoi ne pas directement passer à 1024, 2048 voir 4096 bits par canal, tant qu'on y est? Ça donnerait un peu de marge au cas où il faudrait traiter pas loin de 300 images...
[ Répondre ]
Re: gestion des images > 8 bits
En parlant de ça, voici une étude similaire à ce que mon prof de signal racontait il y a plus de quinze ans:
http://www.arnaudfrichphoto.com/gestion-des-couleurs/couleur(...)
On dira ce qu'on voudra mais qu'on parle de 7 ou 8 bits par canal, le nombre de bits nécessaire et suffisant pour représenter une image reste bien en dessous du chiffre astronomique 32. Quand bien même le traitement des images le justifierait, il serait inutile de grimper au-delà de 16 bits.
[ Répondre ]
Re: gestion des images > 8 bits
puisque ça semble le standard décidé par FantastiX
Je n'ai pas décidé de standard.
Il y a des gens bien plus intelligents que moi qui ont inventé des standards et inventé les règles de colorimétrie, que mon prof' de théorie du signal, lors de mes études supérieures, nous a rapportées (à ma classe et moi), et enseignées. C'étaient des matières sur lesquelles nous étions questionnés à l'examen.
Partant du principe qu'il n'a probablement pas pondu ça tout seul et qu'il avait très certainement des preuves pour étayer ses dires, j'ai tout simplement répété ses paroles. Dommage que je n'aie pas/plus ces cours sous la main.
Peut-être qu'il ne faut pas croire tout ce que les profs nous racontent, après tout...
[ Répondre ]
Re: gestion des images > 8 bits
Il faut bien se rendre à l'évidence et 7 bits sont bien nécessaires pour ne pas percevoir de discontinuités entre deux aplats de vert ! En revanche pour le rouge et le bleu il semble que six suffisent.
C.Q.F.D., échec aux 32 bits par canal...
-->[ ]
[ Répondre ]
Re: gestion des images > 8 bits
J'ai bien appris ce qu'est une approximation, ne t'inquiète pas ;-) . Je n'ai pas étoffé mon raisonnement, supposant, sans doute à tort, que le reste serait implicite.
Si je parlais de la *représentation* d'une image, où 8 bits par canal est suffisant pour l'oeil humain, il en va autrement pour le traitement, bien sûr. Pour une opération sur un canal de 8 bits, le résultat sera sur 16 bits en raison de la multiplication. Mais ça reste malgré tout largement inférieur à 32 bits par canal, ce qui faisait l'objet de la question initiale de PMA.
Nous sommes donc bien d'accord que la diffusion d'une image à raison de 8 bits par canal, c'est suffisant. Le traitement, sur 16 bits par canal, d'une image, c'est suffisant. Le traitement sur 32 bits, par contre, comme le demandait PMA, j'en conclus que c'est inutile.
Sommes-nous toujours d'accord?
[ Répondre ]
Re: gestion des images > 8 bits
pour traiter un jpeg 8 bits il est bénéfique de d'abord passer en 16 bits avant de faire des traitements
C'est dû au traitement numérique: une multiplication de deux nombres de 8 bits donne un nombre de 16 bits. Mais c'est tout de même 65536 fois moins lourd qu'un nombre de 32 bits...
En tout cas, il existe une limite absolue qu'il est inutile de vouloir franchir: celle de la sensibilité de l'oeil humain. Cette limite donne la profondeur maximale absolue des canaux de couleurs.
[ Répondre ]
Re: gestion des images > 8 bits
Voilà un sujet que j'apprécie.
Pour ajouter à ta question, l'oeil humain possède beaucoup moins (4x, si mes souvenirs sont exacts) de cellules rétiniennes sensibles à la couleur que celles sensibles à l'intensité lumineuse. En gros, pour des nuances de gris, 8 bits sont nécessaires pour que l'œil ne distingue plus les seuils entre deux teintes d'intensité de valeur différant d'une unité. Pour les couleurs, ça nous donne 6 bits par canal (R,G,B) soient 18 bits en tout par point lumineux. Finalement, 24 bits, c'est du luxe; 32 bits, ça frise l'indécence...
Donc: que la profondeur des couleurs sur un canal soit gérée sur 32 bits est pour moi une profonde hérésie ou un irrésistible argument marketing ;-) . Mais ce n'est que mon avis, bien entendu.
[ Répondre ]
Re: sous kde....
Kopete est le fer de lance de la messagerie instantanée pour KDE. Seulement il ne gère pas (encore) la VOIP, même s'il gère déjà les webcams. Perso, je parierais bien que ce client évolue suffisamment pour supporter la VOIP mais ce n'est qu'un espoir personnel.
Sous KDE4, il y a Decibel: http://decibel.kde.org/ . Il utilise l'environnement de communication Telepathy.
[ Répondre ]
Re: De bonnes idées
Je viens de lire, plutôt rapidement, c'est vrai, le texte AGPL v3 à http://www.fsf.org/licensing/licenses/agpl-3.0.html et ce que j'en ai compris m'empêche de partager ton opinion.
Je peux toujours m'être trompé dans la compréhension du texte mais je n'y ai lu nulle part qu'il est interdit (voire conditionnel) d'apporter des modifications à un progiciel sous AGPL v3. (A moins que ce ne soit pas ce que tu aies voulu dire.)
D'après ce que j'ai lu, des modifications [personnelles] peuvent être apportées, pour autant, entre autres, que les notices de droit d'auteur soient indiquées et que l'ensemble du programme (modifié) soit disponible sous AGPL v3. J'avais déjà lu le texte de la GPL v2 et ce texte-ci ne me choque vraiment pas.
Mais une erreur (d'interprétation?) de ma part est toujours possible. Je ne demande qu'à comprendre si je me suis trompé ou pas - extraits et exemples à l'appui, si possible, bien entendu.
[ Répondre ]
Ultra-portables libres... mais pas forcément pour tout le monde! :(
Je déplore qu'en Belgique, plus spécifiquement à Liège, il soit toujours aussi difficile voire impossible d'obtenir des PC pré-installés Linux par la filiale commerciale traditionnelle. Je me suis présenté à la FNAC de Liège et j'ai demandé aux vendeurs pourquoi l'ASUS EeePC n'était disponible qu'avec Windows pré-installé.
Il a tenté de me barratiner avec (ce que je soupçonne) de pseudo-excuses sur des problèmes de licences, empêchant ASUS de vendre leurs PC avec Linux pré-installé en Belgique. En grattant un peu plus, bien qu'il ne l'ait pas avoué, le vendeur a bien compris que, si problème de licence il y avait, ce ne pouvait être que du côté Microsoft, menant probablement un lobbying relativement puissant afin d'empêcher sa suprématie de reculer -- du moins en Belgique.
Eh bien, ça, si c'est vrai, ça me fout vraiment les boules et la situtation française me fait envie...
[ Répondre ]



Re: gestion des images > 8 bits
Je ne suis pas d'accord avec la seule argumentation "plus de bits par canal permet de rattraper une photo sous-exposée".
Ce n'est pas ça qui sauvera la photo de manière la plus efficace mais une conversion adaptative, non linéaire, comme pour le cas des CDROM. La résolution des signaux de faible valeur est plus fine et celle des signaux de plus forte amplitude plus faible, en raison de la répartition statistique des valeurs.
La sur- ou sous- exposition résulte d'une mauvaise exploitation de la gamme de valeurs. Exemple: une valeur maximale de 64 sur une échelle de huit bits représente une perte de 75% de la dynamique. Passer à 14 ou 16 bits ne fait que déplacer ou reporter le problème et n'éliminera pas le risque de perdre une photo sur- ou sous- exposée. Une conversion adaptative, oui. Mais ça, ce n'est pas à Gimp de le faire mais aux fabriquants de capteurs -- je ne sais pas si c'est le cas ou pas, remarque.
Si tu es obligé d'augmenter la résolution pour pallier au problème de la sur- ou sous- exposition, c'est que la conversion numérique n'exploite pas la gamme des valeurs numérique de manière efficace. Donc, ce qui compte, c'est avant tout d'avoir un algorithme de conversion efficace (e.g. adaptatif) avant de songer à augmenter la largeur des canaux de couleurs.
D'autre part, le site que tu références compare une image RAW (12/14 bits) avec une image JPEG (8bits). Une comparaison significative aurait été entre RAW et PNG en raison de la compression, non destructrice dans le cas de PNG.
Mais bon... je suis d'accord de me taire sinon je risque de me faire incendier pour hérésie compulsive...
[ Répondre ]