La majorité des gens ne veut/peut pas gérer un serveur, d'où ma remarque sur le cas d'utilisation cité "photos en vacances" où le peer-to-peer ne répond plus au problème. Pour les autres cas d'utilisation j'utilise SyncThing et j'en suis satisfait.
J'en profite pour faire la remarque suivante : Syncthing remplace sans problème des solutions type Dropbox mais il y a des cas de figure où le principe peer to peer (i.e. pas de serveur central) peut poser problème.
Par exemple, on peut se servir de Syncthing pour synchroniser un PC avec les photos prises sur un smartphone. Mais si on part en vacances on éteint généralement son PC. Si par malheur on se fait voler son smartphone, on perd les photos prises pendant les vacances. Dans le cas d'une solution plus classique avec un serveur, le risque est amoindri à moins de n'avoir aucune connexion internet durant les vacances.
Posté par mahikeulbody .
En réponse à la dépêche darktable 2.6.0.
Évalué à 2.
Dernière modification le 02 janvier 2019 à 16:50.
> mais aussi les autres métadonnées telles que le tagging qui est virtuellement infini.
Qu'entends-tu par "tagging", les mots-clés ?
Tu peux bien sûr mettre tout et n'importe quoi dans le tag "mots-clés". Le "standard" XMP prévoit cependant bien d'autres champs qu'il est un peu dommage de ne pas pouvoir utiliser.
Après, ce n'est pas ça qui va me faire quitter DT (et Linux) en faveur de Lightroom mais on peut comprendre que ça puisse en gêner certains (même si l'exprimer par un discours "le libre est arrogant et ne comprends rien aux besoins des utilisateurs" me paraît déplacé et inexact).
Je suppose que tu suggères d'insérer FILE_EXTENSION dans le nom en sortie en plus de SEQUENCE.
J'y vois au moins un problème, voire deux :
- le nom du jpeg fait bien référence au nom du raw mais je doute qu'un tel nom "plaise" au client
- SEQUENCE - si je ne m'abuse - ne créé une séquence que sur l'ensemble des photos sélectionnées dans un même export ; du coup, si comme moi, on exporte à chaque fois qu'on a fini une photo (ctrl-E depuis la chambre noire) ça ne va pas marcher
Bref, il me semble quand même que le plus simple est de renommer les raw comme on le souhaite avant de les importer dans DT afin d'avoir des jpg de même nom (éventuellement suffixé avec un numéro en cas de clones basés sur un même raw).
Avant de traiter quelqu'un de dinosaure il faut prendre la peine de le lire : il ne parle pas de chercher des photos, il parle du nommage qu'elles ont quand elles sont livrées au client.
Mais puisque tu parles des méta-données, tu devrais aussi lire ce qu'il a écrit : il trouve le nombre de champs insuffisants dans DT.
(peu importe qu'on soit d'accord ou pas avec ses deux exigences, là tu réponds à coté et en l'agressant).
Je peux comprendre que tu regrettes que cette fonction ne soit pas présente dans DT mais je suis quand même un peu surpris que cela soit rédhibitoire au point de devoir utiliser d'autres logiciels à la place, payants et non disponibles sous Linux de surcroît.
En ce qui me concerne je renomme* mes raw avant de les importer dans DT avec une règle de type 2018-12-25_15h32-17.xxx. Je ne suis pas photographe professionnel mais en tant que client potentiel il me semble qu'un nommage de mes jpeg sous cette forme me paraîtrait aussi acceptable qu'une numérotation 1…n.
* J'effectue ce renommage avec exiftool ou avec XnViewMP qui utilise exiftool en interne. Ça prend à peine plus de temps que si on pouvait le faire depuis DT.
Posté par mahikeulbody .
En réponse à la dépêche darktable 2.6.0.
Évalué à 5.
Dernière modification le 31 décembre 2018 à 15:00.
que l'ajout d'une simple fonction de renommage qui existe déjà dans de nombreux utilitaires libres ?
Oui, enfin, ce n'est sans doute pas très compliqué mais ça l'est quand même un peu plus que pour les utilitaires que tu cites. Il faut notamment mettre à jour la base de données de DT avec les nouveaux noms, renommer aussi les fichiers xmp correspondants, modifier le contenu de ces fichiers xmp (car ils contiennent le nom original) et peut-être d'autres choses que j'oublie.
Alors si en plus cette fonction ne paraît pas essentielle aux développeurs (ni à un certain nombre d'utilisateurs apparemment) et que personne ne les paye pour ça…
Je reformule pour être sûr d'avoir bien compris :
- je créé un compte XMPP sur un serveur avec moi@mondomaine comme identifiant (sous réserve que ce soit permis)
- quand je me connecte sur un pod avec cet identifiant, celui-ci utilise les DNS de mondomaine pour trouver le serveur XMPP qui héberge mon compte
- si je change de serveur XMPP, je clôture mon compte sur ce serveur, puis je créé un compte avec le même identifiant sur un autre serveur (après avoir mis à jour les DNS de mondomaine)
Merci pour cette explication, je comprends maintenant la différence entre pod et serveur.
Et pour ce qui est d'avoir son propre domaine et serveur: oui, c'est bien ce que je disais: héberger son propre serveur.
Non, moi je parlais juste d'avoir son propre domaine ce qui est quand même plus simple que d'avoir son propre serveur. Si je dis à ma compagne qu'il faudra qu'elle gère un Yunohost le jour où je ne serai plus là
pour ne pas perdre son identité "sociale", ça va pas le faire.
Je ne comprends pas tout : quand je me connecte sur fr.movim.eu je me connecte sur quoi ? Sur un pod Movim ou sur un serveur XMPP ?
Ok, je crois deviner que je me connecte sur un pod Movim qui communique lui-même avec un serveur XMPP. Mais pour un utilisateur lambda qu'est-ce que ça veut dire "changer de pod à la volée" ?
Par ailleurs, en lisant ton message, je "réalise" que l'identifiant est lié au serveur XMPP. Donc, effectivement, si celui-ci disparaît, mon identité disparaît => les problèmes que tu évoques.
Mais alors ta comparaison avec les mails n'est pas tout à fait juste. En effet, d'une part, il est facile d'exporter des mails d'une adresse à une autre. D'autre part, on peut garder la même adresse email toute sa vie sans dépendre d'un serveur : en ayant son propre domaine.
Je suis très étonné que ce soit expérimental dans XMPP après tant d'années. Je suis certes ignare en réseaux sociaux mais il me semblait qu'une telle fonctionnalité faisait nécessairement parie de la base d'un réseau social généraliste (i.e. pas comme Twitter par exemple).
Peut-être que je suis sacrément dépassé de vouloir publier des trucs juste pour ma famille…
Une autre question que je me pose : qu'en est-il de la possibilité d'exporter ses données sur un autre serveur ?
Il y a deux ou trois on m'avait répondu à cette même question que ça serait possible un jour (excepté pour les "pièces jointes" : images, vidéos,…).
J'ai rapidement essayé Movim il y a quelques mois mais je n'avais pas vu comment faire une publication restreinte à une liste de contacts ou un groupe prédéfini. C'est mon inexpérience des réseaux sociaux ou bien c'est comme ça ?
j'ai l'impression que tu as donné sa chance à Lightroom, là où pour Darktable tu as tout de suite arrêté d'essayer de rentrer dedans et de comprendre, voire de documenter ce qui fonctionne bien.
Le problème c'est que la question est généralement "comment j'arrive le plus rapidement possible au rendu que je souhaite". Et là Darktable s'écroule.
Ton avis est respectable mais on trouve aussi des avis différents de photographes professionnels, y compris sur la productivité. J'imagine qu'il y a différentes façons de travailler, différents niveaux de maîtrise du logiciel, différentes attentes quant au résultat final, etc…, autant de pistes pour expliquer ces différences d'appréciation.
Cela relativise en tous cas ton "là Darktable s'écroule".
En ce qui me concerne (je ne suis pas un pro), le vrai critère de choix initial a été la disponibilité sous Linux (je me suis lassé de devoir passer par Virtualbox). Coté DAM, le logiciel que j'aurais aimé voir porté sous Linux n'est pas Lightroom mais iMatch, à coté duquel Lightroom fait pâle figure, tout comme Digikam (sans parler de Darktable dont ce n'est de toutes façons pas l'ambition première).
Je n'avais pas remarqué que l'interface de Darktable était un clone de celle de Lightroom. Si tu le dis…
Ma remarque reste néanmoins valable : l'évaluation d'une ergonomie comporte une large part de subjectivité et cette évaluation est aussi liée à la maîtrise que l'on a du logiciel. Moi, je trouve l'ergonomie excellente mais il m'a effectivement fallu un peu de temps et surtout visionner des tutoriels sur youtube. Peut-être qu'effectivement l’interface de Darktable est moins immédiatement assimilable que celle de Lightroom mais l'essentiel est la très grande efficacité qui en résulte une fois qu'on a acquis la maîtrise du logiciel.
je vois difficilement comment Darktable pourrait être meilleur que Lightroom sur le traitement des RAWS.
Ce que tu appelles "traitement des raw" comprends en réalité deux parties bien distinctes :
- le dématriçage : transformation de l'image raw "type matrice de Bayer" en une image comportant une valeur pour chaque composante RGB sur chaque pixel (ce qui n'est pas le cas dans l'image raw)
- les outils de développement à proprement parler : balance des blancs, courbe de tonalité, correction d'exposition, traitement des couleurs, etc…
Il n'y a aucun mystère particulier sur l'image raw et ce n'est pas vraiment au stade du dématriçage que le "développement" de la photo se joue. Le fichier raw peut contenir des informations propriétaires et non documentées mais il s'agit essentiellement de la configuration utilisée par l'appareil photo lors de la prise de vue pour convertir le raw en jpeg. A moins de vouloir obtenir le même résultat que le jpeg boîtier (quel intérêt ?), elles ne sont pas très utiles. En fait, le travail de retro-ingénierie nécessaire est surtout relatif aux corrections qu'il faut appliquer aux objectifs (les grands éditeurs comme Adobe, DxO, etc… ont sûrement les informations directement).
En ce qui concerne le développement lui-même (ce qu'il y après le dématriçage), il n'y a à mon avis aucune raison liée à d'éventuelles informations qu'aurait Adobe et pas Darktable qui pourrait handicaper ce dernier.
PS. Oui, Darktable a bien sûr beaucoup évolué en deux ou trois ans. Ensuite, il faut être conscient qu'il n'applique par défaut aucun traitement excepté une balance des blancs et une courbe de niveau (qui est effectivement une retro-ingénierie et donc une approximation de celle appliquée par le boîtier pour produire ses jpeg) => par rapport à un logiciel qui fait des réglages par défaut dits "intelligents", il faut peut-être plus de temps si on est débutant sur le logiciel ou, plus généralement, dans le domaine du développement.
Désolé, mais je connais un peu le sujet : Rawtherapee et Digikam ne sont pas des équivalents à Lightroom
C'est dit avec beaucoup d'assurance mais un "argument d'autorité" sans qu'on sache qui est cette autorité, c'est assez peu convainquant. De plus, on trouve plein d'articles de photographes professionnels qui comparent les deux. J'imagine mal qu'ils s'amusent à comparer des choux et des carottes.
d'autre part darktable est loin derrière Lightroom en ce qui concerne l'ergonomie, la facilité d'utilisation
Ergonomie et facilité d'utilisation sont pour moi des points peu pertinents à prendre en compte lorsqu'on parle d'équivalence car ils sont subjectifs. Ils sont d'autant plus subjectifs qu'il s'agit ici de logiciels malgré tout complexes ce qui induit une courbe d'apprentissage assez grande et parfois rebutante quand on est habitué à un autre logiciel.
L'exemple typique est Gimp dont l'ergonomie différente de celle de Photoshop provoque souvent un rejet de la part d'utilisateurs habitués à Photoshop après seulement quelques minutes d'essai (alors que le chemin inverse leur ferait sans doute le même effet).
darktable est loin derrière Lightroom en ce qui concerne la récupération des hautes lumières…
Je ne m'aventurerais pas à comparer la récupération des lumières dans Darktable avec celle dans Lightroom mais quand bien même tu aurais raison, je pourrais alors citer les modes de sélection supérieurs de Darktable et ainsi de suite…
Le seul point qui me paraît indubitablement supérieur dans Lightroom, c'est le catalogage.
J'utilise Darktable qui est probablement aussi puissant (voire plus) pour le développement raw que Lightroom selon pas mal d'avis "d'experts" ayant pris la peine d'essayer les deux. On n'est pas obligé de les croire mais ça incite à penser que ça vaut la peine de vérifier.
En revanche, pour le catalogage et la gestion des tag xmp, il n'y a pas photo : Lightroom dépasse largement Darktable. Mais il y a alors Digikam* qui est un concurrent honorable de Lightroom dans ce domaine.
* Il s'est débarrassé d'une grande partie de ses lourdes dépendances à KDE qui faisait fuir ceux qui étaient sous Gnome ou XFCE.
# Gandi
Posté par mahikeulbody . En réponse au message Quel registrar chosir pour un domaine en .net. Évalué à 8.
J'ai un domaine en .net chez Gandi, avec mes emails hébergés ailleurs, depuis de nombreuses années : aucun souci particulier.
[^] # Re: Syncthing très bien mais...
Posté par mahikeulbody . En réponse au message Syncthing et appareil maitre. Évalué à 1.
La majorité des gens ne veut/peut pas gérer un serveur, d'où ma remarque sur le cas d'utilisation cité "photos en vacances" où le peer-to-peer ne répond plus au problème. Pour les autres cas d'utilisation j'utilise SyncThing et j'en suis satisfait.
# Syncthing très bien mais...
Posté par mahikeulbody . En réponse au message Syncthing et appareil maitre. Évalué à 3.
J'en profite pour faire la remarque suivante : Syncthing remplace sans problème des solutions type Dropbox mais il y a des cas de figure où le principe peer to peer (i.e. pas de serveur central) peut poser problème.
Par exemple, on peut se servir de Syncthing pour synchroniser un PC avec les photos prises sur un smartphone. Mais si on part en vacances on éteint généralement son PC. Si par malheur on se fait voler son smartphone, on perd les photos prises pendant les vacances. Dans le cas d'une solution plus classique avec un serveur, le risque est amoindri à moins de n'avoir aucune connexion internet durant les vacances.
# Ça se passe au niveau du partage
Posté par mahikeulbody . En réponse au message Syncthing et appareil maitre. Évalué à 2.
C'est défini au niveau de chaque partage (ce qui me paraît d'ailleurs plus logique qu'au niveau de l'appareil).
'Gérer' le partage considéré, onglet 'Avancé' et choisir le type de partage, en l'occurrence 'Envoi (lecture seule)' sur le maître.
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 2. Dernière modification le 02 janvier 2019 à 16:50.
> mais aussi les autres métadonnées telles que le tagging qui est virtuellement infini.
Qu'entends-tu par "tagging", les mots-clés ?
Tu peux bien sûr mettre tout et n'importe quoi dans le tag "mots-clés". Le "standard" XMP prévoit cependant bien d'autres champs qu'il est un peu dommage de ne pas pouvoir utiliser.
Après, ce n'est pas ça qui va me faire quitter DT (et Linux) en faveur de Lightroom mais on peut comprendre que ça puisse en gêner certains (même si l'exprimer par un discours "le libre est arrogant et ne comprends rien aux besoins des utilisateurs" me paraît déplacé et inexact).
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 1.
Je suppose que tu suggères d'insérer FILE_EXTENSION dans le nom en sortie en plus de SEQUENCE.
J'y vois au moins un problème, voire deux :
- le nom du jpeg fait bien référence au nom du raw mais je doute qu'un tel nom "plaise" au client
- SEQUENCE - si je ne m'abuse - ne créé une séquence que sur l'ensemble des photos sélectionnées dans un même export ; du coup, si comme moi, on exporte à chaque fois qu'on a fini une photo (ctrl-E depuis la chambre noire) ça ne va pas marcher
Bref, il me semble quand même que le plus simple est de renommer les raw comme on le souhaite avant de les importer dans DT afin d'avoir des jpg de même nom (éventuellement suffixé avec un numéro en cas de clones basés sur un même raw).
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 3.
Avant de traiter quelqu'un de dinosaure il faut prendre la peine de le lire : il ne parle pas de chercher des photos, il parle du nommage qu'elles ont quand elles sont livrées au client.
Mais puisque tu parles des méta-données, tu devrais aussi lire ce qu'il a écrit : il trouve le nombre de champs insuffisants dans DT.
(peu importe qu'on soit d'accord ou pas avec ses deux exigences, là tu réponds à coté et en l'agressant).
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 2.
Je peux comprendre que tu regrettes que cette fonction ne soit pas présente dans DT mais je suis quand même un peu surpris que cela soit rédhibitoire au point de devoir utiliser d'autres logiciels à la place, payants et non disponibles sous Linux de surcroît.
En ce qui me concerne je renomme* mes raw avant de les importer dans DT avec une règle de type 2018-12-25_15h32-17.xxx. Je ne suis pas photographe professionnel mais en tant que client potentiel il me semble qu'un nommage de mes jpeg sous cette forme me paraîtrait aussi acceptable qu'une numérotation 1…n.
* J'effectue ce renommage avec exiftool ou avec XnViewMP qui utilise exiftool en interne. Ça prend à peine plus de temps que si on pouvait le faire depuis DT.
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 5. Dernière modification le 31 décembre 2018 à 15:00.
Oui, enfin, ce n'est sans doute pas très compliqué mais ça l'est quand même un peu plus que pour les utilitaires que tu cites. Il faut notamment mettre à jour la base de données de DT avec les nouveaux noms, renommer aussi les fichiers xmp correspondants, modifier le contenu de ces fichiers xmp (car ils contiennent le nom original) et peut-être d'autres choses que j'oublie.
Alors si en plus cette fonction ne paraît pas essentielle aux développeurs (ni à un certain nombre d'utilisateurs apparemment) et que personne ne les paye pour ça…
[^] # Re: Oui, mais non.
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 5.
Si on veut renommer avec une règle basée sur les EXIF, alors non, n'importe quel gestionnaire de fichiers ne fait pas le boulot.
Mais il y a bien sûr des logiciels dédiés qui font ça très bien et l'absence de cette fonction dans DT me paraît anecdotique.
# Fantastique dépêche !
Posté par mahikeulbody . En réponse à la dépêche darktable 2.6.0. Évalué à 5.
Fantastique dépêche !
Je l'admets, c'est un commentaire inutile mais tant pis pour mon karma, j'avais besoin de le dire.
[^] # Re: exporter un compte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 4.
Ah, ça c'est bien.
Je reformule pour être sûr d'avoir bien compris :
- je créé un compte XMPP sur un serveur avec moi@mondomaine comme identifiant (sous réserve que ce soit permis)
- quand je me connecte sur un pod avec cet identifiant, celui-ci utilise les DNS de mondomaine pour trouver le serveur XMPP qui héberge mon compte
- si je change de serveur XMPP, je clôture mon compte sur ce serveur, puis je créé un compte avec le même identifiant sur un autre serveur (après avoir mis à jour les DNS de mondomaine)
[^] # Re: publier de façon restreinte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 2.
Certes. Ce n'était d'ailleurs pas une critique de ma part, juste un étonnement.
En tous cas, c'est rédhibitoire pour moi.
[^] # Re: exporter un compte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 1.
Quid de l'identité, elle peut être de la forme moi@mondomaine sur un serveur XMPP que je ne gère pas ?
[^] # Re: exporter un compte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 2.
Merci pour cette explication, je comprends maintenant la différence entre pod et serveur.
Non, moi je parlais juste d'avoir son propre domaine ce qui est quand même plus simple que d'avoir son propre serveur. Si je dis à ma compagne qu'il faudra qu'elle gère un Yunohost le jour où je ne serai plus là
pour ne pas perdre son identité "sociale", ça va pas le faire.
[^] # Re: exporter un compte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 2.
Je ne comprends pas tout : quand je me connecte sur fr.movim.eu je me connecte sur quoi ? Sur un pod Movim ou sur un serveur XMPP ?
Ok, je crois deviner que je me connecte sur un pod Movim qui communique lui-même avec un serveur XMPP. Mais pour un utilisateur lambda qu'est-ce que ça veut dire "changer de pod à la volée" ?
Par ailleurs, en lisant ton message, je "réalise" que l'identifiant est lié au serveur XMPP. Donc, effectivement, si celui-ci disparaît, mon identité disparaît => les problèmes que tu évoques.
Mais alors ta comparaison avec les mails n'est pas tout à fait juste. En effet, d'une part, il est facile d'exporter des mails d'une adresse à une autre. D'autre part, on peut garder la même adresse email toute sa vie sans dépendre d'un serveur : en ayant son propre domaine.
[^] # Re: publier de façon restreinte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 3.
Je suis très étonné que ce soit expérimental dans XMPP après tant d'années. Je suis certes ignare en réseaux sociaux mais il me semblait qu'une telle fonctionnalité faisait nécessairement parie de la base d'un réseau social généraliste (i.e. pas comme Twitter par exemple).
Peut-être que je suis sacrément dépassé de vouloir publier des trucs juste pour ma famille…
# exporter un compte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 4.
Une autre question que je me pose : qu'en est-il de la possibilité d'exporter ses données sur un autre serveur ?
Il y a deux ou trois on m'avait répondu à cette même question que ça serait possible un jour (excepté pour les "pièces jointes" : images, vidéos,…).
# publier de façon restreinte
Posté par mahikeulbody . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 6.
J'ai rapidement essayé Movim il y a quelques mois mais je n'avais pas vu comment faire une publication restreinte à une liste de contacts ou un groupe prédéfini. C'est mon inexpérience des réseaux sociaux ou bien c'est comme ça ?
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 3.
C'est à moi que tu réponds ???
Je n'utilise que Darktable !
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 2.
Ton avis est respectable mais on trouve aussi des avis différents de photographes professionnels, y compris sur la productivité. J'imagine qu'il y a différentes façons de travailler, différents niveaux de maîtrise du logiciel, différentes attentes quant au résultat final, etc…, autant de pistes pour expliquer ces différences d'appréciation.
Cela relativise en tous cas ton "là Darktable s'écroule".
En ce qui me concerne (je ne suis pas un pro), le vrai critère de choix initial a été la disponibilité sous Linux (je me suis lassé de devoir passer par Virtualbox). Coté DAM, le logiciel que j'aurais aimé voir porté sous Linux n'est pas Lightroom mais iMatch, à coté duquel Lightroom fait pâle figure, tout comme Digikam (sans parler de Darktable dont ce n'est de toutes façons pas l'ambition première).
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 2.
Je n'avais pas remarqué que l'interface de Darktable était un clone de celle de Lightroom. Si tu le dis…
Ma remarque reste néanmoins valable : l'évaluation d'une ergonomie comporte une large part de subjectivité et cette évaluation est aussi liée à la maîtrise que l'on a du logiciel. Moi, je trouve l'ergonomie excellente mais il m'a effectivement fallu un peu de temps et surtout visionner des tutoriels sur youtube. Peut-être qu'effectivement l’interface de Darktable est moins immédiatement assimilable que celle de Lightroom mais l'essentiel est la très grande efficacité qui en résulte une fois qu'on a acquis la maîtrise du logiciel.
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 1.
Ce que tu appelles "traitement des raw" comprends en réalité deux parties bien distinctes :
- le dématriçage : transformation de l'image raw "type matrice de Bayer" en une image comportant une valeur pour chaque composante RGB sur chaque pixel (ce qui n'est pas le cas dans l'image raw)
- les outils de développement à proprement parler : balance des blancs, courbe de tonalité, correction d'exposition, traitement des couleurs, etc…
Il n'y a aucun mystère particulier sur l'image raw et ce n'est pas vraiment au stade du dématriçage que le "développement" de la photo se joue. Le fichier raw peut contenir des informations propriétaires et non documentées mais il s'agit essentiellement de la configuration utilisée par l'appareil photo lors de la prise de vue pour convertir le raw en jpeg. A moins de vouloir obtenir le même résultat que le jpeg boîtier (quel intérêt ?), elles ne sont pas très utiles. En fait, le travail de retro-ingénierie nécessaire est surtout relatif aux corrections qu'il faut appliquer aux objectifs (les grands éditeurs comme Adobe, DxO, etc… ont sûrement les informations directement).
En ce qui concerne le développement lui-même (ce qu'il y après le dématriçage), il n'y a à mon avis aucune raison liée à d'éventuelles informations qu'aurait Adobe et pas Darktable qui pourrait handicaper ce dernier.
PS. Oui, Darktable a bien sûr beaucoup évolué en deux ou trois ans. Ensuite, il faut être conscient qu'il n'applique par défaut aucun traitement excepté une balance des blancs et une courbe de niveau (qui est effectivement une retro-ingénierie et donc une approximation de celle appliquée par le boîtier pour produire ses jpeg) => par rapport à un logiciel qui fait des réglages par défaut dits "intelligents", il faut peut-être plus de temps si on est débutant sur le logiciel ou, plus généralement, dans le domaine du développement.
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 8.
C'est dit avec beaucoup d'assurance mais un "argument d'autorité" sans qu'on sache qui est cette autorité, c'est assez peu convainquant. De plus, on trouve plein d'articles de photographes professionnels qui comparent les deux. J'imagine mal qu'ils s'amusent à comparer des choux et des carottes.
Ergonomie et facilité d'utilisation sont pour moi des points peu pertinents à prendre en compte lorsqu'on parle d'équivalence car ils sont subjectifs. Ils sont d'autant plus subjectifs qu'il s'agit ici de logiciels malgré tout complexes ce qui induit une courbe d'apprentissage assez grande et parfois rebutante quand on est habitué à un autre logiciel.
L'exemple typique est Gimp dont l'ergonomie différente de celle de Photoshop provoque souvent un rejet de la part d'utilisateurs habitués à Photoshop après seulement quelques minutes d'essai (alors que le chemin inverse leur ferait sans doute le même effet).
Je ne m'aventurerais pas à comparer la récupération des lumières dans Darktable avec celle dans Lightroom mais quand bien même tu aurais raison, je pourrais alors citer les modes de sélection supérieurs de Darktable et ainsi de suite…
Le seul point qui me paraît indubitablement supérieur dans Lightroom, c'est le catalogage.
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 7.
J'utilise Darktable qui est probablement aussi puissant (voire plus) pour le développement raw que Lightroom selon pas mal d'avis "d'experts" ayant pris la peine d'essayer les deux. On n'est pas obligé de les croire mais ça incite à penser que ça vaut la peine de vérifier.
En revanche, pour le catalogage et la gestion des tag xmp, il n'y a pas photo : Lightroom dépasse largement Darktable. Mais il y a alors Digikam* qui est un concurrent honorable de Lightroom dans ce domaine.
* Il s'est débarrassé d'une grande partie de ses lourdes dépendances à KDE qui faisait fuir ceux qui étaient sous Gnome ou XFCE.