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).
[^] # 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).