Il me semble que par défaut, en l'absence de licence, toute reprise de code est interdite.
Donc dans ton premier cas, le développeur qui prétend n'avoir pas vu la licence avoue lui-même l'illégalité de son acte.
Dans le second cas, y a-t-il une différence juridique entre retirer un partie d'un fichier, et retirer un fichier d'une archive? Si je montre que mon archive (incorporant la licence, donc) était présente sur un serveur à une date antérieure à la redistribution, ça devrait suffire comme preuve, non?
Et si je ne pas trouver un tel serveur, même si j'avais mis la licence abrégée dans chaque fichier, je n'aurai toujours aucun moyen de montrer que les fichiers ont été altérés...
Bon, je suis d'accord qu'on est là dans le domaine de la drosophilophilie, et qu'il vaut probablement mieux incorporer le disclaimer, ne serait-ce que pour suivre une tradition longuement établie.
Au sujet de ces "versions courtes" de licences, ça fait un moment que je m'interroge sur leur utilité réelle...
Si on distribue une archive avec le texte complet de la licence, un fichier ReadMe spécifiant que tout le code source est couvert par ladite licence, est-il encore utile de remettre ce paragraphe dans chaque fichier? J'ai l'impression qu'une ligne spécifiant le copyright devrait suffire, mais peut-être y a-t-il une subtitlité juridique qui m'échappe?
Intel est le cancre en matière d'OpenGL. Toutes plateformes confondues, leur drivers sont à la ramasse.
Et non, il ne s'agit pas d'une question de matos: sous windows, leurs drivers DirectX supportent de nombreuses fonctionnalités modernes. Mais pas leur drivers OpenGL, et apparemment ils n'ont pas l'intention de changer cela. En fait, Intel est probablement l'un des plus gros obstacle pour l'adoption d'OpenGL comme API multi-plateforme crédible.
Je sais que la marque est quelque peu idéalisée chez les linuxiens, et il y a de bonnes raison à cela, mais tout n'est pas rose, loin de là. Surtout qu'amha OpenGL est d'une importance cruciale pour l'avenir de la couche graphique des systèmes libres (et je ne parle pas de 3D ou d'effets bling-bling).
J'évoque notamment un problème "technique" qui fait qu'en lisant le titre on ne peut pas savoir si le livre ne va parler que du noyau ou si il est plus généraliste et évoque tous les aspects d'une distribution.
Et, justement, ce livre ne s'adresse pas à des techniciens. Lorsque l'on travaille dans (ou est passionné par) un domaine, on se doit d'employer un vocabulaire précis, et il est frustrant de constater que "les autres" emploient nos termes à tort et à travers.
Mais il n'est pas possible d'être rigoureux dans tous les domaines, la moindre discussion deviendrait un enfer aride. C'est pour ça que dans la vie quotidienne, il existe tout un tas de raccourcis, qui permettent de se comprendre globalement. Le terme "Linux" est devenu un tel raccourci, et je trouve stérile de se battre contre ça.
[troll mode="flameware"]D'autant que la rigueur du terme "correct" proposé laisse elle-même à désirer, ne serait-ce que parce qu'il passe complètement sous silence l'importance du serveur X.[/troll]
Je suis un peu effaré par la nature des deux premiers commentaires.
Je suis dans le libre depuis de (très) nombreuses années, et l'intolérance croissante que l'on peut trouver dans les communautés libristes m'attriste vraiment. Peut-être que je suis en train de devenir un vieux con, mais j'ai l'impression qu'un attachement aveugle à des idéaux a pris le pas sur la volonté de partager et de faire avancer les choses.
En tout cas, merci pour ce livre, je l'ai parcouru en vitesse et je pense qu'il répond à un besoin, la plupart des autres ouvrages étant soit trop simples, soit trop arides.
Même si je ne doute pas que clang ait encore beaucoup de chemin à faire, je ne pense pas que la compilation du noyau soit représentative de l'ensemble des projets "exigeants": c'est de la programmation système, et en tant que telle, a des besoins particuliers.
Pour de l'applicatif, il me semble au contraire que s'appuyer sur les spécificités d'un compilateur est plutôt mal vu.
Après, le standard C++ est tellement complexe qu'il est peut-être plus prudent de calquer le comportement d'un compilateur existant.
Parmi les raisons du succès du langage Basic, je pense qu'on peut citer:
- Étant un langage très linéaire, un programme pouvait facilement tenir dans un seul document; ça tombe bien, il n'y avait pas de système de gestion de fichiers sur ces machines (sur K7, ça aurait pu être drôle).
- Le basic pouvait se contenter d'un éditeur très frustre. Vraiment très frustre. Il aurait été difficile de faire de la programmation fonctionnelle avec ça.
- C'est devenu rapidement un quasi-standard (presque tous les premiers micros parlaient basic, chacun avait son propre dialecte mais il restait facile d'échanger des programmes).
- Enfin, arriver à faire un langage interprété qui tourne sur des machines de si faibles capacités n'est pas évident. Bon, d'accord, Forth aurait été un meilleur choix, mais certainement un poil plus difficile à apprendre... (d'ailleurs il y avait un micro, le Jupiter Ace, dont le langage natif était Forth).
Je n'ai aucune envie de créer une polémique, comme je l'ai dit je reconnais le travail effectué et je comprends l'orientation traitement du signal du projet.
Je regrette que la présentation du projet ne soit pas plus explicite de ce côté là.
(Et non, ce n'est pas parce qu'un outil peut tout faire, qu'il est approprié pour tout. L'ergonomie a toujours existé, y compris dans le monde unix: la présence de nombreuses variations autour d'outils fonctionnellement équivalents en est bel exemple.)
Pour information, la spécification du PNG est très claire sur le sujet du gamma:
En théorie, si des informations satellites ou de thermographie sont encodées en PNG, elles devraient explicitement notifier dans les métadonnées un gamma de 1.0 (encodage linéaire).
Oui, c'est bien ça: je me place d'un point de vue "artiste", alors que l'outil se situe dans une optique "traitement du signal".
Quand à spécifier les corrections gamma à chaque utilisation, cela devient vite très lourd, et peut dans certains cas générer des pertes si la précision n'est pas suffisante (comme dans gimp). Ce n'est pas pour rien qu'un standard est apparu pour cela (même Apple a fini par y venir), et que les logiciels "de création" commencent à prendre en compte l'espace de couleur dans leurs opérations.
Enfin, je continue de penser que, au moins dans le cas des images dont le gamma est stocké dans les métadonnées, le logiciel devrait prendre en compte cette information.
Je comprend l'orientation choisie, même si je trouve ça dommage.
De plus le nom de l'application est alors trompeur: par "image", on désigne la plupart du temps un document destiné à être visualisé, pas une image satellite. Or, la quasi-totalité de ces documents est encodé dans un espace de couleur non linéaire (gamma 2.2 étant un standard); et quand ce n'est pas le cas, il s'agit la plupart du temps d'un format spécifique aisément reconnaissable, ou bien le gamma est spécifié dans les méta-données.
En ce qui concerne l'image du Dalaï Lama, je ne suis pas d'accord, mais parce que je me place d'un point de vue "artiste". Le gamma standard est non-linéaire, donc cette image est parfaitement représentative d'une utilisation courante. Elle exacerbe le problème, mais elle n'est en aucun cas trafiquée pour le créer. Il suffit de surfer sur n'importe quel site dédié aux arts graphiques numériques pour voir que la prise en compte du gamma est une étape clef de la production d'images. Et que de nombreux outils compliquent la tâche là où ils pourraient la simplifier (c'est de moins en moins vrai).
L'exemple du plugin Gimp est flagrant: il va donner pour certaines opérations un résultat (légèrement) erroné, puisqu'un artiste ne vas pas travailler sur une image linéarisée (elle s'afficherait alors de façon incorrecte). Le plugin au moins devrait travailler en espace linéaire, surtout que Gimp connait la notion d'espace de couleur, il n'y a donc pas d'ambiguïté de ce côté-là.
Encore une fois je comprends l'orientation "scientifique" du projet, mais il y a déjà pas mal d'outils dans ce domaine. Un outil adapté à la création aurait été novateur.
C'est la dernière option de ta commande resize le ",2" qui semble faire la différence. (Elle n'est pas documentée en détail dans l'aide, il est juste dit que cela concerne le centre, je suppose le centre de l'interpolation.)
Ne serait-il pas pertinent de faire travailler gmic en espace de couleur linéaire? La plupart des logiciels de traitement d'image semblent prendre cette direction. Cela éviterait bien des complications...
Donc soit j'utilise mal gmic, soit il y a une subtilité qui m'a complètement échappé, soit il y a un problème dans l'une des fonctions utilisées de gmic...
Bon, je répond à ma dernière question, la documentation sur le site semble concerner la toute dernière version, donc la fonction apply_gamma est un ajout récent.
Du coup j'ai essayé d'installer gmic sur une ubuntu 9.04, l'installation du .deb se déroule correctement mais à l'exécution il lui manque libMagick++.so.10. Un petit problème de dépendances dans le package, apparement. Un petit lien symbolique pas joli du tout permet de lancer gmic sans partir à la chasse à la bibliothèque.
Premier constat, le résultat est toujours le même sous linux avec la dernière version.
Ensuite, j'ai essayé de "linéariser" l'espace de couleur avec la commande suivante:
...mais je n'obtiens toujours pas le résultat escompté. Peut-être parce qu'il faudrait en plus passer sur une précision supérieure? Ou bien ai-je fait une erreur dans le choix des commandes?
(en l'occurrence il ne parle que des algorithmes de redimensionnement, mais le problème est plus vaste; article découvert via le wiki de Blender)
Dans cet article il donne une image (le jpeg du Dalai Lama) qui, une fois redimensionnée de 50% dans la quasi totalité des logiciels, donne un résultat erroné (soit tout gris, ou bien couleurs complètement fausses). L'image est un cas extrême, spécialement conçu pour mettre en évidence le problème, sur une cas réel l'erreur est plus discrète mais bien présente.
Et le résultat est faux (image verte). J'ai essayé les différents types d'interpolations, j'obtiens la plupart du temps un dalai lama vert, un carré gris avec la "moving average interpolation", et un dalai rose avec la "grid interpolation".
Pour info, Gimp donne un carré gris avec tous les types d'interpolation, et un dalai lama vert sans interpolation. Firefox donne aussi un carré tout gris. Par contre GEGL devrait gérer la chose correctement (pas testé).
Mes questions:
- Ai-je loupé quelque chose? Une option pour prendre en compte le gamma de l'image lors des transformations?
- Pourquoi une telle différence par rapport à Gimp? (il me semble que l'interpolation ne devrait jamais donner un dalai lama vert?)
- Dans la version testée (1.3.2.0, sous windows pour le moment), je n'ai trouvé aucune option pour appliquer une corection de gamma, qui aurait permis de linéariser l'espace de couleur avant de faire la transformation, puis de la remettre en gamma 2.2. Pourtant cette fonction est documentée sur le site web?
Je n'ai pas les connaissances nécessaires pour donner une réponse "définitive" (et je ne suis même pas sûr qu'une réponse scientifiquement valable soit possible), mais je doute que l'on puisse ne serait-ce que s'approcher de l'impact d'un gros météorite.
En ce qui concerne ton exemple nucléaire, je pense qu'il épargnerait la plus grande partie de la vie aquatique. De plus on sait maintenant que certaines bactéries se sentent parfaitement à l'aise dans un bain de radiations. Il y a mêmes des bestioles vivantes qui ont des capacités de survie tout à fait étonnantes (les tardigrades, par exemple). Enfin, il faut un sacré nombre de bombes pour arriver à couvrir de radiations toute la surface de la planète... Pas sûr qu'on aie les matières premières nécessaires. Et dans le cas d'un guerre, on viserait les points stratégiques, pas une couverture totale.
Entièrement d'accord, sauf que j'ajouterai une petite précision: cette situation est catastrophique du point de vue de l'homme (et des espèces menacées). En ce qui concerne "la Nature", elle a connu bien pire; je doute qu'on arrive à faire aussi bien que l'Extinction_du_permien, même en s'y mettant tous. Et la plupart du temps, les extinction massives ont permis à de nouvelles formes de vie d'émerger.
Juste pour rappeler que l'écologie c'est un combat pour sauvegarder nos conditions de vie, pas pour protéger la nature dans l'absolu; elle sait très bien se passer de nous, et on est loin de pouvoir la mettre en réel danger.
Voila par contre un argument vraiment pertinent: le coût.
On trouve pas mal de freeware (et un peu d'open source) sous windows, mais la majorité reste quand même du shareware ou 100% payant. Et quand je vois la qualité affligeante de certains trucs, c'est vraiment difficile d'ouvrir le porte-monnaie...
Ceci dit, pour envoyer du sysex et éditer un fichier binaire gratuitement, tu n'aurais pas cherché trois jours...
La seule critique que je fait, c'est vis à vis du titre du journal, et de ça:
« Je doute être parvenu à mes fins si j'avais (encore) été sous Windows (j'entends par là que j'ai sous linux tous les outils dont j'ai besoin via un simple aptitude search) ; et si je n'avais pas été un geek forcené ;) »
Je maintiens que tout un tas de musiciens travaillant sous windows (ou mac os d'ailleurs) seraient parvenu au même résultat sans plus de difficultés. Parce que pour faire un "aptitude search", il faut savoir quoi chercher; et dans ce cas un tour sur google ou audiofanzine, et le windowsien trouve son bonheur.
Il faut quelques connaissances informatiques pour convertir le fichier, mais il y a pleins de gens sous windows qui en sont capables aussi...
Bon, il y a plus de chance qu'un mao-iste sous linux soit geek, ça on ne peut pas le nier...
Le moinssage ne m'étonne pas trop, et ça rejoint ce qui m'a fait tiquer dans ce journal: une certaine perte d'objectivité qui me met mal à l'aise.
Bon, je ne veux pas faire mon rabat-joie, mais tous les outils que tu as utilisés existent sous windows. La manip y serait tout aussi facile à faire. Si tu avais détourné un outil genre awk ou sed pour convertir ton fichier, ça aurait donné un léger avantage à Linux, mais vu que tu as utilisé un script PHP...
Ce n'est pas une critique envers la MAO sous linux, je suis moi-même en train d'y revenir après une petite infidélité sous windows. Mais les avantages ne sont pas qu'on peut y faire plus de choses (au contraire, il y a des trucs qui n'existent que sous windows pour l'instant); les avantages sont qu'on y fait les choses différemment (pas de logiciels monolithiques), et que l'on a une certaine garantie de pérennité dans les outils et formats utilisés.
Je sais que le sujet avait été abordé sur la mailing-list LAD (Linux Audio Developer), et la conclusion était que le temps réel "soft" de BeOS était mieux qu'un vanilla kernel, mais moins bien qu'un noyau patché. Comme les différents éléments du patch RT sont petit à petit intégrés dans la branche principale, je pense qu'à long terme Linux pourrait offrir une meilleure latence out of the box.
Je dit "pourrait" parce que le noyau ne fait pas tout. Il faut aussi une couche audio efficace (on l'a, elle s'appelle Jack), et facile à mettre en oeuvre (sans commentaires). BeOS avait ça. D'ailleurs la plupart des fonctionnalités plébiscitées de Jack (et même de GStreamer) étaient déjà présente dans le MediaKit.
Enfin et surtout, il faut des applications, et là BeOS avait un excellent départ, dû en partie au fait que nombre de développeurs venaient du monde Mac, traditionnellement lié à la MAO.
Si l'imbroglio Alsa/Jack/PulseAudio (et Ladpa/Dssi/Lv2, et Laddca/Lash/Ladish, etc.) débouche sur une solution stable et efficace, je pense que Linux a beaucoup à offrir à la MAO.
Dans tout les cas, Haiku semble très prometteur...
PS: pour ce qui est de l'utilité d'un noyau patché RT pour écouter de la musique, je pense que le seul intérêt est d'éviter les coupures liées à la charge.
Le problème, c'est qu'optimiser pour un seul processeur c'est très différent de l'optimisation pour du multi-coeur.
Je suis entièrement d'accord sur le fait que la course à la puissance soit néfaste, et est probablement due en grande partie à l'intérêt du marché (cycle renouvellement des machines / renouvellement du logiciel).
Mais il faut voir aussi que depuis de nombreuses années, l'informatique "grand public" a vraiment du mal à franchir l'étape du multi-proc/multi-coeur, qui a pourtant beaucoup à apporter dans tous les dommaines (pas seulement la puissance). Personnellement, face à une alternative, je préfère voir le logiciel libre privilégier les architectures à venir, plutôt que prendre du retard et contribuer à l'effet pénalisant de la compatibilité ascendante.
Comme dit ci-dessus, si tu es novice et que la 3D t'intéresse, peu importe que ça soit sous tel ou tel logiciel. Les techniques utilisées sont les mêmes, seule la connaissance de l'interface change, et pour celle-ci on trouve de très bons tutos sur le net (de plus une fois qu'on a saisi la logique interne de Blender, on retrouve ses petits très facilement).
Il est par contre plus difficile de faire passer une technique artistique dans un tutoriel, donc là ça m'a tout l'air d'être une occasion en or... Dommage que ce soit à Paris... ^_^
Pour ta dernière question, on peut très bien "se passer de Maya et ZBrush", y compris dans le domaine professionnel. Il n'y a rien d'essentiel qui manque à Blender (je ne connais pas suffisament les autres softs pour en parler), mais tout un tas de petits détails qui vont compliquer un peu les choses, ou apporter certaines limitations. Par exemple Blender ne supporte pas autant de polygones en mode sculpture que ZBrush, il n'y a pas toujours des scripts d'importation/exportation pour les formats utilisés par les autres softs, certaines possibilités de prévisualisation en temps réel ne sont pas (encore) présentes, etc. Et puis, l'interface un peu particulière en rebute plus d'un.
Tu compares deux choses qui n'ont rien à voir. Le principe de la diffusion libre, c'est que c'est gratuit pour la plupart des gens, et ceux qui sont passionnés/enthousiasmés paient plus, non pas pour accéder au produit, mais pour soutenir les artistes.
C'est exactement la même chose lorsqu'un groupe offre un album pour un prix qu'on choisit soi-même (Radiohead) ou rien du tout (Lonah et autres groupes sur jamendo), et en même temps propose une édition collector qui contient exactement la même chose (à quelques morceaux de papier près) mais pour vachement cher.
C'est une forme moderne de mécénat. Le groupe Binary Mind a une très bonne réflexion là-dessus sur leur site:
[^] # Re: Utilité réelle de ces "versions courtes"?
Posté par drakmaniso . En réponse au journal Licence de logiciel libre et droit français. Évalué à 1.
[^] # Re: Utilité réelle de ces "versions courtes"?
Posté par drakmaniso . En réponse au journal Licence de logiciel libre et droit français. Évalué à 1.
Donc dans ton premier cas, le développeur qui prétend n'avoir pas vu la licence avoue lui-même l'illégalité de son acte.
Dans le second cas, y a-t-il une différence juridique entre retirer un partie d'un fichier, et retirer un fichier d'une archive? Si je montre que mon archive (incorporant la licence, donc) était présente sur un serveur à une date antérieure à la redistribution, ça devrait suffire comme preuve, non?
Et si je ne pas trouver un tel serveur, même si j'avais mis la licence abrégée dans chaque fichier, je n'aurai toujours aucun moyen de montrer que les fichiers ont été altérés...
Bon, je suis d'accord qu'on est là dans le domaine de la drosophilophilie, et qu'il vaut probablement mieux incorporer le disclaimer, ne serait-ce que pour suivre une tradition longuement établie.
# Utilité réelle de ces "versions courtes"?
Posté par drakmaniso . En réponse au journal Licence de logiciel libre et droit français. Évalué à 2.
Si on distribue une archive avec le texte complet de la licence, un fichier ReadMe spécifiant que tout le code source est couvert par ladite licence, est-il encore utile de remettre ce paragraphe dans chaque fichier? J'ai l'impression qu'une ligne spécifiant le copyright devrait suffire, mais peut-être y a-t-il une subtitlité juridique qui m'échappe?
[^] # Re: Intel, intel, intel
Posté par drakmaniso . En réponse au journal Nvidia arrête le support de son pilote opensource nv. Évalué à 10.
Et non, il ne s'agit pas d'une question de matos: sous windows, leurs drivers DirectX supportent de nombreuses fonctionnalités modernes. Mais pas leur drivers OpenGL, et apparemment ils n'ont pas l'intention de changer cela. En fait, Intel est probablement l'un des plus gros obstacle pour l'adoption d'OpenGL comme API multi-plateforme crédible.
Je sais que la marque est quelque peu idéalisée chez les linuxiens, et il y a de bonnes raison à cela, mais tout n'est pas rose, loin de là. Surtout qu'amha OpenGL est d'une importance cruciale pour l'avenir de la couche graphique des systèmes libres (et je ne parle pas de 3D ou d'effets bling-bling).
[^] # Re: argh
Posté par drakmaniso . En réponse au journal Ubuntu: Nouveau look et nouveau logo. Évalué à 2.
https://wiki.ubuntu.com/Brand2
Dans les screenshots de la première page, je pense que c'est surtout le fond d'écran qui est inapproprié.
[^] # Re: Réponse aux deux premiers commentaires
Posté par drakmaniso . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 4.
Et, justement, ce livre ne s'adresse pas à des techniciens. Lorsque l'on travaille dans (ou est passionné par) un domaine, on se doit d'employer un vocabulaire précis, et il est frustrant de constater que "les autres" emploient nos termes à tort et à travers.
Mais il n'est pas possible d'être rigoureux dans tous les domaines, la moindre discussion deviendrait un enfer aride. C'est pour ça que dans la vie quotidienne, il existe tout un tas de raccourcis, qui permettent de se comprendre globalement. Le terme "Linux" est devenu un tel raccourci, et je trouve stérile de se battre contre ça.
[troll mode="flameware"]D'autant que la rigueur du terme "correct" proposé laisse elle-même à désirer, ne serait-ce que parce qu'il passe complètement sous silence l'importance du serveur X.[/troll]
[^] # Re: Réponse aux deux premiers commentaires
Posté par drakmaniso . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 10.
Je suis dans le libre depuis de (très) nombreuses années, et l'intolérance croissante que l'on peut trouver dans les communautés libristes m'attriste vraiment. Peut-être que je suis en train de devenir un vieux con, mais j'ai l'impression qu'un attachement aveugle à des idéaux a pris le pas sur la volonté de partager et de faire avancer les choses.
En tout cas, merci pour ce livre, je l'ai parcouru en vitesse et je pense qu'il répond à un besoin, la plupart des autres ouvrages étant soit trop simples, soit trop arides.
[^] # Re: Compiler un gros projet, voire le noyau...
Posté par drakmaniso . En réponse au journal Clang arrive avec le C++, et ça va faire mal. Évalué à 4.
Pour de l'applicatif, il me semble au contraire que s'appuyer sur les spécificités d'un compilateur est plutôt mal vu.
Après, le standard C++ est tellement complexe qu'il est peut-être plus prudent de calquer le comportement d'un compilateur existant.
[^] # Re: Belle initiative !
Posté par drakmaniso . En réponse au journal La liberté informatique - une question de connaissance. Évalué à 2.
- Étant un langage très linéaire, un programme pouvait facilement tenir dans un seul document; ça tombe bien, il n'y avait pas de système de gestion de fichiers sur ces machines (sur K7, ça aurait pu être drôle).
- Le basic pouvait se contenter d'un éditeur très frustre. Vraiment très frustre. Il aurait été difficile de faire de la programmation fonctionnelle avec ça.
- C'est devenu rapidement un quasi-standard (presque tous les premiers micros parlaient basic, chacun avait son propre dialecte mais il restait facile d'échanger des programmes).
- Enfin, arriver à faire un langage interprété qui tourne sur des machines de si faibles capacités n'est pas évident. Bon, d'accord, Forth aurait été un meilleur choix, mais certainement un poil plus difficile à apprendre... (d'ailleurs il y avait un micro, le Jupiter Ace, dont le langage natif était Forth).
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 2.
Je regrette que la présentation du projet ne soit pas plus explicite de ce côté là.
(Et non, ce n'est pas parce qu'un outil peut tout faire, qu'il est approprié pour tout. L'ergonomie a toujours existé, y compris dans le monde unix: la présence de nombreuses variations autour d'outils fonctionnellement équivalents en est bel exemple.)
Pour information, la spécification du PNG est très claire sur le sujet du gamma:
http://www.w3.org/TR/PNG/#13Decoder-gamma-handling
En théorie, si des informations satellites ou de thermographie sont encodées en PNG, elles devraient explicitement notifier dans les métadonnées un gamma de 1.0 (encodage linéaire).
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 1.
Quand à spécifier les corrections gamma à chaque utilisation, cela devient vite très lourd, et peut dans certains cas générer des pertes si la précision n'est pas suffisante (comme dans gimp). Ce n'est pas pour rien qu'un standard est apparu pour cela (même Apple a fini par y venir), et que les logiciels "de création" commencent à prendre en compte l'espace de couleur dans leurs opérations.
Enfin, je continue de penser que, au moins dans le cas des images dont le gamma est stocké dans les métadonnées, le logiciel devrait prendre en compte cette information.
En tout cas, bonne continuation.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 2.
De plus le nom de l'application est alors trompeur: par "image", on désigne la plupart du temps un document destiné à être visualisé, pas une image satellite. Or, la quasi-totalité de ces documents est encodé dans un espace de couleur non linéaire (gamma 2.2 étant un standard); et quand ce n'est pas le cas, il s'agit la plupart du temps d'un format spécifique aisément reconnaissable, ou bien le gamma est spécifié dans les méta-données.
En ce qui concerne l'image du Dalaï Lama, je ne suis pas d'accord, mais parce que je me place d'un point de vue "artiste". Le gamma standard est non-linéaire, donc cette image est parfaitement représentative d'une utilisation courante. Elle exacerbe le problème, mais elle n'est en aucun cas trafiquée pour le créer. Il suffit de surfer sur n'importe quel site dédié aux arts graphiques numériques pour voir que la prise en compte du gamma est une étape clef de la production d'images. Et que de nombreux outils compliquent la tâche là où ils pourraient la simplifier (c'est de moins en moins vrai).
L'exemple du plugin Gimp est flagrant: il va donner pour certaines opérations un résultat (légèrement) erroné, puisqu'un artiste ne vas pas travailler sur une image linéarisée (elle s'afficherait alors de façon incorrecte). Le plugin au moins devrait travailler en espace linéaire, surtout que Gimp connait la notion d'espace de couleur, il n'y a donc pas d'ambiguïté de ce côté-là.
Encore une fois je comprends l'orientation "scientifique" du projet, mais il y a déjà pas mal d'outils dans ce domaine. Un outil adapté à la création aurait été novateur.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 2.
Mais ce n'est pas juste une question d'ordre, car la ligne de commande:
gmic gamma_dalai_lama_gray.jpg -apply_gamma 0.4545 -r 50%,50% -apply_gamma 2.2 -o out6.png...fourni également un résultat erroné.
C'est la dernière option de ta commande resize le ",2" qui semble faire la différence. (Elle n'est pas documentée en détail dans l'aide, il est juste dit que cela concerne le centre, je suppose le centre de l'interpolation.)
Ne serait-il pas pertinent de faire travailler gmic en espace de couleur linéaire? La plupart des logiciels de traitement d'image semblent prendre cette direction. Cela éviterait bien des complications...
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 2.
Je viens de faire quelques tests avec le "concurrent" ImageMagick. La ligne de commande recommandée sur le site cité plus haut:
convert gamma_dalai_lama_gray.jpg -depth 16 -gamma 0.4545 -scale 50% -gamma 2.2 out3.png...fourni bel est bien le resultat escompté (un beau dalai lama en couleur, un peu délavé).
Pour voir si la différence était due au passage en précision 16 bits, j'ai supprimé la conversion:
convert gamma_dalai_lama_gray.jpg -gamma 0.4545 -scale 50% -gamma 2.2 out4.png...est le résultat est toujours correct.
Donc soit j'utilise mal gmic, soit il y a une subtilité qui m'a complètement échappé, soit il y a un problème dans l'une des fonctions utilisées de gmic...
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 4.
Du coup j'ai essayé d'installer gmic sur une ubuntu 9.04, l'installation du .deb se déroule correctement mais à l'exécution il lui manque libMagick++.so.10. Un petit problème de dépendances dans le package, apparement. Un petit lien symbolique pas joli du tout permet de lancer gmic sans partir à la chasse à la bibliothèque.
Premier constat, le résultat est toujours le même sous linux avec la dernière version.
Ensuite, j'ai essayé de "linéariser" l'espace de couleur avec la commande suivante:
gmic -apply_gamma 0.4545 gamma_dalai_lama_gray.jpg -r 50%,50% -apply_gamma 2.2 -o out2.png...mais je n'obtiens toujours pas le résultat escompté. Peut-être parce qu'il faudrait en plus passer sur une précision supérieure? Ou bien ai-je fait une erreur dans le choix des commandes?
# Problème de (non) prise en compte du gamma?
Posté par drakmaniso . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 7.
J'étais justement en train de lire un article très intéressant sur les problèmes de la gestion du gamma dans les logiciels de traitement d'image:
http://www.4p8.com/eric.brasseur/gamma.html
(en l'occurrence il ne parle que des algorithmes de redimensionnement, mais le problème est plus vaste; article découvert via le wiki de Blender)
Dans cet article il donne une image (le jpeg du Dalai Lama) qui, une fois redimensionnée de 50% dans la quasi totalité des logiciels, donne un résultat erroné (soit tout gris, ou bien couleurs complètement fausses). L'image est un cas extrême, spécialement conçu pour mettre en évidence le problème, sur une cas réel l'erreur est plus discrète mais bien présente.
J'ai donc essayé avec gmic:
gmic gamma_dalai_lama_gray.jpg -r 50%,50% -o out.pngEt le résultat est faux (image verte). J'ai essayé les différents types d'interpolations, j'obtiens la plupart du temps un dalai lama vert, un carré gris avec la "moving average interpolation", et un dalai rose avec la "grid interpolation".
Pour info, Gimp donne un carré gris avec tous les types d'interpolation, et un dalai lama vert sans interpolation. Firefox donne aussi un carré tout gris. Par contre GEGL devrait gérer la chose correctement (pas testé).
Mes questions:
- Ai-je loupé quelque chose? Une option pour prendre en compte le gamma de l'image lors des transformations?
- Pourquoi une telle différence par rapport à Gimp? (il me semble que l'interpolation ne devrait jamais donner un dalai lama vert?)
- Dans la version testée (1.3.2.0, sous windows pour le moment), je n'ai trouvé aucune option pour appliquer une corection de gamma, qui aurait permis de linéariser l'espace de couleur avant de faire la transformation, puis de la remettre en gamma 2.2. Pourtant cette fonction est documentée sur le site web?
[^] # Re: Faux problème
Posté par drakmaniso . En réponse au journal [HS] Pour en finir avec le réchauffement climatique anthropique.... Évalué à 2.
En ce qui concerne ton exemple nucléaire, je pense qu'il épargnerait la plus grande partie de la vie aquatique. De plus on sait maintenant que certaines bactéries se sentent parfaitement à l'aise dans un bain de radiations. Il y a mêmes des bestioles vivantes qui ont des capacités de survie tout à fait étonnantes (les tardigrades, par exemple). Enfin, il faut un sacré nombre de bombes pour arriver à couvrir de radiations toute la surface de la planète... Pas sûr qu'on aie les matières premières nécessaires. Et dans le cas d'un guerre, on viserait les points stratégiques, pas une couverture totale.
[^] # Re: Faux problème
Posté par drakmaniso . En réponse au journal [HS] Pour en finir avec le réchauffement climatique anthropique.... Évalué à 10.
Juste pour rappeler que l'écologie c'est un combat pour sauvegarder nos conditions de vie, pas pour protéger la nature dans l'absolu; elle sait très bien se passer de nous, et on est loin de pouvoir la mettre en réel danger.
[^] # Re: Publicité mensongère?
Posté par drakmaniso . En réponse au journal Comment j'ai ressuscité mon clavier-synthétiseur grâce à linux. Évalué à 2.
On trouve pas mal de freeware (et un peu d'open source) sous windows, mais la majorité reste quand même du shareware ou 100% payant. Et quand je vois la qualité affligeante de certains trucs, c'est vraiment difficile d'ouvrir le porte-monnaie...
Ceci dit, pour envoyer du sysex et éditer un fichier binaire gratuitement, tu n'aurais pas cherché trois jours...
[^] # Re: Publicité mensongère?
Posté par drakmaniso . En réponse au journal Comment j'ai ressuscité mon clavier-synthétiseur grâce à linux. Évalué à 6.
« Je doute être parvenu à mes fins si j'avais (encore) été sous Windows (j'entends par là que j'ai sous linux tous les outils dont j'ai besoin via un simple aptitude search) ; et si je n'avais pas été un geek forcené ;) »
Je maintiens que tout un tas de musiciens travaillant sous windows (ou mac os d'ailleurs) seraient parvenu au même résultat sans plus de difficultés. Parce que pour faire un "aptitude search", il faut savoir quoi chercher; et dans ce cas un tour sur google ou audiofanzine, et le windowsien trouve son bonheur.
Il faut quelques connaissances informatiques pour convertir le fichier, mais il y a pleins de gens sous windows qui en sont capables aussi...
Bon, il y a plus de chance qu'un mao-iste sous linux soit geek, ça on ne peut pas le nier...
Le moinssage ne m'étonne pas trop, et ça rejoint ce qui m'a fait tiquer dans ce journal: une certaine perte d'objectivité qui me met mal à l'aise.
# Publicité mensongère?
Posté par drakmaniso . En réponse au journal Comment j'ai ressuscité mon clavier-synthétiseur grâce à linux. Évalué à 5.
Ce n'est pas une critique envers la MAO sous linux, je suis moi-même en train d'y revenir après une petite infidélité sous windows. Mais les avantages ne sont pas qu'on peut y faire plus de choses (au contraire, il y a des trucs qui n'existent que sous windows pour l'instant); les avantages sont qu'on y fait les choses différemment (pas de logiciels monolithiques), et que l'on a une certaine garantie de pérennité dans les outils et formats utilisés.
Sur ce, bonne continuation!
[^] # Re: Haiku pour le son (temps réel, toussa)
Posté par drakmaniso . En réponse à la dépêche Le projet Haiku Project annonce la disponibilité d'Haiku R1/Alpha 1. Évalué à 7.
Je dit "pourrait" parce que le noyau ne fait pas tout. Il faut aussi une couche audio efficace (on l'a, elle s'appelle Jack), et facile à mettre en oeuvre (sans commentaires). BeOS avait ça. D'ailleurs la plupart des fonctionnalités plébiscitées de Jack (et même de GStreamer) étaient déjà présente dans le MediaKit.
Enfin et surtout, il faut des applications, et là BeOS avait un excellent départ, dû en partie au fait que nombre de développeurs venaient du monde Mac, traditionnellement lié à la MAO.
Si l'imbroglio Alsa/Jack/PulseAudio (et Ladpa/Dssi/Lv2, et Laddca/Lash/Ladish, etc.) débouche sur une solution stable et efficace, je pense que Linux a beaucoup à offrir à la MAO.
Dans tout les cas, Haiku semble très prometteur...
PS: pour ce qui est de l'utilité d'un noyau patché RT pour écouter de la musique, je pense que le seul intérêt est d'éviter les coupures liées à la charge.
[^] # Re: Quad
Posté par drakmaniso . En réponse au journal BFS : La revanche. Évalué à 6.
Je suis entièrement d'accord sur le fait que la course à la puissance soit néfaste, et est probablement due en grande partie à l'intérêt du marché (cycle renouvellement des machines / renouvellement du logiciel).
Mais il faut voir aussi que depuis de nombreuses années, l'informatique "grand public" a vraiment du mal à franchir l'étape du multi-proc/multi-coeur, qui a pourtant beaucoup à apporter dans tous les dommaines (pas seulement la puissance). Personnellement, face à une alternative, je préfère voir le logiciel libre privilégier les architectures à venir, plutôt que prendre du retard et contribuer à l'effet pénalisant de la compatibilité ascendante.
[^] # Re: Titre trompeur
Posté par drakmaniso . En réponse à la dépêche Rappel pour la rencontre du 26/09/2009 sur Blender. Évalué à 5.
Il est par contre plus difficile de faire passer une technique artistique dans un tutoriel, donc là ça m'a tout l'air d'être une occasion en or... Dommage que ce soit à Paris... ^_^
Pour ta dernière question, on peut très bien "se passer de Maya et ZBrush", y compris dans le domaine professionnel. Il n'y a rien d'essentiel qui manque à Blender (je ne connais pas suffisament les autres softs pour en parler), mais tout un tas de petits détails qui vont compliquer un peu les choses, ou apporter certaines limitations. Par exemple Blender ne supporte pas autant de polygones en mode sculpture que ZBrush, il n'y a pas toujours des scripts d'importation/exportation pour les formats utilisés par les autres softs, certaines possibilités de prévisualisation en temps réel ne sont pas (encore) présentes, etc. Et puis, l'interface un peu particulière en rebute plus d'un.
[^] # Re: Hum
Posté par drakmaniso . En réponse au journal Blender - le DVD du projet Durian. Évalué à 1.
C'est exactement la même chose lorsqu'un groupe offre un album pour un prix qu'on choisit soi-même (Radiohead) ou rien du tout (Lonah et autres groupes sur jamendo), et en même temps propose une édition collector qui contient exactement la même chose (à quelques morceaux de papier près) mais pour vachement cher.
C'est une forme moderne de mécénat. Le groupe Binary Mind a une très bonne réflexion là-dessus sur leur site:
http://www.binarymind.org/index.php?option=com_content&t(...)