Pour résumer, le problème évoqué dans ce lien est que GIMP est destructif, à l'heure actuelle, alors que Darktable est uniquement non destructif
Oui et non. Le problème n'est pas tellement d'être destructif ou non, c'est d'être répétable. Avec Darktable, les opérations faites sur l'image sont faites dans un ordre déterminé par le logiciel (les modules sont appliqués de bas en haut par rapport à l'ordre dans lequel ils sont affichés). Si je joue avec le module contrastes/luminosité/saturation, et qu'après je change le réglage de réduction du bruit, alors Darktable va réappliquer tous les calculs en repartant du RAW, en commençant par la réduction de bruit, même si c'est la dernière opération que j'ai fait.
Ça n'aurait pas vraiment de sens de lancer Gimp dans le flot Darktable : ça me permettrait de faire une modif d'image une fois dans Gimp, mais que se passerait-il si je changeais les réglages côté Darktable après ?
Donc, pour l'instant, le seul flot raisonnable, c'est de bien travailler son image dans Darktable, de l'exporter, et de retoucher le résultat dans Gimp. Si on veut modifier les réglages de Darktable, il faudra refaire le boulot dans Gimp.
Ça pourrait changer avec les prochaines versions de Gimp, qui saura aussi gérer une pile d'effets via GEGL. On peut imaginer d'avoir des opérations faites dans Gimp au milieu du pipeline de Darktable. Mais ça n'arrivera pas demain ;-).
les RAW sont en général en très haute résolution, donc la perte peut être très raisonnable
La perte d'information, ce n'est pas sur la résolution (l'export en .png la conserve sans problème par exemple), mais sur la profondeur des pixels. Gimp utilise pour l'instant 8 bits/pixel/couleur (ça changera dans la 2.10), et Darktable utilise des flottants 24 bits. Pour le résultat final, 8 bits/pixel/couleur est suffisant pour la plupart des utilisations (pour de l'affichage sur un écran lambda, on ne peut pas faire mieux), mais pour les calculs intermédiaires, les erreurs d'arrondis se cumulent, et faire tous les traitements sur 8 bits peut poser problème même pour des non-puristes non-professionnels. L'autre intérêt d'utiliser des flottants est qu'on peut manipuler des valeurs intermédiaires qui débordent de l'intervalle des valeurs représentables (trop blanc ou trop noires), mais revenir dans des bonnes valeurs plus loin dans le pipeline. Par exemple, c'est ce qui permet de retrouver les détails dans des parties un peu sur/sous-exposées avec le module « Shadows and Highlights » de Darktable.
[^] # Re: Darktable
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable : entrevue avec Johannes Hanika. Évalué à 9.
Oui et non. Le problème n'est pas tellement d'être destructif ou non, c'est d'être répétable. Avec Darktable, les opérations faites sur l'image sont faites dans un ordre déterminé par le logiciel (les modules sont appliqués de bas en haut par rapport à l'ordre dans lequel ils sont affichés). Si je joue avec le module contrastes/luminosité/saturation, et qu'après je change le réglage de réduction du bruit, alors Darktable va réappliquer tous les calculs en repartant du RAW, en commençant par la réduction de bruit, même si c'est la dernière opération que j'ai fait.
Ça n'aurait pas vraiment de sens de lancer Gimp dans le flot Darktable : ça me permettrait de faire une modif d'image une fois dans Gimp, mais que se passerait-il si je changeais les réglages côté Darktable après ?
Donc, pour l'instant, le seul flot raisonnable, c'est de bien travailler son image dans Darktable, de l'exporter, et de retoucher le résultat dans Gimp. Si on veut modifier les réglages de Darktable, il faudra refaire le boulot dans Gimp.
Ça pourrait changer avec les prochaines versions de Gimp, qui saura aussi gérer une pile d'effets via GEGL. On peut imaginer d'avoir des opérations faites dans Gimp au milieu du pipeline de Darktable. Mais ça n'arrivera pas demain ;-).
La perte d'information, ce n'est pas sur la résolution (l'export en .png la conserve sans problème par exemple), mais sur la profondeur des pixels. Gimp utilise pour l'instant 8 bits/pixel/couleur (ça changera dans la 2.10), et Darktable utilise des flottants 24 bits. Pour le résultat final, 8 bits/pixel/couleur est suffisant pour la plupart des utilisations (pour de l'affichage sur un écran lambda, on ne peut pas faire mieux), mais pour les calculs intermédiaires, les erreurs d'arrondis se cumulent, et faire tous les traitements sur 8 bits peut poser problème même pour des non-puristes non-professionnels. L'autre intérêt d'utiliser des flottants est qu'on peut manipuler des valeurs intermédiaires qui débordent de l'intervalle des valeurs représentables (trop blanc ou trop noires), mais revenir dans des bonnes valeurs plus loin dans le pipeline. Par exemple, c'est ce qui permet de retrouver les détails dans des parties un peu sur/sous-exposées avec le module « Shadows and Highlights » de Darktable.