Oui, aussi (d'où ma conclusion sur le fait que la seule vraie solution est de changer de matériel). Je citais le noyau car c'est du logiciel au même titre que l'application qui pose problème à l'auteur du journal, apporté par la même mise à jour. Donc avoir peur de l'application et pas du noyau est particulièrement paradoxal.
Euh, tu réalises que tu as sur ton téléphone un noyau fourni par ton constructeur. Côté permission, c'est autrement pire que tout ce que tu cites, le code qui tourne dans le noyau a accès à absolument tout sur ton téléphone. Est-ce que tu as pensé à désinstaller ton noyau ?
Le système de droit, c'est fait pour te permettre d'installer des applications venant de fournisseurs en qui tu as moyennement confiance seulement. Si tu n'a pas confiance en Samsung et que tu as un téléphone Samsung, la seule option que tu as est de changer de téléphone. Tout ce que tu peux faire d'autre ne pourra que te donner l'illusion de sécurité, mais ça ne changera strictement rien à ce que Samsung peut faire sur ton téléphone.
ce que j'aimerais c'est un système de publication géré par la communauté
OK, mais c'est totalement orthogonal au système d'archives ouvertes, et au fait que les publis soient accessibles ou non. Tu peux faire du peer-reviewé ou non sur une archive ouverte, tu peux avoir un éditeur privé qui fait de l'open access, … Si on invente un super nouveau système pour décider quelle publi est acceptée ou non, ça ne changera rien au fait que la publi puisse aller sur HAL.
Il commence à y avoir des labels gérés par des universitaires qui concurrencent les éditeurs classiques. En informatique, il y a ça par exemple : https://www.dagstuhl.de/publikationen/. Là, y'a un problème qu'une loi peut difficilement résoudre : les éditeurs « prestigieux » sont ceux qui sont privés et cher. Ceux qui sont les plus proches de mon sens de l'éthique n'ont pas (encore ?) la même renommée.
Je n'ai écrit nulle part que toutes les publis peer-reviewées étaient sur HAL. Seulement qu'une grande partie des publis qui sont sur HAL étaient peer-reviewées.
On est d'accord sur le fait qu'il y a de la marge de progression pour avoir plus de publis disponibles sur ces archives, ou plus généralement sans abonnement sur le web, mais il n'y a pas besoin de revoir le système de peer-review pour ça.
Ça ne propose pas d'alternative au modèle d'évaluation a priori par les pairs qui n'est pas présent dans un système d'archive ouverte
Non, c'est indépendant. La plupart des papiers présents sur https://hal.archives-ouvertes.fr/ sont des papiers peer-reviewés à la base. L'éditeur demande en général le transfert de copyright sur la version finale, mais on garde la propriété de notre version et il suffit d'une petite différence (en particulier enlever la notice de copyright de l'éditeur) pour que ça soit déposable sur HAL. Je ne suis pas juriste, mais en tout cas c'est comme ça que marche pour HAL.
En voyant le titre, je pensais avoir un moyen simple de répondre à la question « est-ce qu'il y a un fichier qui a changé alors qu'il n'était pas censé ? » i.e. « est-ce que mon disque dur est en train de rendre l'âme et que le contenu des fichiers change tout seul ».
Si je comprends bien, ce qui s'en rapproche le plus est « fim diff », mais ça liste tous les fichiers qui ont changé, y compris ceux que l'utilisateur a effectivement modifié.
Est-ce qu'il y a un moyen simple de lister les fichiers pour lesquels les timestamps n'ont pas bougé depuis le dernier commit, mais dont le contenu a changé ? En gros, "btrfs scrub" mais en espace utilisateur.
(Je pensais être à l'abri des corruptions de données jusqu'au jour où j'ai comparé le contenu d'un backup sur un vieux disque dur avec les données live : 3 corruptions silencieuses en moins de 10 ans sur quelques dizaines de Go de données. Quand même …)
Le vrai test, c'est donc de comparer son écran, affichant du blanc, et une feuille de papier blanc
Non, ça n'a pas de sens.
Ton écran émet de la lumière, alors qu'une feuille de papier « blanc » ne fait que réfléchir ce qu'elle reçoit. La lumière émise par une feuille de papier « blanc » est simplement de la même couleur que la lumière qui l'éclaire.
Si tu mets la feuille blanche en face de ton écran dans une pièce non-éclairée, elle sera forcément de la même couleur que l'écran par exemple. Et si tu fais l'expérience dans une pièce bien éclairée, la feuille sera de la même couleur que l'éclairage, donc tu ne compares pas l'écran et la feuille, mais l'écran et la source d'éclairage.
Pas quand le user agent n'est pas celui de ton navigateur
Ah, OK, je pensais que c'était l'IP source.
Du coup, c'est trash parce que quid du js qui check le user agent?
Le js côté client, no problem, mais effectivement s'il y a un truc qui sert une page différente en fonction du user-agent côté serveur, c'est très vilain si le proxy le change.
Euh, ça veut pas dire qu'il y a proxy, ça. Ça peut juste être du NAT, non ? C'est effectivement le cas chez (presque ?) tous les opérateurs mobiles vu qu'il n'y a plus assez d'IPv4 et que les gens sont pas prêts à sauter dans IPv6.
Tu peux jouer un peu avec darktable qui fait uniquement de l'édition non-destructrice, y compris avec des opérations non-triviales sur les images. C'est un plaisir à utiliser. Côté performance, on ne perd pas vraiment :
Si on continue à travailler comme avant, on ne modifie que le dernier filtre de la pile, et si le logiciel est un peu intelligent il a en cache la sortie de l'avant-dernier filtre => chaque opération n'applique qu'un filtre, comme avant côté temps de calcul (mais plus gourmand en RAM).
Si on utilise vraiment le non-destructif, cf. la réponse de VictorAche : on utilise plus le CPU/GPU, mais ça reste beaucoup plus rapide que de tout ré-appliquer à la main.
Sauf erreur de ma part, Photoshop sait faire du non-destructif depuis des lustres et personne ne s'en plaint.
Je ne sais pas ce qui est prévu pour Gimp, mais par exemple avec darktable, par défaut, il n'applique le pipeline que sur la portion d'image visible ou bien il travaille sur une image avec résolution réduite si le facteur de zoom est petit (donc ça va toujours vite), mais le non-destructif fait qu'il peut ré-appliquer le pipeline sur l'image complète au moment de l'export (donc pas de compromis sur la qualité au final).
Je ne vois aucune promesse ni aucun objectif sur la page, juste qu'il espère que la police sera un jour open-source : « I don't know if in the future my font PragmataPro™ will be open source (I hope) ».
Une fois son objectif atteint, elle sera opensource !
Source ?
Tout ce que je vois sur la page, c'est un commentaire de l'auteur qui dit justement en réponse à quelqu'un qui lui suggère kickstarter : « My conclusion is that PragmataPro is not for everyone, so it would senseless to try again with crowdfunding » donc j'ai l'impression que c'était une tentative passée mais abandonnée.
Ca, c'est vrai jusqu'au jour où tu fais un git gc (ou bien que Git décide tout seul de faire un gc --auto). Les packs sont delta compressées comme les autres SCM (même si conceptuellement ça reste un snapshot).
Pas vraiment : ces trucs sont intégrés au navigateur, mais à partir du moment où c'est un vilain qui fait faire ce qu'il veut au navigateur, il peut commencer par désactiver ces protections par l'intérieur.
Oui, enfin ça ça arrête l'application vérolée par un script kiddie, mais si l'appli compromise est un peu maline, elle cherche un navigateur web et elle lui demande de faire le boulot pour elle (regarde ce que tu peux faire faire à un process qui tourne avec "gdb -p").
Euh, oui, justement, et c'est pour ça que c'est intéressant de paralléliser. Il n'y pas que le CPU qui en bénéficie, ça permet justement d'utiliser les temps de latences de certains composants pour faire autre chose. Typiquement, lancer les services qui n'ont pas besoin du réseau pendant qu'on attend une adresse IP via DHCP.
Bon probablement largement gourmand en ressources* (par rapport à un bash par ex. )
Rien à voir : Terminology est un émulateur de terminal (ce qui affiche la fenêtre, fait le rendu des polices, …), et bash est un shell (qui peut tourner dans Terminology).
Pour la manière de gérer l'arborescence, ce que tu décris ressemble pas mal aux « albums physiques » de Piwigo : http://piwigo.org/doc/doku.php?id=user_documentation:albums_management
(je n'ai jamais utilisé Piwigo comme ça). Par contre, une contrainte qui ne sera pas forcément acceptable pour toi : Piwigo considère les images comme des fichiers servis statiquement par le serveur web, donc je ne crois pas que tu puisses avoir tes photos en dehors de l'arborescence du serveur web, et si tu veux une gestion correcte des permissions ça ne marchera probablement pas. Pour les albums virtuels, c'est différent vu que les URL sont générées aléatoirement au moment de l'upload => la sécurité est assuré par le fait que les URLs ne sont pas devinables.
Je ne suis pas non plus 100% convaincu par Piwigo, mais dans la catégorie « outil libre, avec plein de fonctionnalités, bien maintenu et avec une grosse communauté », il est à peu près le seul.
Par contre, j'ai l'impression que owncloud ferait vraiment tout ce que tu veux.
Pour l'hébergement de photos, si Gallery t'avais plu tu aimeras sans doute Piwigo. Sinon, l'application de galerie photos de OwnCloud est assez basique mais pas mal aussi.
Je ne suis pas sûr de comprendre pourquoi tu continues cette conversation. Je ne suis pas développeur Darktable, je constate que sur ma machine avec 4 Go, c'est un peu juste et j'ai donné quelques pistes d'explication avec un lien vers plus de détails. Si tu penses savoir mieux que les développeurs de Darktable ce qu'ils devraient faire, le lieu pour les conseiller est la mailing-list, mais pas ici.
Je ne connais pas les détails, je suppose que le buffer de sortie d'un module est le buffer d'entrée du suivant en effet. Mais toujours est-il que pendant l'exécution d'un module, tu as besoin d'un buffer d'entrée et d'un de sortie, plus les données internes (qui peuvent manipuler plusieurs images), ça grimpe très vite.
Et vu que beaucoup d'opérations sont très gourmandes en CPU, il faut un cache pour éviter de tout recalculer à chaque fois pour que ça soit raisonnablement utilisable.
Même pour des images de quelques dizaines de megapixels, il faut 4Go de ram ?
Oui. Je l'utilise sur des images 16 Mpixels, et avec 4 Go sur une machine 32 bits, il n'avait pas assez d'espace d'adressage (ça marchait, mais plantage plus ou moins aléatoires à l'export). En passant en 64 bits, ça va mieux.
20 Mpixel * 3 cannaux * 4 octet (1 flottant simple précision) = 240 Mo par image.
Le moindre module va utiliser un buffer source et un buffer destination, donc 480 Mo juste pour stocker l'entrée et la sortie.
Au contraire, c'est codé en C avec un soucis permanent de perfs (il n'acceptera même pas de tourner sur un processeur qui n'a pas les instructions SSE qui vont bien). Je n'imagine même pas le désastre en Java avec 3 java.lang.Float par pixel ;-).
[^] # Re: Mauvaises permissions
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 3.
Oui, aussi (d'où ma conclusion sur le fait que la seule vraie solution est de changer de matériel). Je citais le noyau car c'est du logiciel au même titre que l'application qui pose problème à l'auteur du journal, apporté par la même mise à jour. Donc avoir peur de l'application et pas du noyau est particulièrement paradoxal.
[^] # Re: Mauvaises permissions
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 5.
Euh, tu réalises que tu as sur ton téléphone un noyau fourni par ton constructeur. Côté permission, c'est autrement pire que tout ce que tu cites, le code qui tourne dans le noyau a accès à absolument tout sur ton téléphone. Est-ce que tu as pensé à désinstaller ton noyau ?
Le système de droit, c'est fait pour te permettre d'installer des applications venant de fournisseurs en qui tu as moyennement confiance seulement. Si tu n'a pas confiance en Samsung et que tu as un téléphone Samsung, la seule option que tu as est de changer de téléphone. Tout ce que tu peux faire d'autre ne pourra que te donner l'illusion de sécurité, mais ça ne changera strictement rien à ce que Samsung peut faire sur ton téléphone.
[^] # Re: Archive ouverte vs peer review
Posté par Matthieu Moy (site web personnel) . En réponse au journal PLRN Article 9 - "Libre" accès aux publications scientifiques de la recherche publique. Évalué à 2.
OK, mais c'est totalement orthogonal au système d'archives ouvertes, et au fait que les publis soient accessibles ou non. Tu peux faire du peer-reviewé ou non sur une archive ouverte, tu peux avoir un éditeur privé qui fait de l'open access, … Si on invente un super nouveau système pour décider quelle publi est acceptée ou non, ça ne changera rien au fait que la publi puisse aller sur HAL.
Il commence à y avoir des labels gérés par des universitaires qui concurrencent les éditeurs classiques. En informatique, il y a ça par exemple : https://www.dagstuhl.de/publikationen/. Là, y'a un problème qu'une loi peut difficilement résoudre : les éditeurs « prestigieux » sont ceux qui sont privés et cher. Ceux qui sont les plus proches de mon sens de l'éthique n'ont pas (encore ?) la même renommée.
[^] # Re: Archive ouverte vs peer review
Posté par Matthieu Moy (site web personnel) . En réponse au journal PLRN Article 9 - "Libre" accès aux publications scientifiques de la recherche publique. Évalué à 2.
Bah du coup, tu proposes quoi ? Parce que juste me dire que tu n'es pas d'accord sans dire sur quel point, ça ne nous fait pas beaucoup avancer …
[^] # Re: Archive ouverte vs peer review
Posté par Matthieu Moy (site web personnel) . En réponse au journal PLRN Article 9 - "Libre" accès aux publications scientifiques de la recherche publique. Évalué à 2.
Je n'ai écrit nulle part que toutes les publis peer-reviewées étaient sur HAL. Seulement qu'une grande partie des publis qui sont sur HAL étaient peer-reviewées.
On est d'accord sur le fait qu'il y a de la marge de progression pour avoir plus de publis disponibles sur ces archives, ou plus généralement sans abonnement sur le web, mais il n'y a pas besoin de revoir le système de peer-review pour ça.
# Archive ouverte vs peer review
Posté par Matthieu Moy (site web personnel) . En réponse au journal PLRN Article 9 - "Libre" accès aux publications scientifiques de la recherche publique. Évalué à 8.
Non, c'est indépendant. La plupart des papiers présents sur https://hal.archives-ouvertes.fr/ sont des papiers peer-reviewés à la base. L'éditeur demande en général le transfert de copyright sur la version finale, mais on garde la propriété de notre version et il suffit d'une petite différence (en particulier enlever la notice de copyright de l'éditeur) pour que ça soit déposable sur HAL. Je ne suis pas juriste, mais en tout cas c'est comme ça que marche pour HAL.
[^] # Re: Détecter les problèmes matériels
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 3.
Fait :
https://github.com/evrignaud/fim/issues/2
# Détecter les problèmes matériels
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 3.
En voyant le titre, je pensais avoir un moyen simple de répondre à la question « est-ce qu'il y a un fichier qui a changé alors qu'il n'était pas censé ? » i.e. « est-ce que mon disque dur est en train de rendre l'âme et que le contenu des fichiers change tout seul ».
Si je comprends bien, ce qui s'en rapproche le plus est « fim diff », mais ça liste tous les fichiers qui ont changé, y compris ceux que l'utilisateur a effectivement modifié.
Est-ce qu'il y a un moyen simple de lister les fichiers pour lesquels les timestamps n'ont pas bougé depuis le dernier commit, mais dont le contenu a changé ? En gros, "btrfs scrub" mais en espace utilisateur.
(Je pensais être à l'abri des corruptions de données jusqu'au jour où j'ai comparé le contenu d'un backup sur un vieux disque dur avec les données live : 3 corruptions silencieuses en moins de 10 ans sur quelques dizaines de Go de données. Quand même …)
[^] # Re: Au moins une erreur
Posté par Matthieu Moy (site web personnel) . En réponse au journal Lumière bleue, attention les yeux.. Évalué à 6.
Non, ça n'a pas de sens.
Ton écran émet de la lumière, alors qu'une feuille de papier « blanc » ne fait que réfléchir ce qu'elle reçoit. La lumière émise par une feuille de papier « blanc » est simplement de la même couleur que la lumière qui l'éclaire.
Si tu mets la feuille blanche en face de ton écran dans une pièce non-éclairée, elle sera forcément de la même couleur que l'écran par exemple. Et si tu fais l'expérience dans une pièce bien éclairée, la feuille sera de la même couleur que l'éclairage, donc tu ne compares pas l'écran et la feuille, mais l'écran et la source d'éclairage.
[^] # Re: Pareil
Posté par Matthieu Moy (site web personnel) . En réponse au journal Free Mobile: C'est quoi leur projet?. Évalué à 2.
Ah, OK, je pensais que c'était l'IP source.
Le js côté client, no problem, mais effectivement s'il y a un truc qui sert une page différente en fonction du user-agent côté serveur, c'est très vilain si le proxy le change.
[^] # Re: Pareil
Posté par Matthieu Moy (site web personnel) . En réponse au journal Free Mobile: C'est quoi leur projet?. Évalué à 2.
Euh, ça veut pas dire qu'il y a proxy, ça. Ça peut juste être du NAT, non ? C'est effectivement le cas chez (presque ?) tous les opérateurs mobiles vu qu'il n'y a plus assez d'IPv4 et que les gens sont pas prêts à sauter dans IPv6.
[^] # Re: Question de n00b
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 6.
Tu peux jouer un peu avec darktable qui fait uniquement de l'édition non-destructrice, y compris avec des opérations non-triviales sur les images. C'est un plaisir à utiliser. Côté performance, on ne perd pas vraiment :
Si on continue à travailler comme avant, on ne modifie que le dernier filtre de la pile, et si le logiciel est un peu intelligent il a en cache la sortie de l'avant-dernier filtre => chaque opération n'applique qu'un filtre, comme avant côté temps de calcul (mais plus gourmand en RAM).
Si on utilise vraiment le non-destructif, cf. la réponse de VictorAche : on utilise plus le CPU/GPU, mais ça reste beaucoup plus rapide que de tout ré-appliquer à la main.
Sauf erreur de ma part, Photoshop sait faire du non-destructif depuis des lustres et personne ne s'en plaint.
Je ne sais pas ce qui est prévu pour Gimp, mais par exemple avec darktable, par défaut, il n'applique le pipeline que sur la portion d'image visible ou bien il travaille sur une image avec résolution réduite si le facteur de zoom est petit (donc ça va toujours vite), mais le non-destructif fait qu'il peut ré-appliquer le pipeline sur l'image complète au moment de l'export (donc pas de compromis sur la qualité au final).
[^] # Re: rxvt-unicode mais…
Posté par Matthieu Moy (site web personnel) . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 2.
Je ne vois aucune promesse ni aucun objectif sur la page, juste qu'il espère que la police sera un jour open-source : « I don't know if in the future my font PragmataPro™ will be open source (I hope) ».
Ma source est juste la page officielle :
http://www.fsd.it/fonts/pragmatapro.htm#comment-1742593877
[^] # Re: rxvt-unicode mais…
Posté par Matthieu Moy (site web personnel) . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 2.
Source ?
Tout ce que je vois sur la page, c'est un commentaire de l'auteur qui dit justement en réponse à quelqu'un qui lui suggère kickstarter : « My conclusion is that PragmataPro is not for everyone, so it would senseless to try again with crowdfunding » donc j'ai l'impression que c'était une tentative passée mais abandonnée.
[^] # Re: color2gray et organisation du code
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 3.
Ca, c'est vrai jusqu'au jour où tu fais un git gc (ou bien que Git décide tout seul de faire un gc --auto). Les packs sont delta compressées comme les autres SCM (même si conceptuellement ça reste un snapshot).
[^] # Re: Pare-feu applicatif
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Un peu plus de sécurité sous Linux. Évalué à 3.
Pas vraiment : ces trucs sont intégrés au navigateur, mais à partir du moment où c'est un vilain qui fait faire ce qu'il veut au navigateur, il peut commencer par désactiver ces protections par l'intérieur.
[^] # Re: Pare-feu applicatif
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Un peu plus de sécurité sous Linux. Évalué à 3.
Oui, enfin ça ça arrête l'application vérolée par un script kiddie, mais si l'appli compromise est un peu maline, elle cherche un navigateur web et elle lui demande de faire le boulot pour elle (regarde ce que tu peux faire faire à un process qui tourne avec "gdb -p").
[^] # Re: Merci
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4.
Euh, oui, justement, et c'est pour ça que c'est intéressant de paralléliser. Il n'y pas que le CPU qui en bénéficie, ça permet justement d'utiliser les temps de latences de certains composants pour faire autre chose. Typiquement, lancer les services qui n'ont pas besoin du réseau pendant qu'on attend une adresse IP via DHCP.
[^] # Re: Si tu montres à un vrai geek un super truc sur ton ordi, il regardera tout le reste sauf ça
Posté par Matthieu Moy (site web personnel) . En réponse au journal Gérer son espace de travail git avec "gws". Évalué à 4.
Rien à voir : Terminology est un émulateur de terminal (ce qui affiche la fenêtre, fait le rendu des polices, …), et bash est un shell (qui peut tourner dans Terminology).
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 4.
Pour le LDAP, il y a un plugin : http://piwigo.org/ext/extension_view.php?eid=650
(plus l'air d'être maintenu par contre, mauvaise nouvelle).
Pour la manière de gérer l'arborescence, ce que tu décris ressemble pas mal aux « albums physiques » de Piwigo : http://piwigo.org/doc/doku.php?id=user_documentation:albums_management
(je n'ai jamais utilisé Piwigo comme ça). Par contre, une contrainte qui ne sera pas forcément acceptable pour toi : Piwigo considère les images comme des fichiers servis statiquement par le serveur web, donc je ne crois pas que tu puisses avoir tes photos en dehors de l'arborescence du serveur web, et si tu veux une gestion correcte des permissions ça ne marchera probablement pas. Pour les albums virtuels, c'est différent vu que les URL sont générées aléatoirement au moment de l'upload => la sécurité est assuré par le fait que les URLs ne sont pas devinables.
Une autre option, c'est d'avoir ton arborescence de travail quelque part, et de synchroniser régulièrement vers ta galerie avec quelque chose comme http://piwigo.org/doc/doku.php?id=user_documentation:tools:piwigo_import_tree .
Je ne suis pas non plus 100% convaincu par Piwigo, mais dans la catégorie « outil libre, avec plein de fonctionnalités, bien maintenu et avec une grosse communauté », il est à peu près le seul.
Par contre, j'ai l'impression que owncloud ferait vraiment tout ce que tu veux.
# Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 6.
Pour l'hébergement de photos, si Gallery t'avais plu tu aimeras sans doute Piwigo. Sinon, l'application de galerie photos de OwnCloud est assez basique mais pas mal aussi.
[^] # Re: ça existait déjà
Posté par Matthieu Moy (site web personnel) . En réponse au journal Des bookmarks dans mon terminal !. Évalué à 2.
Bien plus basique, mais très pratique aussi, il y a "cd -", qui revient dans le répertoire où tu étais avant le dernier cd.
[^] # Re: Va falloir que je m'y mette
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 1.6 : traitement de photos, développement d’images RAW. Évalué à 3.
Je ne suis pas sûr de comprendre pourquoi tu continues cette conversation. Je ne suis pas développeur Darktable, je constate que sur ma machine avec 4 Go, c'est un peu juste et j'ai donné quelques pistes d'explication avec un lien vers plus de détails. Si tu penses savoir mieux que les développeurs de Darktable ce qu'ils devraient faire, le lieu pour les conseiller est la mailing-list, mais pas ici.
[^] # Re: Va falloir que je m'y mette
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 1.6 : traitement de photos, développement d’images RAW. Évalué à 2.
Je ne connais pas les détails, je suppose que le buffer de sortie d'un module est le buffer d'entrée du suivant en effet. Mais toujours est-il que pendant l'exécution d'un module, tu as besoin d'un buffer d'entrée et d'un de sortie, plus les données internes (qui peuvent manipuler plusieurs images), ça grimpe très vite.
Et vu que beaucoup d'opérations sont très gourmandes en CPU, il faut un cache pour éviter de tout recalculer à chaque fois pour que ça soit raisonnablement utilisable.
[^] # Re: Va falloir que je m'y mette
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 1.6 : traitement de photos, développement d’images RAW. Évalué à 5.
Oui. Je l'utilise sur des images 16 Mpixels, et avec 4 Go sur une machine 32 bits, il n'avait pas assez d'espace d'adressage (ça marchait, mais plantage plus ou moins aléatoires à l'export). En passant en 64 bits, ça va mieux.
20 Mpixel * 3 cannaux * 4 octet (1 flottant simple précision) = 240 Mo par image.
Le moindre module va utiliser un buffer source et un buffer destination, donc 480 Mo juste pour stocker l'entrée et la sortie.
Plus de détails : http://www.darktable.org/2012/03/darktable-and-memory/
Au contraire, c'est codé en C avec un soucis permanent de perfs (il n'acceptera même pas de tourner sur un processeur qui n'a pas les instructions SSE qui vont bien). Je n'imagine même pas le désastre en Java avec 3 java.lang.Float par pixel ;-).