mahikeulbody a écrit 1577 commentaires

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.

C'est à moi que tu réponds ???

Je n'utilise que Darktable !

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.

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).

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)

ç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.

Je viens d'essayer sur le mien, ça désactive bien la fonction, sans crash.
Je suis sous Android 7.

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 ?

Sur mon smartphone, les choses sont un peu différentes : je ne vois pas de FMD et dans la partie 'administration' je peux cocher/décocher la fonction "localiser mon appareil" (j'aurais préféré un truc plus précis comme "autorisation de localiser mon appareil à ma demande").

Google n'a pas besoin d'un compte google pour t'espionner.

Tu donnes de l'eau à mon moulin !

Puisque c'est Google qui développe FMD et qu'il n'en a pas besoin pour te localiser (entre autres choses), pourquoi veux-tu désinstaller FMD ?

Enfaite c'est peut-être un gros bug (franchement sérieux niveau sécurité…) d'android.

Ah, lequel ?

(tu as lu mon autre commentaire ?)

Supprimer cette application ne sert à rien (sauf pour gagner de la place en mémoire) car elle n'est pas en charge de communiquer la localisation du smartphone où elle est installée, elle est en charge de trouver celle d'un autre device Android dont on possède le login-password du compte Google installé (s'il y en a un).

Ce n'est pas un daemon, c'est un client.

Pour localiser le smartphone concerné, il n'y a pas besoin que Find My Device soit installé, il suffit d'utiliser un navigateur web sur n'importe quel PC et de chercher Find My Device dans Google, puis d'entrer les identifiants du compte Google associé à ton smartphone. En fait l'appli Android n'a de sens que si tu as d'autres devices Android dont tu possèdes les identifiants Google.

Pour résumer :
- une personne lambda ne peut pas localiser ton smartphone si elle n'a pas les identifiants de ton compte Google, que Find My Device soit installé ou pas
- une personne lambda peut localiser ton smartphone si elle a les identifiants de ton compte Google, que Find My Device soit installé ou pas
- Google pourra te suivre à la trace si tu as un compte Google, que Find My Device soit installé ou pas
- il n'y a pas lieu de se méfier de Find My Device car… elle est développée par Google qui n'en a pas besoin pour te localiser (voir alinéa précédent)
- cette application n'est utile que si tu as un autre device Android ("utile" mais pas nécessaire puisqu'on peut aussi utiliser un navigateur web, y compris sur ton smartphone)

J'imagine qu'il faut prendre en compte l'historique du logiciel et des toolkits multi-plateforme disponibles au début du projet. Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.

Ceci dit, vu qu'ils ont aussi créé Rust alors qu'il y avait très probablement d'autres langages qui auraient pu convenir, c'est peut-être l'effet du syndrome "not invented here" (même si au final, ça donne un très bon langage utilisable par la communauté).

Dans ma vision naïve des choses, Wayland n'impactait que les toolkits graphiques utilisés par les applications.
Qu'est-ce que je n'ai pas compris ?

> elle n'est plus vendu comme rolling ? ok, j'ai vécu sous un pont.

Je pense même que tu es né sous le pont vu que sauf erreur grossière de ma part Fedora n'a jamais été une rolling release (ou alors à une époque dont le commun des mortels n'a pas souvenir).

Je n'ai rien compris !

Et que vient faire le rolling release dans cette diatribe contre une distribution qui ne l'est pas ?

Désolé, c'est grub-btrfs (et non l'inverse). Je l'ai trouvé dans les dépôts officiels de ma manjaro.

A moins que j'ai raté quelque chose, Timeshift ne garantit pas de pouvoir revenir en arrière.
En effet, on fait un snapshot de @/ avant une mise à jour. Puis on fait la mise à jour. Un éventuel problème peut être visible de suite, auquel cas on demande à Timeshift de restaurer les snapshot que l'on vient de faire et on reboote (la restauration implique un reboot pour être effective). Tout va bien.

Mais le problème peut aussi ne se révéler que lorsqu'on reboote le système après une mise à jour et que ça plante avant d'arriver sur le bureau => impossible de demander une restauration à Timeshift. Il faut se débrouiller avec les moyens habituels (pas forcément à la portée de Mr Michu).

C'est là qu'intervient btrfs-grub : il créé automatiquement une entrée dans grub pour chaque nouveau snapshot de @/. Du coup, si ça plante au redémarrage après la mise à jour, il suffit de choisir un des snapshots existants via une des entrées de grub.

Du coup, je n'utilise Timeshift que comme une UI pour créer un snapshot, les lister ou en supprimer, jamais pour en restaurer un.

Pour ce qui est de btrfs, je m'y suis mis moi aussi, y compris pour les données (en raid 1) et pour le moment j'en suis satisfait.

Je comprends bien qu'en réalité, tu as voulu dire "il faudrait que les applications XMPP existantes soient aussi simples à utiliser que Whatsapp" mais c'est de nature à induire en erreur Mamie Janine si elle venait à s'égarer par ici.

Par ailleurs, le titre laisse aussi entendre que l'interface de Whatsapp est mieux puisque plus facile à utiliser. En réalité, c'est au prix d'un gros bémol pas forcément acceptable par tous (la transmission automatique des contacts) que ce mieux est possible.

Un titre plus exact aurait pu être : "Acceptons de perdre un peu de notre privacité - et celles de nos amis qui n'ont rien demandé - afin d'avoir des messageries xmpp aussi faciles à utiliser que Whatsapp.

Après, l'article lui-même ne pose pas de problème, il explicite tout comme il faut.

Pour ce qui est de se servir des contacts pour établir automatiquement la liste des contacts tout en restant éthique j'ai la solution : il faut juste une déclaration sur l'honneur : "Si moi, sous-signé Whatsapp (par exemple), détecte qu'un contact de la liste est déjà dans ma base d'utilisateurs alors je l'utilise sinon je le jette, je l'oublie, c'est comme si ne l'avais jamais vu promis juré".

Simple, non ?
Mais juste pas crédible.

Il faut un disque dans chaque maison. Donc la solution avec deux maisons est plus chère.

Tu as raison, je vais m'en tenir à une seule maison, j'ai pas le budget pour deux disques.