Quelqu'un a t-il un retour d'expérience sur Qobuz Premium (l'équivalent fonctionnel et tarifaire de Spotify et Deezer, pas les offres à 20 ou 30€), notamment au niveau des applis ?
Je sais qu'il n'y a pas d'appli native Linux mais est-ce que ça marche sous wine ? Est-ce que l'appli Android présente les mêmes qualités/défauts que celles de Spotify/Deezer ? Bref, ça serait bien d'étendre cet intéressante discussion à ce troisième larron qui, comme Deezer, est français (si toutefois son auteur initial n'y voit pas un squat malvenu).
Si au final tu n'écoutes que tes fichiers une bonne solution est d'utiliser Subsonic (c'est d'ailleurs là-dessus que s'appuie Ubuntu Music, au moins pour le client Android).
Objectivement c'est faux et de beaucoup* : Qobuz déclare avoir 12 millions de titre alors que ses deux concurrents en déclarent 20 millions.
* sous réserve de la sincérité de Deezer et Spotify.
Mais il serait plus intéressant d'avoir les chiffres par genre : classique, pop/rock, jazz, folk, reggae, rap, etc… (sans rentrer non plus dans les sous-genres).
C'est que j'utilisais dans mon boulot. TortoiseSVN offre une fonction très pratique où en sélectionnant deux révisions il affiche directement un doc avec les marques de révisions indiquant les différences entre les deux docs. En revanche on demandait à l'auteur de commiter lui-même afin qu'il puisse saisir la description des modifications (un simple clic-droit sur le fichier à commiter). Chaque commit déclenchait un email aux intéressés avec la description du commit. SVN était configuré pour que chacun ait une copie de tous les documents dans les répertoires qui l'intéressent (=> accès offline aux documents), un simple clic droit sur un répertoire donnant accès à la mise à jour du répertoire avec les commits fait par d'autres utilisateurs.
Je sais que SVN c'est considéré comme has-been mais pour ce genre d'usage et avec un client bien fichu comme TortoiseSVN, c'est très simple à utiliser même pour des non-informaticiens (il faut quand même un admin pour gérer le truc).
Au départ (il y a un peu plus de 25 ans), Ada n'était pas "objet" du tout, la seule API graphique disponible était directement X-Windows et ce n'était pas le langage le plus simple à appréhender. En outre, le marché proposait très peu de développeurs Ada. J'imagine que ces raisons, parmi d'autres sans doute, n'ont pas incité les entreprises à faire l'effort d'adopter le langage, sauf pour certains clients où ce choix était stratégique (systèmes à haute sûreté comme la conduite de centrales nucléaires, par exemple).
Je n'ai pas de souvenir précis mais je suis à peu près sûr qu'il m'a suffit de cliquer sur le + en haut à gauche de mon gmail pour créer mon G+ (ainsi que ceux de ma femme et de mon fils), les trois comptes étant sur trois domaines google apps gratuits différents (i.e. trois domaines).
En revanche, je me souviens que je n'ai pas eu accès à G+ les premiers mois, mais c'était la même chose pour les google apps payants.
Il me semble que quand on répond à la question secrète le password est envoyé sur l'adresse mail concernée, il n'est pas donné en direct. Donc on n'est pas plus avancé.
La killer feature de Picasa (pour moi) c'est la reconnaissance faciale : détermination des zones de visage et identification automatique des personnes correspondantes dès lors que l'on a manuellement identifié ces personnes sur un ou plusieurs photos (Digikam en est encore loin). Ca marche très bien et c'est super pratique pour retrouver des photos.
Cette fonctionnalité est couplée (depuis la 3.9) à un taggage XMP standard permettant la réutilisation de cette reconnaissance de visage par d'autres logiciels (sous réserve qu'ils analysent les champs XMP correspondants) => plus de dépendance à Picasa.
On pourrait donc limiter l'utilisation de Picasa à la reconnaissance faciale. Malheureusement, à ma connaissance, aucun logiciel libre sous Linux n'est à ce jour capable d'analyser les champs XMP concernés alors que Photoshop Bridge ou iMatch (et peut-être XnViewMP ?) en sont capables.
Donc, en ce qui me concerne, j'utilise Picasa sous Wine (le Wine standard) pour tagguer les visages (et que les visages) + iMatch (également sous Wine) pour le reste. Rien que du propriétaire et le tout sous Wine. Si je récolte pas un -10 avec cet aveu, je serai verni…
En ce qui me concerne j'utilise la dernière version (3.9) sous le Wine "normal" et ça marche très bien (et très vite). Je ne sais pas trop ce qu'apporte le Wine modifié par Google (il était peut-être plus nécessaire dans les versions précédentes ?).
Ceci dit, je n'utilise Picasa que parce qu'il est pour moi irremplaçable pour tagguer les visages (NB. La 3.9 offre l'option d'écrire les tags de visage dans un format XMP standardisé => pas de dépendance à Picasa).
Par ailleurs, pour les utilisateurs souhaitant tagguer leur photos au format XMP de façon un peu plus poussée que la légende et les mots clé, il n'y a pas beaucoup de choix "libre" sur Linux : à ma connaissance seul Digikam fait une partie du boulot (IPTC Core mais pas encore IPTC Extension, me semble t-il). Sinon, il y a XnViewMP qui n'est pas libre mais assez complet lui aussi.
Tu dois te rendre d'un point A à un point B. Si tu peux y aller à pied, tu utilises ce moyen de transport, lent mais en principe sûr. Si tu ne peux pas y aller à pied (parce que trop éloigné par exemple) tu choisis de rester à la maison ou bien tu choisis de prendre ta voiture où tu risques pourtant l'accident malgré ta prudence ?
Il se trouve que pour les élections d'élus politiques, il est possible "d'aller à pied" (i.e. voter papier) car elles sont peu fréquentes et que l’État mobilise un important dispositif. Sur ce point je ne souhaite pas que ça change.
En revanche, dans d'autres situations où il n'est pas possible d'aller à pied il me paraît pertinent de prendre sa voiture (i.e. voter électroniquement), en prenant le maximum de précautions*, plutôt que de rester à la maison (i.e. laisser faire sans s'exprimer).
*De la même façon qu'on améliore la sécurité automobile pour rendre le risque "acceptable" par rapport au gain escompté, je suis persuadé qu'on peut faire de même pour le vote électronique. Encore faut-il ne pas laisser la chose, par jusqu'au boutisme, aux mains d'entreprises qui n'ont qu'un intérêt lucratif en la matière.
Moi je vois le cas de la mise en œuvre d'une démocratie participative à un niveau local. Actuellement, une fois élue pour 7 ans, l'équipe municipale décide le plus souvent seule. Entre le risque malgré tout assez faible que mon avis soit manipulé et celui, certain, qu'on ne me le demande pas durant sept ans, je fais vite le choix.
Je pense qu'entre les élections politiques et le choix d'un restau, il y a de la place pour quelques usages raisonnables.
Je pense que le vote électronique peut trouver une place acceptable là où il n'y a actuellement pas de vote car ce serait trop lourd d'en organiser un "papier" par rapport à l'enjeu du vote. Pour ce genre de cas, un vote internet peut souvent suffire ce qui résout le problème du coût. L'idée étant qu'un vote électronique n'offrant que 99,99% de fiabilité est peut-être mieux que pas de vote du tout (quoique ça peut se discuter).
Complètement hors sujet, je suis d'accord. Mais ce n'est pas ce que j'ai fait.
J'ai juste dit (de façon inutilement sarcastique, je le regrette) que la "liberté" des données étaient aussi importante que celle du logiciel, ce que l'expression "logiciel privateur" peut faire parfois oublier. Si une solution libre m'impose de croiser les doigts pour qu'un jour un développeur fasse un outil de migration Kimdaba --> XMP, j'aurai tendance à considérer que mes photos ne sont pas si libres que ça. En tous cas, elles ne sont pas libres là, maintenant, quand je voudrais qu'elles le soient pour les utiliser aussi avec d'autres logiciels, d'autres environnements (ce qu'on appelle l'inter-opérabilité). Ce qui m'amenait à préférer, si nécessaire, un logiciel privateur mais respectant les standards du domaine. Je ne vois pas dans ce raisonnement de "comparaison" avec quoi que ce soit.
1) Bonjour pour hiérarchiser des IPTC : c'est transparent pour l'utilisateur dans Digikam ou XnViewMP (et d'autres). Par ailleurs, XMP le permet depuis 2008.
2) griffonnage des photos : XMP permet de stocker les meta-données dans un fichier "sidecar" associé à l'image. C'est notamment utilisé pour les raw.
3) Rebonjour pour changer de logiciel : c'était justement l'objet de mon premier commentaire (sur un ton que je regrette un peu) ! La durée de vie espérée d'une collection de photos peut atteindre des dizaines d'années. J'ai plus confiance dans un standard adopté par tous les professionnels de la photo que dans l'avenir d'une solution isolée. Et au delà de la pérennité dans le temps il y a aussi l'inter-opérabilité au présent. Aujourd'hui je peux gérer ma collection dans XnViewMP ou Digikam sous Linux, ou bien dans un logiciel Windows (je n'ai pas encore pu convaincre mes enfants d'abandonner Windows sur leur PC) sans devoir faire aucun import/export.
4) Je ne doute pas que Kphotoalbum soit un excellent logiciel permettant des recherches sophistiquées et capable de visualiser des raw ou du xcf mais ce n'est pas le seul, d'autres offrent ces possibilités tout en supportant le standard, permettant ainsi une inter-opérabilité sans prise de tête.
1) Je n'ai pas fait de remarque sur la lisibilité des données, juste sur la possibilité de les récupérer dans d'autres logiciels.
2) Je n'ai pas dit que Kimdaba était mauvais, juste que c'était loin d'être une garantie pour migrer ses données facilement et que l'adoption d'un standard (en l'occurrence IPTC ou XMP) semble plus naturel qu'une initiative isolée aussi bien faite soit-elle.
3) "Si un logiciel n'est pas capable d'importer des données Kimdaba, c'est que le logiciel en question est mauvais" : no comment.
4) Digikam, XnViewMP et d'autres qui ne me reviennent pas à l'esprit à l'instant. En tous cas, beaucoup plus que le "aucun autre ne fait ça" de ton précédent commentaire.
5) Hélas, il restait une miette de pain, voir point 3 :-)
Cool, on se retrouve donc avec un fichier au format Kimdaba et on croise les doigts pour arriver à l'importer dans le logiciel vers lequel on veut migrer. Ça va pas le faire pour le commun des mortels…
Par ailleurs, ce n'est pas le seul logiciel à gérer les tags hiérarchisés et la norme XMP le prévoit depuis fin 2008).
Ceci dit, je reconnais que je profitais de l'occasion pour troller un peu sur le fanatisme du "logiciel privateur" curieusement parfois moins regardant sur la situation des données associées :-)
(titre un peu provocateur mais sans méchanceté particulière vis à vis de ce logiciel que je ne connais pas)
Nul part dans la documentation on ne trouve mention de IPTC ou de XMP. Autrement dit, on n'est même pas sûr que les tags dont ils parlent sont stockés dans les photos et pas seulement dans la base de données du logiciel. Parce que si ce n'est pas le cas, après avoir taggué des milliers de photos, celles-ci deviennent "prisonnières" du logiciel (à moins d'accepter de tout re-tagguer sous un autre logiciel). J'imagine que KPhotoAlbum écrit ses tags dans des keywords IPTC mais si c'est le cas, le fait que ce ne soit pas mentionné en dit long sur le peu d'intérêt que ça semble avoir pour les développeurs ou les utilisateurs. Du moment que le logiciel est libre, hein…
Je préfère un logiciel non libre (XnViewMP par exemple) mais tagguant les photos en IPTC ou XMP (de préférence via une librairie reconnue telle que Exiftool). Ma liberté de le quitter est ainsi préservée et elle m'est bien plus précieuse que celle de pouvoir le modifier…
# et Qobuz ?
Posté par mahikeulbody . En réponse au journal Retour d’expérience : Deezer vs. Spotify (c’est Spotify qui gagne). Évalué à 2.
Quelqu'un a t-il un retour d'expérience sur Qobuz Premium (l'équivalent fonctionnel et tarifaire de Spotify et Deezer, pas les offres à 20 ou 30€), notamment au niveau des applis ?
Je sais qu'il n'y a pas d'appli native Linux mais est-ce que ça marche sous wine ? Est-ce que l'appli Android présente les mêmes qualités/défauts que celles de Spotify/Deezer ? Bref, ça serait bien d'étendre cet intéressante discussion à ce troisième larron qui, comme Deezer, est français (si toutefois son auteur initial n'y voit pas un squat malvenu).
[^] # Re: Les goûts et les couleurs...
Posté par mahikeulbody . En réponse au journal Retour d’expérience : Deezer vs. Spotify (c’est Spotify qui gagne). Évalué à 0.
Il n'a pas les fonctions d'un cloud classique, je préfère parler de Deezer/Spotify perso (en bien plus paramétrable, soit dit en passant).
[^] # Re: Les goûts et les couleurs...
Posté par mahikeulbody . En réponse au journal Retour d’expérience : Deezer vs. Spotify (c’est Spotify qui gagne). Évalué à 1.
Si au final tu n'écoutes que tes fichiers une bonne solution est d'utiliser Subsonic (c'est d'ailleurs là-dessus que s'appuie Ubuntu Music, au moins pour le client Android).
[^] # Re: Qobuz?
Posté par mahikeulbody . En réponse au journal Retour d’expérience : Deezer vs. Spotify (c’est Spotify qui gagne). Évalué à 2.
Objectivement c'est faux et de beaucoup* : Qobuz déclare avoir 12 millions de titre alors que ses deux concurrents en déclarent 20 millions.
* sous réserve de la sincérité de Deezer et Spotify.
Mais il serait plus intéressant d'avoir les chiffres par genre : classique, pop/rock, jazz, folk, reggae, rap, etc… (sans rentrer non plus dans les sous-genres).
[^] # Re: Rien d'autres
Posté par mahikeulbody . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 2.
C'est complémentaire à une gestion de docs mais ça ne la remplace pas (sauf dans le cas d'un seul auteur par document).
[^] # Re: SVN ou autre
Posté par mahikeulbody . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 4.
C'est que j'utilisais dans mon boulot. TortoiseSVN offre une fonction très pratique où en sélectionnant deux révisions il affiche directement un doc avec les marques de révisions indiquant les différences entre les deux docs. En revanche on demandait à l'auteur de commiter lui-même afin qu'il puisse saisir la description des modifications (un simple clic-droit sur le fichier à commiter). Chaque commit déclenchait un email aux intéressés avec la description du commit. SVN était configuré pour que chacun ait une copie de tous les documents dans les répertoires qui l'intéressent (=> accès offline aux documents), un simple clic droit sur un répertoire donnant accès à la mise à jour du répertoire avec les commits fait par d'autres utilisateurs.
Je sais que SVN c'est considéré comme has-been mais pour ce genre d'usage et avec un client bien fichu comme TortoiseSVN, c'est très simple à utiliser même pour des non-informaticiens (il faut quand même un admin pour gérer le truc).
[^] # Re: Popularité
Posté par mahikeulbody . En réponse à la dépêche Publication de la nouvelle norme Ada 2012. Évalué à 5.
Au départ (il y a un peu plus de 25 ans), Ada n'était pas "objet" du tout, la seule API graphique disponible était directement X-Windows et ce n'était pas le langage le plus simple à appréhender. En outre, le marché proposait très peu de développeurs Ada. J'imagine que ces raisons, parmi d'autres sans doute, n'ont pas incité les entreprises à faire l'effort d'adopter le langage, sauf pour certains clients où ce choix était stratégique (systèmes à haute sûreté comme la conduite de centrales nucléaires, par exemple).
[^] # Re: Accés à la version gratuite encore possible (mais pour un utilisateur maximum)
Posté par mahikeulbody . En réponse au journal Plus d'inscription à la version gratuite de Google Apps. Évalué à 2.
Notamment l'alias spécial * qui collecte tout ce qui n'est pas explicitement défini (souvent du spam, d'ailleurs).
[^] # Re: Qu'est-ce qui fait tourner le monde ?
Posté par mahikeulbody . En réponse au journal Plus d'inscription à la version gratuite de Google Apps. Évalué à 0.
Je n'ai pas de souvenir précis mais je suis à peu près sûr qu'il m'a suffit de cliquer sur le + en haut à gauche de mon gmail pour créer mon G+ (ainsi que ceux de ma femme et de mon fils), les trois comptes étant sur trois domaines google apps gratuits différents (i.e. trois domaines).
En revanche, je me souviens que je n'ai pas eu accès à G+ les premiers mois, mais c'était la même chose pour les google apps payants.
[^] # Re: Qu'est-ce qui fait tourner le monde ?
Posté par mahikeulbody . En réponse au journal Plus d'inscription à la version gratuite de Google Apps. Évalué à 4.
Faux : j'ai plusieurs Google Apps gratuits et chacun a Google+.
[^] # Re: grsync
Posté par mahikeulbody . En réponse à la dépêche Synchroniser vos dossiers locaux/distants. Évalué à 1.
Exact, c'est du backup, pas de la sync. Au temps pour moi.
# grsync
Posté par mahikeulbody . En réponse à la dépêche Synchroniser vos dossiers locaux/distants. Évalué à 1.
Il y a aussi grsync : rsync + interface GTK.
# Je ne comprends pas
Posté par mahikeulbody . En réponse au journal [ sécurité ] Comment se faire plomber sa messagerie (ou tout autre compte) par la "question secrète". Évalué à 0. Dernière modification le 04 mai 2012 à 17:14.
Il me semble que quand on répond à la question secrète le password est envoyé sur l'adresse mail concernée, il n'est pas donné en direct. Donc on n'est pas plus avancé.
[^] # Re: picatchou?
Posté par mahikeulbody . En réponse au journal Picasa pour Linux, c'est bientôt fini !. Évalué à 2. Dernière modification le 24 avril 2012 à 16:48.
La killer feature de Picasa (pour moi) c'est la reconnaissance faciale : détermination des zones de visage et identification automatique des personnes correspondantes dès lors que l'on a manuellement identifié ces personnes sur un ou plusieurs photos (Digikam en est encore loin). Ca marche très bien et c'est super pratique pour retrouver des photos.
Cette fonctionnalité est couplée (depuis la 3.9) à un taggage XMP standard permettant la réutilisation de cette reconnaissance de visage par d'autres logiciels (sous réserve qu'ils analysent les champs XMP correspondants) => plus de dépendance à Picasa.
On pourrait donc limiter l'utilisation de Picasa à la reconnaissance faciale. Malheureusement, à ma connaissance, aucun logiciel libre sous Linux n'est à ce jour capable d'analyser les champs XMP concernés alors que Photoshop Bridge ou iMatch (et peut-être XnViewMP ?) en sont capables.
Donc, en ce qui me concerne, j'utilise Picasa sous Wine (le Wine standard) pour tagguer les visages (et que les visages) + iMatch (également sous Wine) pour le reste. Rien que du propriétaire et le tout sous Wine. Si je récolte pas un -10 avec cet aveu, je serai verni…
[^] # Re: Et non
Posté par mahikeulbody . En réponse au journal Picasa pour Linux, c'est bientôt fini !. Évalué à 2.
En ce qui me concerne j'utilise la dernière version (3.9) sous le Wine "normal" et ça marche très bien (et très vite). Je ne sais pas trop ce qu'apporte le Wine modifié par Google (il était peut-être plus nécessaire dans les versions précédentes ?).
Ceci dit, je n'utilise Picasa que parce qu'il est pour moi irremplaçable pour tagguer les visages (NB. La 3.9 offre l'option d'écrire les tags de visage dans un format XMP standardisé => pas de dépendance à Picasa).
Par ailleurs, pour les utilisateurs souhaitant tagguer leur photos au format XMP de façon un peu plus poussée que la légende et les mots clé, il n'y a pas beaucoup de choix "libre" sur Linux : à ma connaissance seul Digikam fait une partie du boulot (IPTC Core mais pas encore IPTC Extension, me semble t-il). Sinon, il y a XnViewMP qui n'est pas libre mais assez complet lui aussi.
[^] # Re: Le vote électronique peut être une solution... dans certains cas
Posté par mahikeulbody . En réponse au journal [présidentielles] 1 million d'électeurs. Évalué à -1.
Tu dois te rendre d'un point A à un point B. Si tu peux y aller à pied, tu utilises ce moyen de transport, lent mais en principe sûr. Si tu ne peux pas y aller à pied (parce que trop éloigné par exemple) tu choisis de rester à la maison ou bien tu choisis de prendre ta voiture où tu risques pourtant l'accident malgré ta prudence ?
Il se trouve que pour les élections d'élus politiques, il est possible "d'aller à pied" (i.e. voter papier) car elles sont peu fréquentes et que l’État mobilise un important dispositif. Sur ce point je ne souhaite pas que ça change.
En revanche, dans d'autres situations où il n'est pas possible d'aller à pied il me paraît pertinent de prendre sa voiture (i.e. voter électroniquement), en prenant le maximum de précautions*, plutôt que de rester à la maison (i.e. laisser faire sans s'exprimer).
*De la même façon qu'on améliore la sécurité automobile pour rendre le risque "acceptable" par rapport au gain escompté, je suis persuadé qu'on peut faire de même pour le vote électronique. Encore faut-il ne pas laisser la chose, par jusqu'au boutisme, aux mains d'entreprises qui n'ont qu'un intérêt lucratif en la matière.
[^] # Re: Le vote électronique peut être une solution... dans certains cas
Posté par mahikeulbody . En réponse au journal [présidentielles] 1 million d'électeurs. Évalué à 0.
Moi je vois le cas de la mise en œuvre d'une démocratie participative à un niveau local. Actuellement, une fois élue pour 7 ans, l'équipe municipale décide le plus souvent seule. Entre le risque malgré tout assez faible que mon avis soit manipulé et celui, certain, qu'on ne me le demande pas durant sept ans, je fais vite le choix.
Je pense qu'entre les élections politiques et le choix d'un restau, il y a de la place pour quelques usages raisonnables.
# Le vote électronique peut être une solution... dans certains cas
Posté par mahikeulbody . En réponse au journal [présidentielles] 1 million d'électeurs. Évalué à -2.
Je pense que le vote électronique peut trouver une place acceptable là où il n'y a actuellement pas de vote car ce serait trop lourd d'en organiser un "papier" par rapport à l'enjeu du vote. Pour ce genre de cas, un vote internet peut souvent suffire ce qui résout le problème du coût. L'idée étant qu'un vote électronique n'offrant que 99,99% de fiabilité est peut-être mieux que pas de vote du tout (quoique ça peut se discuter).
[^] # Re: Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à -1.
Complètement hors sujet, je suis d'accord. Mais ce n'est pas ce que j'ai fait.
J'ai juste dit (de façon inutilement sarcastique, je le regrette) que la "liberté" des données étaient aussi importante que celle du logiciel, ce que l'expression "logiciel privateur" peut faire parfois oublier. Si une solution libre m'impose de croiser les doigts pour qu'un jour un développeur fasse un outil de migration Kimdaba --> XMP, j'aurai tendance à considérer que mes photos ne sont pas si libres que ça. En tous cas, elles ne sont pas libres là, maintenant, quand je voudrais qu'elles le soient pour les utiliser aussi avec d'autres logiciels, d'autres environnements (ce qu'on appelle l'inter-opérabilité). Ce qui m'amenait à préférer, si nécessaire, un logiciel privateur mais respectant les standards du domaine. Je ne vois pas dans ce raisonnement de "comparaison" avec quoi que ce soit.
[^] # Re: Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à 1.
Par exemple, Digikam avec les meta-données dans des fichiers sidecar XMP. Mais il y en a d'autres.
[^] # Re: Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à 5.
1) Bonjour pour hiérarchiser des IPTC : c'est transparent pour l'utilisateur dans Digikam ou XnViewMP (et d'autres). Par ailleurs, XMP le permet depuis 2008.
2) griffonnage des photos : XMP permet de stocker les meta-données dans un fichier "sidecar" associé à l'image. C'est notamment utilisé pour les raw.
3) Rebonjour pour changer de logiciel : c'était justement l'objet de mon premier commentaire (sur un ton que je regrette un peu) ! La durée de vie espérée d'une collection de photos peut atteindre des dizaines d'années. J'ai plus confiance dans un standard adopté par tous les professionnels de la photo que dans l'avenir d'une solution isolée. Et au delà de la pérennité dans le temps il y a aussi l'inter-opérabilité au présent. Aujourd'hui je peux gérer ma collection dans XnViewMP ou Digikam sous Linux, ou bien dans un logiciel Windows (je n'ai pas encore pu convaincre mes enfants d'abandonner Windows sur leur PC) sans devoir faire aucun import/export.
4) Je ne doute pas que Kphotoalbum soit un excellent logiciel permettant des recherches sophistiquées et capable de visualiser des raw ou du xcf mais ce n'est pas le seul, d'autres offrent ces possibilités tout en supportant le standard, permettant ainsi une inter-opérabilité sans prise de tête.
[^] # Re: Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à 1.
1) Je n'ai pas fait de remarque sur la lisibilité des données, juste sur la possibilité de les récupérer dans d'autres logiciels.
2) Je n'ai pas dit que Kimdaba était mauvais, juste que c'était loin d'être une garantie pour migrer ses données facilement et que l'adoption d'un standard (en l'occurrence IPTC ou XMP) semble plus naturel qu'une initiative isolée aussi bien faite soit-elle.
3) "Si un logiciel n'est pas capable d'importer des données Kimdaba, c'est que le logiciel en question est mauvais" : no comment.
4) Digikam, XnViewMP et d'autres qui ne me reviennent pas à l'esprit à l'instant. En tous cas, beaucoup plus que le "aucun autre ne fait ça" de ton précédent commentaire.
5) Hélas, il restait une miette de pain, voir point 3 :-)
[^] # Re: Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à 1.
Cool, on se retrouve donc avec un fichier au format Kimdaba et on croise les doigts pour arriver à l'importer dans le logiciel vers lequel on veut migrer. Ça va pas le faire pour le commun des mortels…
Par ailleurs, ce n'est pas le seul logiciel à gérer les tags hiérarchisés et la norme XMP le prévoit depuis fin 2008).
Ceci dit, je reconnais que je profitais de l'occasion pour troller un peu sur le fanatisme du "logiciel privateur" curieusement parfois moins regardant sur la situation des données associées :-)
# Le logiciel est libre mais les données le sont-elles ?
Posté par mahikeulbody . En réponse à la dépêche KPhotoAlbum 4.2 est disponible. Évalué à 1.
(titre un peu provocateur mais sans méchanceté particulière vis à vis de ce logiciel que je ne connais pas)
Nul part dans la documentation on ne trouve mention de IPTC ou de XMP. Autrement dit, on n'est même pas sûr que les tags dont ils parlent sont stockés dans les photos et pas seulement dans la base de données du logiciel. Parce que si ce n'est pas le cas, après avoir taggué des milliers de photos, celles-ci deviennent "prisonnières" du logiciel (à moins d'accepter de tout re-tagguer sous un autre logiciel). J'imagine que KPhotoAlbum écrit ses tags dans des keywords IPTC mais si c'est le cas, le fait que ce ne soit pas mentionné en dit long sur le peu d'intérêt que ça semble avoir pour les développeurs ou les utilisateurs. Du moment que le logiciel est libre, hein…
Je préfère un logiciel non libre (XnViewMP par exemple) mais tagguant les photos en IPTC ou XMP (de préférence via une librairie reconnue telle que Exiftool). Ma liberté de le quitter est ainsi préservée et elle m'est bien plus précieuse que celle de pouvoir le modifier…