Tu fais de la rhétorique (d'autres ici aussi). Backup, sauvegarde, bon/mauvais,…
Des noms, des noms ! ;-)
Je me fous de savoir le nom qu'il faut donner aux choses, ça n'est pas très intéressant. Ce qu'il faut savoir c'est quelle sécurité, tu as pour tes données. Pour cela il faut que tu évalue d'une part les risques et d'autre part l'importance de tes données.
Tu veux plutôt dire « Ce qu'il faut savoir c'est quel niveau de sécurité tu veux pour tes données » ?
Dans ce cas, oui c'est une évidence mais je suis d'accord avec ton affirmation.
Ta copie locale te donne une sécurité très faible. Elle protège des erreurs de manipulation, mais d'aucun problème technique (fs corrompu, disque qui meurt,…), d'aucun problème extérieur (vol du matériel) ni d'aucune attaque (ransomeware).
Oui tout à fait (encore que bon avec Btrfs/RAID1 je suis protégé en théorie contre le disque qui meurt ou les données qui deviennent corrompues).
Mais il faut bien comprendre que la sauvegarde locale ne peut être envisagée qu'à condition que l'on dispose d'une sauvegarde distante.
Ce sont à peu de choses près les mêmes problématiques qu'un dépôt local vs dépôt distant dans le cas de la gestion de versions : on peut avoir seulement un dépôt distant (CVS) ou un dépôt local et un dépôt distant (Git), mais pas juste son propre dépôt local (enfin si juste pour jouer ou expérimenter).
Si tu es le seul à pouvoir évaluer l'importance de tes données, ce que je vois généralement c'est une grosse différence de comportement entre ceux qui ont confiance en leur disque (souvent ils n'ont jamais eu de problème avec) et ceux qui ne leur font pas confiance (généralement ils t'expliquent comment ils ont déjà perdu des données).
Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
Bref l'importance c'est de comprendre ce que protège ta méthode et d'évaluer la réalité des risques (est-ce que tu risque le vol ? est-ce que ton disque va mourir ?…).
Au risque de me répéter, mon approche combine une sauvegarde locale et une sauvegarde distante. Donc pour le vol et le disque qui meurt, c'est couvert.
La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi. Tout comme le fait de travailler avec un dépôt local au lieu de juste un dépôt distant. Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Si les données étaient critiques, je synchroniserais tous les soir. Comme elles ne changent pas tant que ça et qu'elles ne sont pas si importante que cela, je synchronise tous les mois environ (ou juste après un changement important).
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ?
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
Je ne sais pas si tu fais exprès ? Il suffit de remonter quelques lignes plus haut et de voir ce que j'ai écris :
Pour la corruption des données, je pense justement que mon approche est peut-être plus saine car je suis en RAID1 avec Btrfs, donc les corruptions de données peuvent être détectées et corrigées.
Cela ne signifie pas du tout que j'utilise mon RAID1 comme backup ! Cela signifie juste que cela me protège contre les données corrompues (bit rot par exemple).
Un RAID1 cela ne protège certainement pas contre les "rm -rf" ou "dd /dev/sd0" (i.e. les erreurs utilisateurs).
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog.
Ca n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
Tu n'as pas cherché à comprendre mon explication qui démontre qu'un fichier corrompu (sur ton disque dur d'origine) n'est pas forcément détecté par ton système et peut par la suite remplacer tes sauvegardes.
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
Désolé mais tu mélanges tout (copie online/DSCM/cow/btrfs/raid/whatever).
Je tente une dernière fois :
1. gestion de versions et sauvegarde de données me semble très similaire
2. je me suis inspiré de la gestion de version décentralisée, pour élaborer ma stratégie de sauvegarde : local et distant
3. Btrfs est anecdotiquement utilisé pour faire la sauvegarde locale (snapshot) mais j'aurais pu utiliser un bête "cp" et le résultat aurait été le même
4. Btrfs/RAID1 est anecdotiquement utilisé pour détecter/corriger les données corrompues (bit rot), c'est juste un bonus qui ne change pas grand chose à ma stratégie
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
C'est ta propre définition de la notion de sauvegarde, Wikipedia (en particulier la définition anglaise) donne une autre vision (que je partage, mais c'est mon avis).
Ce serait comme dire qu'un dépôt local ne sert à rien dans le cas de la gestion de version distribuée.
Tu ne protèges pas du tout de la même chose avec un DSCM et avec une sauvegarde.
Ce n'était pas l'objet de ma remarque (homme de paille ou mauvaise compréhension ?).
Je disais que dire qu'une sauvegarde « locale » est complètement inutile par rapport à une sauvegarde « distante » c'est comme dire qu'un dépôt « local » est complètement inutile par rapport à un dépôt « distant ». C'est ton avis extrême que je critiquais.
L'objet de la remarque n'est pas du tout de comparer l'avantage d'utiliser git comme outil de sauvegarde (ce qui est un tout autre sujet).
Pour moi la sauvegarde « locale » ne permet absolument pas de se passer de la sauvegarde « distante », mais elle me rend bien service et me sert régulièrement pour récupérer mes sauvegardes en cas d'accidents.
De même mes dépôts locaux me sont bien utiles mais ne permettent pas de se passer d'un dépôt « distant ».
Donc dire que cette sauvegarde « locale » ne protège de rien n'est absolument pas vrai dans mon cas.
Mon approche va même plus loin, car comme je l'expliquais, les données et les sauvegardes pointent sur le même espace disque (snapshot/CoW) !
Ce qui est pire que tout.
Tu as le moindre problème externe, tu as tout perdu.
Encore une déclaration extrême… On va vite arrêter la discussion si cela continue comme cela.
Ce qui est pire que tout c'est de ne pas avoir de sauvegarde du tout, le fait de copier localement (même maladroitement) les données c'est déjà mieux que rien.
Et oui je suis conscient que si j'ai un problème externe je perds tout. Tout comme un développeur qui travaille sur son dépôt local perd tout s'il n'a pas synchronisé sur le serveur distant.
Je ne connais que trop de gens qui se croyaient à l’abris avec du RAID1. Faire du RAID, c’est très compliqué à faire proprement.
Par exemple si tu mets 2 disques issus du même fabriquant avec des numéros de série relativement proche, il y a de très grandes chances que lors qu’un des disques sautera, la reconstruction achèvera le 2nd disque, qui aura grosso modo la même durée de vie.
Faire du RAID1 proprement, c’est acheter 2 disques de constructeurs différents, à 2 dates relativement éloignées (plusieurs mois, les composants physiques étant presque tous fabriqués au même endroit, quelque soit le fabriquant).
Sans parler que btrfs et RAID ne te protègeront pas d’un « rm -rf / » ou d’un dd foireux.
Le RAID, c’est comme les DCSM, ça n’est pas une solution de backup.
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ? La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Il n'est pas là du tout pour servir de sauvegarde.
Les corruptions de données ne sont pas silencieuses avec des backups.
Des backups, ça se teste régulièrement. L’état SMART des disques est à vérifier régulièrement. fsck à passer régulièrement.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog. Les fichiers deviennent corrompus et peuvent écraser la bonne version qui était dans les sauvegardes lors de la prochaine sauvegarde complète (cela m'est arrivé, c'était un mauvais câble du disque dur qui était en cause).
Et encore une fois, btrfs/raid ne te protège pas des « corruptions » logicielles (rm -rf, dd…)
Encore une fois btrfs/raid est là uniquement pour la corruption des données et le bit rot. Je n'ai jamais dit qu'il était là pour protéger mon rm -rf.
J'ai un peu l'impression que tu te braques sur certains mots-clés après avoir lu en diagonal sans chercher à comprendre ce que je cherchais à exprimer ?
Quelqu'un d'autre peut confirmer si je me suis bien exprimé ou bien c'est à moi de m'exprimer plus clairement ?
Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
C’est tout sauf dépasser.
Pardon je me suis mal exprimé, ce qui je pense est dépassé c'est que seul une sauvegarde distante peut être considérée comme une « bonne » sauvegarde (ou une sauvegarde tout court)
Le problème de la « sauvegarde » locale, c’est qu’elle ne protège que de peu de choses. En fait de rien du tout généralement.
Là c'est un point de vue extrême que je ne partage pas du tout.
Ce serait comme dire qu'un dépôt local ne sert à rien dans le cas de la gestion de version distribuée.
Si tes données sont au même endroit que tes « sauvegardes » (en tout cas sur le même disque physique), alors il y a un risque plus que non négligeable qu’en cas de corruption des données, ta « sauvegarde » le soit aussi.
Mon approche va même plus loin, car comme je l'expliquais, les données et les sauvegardes pointent sur le même espace disque (snapshot/CoW) !
Pour la corruption des données, je pense justement que mon approche est peut-être plus saine car je suis en RAID1 avec Btrfs, donc les corruptions de données peuvent être détectées et corrigées.
Ce qui ne serait pas le cas dans le cas d'une approche traditionnelle où j'ai simplement un disque contenant les données et un disque externe pour contenir la sauvegarde des données (parce que dans ce cas là les corruptions de données sont silencieuses).
Mais effectivement je conçois que le risque est plus grand de perdre les données ET la sauvegarde en même temps lorsque c'est sur la même machine (si la carte mère est défaillante par exemple). C'est ensuite à moi de mesurer le risque par rapport aux bénéfices.
Un rm foireux, un disque qui claque sans crier gare, une mauvaise manip pour flasher une clef USB (que celui qui n’a jamais confondu deux /dev/sdx lors d’un dd lève la main) ou un cryptolocker qui passe, et c’est le drame à la fois pour les données et la « sauvegarde » locale. Ce n’est donc pas (en tout cas pour ma part) une sauvegarde viable, tout au plus un cache temporaire.
Bien ! tu as le même point de vue que la personne avec qui j'avais discuté (i.e. la sauvegarde locale n'est pas une sauvegarde). J'espère que l'on pourra avoir une discussion posée…
Une sauvegarde, c’est pour moi une copie des données dont la probabilité d’être impactée en cas de soucis sur les données d’origine est plus que très faible voire si possible nulle.
C'est ta définition de la sauvegarde. Mais ce n'est certainement pas celle qui est officielle (voir wikipedia par exemple). De mémoire il n'est nul part indiqué où doivent se trouver les données sauvegardées (répertoire à part ? partition à part ? disque à part dans l'ordinateur ? disque externe ? disque distant ?).
Oui c'est moi aussi qui aie posté l'entrée dans le forum ! ;-)
J'essaye de comprendre pourquoi ma question/solution provoque de telle réaction (et surtout si mon approche calquée sur de la gestion de version distribuée) tient la route.
On en est encore là ?
Sauf à considérer que tes données n'ont aucune importance
il faut une sauvegarde distante
C'est exactement le genre de réaction épidermique, ou du moins très tranchée que j'obtiens quand je parle de ce sujet. C'est parfois difficile d'avoir une argumentation posée dans ce cas là, ce qui est dommage.
Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
Tout comme la gestion de version distribuée a apporté la notion de dépôt local, il me semble tout à fait concevable d'avoir la notion de sauvegarde locale. Les avantages, défauts et risques me semblent exactement les mêmes.
Est-ce que aujourd'hui il y a encore quelqu'un qui conteste qu'un dépôt local est bien un dépôt ?
Pourtant on trouve des gens pour dire qu'une sauvegarde locale n'est pas vraiment une sauvegarde.
Note que je synchronise bien ma sauvegarde locale vers ma sauvegarde distante (tout comme on doit synchroniser son dépôt local vers son dépôt distant de temps en temps).
Mon évaluation des risques me laisse à penser que faire une synchronisation vers ma sauvegarde distante tous les jours est un peu « overkill ». Et mes données n'ont pas « aucune » importance car j'y tiens, mais j'accepte par exemple de perdre les photos du dernier WE entre potes (et encore il y a toujours des moyens de récupérer) dans le cas improbable (cf. statistiques de ma région) où je me fais cambrioler.
Bien entendu si j'ai des photos d'un mariage ou d'une naissance, il suffit de déclencher la synchronisation juste après l’événement et c'est réglé.
À mon avis, parler de « bonne » ou « mauvaise » sauvegarde créé une fausse dichotomie car la notion de « bon » ou « mauvais » est très subjectif et dépend beaucoup de l'évaluation des risques.
Il y a beaucoup de manières différentes de faire une sauvegarde et c'est toujours un compromis entre l'effort investi et le résultat obtenu.
Dans mon cas d'utilisation, je considère ma méthode comme une approche de gestion de version distribuée. Je suis conscient des risques d'avoir un dépôt local, donc je synchronise de temps en temps vers un dépôt distant.
En pratique au niveau de la gestion de version, je n'ai jamais corrompu/perdu de dépôt local. Idem pour ma sauvegarde locale.
Peut-être que je suis uniquement chanceux ? C'est pour cela que je demande votre avis.
Il n'y a pas de réponse binaire à cette problématique. Cela dépend de chacun et de son évaluation des risques.
Pour moi cela m'arrive très rarement de faire une erreur et j'ai assez de moyens de récupérer ce que j'ai perdu (gestion de version, backup, photorec, etc.).
J'ai juste besoin de protéger "rm *" car c'est ce qui m'arrive le plus souvent car j'ai de gros doigts… ;-)
Oui j'avais utilisé ce genre de commande auparavant mais je trouve qu'il y a plus d'inconvénients que d'avantages.
Je préfère ne pas avoir de corbeille et récupérer les fichiers manuellement au cas où (backup, git, photorec ou autre).
Jusqu'ici cela a été assez rare et j'ai toujours réussi à retrouver les fichiers.
J'avais un peu peur des effets de bord, mais je vais voir si je peux adapter le script pour avoir une confirmation (au lieu de simplement refuser la commande).
Ah bah j'ai fini par trouver tout seul.
J'ai confondu le rapport agrégé et le rapport légiste. Le rapport agrégé est envoyé tout le temps alors que le rapport légiste peut n'être envoyé qu'en cas d'erreur…
Ouep je suis fait avoir. Mais bon c'est juste un coup à prendre avec cette interface je suppose.
À part le fait que j'étais pas vraiment réveillé, les frais et le taux de change sont assez clairs je trouve.
Ah mince en effet je suis allé trop vite et j'avais pris la ligne du haut chez WorldRemit sans les frais.
Et pour TransferWise, j'avais sélectionné des des GBP par erreur.
Je ne devais vraiment pas être réveillé…
Bon j'ai re-testé en faisant attention et effectivement TransferWise est légèrement plus avantageux la plupart du temps sauf dans des cas particuliers (Afrique du Sud dans mon exemple plus haut par exemple). Ils ont dû ajuster les frais, car on avait fait le test avec mon ami et c'était différent il y 1-2 ans.
Là où WorldRemit est un peu différent, c'est que tu peux envoyer vers un compte bancaire, ou du liquide directement (le destinataire n'a pas besoin de compte bancaire) ou du crédit mobile (Mobile Money Transfer et Airtime). Par exemple vers le Cameroun, tu as toutes les options d'envoi.
Du coup si tu envois du liquide, apparemment c'est vraiment instantané (un peu comme Wester Union par exemple).
Mais bon dans le cas de ton entreprise, pour l'instant il n'y a pas photo, TransferWise est plus adapté.
J'ai testé au pif de District of Columbia, et aujourd'hui c'est $1075.93 pour recevoir 1000 €, alors que Transferwise c'est $1251.50.
Pareil de la Floride.
Si j'envoie 1000 € en Afrique du Sud, j'obtiens aussi 13816 ZAR, alors qu'avec Transferwise c'est 13590 ZAR.
De plus à vue d'oeil WorldRemit a plus de pays/devises à disposition.
Mais comme je l'ai dit, c'est dans certaines situation seulement. Le taux de change et les frais fixes sont différents entre les deux services, donc il faut voir au cas par cas.
J'approuve pour TransferWise, je l'utilise depuis un moment pour des sommes entre 1000 et 5000 euros et cela marche impeccablement.
J'ai eu un soucis une fois et j'ai eu au téléphone quelqu'un de très aimable directement. C'est vraiment appréciable.
Un ami utilise aussi WorldRemit et cela semble plus intéressant dans certaines conditions (par example avec WorldRemit il faut envoyer $1077,70 pour avoir 1000 euros, alors que TransferWise c'est $1259,11). Par contre j'ai pas testé…
Tout d'abord merci pour tes réponses sur Darktable FR. J'ai vu passer tes messages mais je n'ai pas encore eu le temps de m'y pencher.
C'est avec grand plaisir que je retournerai sous Darktable si je pouvais arriver à faire ce que je pouvais.
L'analogie est pertinente (j'avais fait de même d'ailleurs plus haut). Au début il fallait bien choisir son ordinateur et ses périphériques pour pouvoir utiliser linux sans trop de soucis.
Cependant j'ai toujours poussé à l'adoption du logiciel libre et je suis le premier à contribuer quand je peux. Cela me prend beaucoup de temps et d'énergie mais c'est une juste contrepartie.
En ce qui concerne Darktable et Lensfun, de mémoire je suis allé photographier des bâtiments (avec ensuite le long traitement sous Hugin) pour faire entrer le Canon S95 dans lensfun, j'ai tenté de générer de nouvelles courbes de base pour mon Nikon (méthode de l'analyse des JPEG du boîtier, et ensuite de la cible IT8), des nouveaux profils de couleurs en entrée pour le Nikon et un profil de bruit pour le NX1. J'ai aussi sur ma liste de faire entre mon objectif Samsung dans lensfun.
Donc j'ai vraiment essayé de surmonter les difficultés et de contribuer à ces logiciels.
J'ai testé rapidement la V2.2, mais je n'ai pas noté d'amélioration visible pour mon utilisation. Ce qui est normal, car la plus grosse amélioration serait sur ces fameuses courbes de base. Et cela on ne peut pas le modifier à la légère.
Ah bah désolé si j'ai froissé certaines personnes (surtout les développeurs car j'aime bien Darktable malgré mes échecs).
Mais je pense sérieusement que d'un point de vue débutant, avoir des couleurs correctes, une bonne réduction de bruit et un traitement des ombres / hautes lumières est beaucoup plus facile sous Lightroom.
Pour avoir la même chose simplement sous Darktable, de mémoire il faut que l'objectif soit correctement supporté par lensfun, que le boîtier soit dans la base lensfun, qu'une courbe de base soit disponible dans Darktable (et qu'elle fonctionne sans besoin de retouche pour tous les types de situation) et qu'un profil de bruit ait été réalisé pour le boîtier.
Sous Debian Stable, le D7200 n'est pas reconnu, le NX1 n'a pas de profil de bruit, l'objectif Samsung 16-50 S n'est pas dans lensfun, la courbe de base Samsung a des couleurs délirantes et la courbe de base Nikon ne marche pas bien dans tous les cas (high iso par exemple).
Je n'ai peut-être pas eu de chance ? En tout cas pour Nikon je ne suis pas le seul à m'être cassé les dents. Et sur la mailing-list, lorsque l'on a abordé le problème encore récemment, il n'y a pas beaucoup de possesseurs de Nikon qui se sont manifestés pour dire que cela marchait parfaitement et simplement pour eux…
Insultant ? Tu plaisantes ?
J'ai des couleurs/bruits bizarres sur des photos et malgré toute l'aide que j'ai pu trouver la solution c'est soi de retoucher individuellement chaque photos ou bien de réaliser une nouvelle courbe de base ou un nouveau profil de bruit.
Pardon d'oser annoncer que ce n'est peut-être pas à la portée d'un débutant ou amateur s'il tombe sur ce genre de problème.
Pour la balance des blancs, je voulais dire la couleur finale obtenue. Comme j'ai l'original sous les yeux, je peux affirmer que Lightroom respecte mieux les couleurs.
Pour le bruit, j'ai eu le même genre de remarque/excuse sur la mailing-list mais personne n'a réussi par la suite à avoir une réduction de bruit qui soit aussi bien que celle de Lightroom.
Sur les photos en extérieur avec le Nikon j'ai eu moins de soucis. Par contre en intérieur, Darktable me donnait presque 20% de couleurs bizarres. Au final je passais trop de temps à réparer les dégâts. Et ce n'est pas que moi encore une fois, voir les liens plus haut.
C'est peut-être là que cela coince. Pour moi il n'y a pas photos, le résultat avec Lightroom est de très loin supérieur.
Pour moi, aussi bien au niveau de la réduction du bruit, de la balance des blancs et des artefacts de couleur (des sortes de traits/nuages jaunâtre sur la peau), Lightroom est bien plus pertinent (pour la balance des blancs il faudra me croire sur parole vu que j'ai l'original devant mes yeux !).
Je dois dire que je ne comprends comment tu as autant de problèmes.
Mes boîtiers en général comme ils ne sont pas très grand public (Nikon D4s et D5) Je fais mes profils moi-même.
Je n'en fais qu'un pour une photo générale et en général elle convient à une majorité de photos je n'ai rien à faire même pas choisir un profil puisqu'il est là par défaut.
Tu peux constater que je n'ai pas ménagé mes efforts pour que cela marche (et que je ne suis pas le seul à galérer avec Nikon). Le consensus obtenu (voir les réponses) c'est qu'il faut raisonner par catégorie d'image (plein jour, intérieur, lumière artificielle, etc.). C'est ce que fait le constructeur du boîtier apparemment.
Les profil bruit intégré sont ultra simple à utiliser il suffit de l'activer si ton boîtier est reconnu et à un profil.
Là aussi tu peux constater que j'ai persévéré !
Et la réduction de bruit "profil" sous Darktable est tout sauf ultra-simple à utiliser (wavelet, non-local means, uniforme/luminosité, uniforme/couleur, opacité, etc.). En comparaison avec Lightroom (ou Rawtherapee), c'est vraiment la nuit et le jour.
Sans parler des 3-4 autres modules de traitement de bruit qui font plus ou moins la même chose…
Pour faire un profil plus pointu personnalisé il faut regarder les vidéos de Carafife car plusieurs modules entre en compte. > Mais encore une fois une fois que tu as fais ce travail c'est ensuite automatique via les réglages conditionnels il n'y a plus rien à faire quand tu importes tes photos elles sont automatiquement dé bruitées en fonction des isos utilisés.
En théorie oui, en pratique je n'ai pas réussi. Et pourtant j'ai vraiment essayé (de longues heures, pleins d'emails, du matériel acheté, etc.).
Je travaille tous les jours avec Darktable je suis photographe et donc j'ai des centaines de photos par jours ouvrables à travailler si c'était aussi compliqué que tu le dis il y a longtemps que je ne serais plus rentable ;)
Peut-être que ton appareil est bien supporté par Darktable ?
Moi je n'ai pas eu cette chance.
Et encore une fois mon cas est loin d'être isolé. Une simple recherche sur la mailing-list montre que pas mal de personnes se sont cassés les dents dessus aussi.
[^] # Re: Rhétorique
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 2.
Des noms, des noms ! ;-)
Tu veux plutôt dire « Ce qu'il faut savoir c'est quel niveau de sécurité tu veux pour tes données » ?
Dans ce cas, oui c'est une évidence mais je suis d'accord avec ton affirmation.
Oui tout à fait (encore que bon avec Btrfs/RAID1 je suis protégé en théorie contre le disque qui meurt ou les données qui deviennent corrompues).
Mais il faut bien comprendre que la sauvegarde locale ne peut être envisagée qu'à condition que l'on dispose d'une sauvegarde distante.
Ce sont à peu de choses près les mêmes problématiques qu'un dépôt local vs dépôt distant dans le cas de la gestion de versions : on peut avoir seulement un dépôt distant (CVS) ou un dépôt local et un dépôt distant (Git), mais pas juste son propre dépôt local (enfin si juste pour jouer ou expérimenter).
Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
Au risque de me répéter, mon approche combine une sauvegarde locale et une sauvegarde distante. Donc pour le vol et le disque qui meurt, c'est couvert.
La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi. Tout comme le fait de travailler avec un dépôt local au lieu de juste un dépôt distant. Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Si les données étaient critiques, je synchroniserais tous les soir. Comme elles ne changent pas tant que ça et qu'elles ne sont pas si importante que cela, je synchronise tous les mois environ (ou juste après un changement important).
[^] # Re: On en est encore là ?
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
Je ne sais pas si tu fais exprès ? Il suffit de remonter quelques lignes plus haut et de voir ce que j'ai écris :
Cela ne signifie pas du tout que j'utilise mon RAID1 comme backup ! Cela signifie juste que cela me protège contre les données corrompues (bit rot par exemple).
Un RAID1 cela ne protège certainement pas contre les "rm -rf" ou "dd /dev/sd0" (i.e. les erreurs utilisateurs).
Là tu perds un peu en crédibilité. Un petit article pour t'aider à comprendre :
https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/
Tu n'as pas cherché à comprendre mon explication qui démontre qu'un fichier corrompu (sur ton disque dur d'origine) n'est pas forcément détecté par ton système et peut par la suite remplacer tes sauvegardes.
Désolé mais tu mélanges tout (copie online/DSCM/cow/btrfs/raid/whatever).
Je tente une dernière fois :
1. gestion de versions et sauvegarde de données me semble très similaire
2. je me suis inspiré de la gestion de version décentralisée, pour élaborer ma stratégie de sauvegarde : local et distant
3. Btrfs est anecdotiquement utilisé pour faire la sauvegarde locale (snapshot) mais j'aurais pu utiliser un bête "cp" et le résultat aurait été le même
4. Btrfs/RAID1 est anecdotiquement utilisé pour détecter/corriger les données corrompues (bit rot), c'est juste un bonus qui ne change pas grand chose à ma stratégie
C'est ta propre définition de la notion de sauvegarde, Wikipedia (en particulier la définition anglaise) donne une autre vision (que je partage, mais c'est mon avis).
[^] # Re: On en est encore là ?
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Ce n'était pas l'objet de ma remarque (homme de paille ou mauvaise compréhension ?).
Je disais que dire qu'une sauvegarde « locale » est complètement inutile par rapport à une sauvegarde « distante » c'est comme dire qu'un dépôt « local » est complètement inutile par rapport à un dépôt « distant ». C'est ton avis extrême que je critiquais.
L'objet de la remarque n'est pas du tout de comparer l'avantage d'utiliser git comme outil de sauvegarde (ce qui est un tout autre sujet).
Pour moi la sauvegarde « locale » ne permet absolument pas de se passer de la sauvegarde « distante », mais elle me rend bien service et me sert régulièrement pour récupérer mes sauvegardes en cas d'accidents.
De même mes dépôts locaux me sont bien utiles mais ne permettent pas de se passer d'un dépôt « distant ».
Donc dire que cette sauvegarde « locale » ne protège de rien n'est absolument pas vrai dans mon cas.
Encore une déclaration extrême… On va vite arrêter la discussion si cela continue comme cela.
Ce qui est pire que tout c'est de ne pas avoir de sauvegarde du tout, le fait de copier localement (même maladroitement) les données c'est déjà mieux que rien.
Et oui je suis conscient que si j'ai un problème externe je perds tout. Tout comme un développeur qui travaille sur son dépôt local perd tout s'il n'a pas synchronisé sur le serveur distant.
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ? La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Il n'est pas là du tout pour servir de sauvegarde.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog. Les fichiers deviennent corrompus et peuvent écraser la bonne version qui était dans les sauvegardes lors de la prochaine sauvegarde complète (cela m'est arrivé, c'était un mauvais câble du disque dur qui était en cause).
Encore une fois btrfs/raid est là uniquement pour la corruption des données et le bit rot. Je n'ai jamais dit qu'il était là pour protéger mon rm -rf.
J'ai un peu l'impression que tu te braques sur certains mots-clés après avoir lu en diagonal sans chercher à comprendre ce que je cherchais à exprimer ?
Quelqu'un d'autre peut confirmer si je me suis bien exprimé ou bien c'est à moi de m'exprimer plus clairement ?
[^] # Re: On en est encore là ?
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Pardon je me suis mal exprimé, ce qui je pense est dépassé c'est que seul une sauvegarde distante peut être considérée comme une « bonne » sauvegarde (ou une sauvegarde tout court)
Là c'est un point de vue extrême que je ne partage pas du tout.
Ce serait comme dire qu'un dépôt local ne sert à rien dans le cas de la gestion de version distribuée.
Mon approche va même plus loin, car comme je l'expliquais, les données et les sauvegardes pointent sur le même espace disque (snapshot/CoW) !
Pour la corruption des données, je pense justement que mon approche est peut-être plus saine car je suis en RAID1 avec Btrfs, donc les corruptions de données peuvent être détectées et corrigées.
Ce qui ne serait pas le cas dans le cas d'une approche traditionnelle où j'ai simplement un disque contenant les données et un disque externe pour contenir la sauvegarde des données (parce que dans ce cas là les corruptions de données sont silencieuses).
Mais effectivement je conçois que le risque est plus grand de perdre les données ET la sauvegarde en même temps lorsque c'est sur la même machine (si la carte mère est défaillante par exemple). C'est ensuite à moi de mesurer le risque par rapport aux bénéfices.
Bien ! tu as le même point de vue que la personne avec qui j'avais discuté (i.e. la sauvegarde locale n'est pas une sauvegarde). J'espère que l'on pourra avoir une discussion posée…
C'est ta définition de la sauvegarde. Mais ce n'est certainement pas celle qui est officielle (voir wikipedia par exemple). De mémoire il n'est nul part indiqué où doivent se trouver les données sauvegardées (répertoire à part ? partition à part ? disque à part dans l'ordinateur ? disque externe ? disque distant ?).
[^] # Re: Titre
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Oui c'est moi aussi qui aie posté l'entrée dans le forum ! ;-)
J'essaye de comprendre pourquoi ma question/solution provoque de telle réaction (et surtout si mon approche calquée sur de la gestion de version distribuée) tient la route.
[^] # Re: la plupart du temps je sais ce que je fais…
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 1. Dernière modification le 17 juin 2017 à 18:03.
Btrfs n'est pas un FS moderne ?
Chercher btrfs-undelete qui marche ma foi très bien…
[^] # Re: On en est encore là ?
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
C'est exactement le genre de réaction épidermique, ou du moins très tranchée que j'obtiens quand je parle de ce sujet. C'est parfois difficile d'avoir une argumentation posée dans ce cas là, ce qui est dommage.
Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
Tout comme la gestion de version distribuée a apporté la notion de dépôt local, il me semble tout à fait concevable d'avoir la notion de sauvegarde locale. Les avantages, défauts et risques me semblent exactement les mêmes.
Est-ce que aujourd'hui il y a encore quelqu'un qui conteste qu'un dépôt local est bien un dépôt ?
Pourtant on trouve des gens pour dire qu'une sauvegarde locale n'est pas vraiment une sauvegarde.
Note que je synchronise bien ma sauvegarde locale vers ma sauvegarde distante (tout comme on doit synchroniser son dépôt local vers son dépôt distant de temps en temps).
Mon évaluation des risques me laisse à penser que faire une synchronisation vers ma sauvegarde distante tous les jours est un peu « overkill ». Et mes données n'ont pas « aucune » importance car j'y tiens, mais j'accepte par exemple de perdre les photos du dernier WE entre potes (et encore il y a toujours des moyens de récupérer) dans le cas improbable (cf. statistiques de ma région) où je me fais cambrioler.
Bien entendu si j'ai des photos d'un mariage ou d'une naissance, il suffit de déclencher la synchronisation juste après l’événement et c'est réglé.
[^] # Re: Titre
Posté par SaintGermain . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
Merci pour ton avis.
À mon avis, parler de « bonne » ou « mauvaise » sauvegarde créé une fausse dichotomie car la notion de « bon » ou « mauvais » est très subjectif et dépend beaucoup de l'évaluation des risques.
Il y a beaucoup de manières différentes de faire une sauvegarde et c'est toujours un compromis entre l'effort investi et le résultat obtenu.
Dans mon cas d'utilisation, je considère ma méthode comme une approche de gestion de version distribuée. Je suis conscient des risques d'avoir un dépôt local, donc je synchronise de temps en temps vers un dépôt distant.
En pratique au niveau de la gestion de version, je n'ai jamais corrompu/perdu de dépôt local. Idem pour ma sauvegarde locale.
Peut-être que je suis uniquement chanceux ? C'est pour cela que je demande votre avis.
[^] # Re: la plupart du temps je sais ce que je fais…
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 1.
Si tu n'as pas eu le temps de faire un commit ou une sauvegarde, un utilitaire de 'undelete' cela marche très bien aussi.
[^] # Re: la plupart du temps je sais ce que je fais…
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 1.
Il n'y a pas de réponse binaire à cette problématique. Cela dépend de chacun et de son évaluation des risques.
Pour moi cela m'arrive très rarement de faire une erreur et j'ai assez de moyens de récupérer ce que j'ai perdu (gestion de version, backup, photorec, etc.).
J'ai juste besoin de protéger "rm *" car c'est ce qui m'arrive le plus souvent car j'ai de gros doigts… ;-)
[^] # Re: Moins geek...
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 1.
Oui j'avais utilisé ce genre de commande auparavant mais je trouve qu'il y a plus d'inconvénients que d'avantages.
Je préfère ne pas avoir de corbeille et récupérer les fichiers manuellement au cas où (backup, git, photorec ou autre).
Jusqu'ici cela a été assez rare et j'ai toujours réussi à retrouver les fichiers.
[^] # Re: alias rm=rm -i
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 1.
J'avais un peu peur des effets de bord, mais je vais voir si je peux adapter le script pour avoir une confirmation (au lieu de simplement refuser la commande).
Merci
[^] # Re: alias rm=rm -i
Posté par SaintGermain . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 4.
Merci pour ton avis.
Mais est-ce qu'une astuce de ce genre là ne peut pas marcher :
https://superuser.com/questions/864478/prevent-user-typing-accidental-space-between-rm-and-wildcard/864704#864704
# Résolu !
Posté par SaintGermain . En réponse au message email avec DMARC et les rapports. Évalué à 2.
Ah bah j'ai fini par trouver tout seul.
J'ai confondu le rapport agrégé et le rapport légiste. Le rapport agrégé est envoyé tout le temps alors que le rapport légiste peut n'être envoyé qu'en cas d'erreur…
[^] # Re: TransferWise c'est bien, mangez-en
Posté par SaintGermain . En réponse au journal [HS] Etude de cas : TPE internationale et frais bancaires. Évalué à 1.
Ouep je suis fait avoir. Mais bon c'est juste un coup à prendre avec cette interface je suppose.
À part le fait que j'étais pas vraiment réveillé, les frais et le taux de change sont assez clairs je trouve.
[^] # Re: TransferWise c'est bien, mangez-en
Posté par SaintGermain . En réponse au journal [HS] Etude de cas : TPE internationale et frais bancaires. Évalué à 2.
Ah mince en effet je suis allé trop vite et j'avais pris la ligne du haut chez WorldRemit sans les frais.
Et pour TransferWise, j'avais sélectionné des des GBP par erreur.
Je ne devais vraiment pas être réveillé…
Bon j'ai re-testé en faisant attention et effectivement TransferWise est légèrement plus avantageux la plupart du temps sauf dans des cas particuliers (Afrique du Sud dans mon exemple plus haut par exemple). Ils ont dû ajuster les frais, car on avait fait le test avec mon ami et c'était différent il y 1-2 ans.
Là où WorldRemit est un peu différent, c'est que tu peux envoyer vers un compte bancaire, ou du liquide directement (le destinataire n'a pas besoin de compte bancaire) ou du crédit mobile (Mobile Money Transfer et Airtime). Par exemple vers le Cameroun, tu as toutes les options d'envoi.
Du coup si tu envois du liquide, apparemment c'est vraiment instantané (un peu comme Wester Union par exemple).
Mais bon dans le cas de ton entreprise, pour l'instant il n'y a pas photo, TransferWise est plus adapté.
[^] # Re: TransferWise c'est bien, mangez-en
Posté par SaintGermain . En réponse au journal [HS] Etude de cas : TPE internationale et frais bancaires. Évalué à 1.
J'ai testé au pif de District of Columbia, et aujourd'hui c'est $1075.93 pour recevoir 1000 €, alors que Transferwise c'est $1251.50.
Pareil de la Floride.
Si j'envoie 1000 € en Afrique du Sud, j'obtiens aussi 13816 ZAR, alors qu'avec Transferwise c'est 13590 ZAR.
De plus à vue d'oeil WorldRemit a plus de pays/devises à disposition.
Mais comme je l'ai dit, c'est dans certaines situation seulement. Le taux de change et les frais fixes sont différents entre les deux services, donc il faut voir au cas par cas.
# TransferWise c'est bien, mangez-en
Posté par SaintGermain . En réponse au journal [HS] Etude de cas : TPE internationale et frais bancaires. Évalué à 4.
J'approuve pour TransferWise, je l'utilise depuis un moment pour des sommes entre 1000 et 5000 euros et cela marche impeccablement.
J'ai eu un soucis une fois et j'ai eu au téléphone quelqu'un de très aimable directement. C'est vraiment appréciable.
Un ami utilise aussi WorldRemit et cela semble plus intéressant dans certaines conditions (par example avec WorldRemit il faut envoyer $1077,70 pour avoir 1000 euros, alors que TransferWise c'est $1259,11). Par contre j'ai pas testé…
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
Tout d'abord merci pour tes réponses sur Darktable FR. J'ai vu passer tes messages mais je n'ai pas encore eu le temps de m'y pencher.
C'est avec grand plaisir que je retournerai sous Darktable si je pouvais arriver à faire ce que je pouvais.
L'analogie est pertinente (j'avais fait de même d'ailleurs plus haut). Au début il fallait bien choisir son ordinateur et ses périphériques pour pouvoir utiliser linux sans trop de soucis.
Cependant j'ai toujours poussé à l'adoption du logiciel libre et je suis le premier à contribuer quand je peux. Cela me prend beaucoup de temps et d'énergie mais c'est une juste contrepartie.
En ce qui concerne Darktable et Lensfun, de mémoire je suis allé photographier des bâtiments (avec ensuite le long traitement sous Hugin) pour faire entrer le Canon S95 dans lensfun, j'ai tenté de générer de nouvelles courbes de base pour mon Nikon (méthode de l'analyse des JPEG du boîtier, et ensuite de la cible IT8), des nouveaux profils de couleurs en entrée pour le Nikon et un profil de bruit pour le NX1. J'ai aussi sur ma liste de faire entre mon objectif Samsung dans lensfun.
Donc j'ai vraiment essayé de surmonter les difficultés et de contribuer à ces logiciels.
J'ai testé rapidement la V2.2, mais je n'ai pas noté d'amélioration visible pour mon utilisation. Ce qui est normal, car la plus grosse amélioration serait sur ces fameuses courbes de base. Et cela on ne peut pas le modifier à la légère.
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 2.
Oui c'est celle que j'utilisais.
J'ai aussi compilé la 2.2.0 pour tester, mais il n'y a pas d'amélioration pour mon utilisation.
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 2.
Ah bah désolé si j'ai froissé certaines personnes (surtout les développeurs car j'aime bien Darktable malgré mes échecs).
Mais je pense sérieusement que d'un point de vue débutant, avoir des couleurs correctes, une bonne réduction de bruit et un traitement des ombres / hautes lumières est beaucoup plus facile sous Lightroom.
Pour avoir la même chose simplement sous Darktable, de mémoire il faut que l'objectif soit correctement supporté par lensfun, que le boîtier soit dans la base lensfun, qu'une courbe de base soit disponible dans Darktable (et qu'elle fonctionne sans besoin de retouche pour tous les types de situation) et qu'un profil de bruit ait été réalisé pour le boîtier.
Sous Debian Stable, le D7200 n'est pas reconnu, le NX1 n'a pas de profil de bruit, l'objectif Samsung 16-50 S n'est pas dans lensfun, la courbe de base Samsung a des couleurs délirantes et la courbe de base Nikon ne marche pas bien dans tous les cas (high iso par exemple).
Je n'ai peut-être pas eu de chance ? En tout cas pour Nikon je ne suis pas le seul à m'être cassé les dents. Et sur la mailing-list, lorsque l'on a abordé le problème encore récemment, il n'y a pas beaucoup de possesseurs de Nikon qui se sont manifestés pour dire que cela marchait parfaitement et simplement pour eux…
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
Insultant ? Tu plaisantes ?
J'ai des couleurs/bruits bizarres sur des photos et malgré toute l'aide que j'ai pu trouver la solution c'est soi de retoucher individuellement chaque photos ou bien de réaliser une nouvelle courbe de base ou un nouveau profil de bruit.
Pardon d'oser annoncer que ce n'est peut-être pas à la portée d'un débutant ou amateur s'il tombe sur ce genre de problème.
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
Pour la balance des blancs, je voulais dire la couleur finale obtenue. Comme j'ai l'original sous les yeux, je peux affirmer que Lightroom respecte mieux les couleurs.
Pour le bruit, j'ai eu le même genre de remarque/excuse sur la mailing-list mais personne n'a réussi par la suite à avoir une réduction de bruit qui soit aussi bien que celle de Lightroom.
Sur les photos en extérieur avec le Nikon j'ai eu moins de soucis. Par contre en intérieur, Darktable me donnait presque 20% de couleurs bizarres. Au final je passais trop de temps à réparer les dégâts. Et ce n'est pas que moi encore une fois, voir les liens plus haut.
Pour les Samsung, c'est bien plus n'importe quoi.
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 1.
C'est peut-être là que cela coince. Pour moi il n'y a pas photos, le résultat avec Lightroom est de très loin supérieur.
Pour moi, aussi bien au niveau de la réduction du bruit, de la balance des blancs et des artefacts de couleur (des sortes de traits/nuages jaunâtre sur la peau), Lightroom est bien plus pertinent (pour la balance des blancs il faudra me croire sur parole vu que j'ai l'original devant mes yeux !).
Voici un petit zoom avec Lightroom à gauche et Darktable à droite :
https://filebin.net/rww7rp8yu3tov0zh
Chacun pourra juger comme cela.
À noter que j'ai eu ce résultat en moins de 10-15mn en partant d'absolument zéro avec Lightroom (jamais utilisé auparavant).
[^] # Re: Peut-être pas pour un amateur ?
Posté par SaintGermain . En réponse à la dépêche darktable 2.2.0. Évalué à 2.
Voici un petit historique de mes efforts :
- https://redmine.darktable.org/issues/11053
- https://darktable-fr.tuxfamily.org/forums/sujet/probleme-de-couleur-avec-nikon-d7200/
- https://www.mail-archive.com/darktable-user@lists.darktable.org/msg00662.html
- https://www.mail-archive.com/darktable-user@lists.darktable.org/msg00805.html
Tu peux constater que je n'ai pas ménagé mes efforts pour que cela marche (et que je ne suis pas le seul à galérer avec Nikon). Le consensus obtenu (voir les réponses) c'est qu'il faut raisonner par catégorie d'image (plein jour, intérieur, lumière artificielle, etc.). C'est ce que fait le constructeur du boîtier apparemment.
Cela dépend du résultat que tu veux obtenir.
Par exemple les fils de discussion récent que j'ai initié :
https://www.mail-archive.com/darktable-user@lists.darktable.org/msg01747.html
https://darktable-fr.tuxfamily.org/forums/sujet/balance-des-blancs-et-reduction-du-bruit-pour-un-samsung-nx1/
Là aussi tu peux constater que j'ai persévéré !
Et la réduction de bruit "profil" sous Darktable est tout sauf ultra-simple à utiliser (wavelet, non-local means, uniforme/luminosité, uniforme/couleur, opacité, etc.). En comparaison avec Lightroom (ou Rawtherapee), c'est vraiment la nuit et le jour.
Sans parler des 3-4 autres modules de traitement de bruit qui font plus ou moins la même chose…
En théorie oui, en pratique je n'ai pas réussi. Et pourtant j'ai vraiment essayé (de longues heures, pleins d'emails, du matériel acheté, etc.).
Peut-être que ton appareil est bien supporté par Darktable ?
Moi je n'ai pas eu cette chance.
Et encore une fois mon cas est loin d'être isolé. Une simple recherche sur la mailing-list montre que pas mal de personnes se sont cassés les dents dessus aussi.