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.
Posté par mahikeulbody .
En réponse au journal Adobe sous Linux ?.
Évalué à 10.
Dernière modification le 11 décembre 2018 à 09:23.
Je pirate Lightroom (car il n'a pas d'équivalent sous Linux), mais pour mes besoins Gimp me suffit, donc je ne pirate pas Photoshop…
Il aurait été plus juste de dire :
Je pirate Lightroom car les équivalents Linux existent mais ne me conviennent pas autant que Lightroom, alors que je ne pirate pas Photoshop car Gimp me suffit.
NB. Il ne s'agit pas ici de lancer une discussion sur les mérites comparés des différents logiciels impliqués, il s'agit juste de rectifier une contre-vérité : il y a des équivalents* à Lightroom sous Linux (Darktable, Rawtherapy, Digikam principalement).
* au sens "on peut faire les mêmes choses", sans préjuger de la façon plus ou moins facile de les faire selon le logiciel.
Par ailleurs, au delà du fait que pirater c'est pas bien, pirater un logiciel dont certaines sorties sont propriétaires est assez risqué. En effet, si les tags IPTC ou XMP créés avec Lightroom sont portables d'un logiciel à un autre, les historiques de développement raw eux ne le sont pas => ils seront complètement perdus si un jour on ne peut plus pirater le logiciel. Or un photographe qui développe ses raw accepte rarement de bon cœur de les perdre (et si c'est un pro, c'est difficilement envisageable).
Tu pourrais peut-être essayer de configurer un compte google juste pour voir si ça te permet de désactiver le service sans que Settings plante. Puis une fois le service arrêté, tu n'aurais plus qu'à désinstaller le compte.
L'idée sous-jacente est qu'il s'agit peut-être d'un bug provoqué par l'absence de compte google au moment de désactiver un service google.
Mais même si c'est ça, ça n'expliquerait pas comment le service s'est retrouvé activé s'il n'y a jamais eu de compte google configuré sur ce smartphone…
Si j'ai bien compris ce n'est pas l'app elle-même qui est en cause (si ça se trouve, il ne l'a pas non plus). En fait il veut désactiver le service qui écoute les requêtes extérieures demandant la localisation du smartphone (requêtes faite via une page web ou via un FDM installé sur un autre device Android).
Cette désactivation est un paramétrage (voir son post plus haut sur comment l'effectuer) sauf que chez lui ça plante l'appli 'Paramétrages'. Du coup, il cherche à carrément désinstaller le service.
Ce plantage ressemble à un vrai bug car je ne l'ai pas rencontré dans aucun de mes smartphones Android jusqu'à présent (ce qui serait le cas si c'était un truc exprès pour ne pas pouvoir désactiver le service).
(moi, j'attends toujours la fin de la garantie avant d'installer une AOSP, ce qui colle en général avec le moment où le fabricant ne met plus ce modèle à jour)
ça me dit, me montre, le nom ubuntu 18, alors que c'est impossible que j'ai ubuntu 18 installé, vu que l’architecture de mon processeur est de 32bits, donc j'ai installé linux mint.
Mint étant basé sur Ubuntu, il n'est pas impossible qu'il y ait quelques scories qui traînent.
La pub pour FMD se trouve dans tes options puis "Google" => "Security" => "Find My Device".
Ok, j'ai ça aussi mais comme tu dis, ça reste une pub pour une application qu'on a de toutes façons peu de raisons d'installer puisqu'en général si on perd son smartphone on va passer par le web sur un PC pour le localiser (à moins d'avoir plusieurs devices android).
Indépendamment de cette "pub", il y aussi un switch d'activation de la fonction à cet endroit.
Pour voir les [comptes] administrateurs sur l'appareil c'est dans options => "écran de verrouillage et Sécurité" => "Administrateurs de l'appareil".
Moi, j'ai ça dans Sécurité et localisation/Applis d'administration d'appareil où j'ai aussi un switch permettant d'activer ou pas la fonction.
Du coup, si tu désactives la fonction dans le ou les endroits où on en parle, ça ne suffit pas ?
[^] # 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.
[^] # Re: Would be nice
Posté par mahikeulbody . En réponse au journal Adobe sous Linux ?. Évalué à 10. Dernière modification le 11 décembre 2018 à 09:23.
Il aurait été plus juste de dire :
Je pirate Lightroom car les équivalents Linux existent mais ne me conviennent pas autant que Lightroom, alors que je ne pirate pas Photoshop car Gimp me suffit.
NB. Il ne s'agit pas ici de lancer une discussion sur les mérites comparés des différents logiciels impliqués, il s'agit juste de rectifier une contre-vérité : il y a des équivalents* à Lightroom sous Linux (Darktable, Rawtherapy, Digikam principalement).
* au sens "on peut faire les mêmes choses", sans préjuger de la façon plus ou moins facile de les faire selon le logiciel.
Par ailleurs, au delà du fait que pirater c'est pas bien, pirater un logiciel dont certaines sorties sont propriétaires est assez risqué. En effet, si les tags IPTC ou XMP créés avec Lightroom sont portables d'un logiciel à un autre, les historiques de développement raw eux ne le sont pas => ils seront complètement perdus si un jour on ne peut plus pirater le logiciel. Or un photographe qui développe ses raw accepte rarement de bon cœur de les perdre (et si c'est un pro, c'est difficilement envisageable).
[^] # Re: ROM AOSP
Posté par mahikeulbody . En réponse au message [SOLVED] Ne plus se faire espionner par Find My Device sur Android. Évalué à 1.
Tu pourrais peut-être essayer de configurer un compte google juste pour voir si ça te permet de désactiver le service sans que Settings plante. Puis une fois le service arrêté, tu n'aurais plus qu'à désinstaller le compte.
L'idée sous-jacente est qu'il s'agit peut-être d'un bug provoqué par l'absence de compte google au moment de désactiver un service google.
Mais même si c'est ça, ça n'expliquerait pas comment le service s'est retrouvé activé s'il n'y a jamais eu de compte google configuré sur ce smartphone…
[^] # Re: ROM AOSP
Posté par mahikeulbody . En réponse au message [SOLVED] Ne plus se faire espionner par Find My Device sur Android. Évalué à 3. Dernière modification le 03 décembre 2018 à 14:10.
Si j'ai bien compris ce n'est pas l'app elle-même qui est en cause (si ça se trouve, il ne l'a pas non plus). En fait il veut désactiver le service qui écoute les requêtes extérieures demandant la localisation du smartphone (requêtes faite via une page web ou via un FDM installé sur un autre device Android).
Cette désactivation est un paramétrage (voir son post plus haut sur comment l'effectuer) sauf que chez lui ça plante l'appli 'Paramétrages'. Du coup, il cherche à carrément désinstaller le service.
Ce plantage ressemble à un vrai bug car je ne l'ai pas rencontré dans aucun de mes smartphones Android jusqu'à présent (ce qui serait le cas si c'était un truc exprès pour ne pas pouvoir désactiver le service).
[^] # Re: ROM AOSP
Posté par mahikeulbody . En réponse au message [SOLVED] Ne plus se faire espionner par Find My Device sur Android. Évalué à 1.
plus de garantie non plus…
(moi, j'attends toujours la fin de la garantie avant d'installer une AOSP, ce qui colle en général avec le moment où le fabricant ne met plus ce modèle à jour)
# Mint est basé sur Ubuntu
Posté par mahikeulbody . En réponse au message problème concernant linux mint et son sacré keyring. Évalué à 2.
Mint étant basé sur Ubuntu, il n'est pas impossible qu'il y ait quelques scories qui traînent.
[^] # Re: Je ne vois pas le problème
Posté par mahikeulbody . En réponse au message [SOLVED] Ne plus se faire espionner par Find My Device sur Android. Évalué à 2.
Je viens d'essayer sur le mien, ça désactive bien la fonction, sans crash.
Je suis sous Android 7.
[^] # Re: Je ne vois pas le problème
Posté par mahikeulbody . En réponse au message [SOLVED] Ne plus se faire espionner par Find My Device sur Android. Évalué à 2.
Ok, j'ai ça aussi mais comme tu dis, ça reste une pub pour une application qu'on a de toutes façons peu de raisons d'installer puisqu'en général si on perd son smartphone on va passer par le web sur un PC pour le localiser (à moins d'avoir plusieurs devices android).
Indépendamment de cette "pub", il y aussi un switch d'activation de la fonction à cet endroit.
Moi, j'ai ça dans Sécurité et localisation/Applis d'administration d'appareil où j'ai aussi un switch permettant d'activer ou pas la fonction.
Du coup, si tu désactives la fonction dans le ou les endroits où on en parle, ça ne suffit pas ?