Articles précédents : Logiciel
- [45] Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource
- [4] Dr. Geo II, médaille d'or aux ESUG Innovation Technology Awards
- [29] Vision2Pixels: un moteur de critique photographique libre
- [11] Lancement de Horux
- [136] GNOME 2.24 : un air de renouveau
- [31] Sortie de CLFSWM 0809.
- [18] Ouverture de Tosca
- [93] Ekiga 3.00 disponible !
- [26] Sortie de Rockbox 3.0
- [2] AbulÉdu fête ses 10ans avec une nouvelle version et un nouveau modèle économique
Liens connexes
- GIMP (769 hits)
- Notes de publication de GIMP 2.6 (401 hits)
- Présentation en français sur GIMP-fr (1172 hits)
- GIMP sur dmoz (294 hits)
- Journal d'un lecteur sur Gimp 2.6 (1188 hits)
- PC Inpact : Traitement d'image : The GIMP 2.6 fait peau neuve (605 hits)
Dépêche modérée par
Dépêche éditée par
Comme le confirme le cycle assez court, cette étape est principalement une transition vers GIMP 3.0 et le nouveau moteur GEGL censé combler les lacunes reprochées à un logiciel créé il y a maintenant treize ans. Après une longue attente de GIMP 2.4, les développeurs ont donc adopté le célèbre adage en cours dans le logiciel libre « publiez tôt, publiez souvent » (release early, release often).
GIMP (769 hits)
Notes de publication de GIMP 2.6 (401 hits)
Présentation en français sur GIMP-fr (1172 hits)
GIMP sur dmoz (294 hits)
Journal d'un lecteur sur Gimp 2.6 (1188 hits)
PC Inpact : Traitement d'image : The GIMP 2.6 fait peau neuve (605 hits)
> Lire la suite (203 commentaires, moyenne: 3,1). [dépêche : 3810 caractères]
L'interface
L'interface de GIMP a été revue et simplifiée, les entrées de menus ont été regroupées vers un ensemble plus cohérent. La différence à l'ouverture du programme est frappante avec une fenêtre d'image vide, concept absent dans les versions précédentes et qui pouvait perturber les novices (« mais où est la fenêtre principale ? »). Un simple glisser-déplacer dans cette zone ouvre l'image si le format est géré.
Les menus de la boîte à outils et de la fenêtre d'image étaient en grande partie redondant ; ils en forment maintenant un seul, disponible dans la fenêtre d'image.
Le comportement des boîtes à outils et de dialogue est désormais davantage lié à la fenêtre d'image.
Dans cette version 2.6 de nombreux composants de l'interface graphique utilisent la bibliothèque vectorielle de rendu à deux dimensions Cairo. Cela permet d'améliorer grandement le rendu de certains composants comme le démontre cette copie d'écran comparative.
Le moteur
La bibliothèque générique GEGL est en cours d'intégration, et certaines fonctions peuvent désormais y faire appel, pour les outils de couleur par exemple, passant d'une prise en charge sur 8 bits à 32 bits en virgule flottante. Certains effets, comme le flou gaussien par exemple, peuvent également bénéficier optionnellement du nouveau moteur expérimental.
Il faut cependant noter que le flux global de travail reste à 8 bits sur cette version, étant limité par le plus petit dénominateur commun (et ceci jusqu'à l'intégration complète de GEGL).
Les outils
Une sélection mixte polygonale / main levée fait son apparition.
Le cadre des textes devient redimensionnable
La vitesse du dessin a maintenant une influence sur la taille de la brosse. Cela permet, par exemple, de simuler à la souris le tracé obtenu par une tablette graphique puisqu'un mouvement rapide donnera un trait d'épaisseur et d'opacité moindres qu'un mouvement lent.
L'aide
C'est maintenant le moteur de rendu Webkit qui permet de visualiser les nombreuses pages d'aide au format HTML. Ce moteur offre la possibilité de visualiser soit les pages locales, soit les pages d'aide disponibles sur Internet (avec une priorité aux unes ou aux autres en fonction des préférences).
L'avenir
Les développeurs de GIMP ont une idée claire du chemin qui reste à parcourir pour faire de leur logiciel un incontournable du dessin matriciel, en gommant les défauts qui lui sont encore reprochés. La version 2.8 apportera par exemple une amélioration de l'outil texte par l'intégration du travail réalisé dans le cadre du Google Summer of Code 2008. L'intégration de GEGL sera améliorée et les possibilités de scriptage à partir du langage Python seront revues.
La version 3.0 est celle qui verra la bascule complète sur GEGL et l'abandon du moteur 8 bits. Cette version proposera également les groupes de calques, fonction attendue impatiemment par certains.
Pour aider au développement de GIMP et donc participer à l'avènement de la fameuse version 3.0 vous pouvez faire un don ou bien participer à la traque des bugs.
gestion des images > 8 bits
Et la gestion des images avec une profondeur de couleur supérieure à 8 bits c'est pour quand? La 2.8 ou la 3.0?
Perso (et je ne pense pas être le seul) c'est l'évolution majeure de Gimp que j'attends et qui fera que je l'utiliserai régulièrement.
D'ailleurs quand tu annonces la sortie de la 2.6 sur un forum photo la première question qui arrive c'est: "Est-ce qu'il gère enfin le 16 bits?" ...
Tu dis les développeurs ont donc adopté le célèbre adage en cours dans le logiciel libre « publiez tôt, publiez souvent »
Est-ce qu'un rythme fixe a été adopté (genre tous les 6 mois) ou est-ce au petit bonheur la change?
-
[^]Re: gestion des images > 8 bits
Posté par Spacio () le 03/10/2008 à 11:57. (lien). Évalué à 0.Et la gestion des images avec une profondeur de couleur supérieure à 8 bits c'est pour quand? La 2.8 ou la 3.0?
A priori tout de suite si on en croit la description ici: http://gimp-fr.org/presentation_gimp26.php#couleurs-
[^]Re: gestion des images > 8 bits
Posté par gpe () le 03/10/2008 à 12:10. (lien). Évalué à 4.Pas si j'en crois l'avertissement qui suit sur la page que tu cites:
Il est important de noter que Gimp dans son ensemble reste 8-bits jusqu'à ce que GEGL couvre l'ensemble de l'application.
D'ailleurs si tu essaies d'ouvrir un tiff 16 bits Gimp 2.6 t'avertit qu'il ne le gère pas et qu'il va le convertir en 8 bits...
-
[^]Re: gestion des images > 8 bits
Posté par canard_wc () le 03/10/2008 à 14:42. (lien). Évalué à 6.Il semblerai que la profondeur 16 bits soit pour la 2.8 :
- 2.6 représente l'arrivée du moteur GEGL, mais restera un éditeur RVB 8bits. La vitesse de travail sur de grande image en est amélioré.
- 2.8 permettra d'utiliser des images de modes différents (CMJN, 16 bits ...)
-
-
[^]Re: gestion des images > 8 bits
Posté par Anglade Pierre-Matthieu (page perso, ) le 03/10/2008 à 12:15. (lien). Évalué à 6.De toutes façons les capteurs de la majorité des appareils photos sont incapable d'atteindre une dynamique de couleurs tirant pleinement partie d'une description sur 8 bits par canal. Par ailleurs, j'ai la mauvaise habitude d'utiliser des images jpeg qui, si mes souvenirs sont bon, sont soumis à la même limite. Donc, même si je trouve sympa l'idée de pouvoir utiliser une decription incroyablement plus précise des images, je doute fortement que le résultat final puisse être fort différent. À l'écran, en tous cas, la différence ne peut qu'être nulle puisque ma dalle LCD même en mode photo se limite à 6-8 bits par canal. Et même sur tirage photo où je n'ai jamais été déçu par la qualité des tirage des horribles petites photos toute floues que produit l'optique très moyenne de mon compact (à condition que j'ai pris le soins de lui fournir un signal suffisant) je doute que faire mes montage en 32 bits apporte grand chose...
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?--
PMA-
[^]Re: gestion des images > 8 bits
-
[^]Re: gestion des images > 8 bits
Posté par mister popo (page perso, ) le 03/10/2008 à 12:49. (lien). Évalué à 10.C'est très pratique pour les scanners, par exemple. Les scanners sont bien plus précis qu'un appareil photo numérique, les données au dela des 8 bits sont donc pertinentes.
Le cas classique est le scan de diapositives mal exposées. Tu scannes, et ensuite, ton logiciel et permet de piocher dans les 10 ou 12 bits d'informations pour arriver à construire une image correct sur 8 bits. Avec plein de bits, on peut sauver un contre jour, par exemple, qui est à la fois trop clair et trop sombre.
Pas besoin d'être pro pour ça.
-
[^]Re: gestion des images > 8 bits
Posté par case42 (page perso, ) le 03/10/2008 à 12:51. (lien). Évalué à 10.Bon, je suis un photographe amateur, et clairement oui, j'ai besoin de plus de 8bits par canal pour faire de la retouche.
La modification principale que j'apporte sur mes photos, c'est de d'étendre le contraste avec l'outil "courbe" . Souvant il y a des zones "vide" aux extrèmes de l'histogramme (dans les fortes ou faibles lumières donc).
( ex flagrant ici : http://www.xwing.info/digikam/images/histogramme_correction.(...) )
En ajustant cela sur une image 8bits (genre jpeg) , tu te retrouve immencablement avec des
"franges", car forcement, tu as étendu sur 8bits une zone qui couvrait en fait 5 ou 6 bits.
Si tu parts d'une image "RAW", qui tu traite dans un outils qui sait gérer sa profondeur de 16 ou 24 bits, forcement ça change tout! avec le même exemple, tu étends sur 32 bits une zone qui en couvrait 24. Tous as toujours ces "trous" dans ton histogramme, mais ils disparaissent quand tu fais un export vers le format final (en 8bit).
Je pense que je vais prochainement craqué et investir dans un outil plus adapté au traitement photo que Gimp, mais payant: http://bibblelabs.com/fr/-
[^]çà sert à quoi l'histogramme
Posté par syj () le 03/10/2008 à 13:26. (lien). Évalué à 8.Quelqu'un pourrait m'éclairer sur les usages possibles de l'histogramme ?
Car je vois bien que c'est un outil important mais je ne comprends pas son usage et son objectif.-
[^]Re: çà sert à quoi l'histogramme
Posté par Hardy Damien (page perso, ) le 03/10/2008 à 14:08. (lien). Évalué à 9.Tu peux savoir où sont les information dans ta photo et appliquer des filtre pour décaler/étirer/moduler ton spectre. et faire en sorte que le maximum d'information reste dans la partie "visible du spectre".
Tu peux voir rapidement les (sous|sur)expositions
plus d'info par exemple là http://luministes.com/pages/cb_histogramme.cfm
-
[^]Re: çà sert à quoi l'histogramme
Posté par case42 (page perso, ) le 03/10/2008 à 14:12. (lien). Évalué à 10.Sur un histogramme, tu as en X la "valeur" (luminosité ou couleur... donc Xmin tu as "sombre", et en Xmax "clair") et en Y le nombre de pixel qui ont cette valeur (Ymin: peu de pixels ont cette valeur, Ymax: beaucoup de pixels ont cette valeur)
Dans mon exemple, l'histogramme me permet de voir comment je peux optimiser le contraste de ma photo.
Si tu prends toujours l'illustration suivante: http://www.xwing.info/digikam/images/histogramme_correction.(...)
typiquement, une photo avant retouche a un histogramme semblable à celui du bas: avec du vide à droite ou à gauche. Si elle à une bosse à gauche, c'est qu'elle est sous-exposée (tous les pixels ont des valeurs faibles), si elle a une bosse à droite, c'est qu'elle est sur-exposée (tous les pixels ont des valeurs fortes).
Grâce à l'outil "courbe", on peut corriger cela et s'approcher de l'histogramme présenté en haut sur l'image: une répartition optimal des pixels sur toute la plage de valeur.
-
[^]Re: çà sert à quoi l'histogramme
-
-
[^]Re: gestion des images > 8 bits
Posté par Albert () le 03/10/2008 à 16:10. (lien). Évalué à 2.Peut etre pourrait tu regarder du cote de krita (que j'espere qui fonctionnera un jour sur ma distrib vu que les differentes beta et alpha se vautre comme une loutre bourree a l'ouverture de n'importe quel image...) et de digikam. Les deux ont le support 16 bits.
-
[^]Re: gestion des images > 8 bits
Posté par Frédéric COIFFIER () le 03/10/2008 à 16:22. (lien). Évalué à 1.Sans vouloir faire l'apologie des logiciels propriétaires, je t'encourage à craquer pour Bibble ! Pour le développement RAW de photo, il n'y a pas de comparaison possible avec les outils open-source actuels (qui se limitent tous à utiliser dcraw d'une manière ou d'une autre).
De plus, la version 5 sort bientôt (http://bibble-photos.org/interface-bibble ) et l'achat de Bibble 4 donne droit au passage à Bibble 5 gratuitement.-
[^]Re: gestion des images > 8 bits
Posté par Cyprien Le Pannérer (Jabber id, page perso, ) le 03/10/2008 à 17:20. (lien). Évalué à 1.Puisqu'on en est à recommander des outils proprio (Il y a vraiment un manque en logiciel libre la :( ), je te recommande lightzone : http://www.lightcrafts.com/products/index.html
C'est produit que je trouve particulièrement facile à utiliser pour le traitement des raw.
-
[^]Re: gestion des images > 8 bits
Posté par imr () le 03/10/2008 à 17:59. (lien). Évalué à 2.Je connais peu le sujet (je n'ai lu que ça: http://en.wikipedia.org/wiki/Dcraw ), ton commentaire semble laisser entendre que le problème est du coté de dcraw, peux tu préciser la situation et les problèmes qui découlent de son usage?
-
[^]Re: gestion des images > 8 bits
Posté par gpe () le 03/10/2008 à 21:04. (lien). Évalué à 2.dcraw n'est pas le problème en tant que tel, c'est un bon moteur de dérawtisation d'ailleurs beaucoup de logiciels commerciaux se basent sur lui. Mais tout seul il n'est franchement pas pratique d'usage et nécessite pas mal de travail avant d'obtenir une image fianle et aucune surcouche finalisée n'a vu le jour actuellement en tant que logiciel libre.
-
-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 03/10/2008 à 20:01. (lien). Évalué à 2.Sans vouloir critiquer Bibble qui reste un très bon logiciel, il y a quand même une abération dans son design : "Il est *impossible* de faire un Undo !", oui, oui, vous avez bien lu, pas d'annulation des modifications...
Donc tu change quelques reglage et tu te dis que c'était mieux avant, et bien tu es obliger de retrouver tout seul les réglages d'avant...
La solution recomandée sur leur site : Utilisez le copier-coller des préférences ; Avant de faire une manip, avec une touche tu copie les reglage de la photo, tu fais ta modif et si tu veux annuler tu colle les anciens reglage.
Bref le truc super intuitif, très pratique et qui ne permet qu'un niveau d'annulation.
Le pire c'est que Bibble 5 est en dévellopement depuis plusieurs année, et il y a 3/4 mois environs quand je pose la question sur le forum pour savoir si la nouvelle version aura une fonction undo, la personne chargée de communication me répond qu'ils ne savent pas encore si cela sera implémenté...
Donc la ces clairement du foutage de gueule, ils sont à la fin du dévellopement, ils ont déjà des betas internes qui tournent et il ne savent pas si ils vont mettre un undo... Une fonctions qui est quand même un peu au coeur du logiciel et nécéssite pas mal de code un peu partout... Au dernière nouvelles la fonction sera présente dans la 5.0
Donc j'avais laissé tombé la version 4 car même si c'est un des meilleur d'un point de vue qualité pour le développement des RAW, c'est aussi un des moins ergonomique. La version 5 semble corriger tous ces défault, reste plus qu'à attendre qu'elle sorte...-
[^]Re: gestion des images > 8 bits
Posté par gpe () le 03/10/2008 à 20:56. (lien). Évalué à 2.La version 4 offrait un undo global (suppression de toute les modifs).
La version 5 qui va sortir avant la fin de l'année offrira un vrai undo complet.
La version 5 n'est pas la prolongation de la 4 mais une réécriture complète du logiciel qui inclura des fonctions de cataloguages, selon plusieurs mode, de retouche avancée, etc, etc
Son concurrent direct est Lightroom.-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 03/10/2008 à 21:31. (lien). Évalué à 3.Très pratique le undo global... il annule toutes les modifs depuis l'ouverture du fichier ou la dernière sauvegarde. Pas moyen de retourner 3 ou 4 modifs en arrière si on as pas pensé au bon moment à sauvegarder ou à copier les paramètres, ou si entre temps on l'a refait.
Il y a deux ou trois mois je n'aurrais pas parié qu'elle sortirait avant la fin de l'année, mais après la démo à la photokina je pense qu'il devrait réussir... je commencait à avoir peur qu'il nous fassent le même coup que duke nukem forever...
C'est super cool toutes les nouvelles possibilités quelle va apporter, mais je dois avouer que ça m'a particulièrement lourdé qu'on nous annonce des trucs du style cataloguages et autre, et rien sur le undo ???
C'est quand même une fonction de base sur ce genre de logiciel, l'erreur est humaine, et je dois être très humain car quand je fais du dévellopement de photos j'en fais beaucoup. Et j'ai arrêter d'utiliser bibble à cause de ça car je perdais un max de temps.-
[^]Re: gestion des images > 8 bits
Posté par Frédéric COIFFIER () le 03/10/2008 à 22:51. (lien). Évalué à 2.Contrairement à Gimp, les modifications ne sont pas destructives. On déplace un curseur et si ça nous plaît pas, on le remet là où il était. Et des réglages, il n'y en a pas tant que ça par catégorie. Donc, effectivement, quand on débarque, on cherche le "Undo" mais finalement, on arrive à s'en passer.
-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 04/10/2008 à 10:36. (lien). Évalué à 3.Lesmodifs ne détruisent pas l'image mais détruisent tes précédent reglages, donc au final ça reviens au même le plus souvent.
Sous gimp tu fais quelques modifs et ça ne te plait pas tu peut faire quelques undos, sous bible tu ne pas repartir que des dernier point de reprises. (les differentes sauvegardes de l'image et la dernière sauvegarde des reglages)
Et même si tu modifie que quelques reglages c'est très rapidement génant. C'est quand même une fonction de base de l'édition d'image, je suis sur que même paint dispose d'un undo...
D'un point de vue qualité Bibble est au dessus des autres et je l'ai beaucoup utilisé. J'ai fais comme toi, j'ai éssayé de m'en passer, mais au bout d'un moment j'ai finis par en avoir ras le bol de perdre du temps et j'ai abandonné.
Ta formulation est d'ailleur très explicite "on arrive à s'en passer". Ce n'est pas naturel mais on fais avec... Mais au bout d'un moement....
Pour la majoritée des traitement j'utilise maintenant rawtherapee. Il n'est pas libre non plus mais il est bien plus fonctionnel. Il permet de faire des dévellopement de très bonne qualité. Et au niveau du travail sur une photo il est beaucoup plus puissant ; il dispose d'un vrai historique d'édition et permet de naviguer dedans très naturellement.
Bibble ne me sert plus que pour les photos nécéssitant un traitement très poussées pour être exploitable du style une photo très bruitée faite à 1600iso dans un concert ou un spectacle. Mais en dehors de ces cas exceptionels, bibble 4 n'a pas assez d'avantages sur la concurence pour faire oublier ses défaults.
Bibble 5 devrais changer tout ça et avec un peu de bol je pourrais de nouveau utiliser un seul logiciel pour tout mes dévellopements, en attendant une solution libre.
Au niveau solution libre d'ailleur... On commence à avoir toutes les billes pour pouvoir faire un logiciel de qualité.
- DCraw permet le décodage des raw de virtuellement tous les appareil disponibles, et propose de algos de demosaicage tout à fais corrects, des codes pour d'autres algos sont disponibles en libre.
- littlecms permet une bonne gestion des espaces de couleurs
- babl et gegl offre tout le traitement graphique derriere
Il manque juste une jolie interface autour de tout ça...
Et personnellement je ne pense pas que Gimp soit l'idéal pour le dévellopement photo. Il faut bien voir que la retouche photo et le devellopement sont deux opérations différentes qui ne s'organisent pas de la même manière,
A mon avis il faudra une appli suppléméentaire ou un autre mode de fonctionement pour gimp.
Vivement la sortie de Bibble 5 pour mon coffort personnel, mais surtout vievement une solution libre et performante...
-
-
-
-
-
-
-
[+] [^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 13:17. (lien). Évalué à -2.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.-
[^]Re: gestion des images > 8 bits
Posté par Sarcastic (Jabber id, ) le 03/10/2008 à 13:28. (lien). Évalué à 7.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.
Sauf si l'on considère que l'œil ne perçoit pas les 8 bits de façon linéaire, ou qu'on est amené à faire des modifications sur l'image qui vont modifier l'espace colorimétrique (courbe de gamma, histogrammes, tout ça).
-
[^]Re: gestion des images > 8 bits
Posté par Laurent Moussault () le 03/10/2008 à 13:36. (lien). Évalué à 10.D'abord, comme il est expliqué plus haut, l'intérêt principal d'un codage plus précis, c'est que cela permet d'effectuer une série de transformations sans dégrader la qualité finale (perçue). La plupart des transformations dégradent le signal, donc si au départ tu te situe à la limite de ce que l'on peut distinguer, à la sortie tu es en dessous...
C'est exactement la même chose en musique (on travaille avec des dynamiques supérieures à la qualité CD).
Ensuite, la perception humaine est un sujet bien plus complexe qu'une simple histoire de récepteurs. Ce que l'on ne perçoit pas directement peut très bien nous toucher indirectement.
-
[^]Re: gestion des images > 8 bits
Posté par Zenitram (page perso, ) le 03/10/2008 à 14:01. (lien). Évalué à 2.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 ;-) .
Pfff...
32 bits, c'est 8 bits par canal (R,G,B,A, même si la A est rarement utilisé), c'est "juste" un exposant de 2 (contrairement à 24), est c'est surtout parce que c'est pratique.
Ensuite, tu parle de 6 bits "utile" par canal, on est assez d'accord sur ça. MAIS : as-tu appris à l'école ce que c'est que l'approximation? En pratique, sur tes 8 bits tu fais un transformation il te reste 7 bits "utile" (le dernier bit est du bruit venant du manque de précision), tu fais deux transformations 6 bits, 3 transformations hop 5 bits et tu as dénaturé l'image.
Bon, en pratique c'est moins violent car il y a de bons algos pour corriger, mais ça reste de la bidouille. Travailler sur 16 bits par couleur évite le bruit.
Après, pour la diffusion oui c'est inutile. Mais la on parle de travail sur une image, avec les problèmes d'approximation qui en découlent.-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 15:09. (lien). Évalué à 1.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?-
[^]Re: gestion des images > 8 bits
Posté par Zenitram (page perso, ) le 03/10/2008 à 15:16. (lien). Évalué à 2.On est (presque) d'accord.
Je partirai quand même du principe que qui peut le plus peut le moins, donc quitte à tout modifier dans le moteur, autant faire du 32 bits tout de suite, on sait jamais ça peut toujours servir plus tard (genre parce que la vidéo prévoit aussi des modes 10 ou 12 bits pour la diffusion finale, donc 16 bits seront un peu juste en traitement avant codage pour que les derniers bits soient conformes aux attentes), et vu la place qu'on a en RAM et disque dur maintenant ça ne changera pas grand chose.
-
[^]Re: gestion des images > 8 bits
Posté par gpe () le 03/10/2008 à 15:41. (lien). Évalué à 1.Pas d'accord, quand ta source est en plus de 8 bits, Raw des APN qui sont entre 10 et 16 bits, il faut bien un traitement 32 bits pour les traiter correctement et ressortir en 16 bits, non?
-
[^]Re: gestion des images > 8 bits
Posté par case42 (page perso, ) le 03/10/2008 à 15:48. (lien). Évalué à 3.Tout a fait d'accord.
Exemple bête : pour l' [[Imagerie_à_grande_gamme_dynamique]] (c'est un nom qui fait très sérieux mais c'est à la porté de tout amateur de photo)
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...-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 04/10/2008 à 01:36. (lien). Évalué à 1.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...-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 04/10/2008 à 10:41. (lien). Évalué à 2.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é.-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 04/10/2008 à 12:37. (lien). Évalué à 2.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.-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 04/10/2008 à 13:28. (lien). Évalué à 3.Pourquoi faire des télé de 56pouce alors qu'une vieille 10 pouce est largement suffisante pour regarder la starac ?
Ce n'est parce que toi tu n'en as pas besoin qu'il faut limiter les aures et une précision superieur a 8bits est indispensable à beaucoup de personnes, pas que lesphotographe pros mais aussi les amateurs.
Donc peut-etre que ton commentaire était ironique, et en effet ton exemple était absurde. Mais une precision superrieur à 8bits n'est pas une idée absurde mais une idée qui répond à un besoin.
J'essaye juste de te faire comprendre que ce n'est pas absurde, qu'il y a un vrai besoin derriere. Après si tu veut rester sur ton avis que c'est absurde d'avoir plus, je m'en fous mais moi ce que je trouve absurde c'est dene pas comprendre que tout le monde n'a pas les même besoins.-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 05/10/2008 à 15:33. (lien). Évalué à 5.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?-
[^]Re: gestion des images > 8 bits
Posté par case42 (page perso, ) le 05/10/2008 à 16:09. (lien). Évalué à 5.Toujours aussi catégorique?
/me relis le sujet de la news...
Dans la mesure ou on parle de GIMP depuis le début, qui est tout de même, rappelons-le, un logiciel de TRAITEMENT d'image, ta distinction entre traitement et représentation, si elle a sans doute un peu de pertinence quelque part, tombe un peu hors sujet. On parle depuis le début de TRAITEMENT de l'image, et donc dire "ha mais moi je parlais juste de REPRÉSENTATION" à la fin du troll, ça fait vraiment rattrapage aux branches en catastrophe.
Mise à part ça, moi les discours du genre "X c'est largement suffisant" ( avec X comme "8 bits par canal", ou "640K de RAM" ) me laissent toujours sceptique... Je pense que ça dépend énormément de plein de choses, en particulier le périphérique final (déjà entre écran CRT ou TFT, y a un monde, dans l'impression, c'est encore une autre histoire, etc... ). Quand demain on aura jeté nos écrans à la poubelle et qu'on branchera directement nos cartes vidéo sur nos nerfs optiques, y à de fortes chances qu'on trouve ces affreuses images 8bits du début du siècles hideuses.
Sur le postula précis "l'œil ne peut pas distingué un dégradé sur plus de 7bits", moi ça me hérisse le poil de parler d'une valeur digitale avec un organe tout ce qu'il y a de plus analogique (et même pire que ça, biologique).
C'est un peu comme les 24 images par secondes du cinéma. Moi, je déteste aller au cinéma, parce que 24FPS, c'est définitivement insuffisant. Parfois, ça suffit, mais dès que ça bouge un peu, ça se voit, et c'est laid. En plus, immanquablement je ressorts avec mal à la tête ( ça fait cher le mal de tête ).
-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 05/10/2008 à 17:38. (lien). Évalué à 6.Vois pas le rapport.
Le rapport c'est que une télé de 10 pouces c'est suffisant pour afficher n'importe quel film, au dessus c'est pas nécéssaire donc pour quoi avoir une télé de 56 pouces ?
C'est la même chose que pour 8bits c'est suffisant pourquoi en prendre 32 ?
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*.
Il ne s'aggit pas de toi mais tu as quand même poster des messages auquels je répond...
C'est le premier message notament ou tu parle de la différentation entre les deux.
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é.
C'est pas toi qui l'a inventer mais tu n'est pas aller voir ce qui disait les gens qui l'on inventé...
Creuse un petit pour voir les conditions dans lesquelles 200 niveau de couleurs sont suffisante et tu verra que ce genre de tests sont fait sur des images à contraste naturel et avec des taux limites d'aplats.
Si tu prend une images très peu contrastée avec de grands aplats de couleurs unies, si en plus ces aplats sont aux imites de l'espace de couleur, et bien même avec 8bits de précision l'oeil humain fait la différence sans problème entre les différents niveaux.
Cette étude montre que sur des images moyennes, c'est-à-dire 95% des images 200 niveaux sont suffisants, mais ce n'est pas toujours le cas.
De plus pour des tirages haut de gammes en grand formats avec 8bits tes applats quelqu'ils soient auront une drole de gueule.
Donc non ! Même pour de la représentation 8bits n'est pas toujours suffisant. Tout dépend de ce que tu représente. Et c'est même un problème avec les écrans actuels, ils manquent de dynamique et ont souvent un espace de couleur étriqué.
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.
C'est peut-être moi qui suis con mais je ne vois pas de commentaire ou tu ais préciser clairement que tu parlait uniquement de la représentation. On est dans un journal qui parle de Gimp, un outils d'édition d'image, si tu parle d'autre cose il faut être clair. De plus même dans le cas de la représentation il est faut de dire que 200 niveaux suffises. Comme dit au dessus, il ne sont suffisant que pour des images moyennes.
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.
Mais je ne l'oublie pas, c'est d'ailleur un sujet de préoccupation pour moi. Toutes les photos que je fais il faut bien que je les stock, et c'est sur qu'en raw ça prend plus de place qu'en jpeg.
Mais si tu converti en noir en blanc au format timbre poste c'est encore plus petit. Tu devrais stocker tes image en 100x100 sur 1 canal de 1bit et tu verra c'est encore plus petit.
Il y a beaucoup d'information dans les 12bits par canal de mes photos et je ne tiens pas à les predre en passant à 8bits. A chaque fois que je veux refaire un traitement différent d'une photo je suis bien content d'avoir garder le raw...
Maintenant si je sauvegarde tout en 8bits et que je n'utilise plus de bits que pour le traitement et bien quand j'ouvre mon image j'ai quand même perdu 4bits d'information par rapport à ce que mon appareil à produit. Si ma photo est surexposée à l'origine, avec une photo en 8bit je ne peut rien faire a part la suprimmer pour libérer un peu de place. Si elle est en 12 bits je refait ma balance des blancs, je bosse un peu sur l'histogramme et quelques autres trucs et voilà, une jolie photo parfaitement utilisable grace à la magit des 4bits supplémentaires. Pour un exemple en image, tu en trouve plein sur le web, notament :
http://www.cmp-color.fr/rawvsjpeg.html
Une photo ne doit être convertie en 8bits que au dernier moment, une fois que l'on sait qu'elle est prète et qu'il n'y a plus d'autre traitement à éffectuer. A ce moment là on la convertit en 8bit on la sauve en png ou jpeg et on la met sur le net.
Là pas de problème, mais si tu convertit avant cela veut dire que tu va perdre de l'information pendant le traitement de manière irécupérable.
Bien entendu pour un jpeg super compresser de la taille d'un timbre poste sur le web ça ne sert à rien d'avoir plus, on êut même faire avec moins...
Par contre quand tu veut de belle photos et que tu travail desus il faut que à *toutes* les étape tu garde la précision maximale et le choix le plus intéligent dans ce cas en terme de performances et de qualité c'est actuellement le 32 bits. Et gimp est fait pour travailler sur des image et produire de la qualité donc un autre choix serait absurde.
d'autre modes sont possible, gegl et babl gérent aussi le 8/16/32bits entiers, mais ils n'on d'intéret que sur des architecture ou les flotants 32bits on des problèmes de perf.
Tu peut aussi choisir de toujours rester en 8bits si tu ne fait que des images pour le web, mais dans ce cas tu doi toujours faire attention à tes applats à chaque étape du traitement et tu te complique la vie pour rien.-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 06/10/2008 à 15:18. (lien). Évalué à 3.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...-
[^]Re: gestion des images > 8 bits
Posté par case42 (page perso, ) le 06/10/2008 à 15:42. (lien). Évalué à 3.Mais non te tais pas, pour une fois qu'on a un troll^W^W une discutions intéressante :D
Bon plusieurs choses...
Sur le discours "mauvais algo, changer algo, pas changer matos", c'est pas faux mais c'est pas voir très loins non plus. Qu'il ne faille pas prendre les avancés du matos comme alibi pour ne pas travailler sur les algos, je suis tout a fait d'accord. Mais une chose est certaines: a qualité d'algo de traitement égal, avec 12bits on a un meilleur image qu'avec 8, c'est juste certain. Après, que l'oeil fasse pas la différence, c'est pas la question, parce qu'on a tout de même démontré que suite à manipulation, on pouvait rapidement manger la marge qu'on a avec les 12 ou 14 bits.
Bon algo ou pas bon algo, si le constructeur arrive a nous sortir des capteurs en 14, 16 ou soyons fou un jour 24 ou 32 bits, moi je prends, je crache pas dans la soupe.
C'est comme les "megapixels". On lit parfois que ça sert a rien d'en avoir moult, le fait est que plus j'en ais, plus je suis heureux, parce que ça veut dire qu'en moment du traitement, j'aurais beaucoup plus de latitude pour recarder mon image.
Enfin, il y a un détail qui n'a pas été souligné assez fortement depuis le début je trouve, c'est qu'en l'occurrence on compare du 12bits entier (RAW) avec du 32bits flottant (GEGL) (gegl sait faire autre choses, mais ça à l'air d'être le mode le plus convenu).
Or voila, on ne peut pas comparer de la sorte entier et flotant. Et donc, si tu pouvais avoir raison en parlant d'entier (32bits entier c'est trop pour traiter des RAW en 12 ou 14 bits entier), en flottant c'est plus vrai du tout! Un flottant sur moins de 32 bits est pratiquement inutilisable; et pour le coup, je cracherais pas sur du flottant en 64bits.
-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 06/10/2008 à 17:18. (lien). Évalué à 4.L'argument est question était pour montrer une des intérets de plus de 8bits par canal sur un xeemple relativement simple à comprendre, dans la pratique il y a un plus de choses à prendre en compte.
Tout ce que tu dis est vrai pour du jpeg mais pas pour du raw.
L'objectif du fichier RAW est de contenir les données brutes issues du capteur. Le moins possible de traitement est fait dans l'appareil.
Pourquoi ? Car l'appareil dispose d'un temps, du puissance et d'une mémoire limité par rapport à un ordinateur moderne. Il est donc possible au dévellopement d'utiliser des algorithme beaucoup plus évolués et performants.
Donc un fichier raw reçoit les données brutes, c'est-à-dire une image en niveau de gris (chaque cellule ne capture qu'une des trois couleurs) linéaire (le capteur est linéaire, pas le choix...). Chaque pixel correspondant à une céllule du capteur. Les premières étapes sont généralement :
- le dématricage, pour passer de l'image en niveau de gris à une image couleur.
- Un convertion gamma pour quitter le mode linéaire
- La balance des blancs
Sur un fichier raw ces étapes sont éffectuées sur l'ordinateur pas sur l'appareil, donc dans ce cas, on s'en fout des algos utilisés par l'appareil.
J'ai parler de la sur-exposition car c'est une chose très utilisée par les photographes. Comme tu le dis la capture est linéaire mais pas la vision humaine, il y a donc une conversion à éffectuer.
Cette convertsion fait que la gamme sombre va être étirée et la gamme claire compressée. Il y a donc perte d'information dans les tons clairs car au final tu auras par exemple 200 valeur en linéaire converties en 100 valeurs dans l'image finale. Et un effet de peigne dans les valeurs sombres.
Ces pour cela que l'on conseil de surexposer un peu les photos lors de la prise de vue en raw. À la conversion on réexpose correctement l'image de manière à avoir une quantité d'information relativement homogène sur toute la gamme.
Et ça, ce n'est possible que parce que on travaille avec plus d'information que le résultat final. (voir par exemple [1])
Ensuite, pour ce qui est de l'exposition justement. L'appareil fait ce que tu lui demande et heureusement...
Tu peut lui demander d'exposer correctement tes photos et il fera de son mieux, mais il y a des situations ou c'est difficile, d'autre ou ces impossible. Donc c'est toujours valable d'avoir de la marge pour rattraper ce qui est possible.
Tu peut aussi régler toi même ton exposition et dans ce cas la, l'appareil te laissera faire, et si tu t'es planter, c'est cool aussi de pouvoir corriger...
Enfin, il y a des situations ou une sur/sous-exposition est voulue, ça permet d'obtenir des effets très chouette sur certaines photos. Par contre il est souvent agréable de pouvoir retrouver quelques détails dans ces zones pour leur donner un peu de volume.
La sur/sous-exposition est un des éléments qui, quand il est bien maîtriser, permet de faire des chose extrèmement intéressante, à condition d'avoir les outils pour.
Donc en gros, la conversion analogique numérique (dans le capteur) ne fais que capturer ce que tu lui demande (encore heureux ;-)) et donc il est nécéssaire d'augementer la résolution afin de pouvoir faire le meilleur traitement possible derrière et d'avoir la plus grande flexibilité.
Un exemple tout simple : Tu fais une photo pendant un concert. Le chanteur à un projecteur braqué sur lui et le batteur au fond est mal éclairé. En jpeg tu as de forte chance d'obtenir un chanteur cramer et un batteur boucher (san mauvais jeu de mots...)
Avec du raw, tu sur-expose d'1 ou 2 EL et à la convertion tu affine l'exposition des différentes zones de la photos pour obtenir une photo ou le chanteur et le batteur sont bien exposé.
Pour ce qui est de la comparaison RAW/JPEG, je suis daccord qu'il faudrais mieux comparer avec du png. Le problème c'est que tous les appareils produisent du jpeg, donc si tu veux comparer avec du png, et bien ton fichier png soit tu l'obtient a partir du jpeg (no comment) soit à partir du fichier raw (ce qui biase le test...)
Mais bon... je suis d'accord de me taire sinon je risque de me faire incendier pour hérésie compulsive...
Surtout pas, c'est bien qu'il y ait du débat. J'essaye de ne pas trop m'enflammer mais si je deviens méchant n'hésitez pas à me moinser....
[1] http://www.volkergilbertphoto.com/capture_lineaire.html et
http://www.volkergilbertphoto.com/exposer_raw-1.html
-
-
-
-
-
-
-
-
[+] [^]Re: gestion des images > 8 bits
Posté par gringonz () le 10/10/2008 à 21:19. (lien). Évalué à -1.Tout faux !
si tu as 2 images sur 14 bits exposées avec 1IL d'ecart, soit un facteur 2 d'exposition, ca te fait pas 28 bits mais 15 ! puisque avec 15 bits tu codes deux fois plus de nombre qu'avec 14. Donc meme en extreme avec 5 photos separées d'un IL (1 diaph ou une vitesse d'ecart) ben tu monte à à peine plus de 20 bits.
donc avec les calculs intermédiaires c'est aussi simple d'utiliser 32 bits qui est la taille des mots sur les procs (pas de tous OK mais 64 bit ca ne sert vraiement à rien).
-
[+] [^]Re: gestion des images > 8 bits
Posté par gringonz () le 10/10/2008 à 21:44. (lien). Évalué à -1.tout faux !
si tu prends 2 photos separées de 1IL d'exposition, tu double la dynamique, il te faut donc 1 bit de plus soit 15 bits pour décrire l'ensemble. Al'extreme, ceux qui font de la photo HDR vont prendre au max 5 ou 6 photos separees d'1 IL, il de faudra 21 voire 22 bits. Si tes photos sont au depart en 16 bits il t'en faut 2 de plus ! moralité avec 32 bits c'est deja bien large disons pour les calculs intermédiaire... et puis c'est bien la taille de certains processeurs...
-
-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 16:50. (lien). Évalué à 2.quand ta source est en plus de 8 bits, Raw des APN qui sont entre 10 et 16 bits
Ton raisonnement est correct mais c'est la pertinence d'une image, RAW ou pas, en plus de 8 bits par canal qui me titille...-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 03/10/2008 à 20:28. (lien). Évalué à 7.Un exemple tout con qui montre la pertinence des 12 ou 14 bits par cannal des fichiers RAW :
Tu prend un protrait en contre jour. Avec un fichier 8bits, tu va avoir une grosse tache noire au millieu d'un désert blanc. J'éxagère un peu mais l'idée est la.
Sur la même photo en 14 bits tu va avoir dans des teintes tre foncée un portait au millieu et dans des tons très clairs autour des nuages. Tu va pouvoir corriger l'exposition de ta photo de manière à obtnir au final un très joli portait.
Il n'y a rien de magique... Si on raisonne en niveau gris, si tu réduit à 8 bits une photo en 14bits, toutes les niveaux 0 à 64 correspondrons à l'unique couleur 0.
Si ta photo est sous-exposé tu utilise très peu les grandes valeurs mais beaucoup les faibles, si tu as une image en 14 bits tu corrige l'exposition tu convertit en 8bits et tu obtient une photo avec réellement 8bits d'information.
Si tu travail avec une photo en 8bits et que tu n'utilise que la moitiée du spectre, quand tu fais la correction d'exposition tu n'a plus que 7 bits d'informations.
De plus les capteur sont en 14 bits car il capture la lumière de manière linéaire ce qui n'est pas le cas de notre oeil, il y a donc une conversion à éffectuer ; le gamma, et cette transformation fais perdre de l'information dans certaines parties du spectre, il y a donc forcément une perte et donc nécéssitée de plus de 8bits.
Rajoute à ça le nombre de traitement que l'on applique sur une image : demosaicage, convertion sRGB, balance des blancs, contraste....
Tu acumule les erreurs à chaque fois et même avec des algos bien foutus pour limiter au maximum ces problèmes, ça finis par être génant.
Dans Gegl et Babl les opération travail à la base sur des float pour maximiser la précision et ne pas perdre d'information par rapport au format d'origine de l'image. Mais il est possible de coder des version optimiser pour des entiers 8bits, tout est prévu et gegl utilisera automatiquement la bonne fonction.
La dernière fois que j'ai regarder la prioritée était à finir les implémentation en float, mais si il y en as besoin il y aura bientôt à mon avis des versions optimisées pour le 8bit.
Donc pour ceux qui on besoin de plus de 8bits on sera satisfait, et pour ceux qui se contentent de 8bit il n'y aura pas de problèmes...-
[^]Re: gestion des images > 8 bits
Posté par deelight (page perso, ) le 06/10/2008 à 23:16. (lien). Évalué à 3.Très bon exemple. On peut aussi citer l'exemple extremement fréquent des photos en extérieur ou le ciel ressort totalement blanc. Si la photo a été prise en JPEG, on ne pourra pas récupérer de détail dans le ciel. Avec du RAW (14 bits dans mon cas), on peut facilement récupérer les nuages et la couleur naturelle du ciel dans cet aplat blanc, et jongler avec les masques du fusion pour avoir une expositions correcte sur l'ensemble du cliché.
Actuellement je dois utiliser dcraw pour sortir plusieurs JPEG correspondant aux expositions correctes des diverses zones de l'image, et ensuite les fusionner sous Gimp. Le jour ou je pourrais me contenter d'un seul export dcraw, je serai le plus heureux :)
-
-
-
[^]Re: gestion des images > 8 bits
Posté par Sytoka Modon (page perso, ) le 03/10/2008 à 20:32. (lien). Évalué à 3.> il faut bien un traitement
Surtout que sur les bits des APN, il y a de tout et de n'importe quoi ;-)-
[^]Re: gestion des images > 8 bits
-
-
-
-
-
[^]Re: gestion des images > 8 bits
Posté par Amand Tihon (page perso, ) le 03/10/2008 à 14:18. (lien). Évalué à 3.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.
D'autres ont déjà répondu sur le sujet de la perte d'information quand on manipule des images sur 8 bits par canal, je n'en dirai pas plus.
Mais dire que 6 bits sont suffisants pour l'œil, je ne comprends pas du tout. As-tu déjà essayé un dégradé de vert sur 6 bits ? Les bandes sont très clairement visibles.-
[^]Re: gestion des images > 8 bits
Posté par Anglade Pierre-Matthieu (page perso, ) le 03/10/2008 à 15:22. (lien). Évalué à 4.J'avais du mal à le croire mais après un rapide test :
colors = 64;
pixpercolor = 32;
npixx = colors * pixpercolor;
npixy = 50;
fp = fopen("vert6bit.ppm","w");
fprintf(fp,"P3\n# a 64 level green shade\n%d %d\n%d\n",npixx,npixy,colors);
for(i=0; i<npixy; i++) {
for(j=0; j<npixx; j++) {
fprintf(fp,"%d %d %d ",0,j/pixpercolors,0);
}
fprintf(fp,"\n");
}
fclose(fp);
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. Évidemment tout ceci sous réserves des distortions produites par les algorithmes de traitement appliqués par X, la puce graphique, l'écran ... Et sous réserves que mes yeux aient une capacité standard à distinguer les couleurs.--
PMA-
[^]Re: gestion des images > 8 bits
Posté par Frédéric COIFFIER () le 03/10/2008 à 16:29. (lien). Évalué à 6.L'oeil est beaucoup plus sensible au vert. C'est pour ça que tous les capteurs ont plus de cellules sensibles au vert, qu'au rouge ou au bleu. De même, dans la plupart des algos de compression : on préfère dégrader les informations rouges et bleues au profit du vert.
-
[^]Re: gestion des images > 8 bits
Posté par Sytoka Modon (page perso, ) le 03/10/2008 à 20:33. (lien). Évalué à 4.C'est normal, le vert est au milieu du spectre visible
-
[^]Re: gestion des images > 8 bits
Posté par Thomas Douillard () le 04/10/2008 à 14:24. (lien). Évalué à 2.C'est pas parce que le singe vivait dans les arbres, et que l'homme descend du singe ? ou de l'arbre. Ou des deux.
(fin d'élucubration hypotatoire)-
[^]Re: gestion des images > 8 bits
Posté par Sytoka Modon (page perso, ) le 06/10/2008 à 09:01. (lien). Évalué à 2.> que l'homme descend du singe
L'homme ne descend pas du singe, il fait partie de la famille des grands singes !-
[^]Re: gestion des images > 8 bits
-
[^]Re: gestion des images > 8 bits
Posté par Thomas Douillard () le 06/10/2008 à 15:16. (lien). Évalué à 3.J'ai jugé que cette approximation (archie connue bien qu'inexacte de surcroit) permettait mieux de faire passer l'idée d'un héritage génétique ...
En vrai bien sûr qu'on est cousins des grands singes.-
[^]Re: gestion des images > 8 bits
Posté par Sytoka Modon (page perso, ) le 08/10/2008 à 20:54. (lien). Évalué à 2.Le problème est que ce genre de phrase est pérojative envers les autres grands singes. L'Homme a un problème depuis longtemps : partager avec son voisin.
Aujourd'hui, on sais que les autres grands singes sont loin d'être des idiots et que, si on se donnait la peine, il y en a pas mal qui pourraient atteindre le QI du pompiste moyen de l'amérique profonde (moi aussi, je sors ici une phrase toue faite). Bref, on se retrouve face a un dilemme que nous avons déjà eu il y a quelques sciècles avec les noirs ; il faut leur faire de la place et partager les richesses de la planête.
Nos gouvernements (et pas mal de citoyens) ne sont pas prêt à cela.
Pour finir, on n'est pas cousins des grands singes, on est des grands singes ! On est donc cousins des AUTRES grands singes.-
[^]Re: gestion des images > 8 bits
Posté par Thomas Douillard () le 08/10/2008 à 21:12. (lien). Évalué à 2.Ta phrase est compètement discriminatoire envers les autres singes, qui ont aussi droit à leur part des ressources naturelles !
Plus sérieusement, ta limite est complètement arbitraire et très "affective" je trouve. Ta remarque sur le QI par exemple, c'est complètement toi qui le dit ... et c'est complètement mépriser le pompiste moyen aussi, d'ailleurs.
J'ai pas dit que les grands singes étaient bêtes, note bien, le fond de mon message c'est qu'effectivement l'homme ne doit pas détruire complètement son environnement ... c'est dans son propre intérêt d'ailleurs.-
[^]Re: gestion des images > 8 bits
Posté par Sytoka Modon (page perso, ) le 08/10/2008 à 22:33. (lien). Évalué à 2.Et il n'y a pas que les singes... les dauphins...
Parfois, pour faire avancer le débat, on est obliger de balancer des phrases un peu (trop) choc qui oblige à se rendre compte de l'absurdité de notre situation actuelle. Mais rassure toi, je n'en veux pas aux pompistes que je respecte beaucoup (quand j'en vois encore), c'est une image d'épinal comme la tienne que je te renvoyais.
L'Homme d'hier en Occident a eu beaucoup de mal a accueillir les noirs. L'Homme actuel a beaucoup de mal a accueillir ses cousins grands singes qui lui sont ses plus proches parents au sens génétique. L'Homme de demain aura certainement du mal a accueillir les autres espèces...
Un bouquin qui parle un peu de cela est : Les prairies bleus, d'Athur Clarke.
Pour ce qui est du QI, les expériences sur les autres grands singes sont assez étonnantes, mais elles manquent de continuité car justement les résultats pourraient trop déranger.
Pour conclure, je ne suis pas végétarien pour rien ;-)-
[^]Re: gestion des images > 8 bits
Posté par Anglès d'Auriac Jean-Alexandre (Jabber id, ) le 09/10/2008 à 20:24. (lien). Évalué à 2.Tiens, un autre végétarien. Salutation :·D.
-
[^]Re: gestion des images > 8 bits
-
-
-
-
-
-
-
-
-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 16:37. (lien). Évalué à 0.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...
-->[ ]
-
[^]Re: gestion des images > 8 bits
Posté par Sarcastic (Jabber id, ) le 03/10/2008 à 17:09. (lien). Évalué à 6.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. Évidemment tout ceci sous réserves des distortions produites par les algorithmes de traitement appliqués par X, la puce graphique, l'écran ... Et sous réserves que mes yeux aient une capacité standard à distinguer les couleurs.
Le problème, c'est que la vision dépend d'un tas de trucs qui font que ce test sur écran est biaisé.
— L'écran a une dynamique de couleur faible (1000:1, généralement, bien qu'on monte plus haut avec certaines astuces qui détériorent les couleurs). C'est sûr qu'avec une dynamique pareille, pas évident de voir des différences entre les applats. Et encore, c'est en admettant que l'écran affiche des trucs différents entre 7 et 8 bits.
— L'œil s'adapte merveilleusement bien à un tas de trucs, ce qui fait que selon les conditions d'éclairage, tu seras pas amené à voir tout à fait les mêmes choses.
— On a pas tous les mêmes yeux. On a même 2 yeux différents qui ne voient pas tout à fait les mêmes choses (j'ai un œil plus sensible au rouge que l'autre, par exemple).
— Et encore une fois, l'œil s'adapte très bien à certains trucs, selon l'attention qu'on porte à un objet. Mettons une photo. Il y a un tas de contrastes dessus. L'œil va tout voir (Mettons sur 6,3 bits, puisque ça semble le standard décidé par FantastiX). Mais si on fixe une zone plus distincte, moins contrastée, on continuera à voir du contraste. S'il existe, ce qui ne sera pas forcément le cas si l'on se contente de 8 bits.
— Et enfin, cela va dépendre avec quelle partie de l'œil on regarde. Si l'on regarde avec la fovea, ou pas.
Bref, limiter les impressions à du 8 bits par canal, selon moi, c'est idiot, surtout :
— si l'on peut faire plus.
— si l'on fait du noir et blanc (Parce qu'on passe de 24 bits d'informations à 8, et que l'œil est très sensible à la luminance, surtout quand on quitte la fovea).
Évidemment toutes ces remarques sont d'autant plus valables pour les capteurs.-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 19:15. (lien). Évalué à 4.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...-
[^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 19:43. (lien). Évalué à 2.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.-
[^]Re: gestion des images > 8 bits
Posté par Sarcastic (Jabber id, ) le 03/10/2008 à 20:11. (lien). Évalué à 3.Marrant, je vois des barres verticales dans le dégradé orange sur mon écran (En particulier vers le noir). Bon, c'est un test sur écran, comme je l'ai dit, ça vaut pas grand chose.
Cela dit, les critiques que j'ai fait sur la méthode du dégradé restent valable. Si on prend une vraie image, on va avoir des zones à forts contrastes, et d'autres avec beaucoup moins de contrastes. Et qu'on regarde en globalité ou localement, on verra tout de même du contraste, même si le ratio est important (et c'est impossible à évaluer avec un dégradé simple).
Après, je suis bien d'accord que monter au-delà de 16 bits, pour l'impression ou l'affichage, est une hérésie (même si 10 ou 12 bits ne me sembleraient pas de trop).
Toutefois, je pense que travailler en virgule flottante serait bien, parce que ça correspond plus à la façon dont notre œil fonctionne, via sa capacité d'adaptation. Mais l'intérêt, ce serait plutôt côté capteurs, alors, et avec une grande dynamique, ce qui permettrait d'éviter plusieurs prises de vues pour obtenir une image HDR. Et avant que les capteurs suivent…-
[^]Re: gestion des images > 8 bits
Posté par briaeros007 () le 06/10/2008 à 20:28. (lien). Évalué à 2.Marrant, je vois des barres verticales dans le dégradé orange sur mon écran (En particulier vers le noir). Bon, c'est un test sur écran, comme je l'ai dit, ça vaut pas grand chose.
sur mon écran (non calibré) de même.
près, je suis bien d'accord que monter au-delà de 16 bits, pour l'impression ou l'affichage, est une hérésie
Dépend dans quel domaine amha.
Je me rapelle qu'un moment une news avait défrayé la chronique à propos d'un capteur style photo aérienne, et que la dynamique de cet appareil était suffisante pour prendre une photo entre 5 et 32 de diaph ... sans avoir à modifier l'exposition justement (qu'elle stockait suffisament de valeur par canal pour pouvoir "simuler" une exposition avec un diaph variant de 5 à 32 ;))
Mais je retrouve plus la news :(--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: gestion des images > 8 bits
-
-
-
[^]Re: gestion des images > 8 bits
Posté par Troy McClure (page perso, ) le 03/10/2008 à 20:28. (lien). Évalué à 4.32 bits c'est pratique parce que c'est des float:
- c'est rapide pour faire les calculs (SSE)
- la dynamique est quasi "infinie" (virgule flottante), donc pas besoin de s'emmerder à savoir si telle ou telle opération est susceptible de saturer les 8/16 bits de ton image.
-
[^]Re: gestion des images > 8 bits
Posté par beagf (page perso, ) le 03/10/2008 à 21:23. (lien). Évalué à 5.Pour l'impression pro, on utilise quasiment toujours plus de 8bits par canal et dans des espace de couleurs plus grands que ceux utiliser sur le net par exemple.
Pour simplifier, un espace de couleur en RGB est définit par 3 couleurs ; rouge, vert et bleu et un point blanc. Une couleur dans cet espace est definit par la quantitée de chacune de ces couleurs. Tu ne pourra donc pas avoir un rouge plus rouge que celui de référence par exemple...
Un espace de couleur définit un volume qui contient des couleurs, chaqu'une des couleurs de référence définit un axe dans l'espace à trois dimension et une valeur maximale sur cette axe. On définit donc un cube dans cet espace qui contient les couleurs représentables. Celle qui sont en dehors de ce cube ne sont pas représentables.
Le standard sur les ordinateur est d'utiliser l'espace sRGB qui permet de représenté la majeure partie du spectre visible avec une bonne précision en 8bits, c'est à dire 256 niveaux pour chaque couleur de l'absence à la saturation.
Pour l'impression (*) en RGB on va plutôt utiliser le adobeRGB qui est un espace plus grand, c'est-à-dire qu'il contient plus de couleurs. Ca veut dire que sur chaque axe la plage de valeurs est plus importante, donc quand on la discretise il faut plus de bits pour la réprésenter avec la même précision.
Sur ton ordinateur l'espace couleur est plus réduit il te faut donc moins de précision pour que l'oeil humain ne puisse faire la différence entre deux niveaux. Pour l'impression par contre, il te faut une plus grande précision puisque l'espace est plus grand.
De plus en impression (mais aussi sur ton écran...) quand tu regarde en détail une zone à faible contraste (ou quand tu zoom dessus) ton oeil deviens plus sensible au nuance, il n'est pas perturbé. Donc tu as besoin localement d'une plus grande précision.
Quand tu imprimme une grande affiche pour un spectacle avec une chanteuse avec une grande robe rouge, tu peu être sur qu'il y aurra un pervers pour aller regarder les plis de la robe en détail... Et les ombres peuvent devenir très moches...
Il y a plein de hose qui rentre en compte et c'est loin d'être la plus importante, mais autant éviter les problèmes à chaque étapes. Il reste ensuite à trouver un bon imprimmeur...
(*) En fait il sera convertit en CMJN la pluspart du temps mais ça ne change rien ici...
-
-
[^]Re: gestion des images > 8 bits
Posté par Sarcastic (Jabber id, ) le 03/10/2008 à 19:45. (lien). Évalué à 2.Dommage que je n'aie pas/plus ces cours sous la main.
Dommage, en effet.
Peut-être qu'il ne faut pas croire tout ce que les profs nous racontent, après tout...
Je connais un tas de profs qui racontent qu'il ne faut pas mettre d'accent sur les majuscules. (-:
En dehors de ça, c'est probablement vrai dans un tas de contextes, cette histoire de 6/7 bits. Après, le troll c'est de savoir si c'est une hérésie d'imprimer/afficher en plus de 8 bits par canal. Il me semble que dans certains contextes, ça se justifie (Donc, non, ce n'est pas une hérésie).
Après, si tu m'indiques une source qui montre le contraire, en justifiant chacun de mes points, ok.
-
-
-
-
-
-
[^]Re: gestion des images > 8 bits
Posté par gpe () le 03/10/2008 à 13:26. (lien). Évalué à 3.C'est faut. Il faudrait que je retrouve le lien où la démonstration est clairement faite que même pour traiter un jpeg 8 bits il est bénéfique de d'abord passer en 16 bits avant de faire des traitements.
Si au final tu veux avoir un 8 bits réel tu es obligé de traiter au moins en 16 bits sinon tu auras trop de pertes dans les traitements.
De plus tous les reflex actuels font du 12 bits pertinents au minimum. Les scanners également.
Quant au rendu sur écran même s'il est limité sur beaucoup d'écrans actuellement ça progresse et des écrans dépassant les 8 bits arrivent. De plus tout le monde ne se contente pas du rendu sur écran mais beaucoup de photographes font du tirage photo qui en fonction du papier permet d'exploiter pleinement une image avec plus de 8 bits.-
[^]Re: gestion des images > 8 bits
-
[+] [^]Re: gestion des images > 8 bits
Posté par FantastIX () le 03/10/2008 à 13:35. (lien). Évalué à -2.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.
-
-
[^]Imagerie à grande gamme dynamique
Posté par TBTB () le 03/10/2008 à 15:34. (lien). Évalué à 2.Pour certains même 32 bits c'est juste... tout dépend du besoin ;-)
http://fr.wikipedia.org/wiki/Imagerie_%C3%A0_grande_gamme_dy(...)
Et pour ceux qui ne peuvent pas attendre il y a CinePaint (un fork de The Gimp justement) :
http://en.wikipedia.org/wiki/CinePaint
-
[^]Re: gestion des images > 8 bits
Posté par Michel Nicolas (page perso, ) le 03/10/2008 à 16:26. (lien). Évalué à 6."les capteurs de la majorité des appareils photos sont incapable d'atteindre une dynamique de couleurs tirant pleinement partie d'une description sur 8 bits par canal."
-> pour les appareils compacts oui. Mais les réflex sont en mode RAW au minimum en 12 bits pour les plus anciens (comme le canon 350d), 48 bits pour les nouveaux et un peu plus haut de gamme (comme le 40D).
"j'ai la mauvaise habitude d'utiliser des images jpeg"
-> Le jpeg, c'est bien pour des photos de famille, de vacance, etc. C'est facilement partageable (sur cd, sur le net) car de faible poid. Mais ce n'est jamais ce qu'un photographe va utiliser, à fortiori si il compte retoucher son image ensuite.
"la différence ne peut qu'être nulle puisque ma dalle LCD même en mode photo se limite à 6-8 bits"
-> c'est tout à fait vrai pour les LCD grand public. Mais même dans ce cas, ce n'est que le rendu de l'image sur ton écran. Si tu l'imprimes ou le fait tirer dans un labo photo, tu peux profiter de la profondeur de couleur accrue.
De plus, et c'est le plus important, plus il y a de matière à ton image au départ, plus les possibilités de retouches sont grandes. Car dans les manipulation, même basiques, comme la modification du contraste, des courbes etc, on perd de l'information. Donc si tu pars avec une image 8bits et que tu la retravailles, tu risque de perde beaucoup d'informations de couleur et ton image te semblera un peu plate ou blafarde, même sur ton écran 8bits. Pauvre en couleurs en fait.
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
-> Avec un appareil photo compact en jpeg, il n'y a en fait aucun intérêt. Avec un réflex, même entrée de gamme, il y a un énorme intérêt.-
[^]Re: gestion des images > 8 bits
-
-
[+] [^]Re: gestion des images > 8 bits
Posté par Michel Nicolas (page perso, ) le 03/10/2008 à 16:29. (lien). Évalué à -2."les capteurs de la majorité des appareils photos sont incapable d'atteindre une dynamique de couleurs tirant pleinement partie d'une description sur 8 bits par canal."
-> pour les appareils compacts oui. Mais les réflex sont en mode RAW au minimum en 12 bits pour les plus anciens (comme le canon 350d), 48 bits pour les nouveaux et un peu plus haut de gamme (comme le 40D).
"j'ai la mauvaise habitude d'utiliser des images jpeg"
-

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.