find le fait aussi très bien avec le terminateur + à la place de ; en fin de commande.
Euh, pas le mien en tous cas. find ... -exec commande {} + permet simplement d'exécuter une seule commande cmd fichier1 fichier2 ... (éventuellement découpée en plusieurs commandes s'il y a plus de fichiers que la limite de nombre d'arguments autorisée) au lieu de faire cmd fichier1; cmd fichier2; .... C'est plus rapide parce que ça réduit considérablement le nombre de fork+exec, mais pas pour le parallélisme.
J'ai peut-être raté un truc, mais en tous cas la page de man de ma version de find ne contient pas le mot « parallel ».
Perso, depuis que j'ai touché à darktable pour l'édition, je n'utilise plus que ça. Le principe de darktable, c'est de l'édition non-destructrice : on ne touche pas à l'image originale, mais on définit un ensemble de filtres à lui appliquer. Résultat : on peut modifier a postériori n'importe quel filtre n'importe quand (par exemple, retailler une photo, faire plein d'autres choses, et décider que finalement je ne voulais pas la retailler).
Il faut une machine un peu puissante : tout se fait en 32bit/couleur/pixel, donc c'est quasi-inutilisable sur une machine 32 bits, et 4Go de RAM est un minimum.
Le gros défaut que je lui trouve, c'est que par défaut on stocke l'image originale (typiquement l'image RAW, mais ça marche aussi avec des .jpg comme image de départ) et un "sidecar file", petit fichier XML qui décrit la séquence de filtres à appliquer. Même si darktable fait très attention à la compatibilité avec les vieux formats, je n'ai pas tellement confiance pour le stockage à long terme (i.e. est-ce que je pourrais rouvrir les photos dans 20 ans ?), donc une fois que je suis content du boulot avec darktable, j'exporte en .jpg et je gère mes .jpg avec digikam (que je trouve par ailleurs bien meilleur pour le côté « gestion de collection » en lecture-seule sur les images). Digikam a aussi plus de connections à des outils externes que Darktable.
Je n'ai jamais utilise lightroom, mais si j'en juge par l'aspect des screenshots qu'on trouve sur le web, ça a l'air d'être une pâle copie de darktable, à moins que ça ne soit l'inverse ;-).
Comme je l'ai dit dans un autre commentaire, je me suis tourné vers Piwigo. C'est du boulot, mais j'arrive à lui faire faire ce que je veux, c'est personnalisable à souhait.
Il y aurais une solution intermédiaire : utiliser les deux !
Visiblement (je n'ai pas testé), un lien symbolique depuis l'arborescence owncloud vers celle de piwigo, et on peut utiliser owncloud pour la synchro et piwigo pour la galerie publique. Solution à considérer sérieusement pour les auto-hébergés …
Mais avec des photos haute résolution (i.e. pas redimensionnée avec
la résolution max d'un appareil photo même modeste), ça fait un gap
énorme entre XXL et l'original.
Bien sûr mais ce gap n'a aucune importance.
Bah, ça implique que la photo originale ne sera a peu près jamais utilisée pour l'affichage, et donc qu'on n'aura jamais une image plus grande que XXL. Je veux dire, dans la phrase « Donc si la photo originale est plus grande que la place disponible on utilisera la XXL. », la partie gauche de l'implication est une tautologie en pratique.
Avec la stratégie actuelle qui ne redimensionne pas côté client, si je configure XXL à la taille de mon écran plus epsilon, il ne sera jamais utilisé, et si je le configure à quelque chose de plus petit, j'aurais de la place perdue sur l'écran.
Pas si gourmand que ça. Piwigo ne le fait qu'à la demande et met en cache
Oui, ce que je voulais dire, c'est le redimensionnement au pixel près comme le fait Google+ par exemple. Si un visiteur vient avec un navigateur 1 pixel plus grand, il recalcule toute la photo. Bourrin, mais efficace ;-).
Et bien moi je trouve cela beaucoup mieux que de ne pas avoir de plugins et d'avoir une usine à gaz avec beaucoup trop de fonctionnalités dans le "core".
Honnêtement, si on considère que l'affichage avec une taille adaptée à l'écran est une fonctionnalité importante pour l'utilisateur, alors le fait qu'elle soit désactivée par défaut et disponible dans un plugin incompatible avec une bonne partie des thèmes ne peut pas être considéré comme satisfaisant.
Au final, le thème modus n'est pas loin de faire ce que je veux, et il a le bon gout de redimensionner côté client si besoin, mais du coup le choix du thème est dicté par une fonctionnalité qui aurait du être indépendante du reste de la mise en forme, donc l'effet obtenu est à peu près l'inverse de celui recherché avec un système de plugin/thèmes. Et le thème en question est incompatible avec PersoFavicon et LocalFiles Editor pour le CSS (j'ai déjà rapporté les bugs, mais c'est juste pour illustrer à quel point on peut galérer à jongler entre les trucs incompatibles).
J'ai augmenté les tailles XXL (=> WQHD), XL (=> FHD) et L, donc les gens qui ont des écrans de ces tailles ont maintenant des images sans redimensionnement en diaporama plein écran, et qui remplissent bien l'espace modulo downsizing dans les autres configs. Ce que je voulais, mais je trouve ça dommage d'avoir du galérer autant pour arriver à ce que tous les hébergeurs commerciaux « classiques » font out-of-the-box.
Bon, voilà, maintenant que j'ai bien râlé, il faut quand même que je positive un peu : j'ai craqué pour un abonnement sur piwigo.com (http://mmoy.piwigo.com/), on a échangé plusieurs mails en privé avec Pierrick et le support est hyper réactif. Ça fait vraiment plaisir de voir des gens baser leur business-model sur le libre et l'absence de captivité de l'utilisateur !
pas de downsizing dans le navigateur web (résultat aléatoire en qualité selon le navigateur web).
Je crois que ça a quand même bien progressé ces temps-ci.
D'ailleurs, flickr fait du downsizing (en gros, il fait l'inverse de piwigo : plusieurs tailles d'images en statique, il prend juste au dessus et il downsize dans le navigateur), je ne l'aurais pas remarqué sans l'inspecteur de Firefox.
Donc si la photo originale est plus grande que la place disponible on utilisera la XXL.
Mais avec des photos haute résolution (i.e. pas redimensionnée avec la résolution max d'un appareil photo même modeste), ça fait un gap énorme entre XXL et l'original.
pas de downsizing dans le navigateur web (résultat aléatoire en qualité selon le navigateur web).
Je crois que ça a quand même bien progressé ces temps-ci. C'est clair que l'idéal pour l'utilisateur est encore le retaillage sur demande côté serveur, mais c'est super gourmand, tout le monde n'a pas la puissance de calcul de google chez son hébergeur ;-).
Enfin, tout est question de goût, mais moi je préfère un petit downscaling et une image qui remplit bien mon écran, surtout en mode slideshow.
Pour info, avec Modus il vaut mieux désactiver Automatic Size car le thème inclus un mécanisme équivalent (et même meilleur, selon le développeur de Modus, qui est un membre de l'équipe Piwigo
Effectivement, c'est plutôt mieux sans Automatic Size.
Mais si je puis me permettre d'être encore désagréable ;-) c'est le genre de trucs que je trouve très pénible avec ces architectures à plugins : on a une montagne de fonctionnalités, mais au final elles finissent par être toutes incompatibles les unes avec les autres.
(par exemple, si un de mes visiteurs choisit un autre thème, il n'aura plus droit à automatic size parce que je l'ai désactivé pour un thème).
tu as beaucoup de photos qui depassent le 2560x1440 toi ?
Euh, oui, toutes.
2560x1440, c'est 3.6 mégapixels. N'importe quel appareil photo fait deux fois ça aujourd'hui (pas toujours pour de bonnes raisons, mais c'est un autre débat).
bientot ce sera UHD (3840x2060)
Bienvenue dans le futur : mon appareil photos a deux fois plus de pixels que ça, et ce n'est pas énorme pour un réflexe. Un full-frame haut de gamme fait 4 fois ça.
Merci pour la réponse détaillée, et même si j'ai du mal à trouver mon bonheur, bravo pour le boulot sur Piwigo ! (sur le modèle économique et le côté « ne pas retenir l'utilisateur captif », c'est juste parfait !).
Pas de partage d'album par URL […]
En effet. Enfin, il y a le plugin Event Cats,
Pas dispo sur piwigo.com, c'est bien ça ?
avec le plugin « Automatic Size », on arrive à quelque chose de
décent sur un grand écran.
Alors tout va bien :-)
Presque. La taille XXL, ça a l'air grand comme ça, mais ça laisse encore des grosses marges autour de l'image sur un écran WQHD (2560x1440). En mode plein écran, j'utilise un peu moins de la moitié des pixels de mon écran …
À mon avis, faudrait soit ajouter un XXXL, soit basculer en mode « image originale » sur les écrans plus grands que XXL.
Si j'active celui-là, le plugin Automatic Size ne fait plus effet, l'ensemble de la page est limité à un peu moins de 1000px de large (i.e. moins de la moitié de mon écran).
Est-ce vraiment une fonctionnalité si peu demandée pour être dans un plugin incompatible avec autant de thèmes ? Enfin, ça a l'air d'être une question rhétorique et désagréable comme ça, mais je finis vraiment par croire que ça n'intéresse personne sauf moi ;-).
C'est vrai que l'interface de galerie d'images est simple mais assez bien faite (des miniatures, un affichage en plein écran). Mais encore une galerie qui fait de l'upscaling côté client à partir d'une image pas si grande que ça (1024px sur la démo en ligne) :-(.
Pour tous les thèmes que je vois dans la démo ( http://www.zenphoto.org/demo/album2/ ), c'est un design de largeur fixe, et en l’occurrence un qui utilise moins du quart de la largeur de mon écran.
Bon, je sais que ça fait 3 ou 4 fois que je fais mon malin avec mon gros écran en une entrée de forum, mais tant qu'à avoir plein de mégapixels dans son appareil photos, et d'autres pleins de mégapixels sur son écran, c'est dommage de les utiliser pour afficher des images de 600px de large …
Oui, tiens, j'avais vu passer ça sans essayer. Je viens de le faire.
Bon, je ne suis pas vraiment convaincu, je dois être difficile. Pas de moyen simple de télécharger tout un album pour un visiteur (j'ai vu qu'on pouvait télécharger soi-même l'album, et partager le lien de téléchargement, c'est mieux que rien, mais je trouve ça important que les visiteurs puissent le faire sans mon intervention).
Pour l'affichage des photos en plein écran, par défaut l'affichage est limité à 1600px de large, il faut modifier les préférences de chaque galerie pour mettre « Maximum display size = original » si on veut que les visiteurs heureux possesseur d'un grand écran aient du vrai plein écran.
C'est clairement conçu pour les photographes qui veulent vendre leurs photos plus que pour les amateurs qui veulent les donner, mais ça reste intéressant pour un amateur.
Bon, ceci dit, c'est vrai que c'est drôlement bien foutu. L'interface rappelle celle de flickr, mais en beaucoup plus personnalisable. Pas sûr que je craque pour $40/an, mais c'est tentant ;-).
Merci, mais j'étais déjà passé par ceux là, et je les ai éliminés assez vite :
Gallery: http://galleryproject.org/ « Gallery is going into hibernation. The Gallery team has decided to take a step back from actively maintaining this project. » :-(.
PhotoShow: Même problème que PhotoFloat : on télécharge une image de 800px de large et le navigateur upscale. Sur un grand écran, c'est flou. Je ne suis pas fan de la présentation par défaut (les vignettes volontairement toutes pâles), mais je vois que c'est thémable depuis peu, donc c'est sans doute contournable.
Mediagoblin : je n'ai pas trop creusé, mais j'ai vraiment du mal avec l'interface. Tous les thèmes que j'ai vu ont plein de fioritures et un affichage de la photo tout petit.
Oui, tu peux parler d'entiers infinis, vu que sur l'intervalle -2n .. 2n - 1, ça coïncide avec les entiers, et en dehors de l'intervalle, le compilateur a le droit de faire ce qu'il veut. Mais uniquement avec les entiers signés.
Euh, non, dans le deuxième cas le compilateur est en droit d'optimiser parce que a+b qui déborde est un comportement indéfini.
La même chose avec des unsigned int (arithmétique modulo 2n) et le compilateur n'a plus le droit (enfin, sur cet exemple en particulier, a+b 1 && b > 1 && a+b < 2) par exemple).
Un compilateur qui optimise avec une sémantique différente de celle de l'exécution ne serait pas très utile…
Pas vraiment de « Bouleversement », mais la numérotation 2.0 est surtout là pour marquer le fait qu'il y a cassage de compatibilité sur certains points. Le plus important est sans doute push.default qui passe de "matching" à "simple" (i.e. un push sans argument ne pousse que la branche courante pour faire court).
Je ne teste pas non plus (ce n'est pas par flème …), mais il me semble qu'il y a un cas particulier dans le code de GNU rm qui refuse de s'exécuter sur /. Après, on peut trouver des variantes tout aussi dangereuses et acceptées par rm ;-).
Bah non … je n'ai jamais eu l'occasion de tester en vrai, mais je viens de vérifier, « git clone --depth 1 » me donne bien un repo avec le même sha1 pour HEAD, j'ai pu commiter et pusher (le push n'est pas supporté d'après la doc par contre, ça marche « des fois mais pas toujours »). Bien sûr, un « git log » s'arrête là où l'historique local s'arrête.
Ça n'est pas parce que le commit parent est absent qu'on ne peut pas utiliser son sha1 comme référence. Git sait juste qu'il a une référence qu'il ne peut pas suivre parce qu'il n'a pas l'objet dans sa base locale.
Pour l'instant en tous cas, et à ma connaissance, le MPPA ne vise pas vraiment marché de masse avec des processeurs pas cher. Ça vise surtout les applications (embarquées) spécifiques pour lesquelles l'état de l'art est le FPGA voire ASIC ou le GPU.
Pareil ici. Pour l'instant, je fais du Digikam (et au pire, dans 20 ans j'aurai toujours des JPEG triés par répertoires même si j'ai changé d'OS et d'applications entre temps. Il coulera de l'eau sous les ponts avant que JPEG soit illisible) et j'utilise « Open in DarkTable » pour développer mes RAW (puis export depuis DarkTable vers Digikam pour récupérer le JPEG), mais j'aimerais un workflow mieux intégré. DarkTable a l'air vraiment bien …
[^] # Re: Un petit mot sur les performances
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 3.
Euh, pas le mien en tous cas.
find ... -exec commande {} +permet simplement d'exécuter une seule commandecmd fichier1 fichier2 ...(éventuellement découpée en plusieurs commandes s'il y a plus de fichiers que la limite de nombre d'arguments autorisée) au lieu de fairecmd fichier1; cmd fichier2; .... C'est plus rapide parce que ça réduit considérablement le nombre de fork+exec, mais pas pour le parallélisme.J'ai peut-être raté un truc, mais en tous cas la page de man de ma version de find ne contient pas le mot « parallel ».
[^] # Re: Et sinon, c'est quoi?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Firefox Panorama est dans de beaux draps. Évalué à 4.
Ctrl+Shift+E
[^] # Re: Super Logiciel
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche digiKam 4.2 est disponible. Évalué à 5.
Perso, depuis que j'ai touché à darktable pour l'édition, je n'utilise plus que ça. Le principe de darktable, c'est de l'édition non-destructrice : on ne touche pas à l'image originale, mais on définit un ensemble de filtres à lui appliquer. Résultat : on peut modifier a postériori n'importe quel filtre n'importe quand (par exemple, retailler une photo, faire plein d'autres choses, et décider que finalement je ne voulais pas la retailler).
Il faut une machine un peu puissante : tout se fait en 32bit/couleur/pixel, donc c'est quasi-inutilisable sur une machine 32 bits, et 4Go de RAM est un minimum.
Le gros défaut que je lui trouve, c'est que par défaut on stocke l'image originale (typiquement l'image RAW, mais ça marche aussi avec des .jpg comme image de départ) et un "sidecar file", petit fichier XML qui décrit la séquence de filtres à appliquer. Même si darktable fait très attention à la compatibilité avec les vieux formats, je n'ai pas tellement confiance pour le stockage à long terme (i.e. est-ce que je pourrais rouvrir les photos dans 20 ans ?), donc une fois que je suis content du boulot avec darktable, j'exporte en .jpg et je gère mes .jpg avec digikam (que je trouve par ailleurs bien meilleur pour le côté « gestion de collection » en lecture-seule sur les images). Digikam a aussi plus de connections à des outils externes que Darktable.
Je n'ai jamais utilise lightroom, mais si j'en juge par l'aspect des screenshots qu'on trouve sur le web, ça a l'air d'être une pâle copie de darktable, à moins que ça ne soit l'inverse ;-).
[^] # Re: owncloud
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 1.
Comme je l'ai dit dans un autre commentaire, je me suis tourné vers Piwigo. C'est du boulot, mais j'arrive à lui faire faire ce que je veux, c'est personnalisable à souhait.
Il y aurais une solution intermédiaire : utiliser les deux !
http://piwigo.org/forum/viewtopic.php?id=22446
Visiblement (je n'ai pas testé), un lien symbolique depuis l'arborescence owncloud vers celle de piwigo, et on peut utiliser owncloud pour la synchro et piwigo pour la galerie publique. Solution à considérer sérieusement pour les auto-hébergés …
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 5.
Bah, ça implique que la photo originale ne sera a peu près jamais utilisée pour l'affichage, et donc qu'on n'aura jamais une image plus grande que XXL. Je veux dire, dans la phrase « Donc si la photo originale est plus grande que la place disponible on utilisera la XXL. », la partie gauche de l'implication est une tautologie en pratique.
Avec la stratégie actuelle qui ne redimensionne pas côté client, si je configure XXL à la taille de mon écran plus epsilon, il ne sera jamais utilisé, et si je le configure à quelque chose de plus petit, j'aurais de la place perdue sur l'écran.
Oui, ce que je voulais dire, c'est le redimensionnement au pixel près comme le fait Google+ par exemple. Si un visiteur vient avec un navigateur 1 pixel plus grand, il recalcule toute la photo. Bourrin, mais efficace ;-).
Honnêtement, si on considère que l'affichage avec une taille adaptée à l'écran est une fonctionnalité importante pour l'utilisateur, alors le fait qu'elle soit désactivée par défaut et disponible dans un plugin incompatible avec une bonne partie des thèmes ne peut pas être considéré comme satisfaisant.
Au final, le thème modus n'est pas loin de faire ce que je veux, et il a le bon gout de redimensionner côté client si besoin, mais du coup le choix du thème est dicté par une fonctionnalité qui aurait du être indépendante du reste de la mise en forme, donc l'effet obtenu est à peu près l'inverse de celui recherché avec un système de plugin/thèmes. Et le thème en question est incompatible avec PersoFavicon et LocalFiles Editor pour le CSS (j'ai déjà rapporté les bugs, mais c'est juste pour illustrer à quel point on peut galérer à jongler entre les trucs incompatibles).
J'ai augmenté les tailles XXL (=> WQHD), XL (=> FHD) et L, donc les gens qui ont des écrans de ces tailles ont maintenant des images sans redimensionnement en diaporama plein écran, et qui remplissent bien l'espace modulo downsizing dans les autres configs. Ce que je voulais, mais je trouve ça dommage d'avoir du galérer autant pour arriver à ce que tous les hébergeurs commerciaux « classiques » font out-of-the-box.
Bon, voilà, maintenant que j'ai bien râlé, il faut quand même que je positive un peu : j'ai craqué pour un abonnement sur piwigo.com (http://mmoy.piwigo.com/), on a échangé plusieurs mails en privé avec Pierrick et le support est hyper réactif. Ça fait vraiment plaisir de voir des gens baser leur business-model sur le libre et l'absence de captivité de l'utilisateur !
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 3.
D'ailleurs, flickr fait du downsizing (en gros, il fait l'inverse de piwigo : plusieurs tailles d'images en statique, il prend juste au dessus et il downsize dans le navigateur), je ne l'aurais pas remarqué sans l'inspecteur de Firefox.
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 2.
Mais avec des photos haute résolution (i.e. pas redimensionnée avec la résolution max d'un appareil photo même modeste), ça fait un gap énorme entre XXL et l'original.
Je crois que ça a quand même bien progressé ces temps-ci. C'est clair que l'idéal pour l'utilisateur est encore le retaillage sur demande côté serveur, mais c'est super gourmand, tout le monde n'a pas la puissance de calcul de google chez son hébergeur ;-).
Enfin, tout est question de goût, mais moi je préfère un petit downscaling et une image qui remplit bien mon écran, surtout en mode slideshow.
Effectivement, c'est plutôt mieux sans Automatic Size.
Mais si je puis me permettre d'être encore désagréable ;-) c'est le genre de trucs que je trouve très pénible avec ces architectures à plugins : on a une montagne de fonctionnalités, mais au final elles finissent par être toutes incompatibles les unes avec les autres.
(par exemple, si un de mes visiteurs choisit un autre thème, il n'aura plus droit à automatic size parce que je l'ai désactivé pour un thème).
[^] # Re: Pfff
Posté par Matthieu Moy (site web personnel) . En réponse au journal Non pas le chanteur. Évalué à 2.
Cherche mieux … ;-)
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 2.
Euh, oui, toutes.
2560x1440, c'est 3.6 mégapixels. N'importe quel appareil photo fait deux fois ça aujourd'hui (pas toujours pour de bonnes raisons, mais c'est un autre débat).
Bienvenue dans le futur : mon appareil photos a deux fois plus de pixels que ça, et ce n'est pas énorme pour un réflexe. Un full-frame haut de gamme fait 4 fois ça.
[^] # Re: Piwigo
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 2.
Merci pour la réponse détaillée, et même si j'ai du mal à trouver mon bonheur, bravo pour le boulot sur Piwigo ! (sur le modèle économique et le côté « ne pas retenir l'utilisateur captif », c'est juste parfait !).
Pas dispo sur piwigo.com, c'est bien ça ?
Presque. La taille XXL, ça a l'air grand comme ça, mais ça laisse encore des grosses marges autour de l'image sur un écran WQHD (2560x1440). En mode plein écran, j'utilise un peu moins de la moitié des pixels de mon écran …
À mon avis, faudrait soit ajouter un XXXL, soit basculer en mode « image originale » sur les écrans plus grands que XXL.
Effectivement, celui-là est pas mal.
Si j'active celui-là, le plugin Automatic Size ne fait plus effet, l'ensemble de la page est limité à un peu moins de 1000px de large (i.e. moins de la moitié de mon écran).
Idem, même avec le plugin automatic size, les images sont toutes petites.
Là, c'est encore plus petit.
Idem.
Est-ce vraiment une fonctionnalité si peu demandée pour être dans un plugin incompatible avec autant de thèmes ? Enfin, ça a l'air d'être une question rhétorique et désagréable comme ça, mais je finis vraiment par croire que ça n'intéresse personne sauf moi ;-).
[^] # Re: owncloud
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 2.
C'est vrai que l'interface de galerie d'images est simple mais assez bien faite (des miniatures, un affichage en plein écran). Mais encore une galerie qui fait de l'upscaling côté client à partir d'une image pas si grande que ça (1024px sur la démo en ligne) :-(.
[^] # Re: Non-libre
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 1.
J'avais déjà trouvé le forum de feedback, et voté pour les entrées correspondantes :
http://feedback.smugmug.com/forums/17723-smugmug/suggestions/1104583-a-bulk-gallery-download-button-for-my-visitors
http://feedback.smugmug.com/forums/17723-smugmug/suggestions/299234-give-us-the-ability-to-save-default-settings-for-n
[^] # Re: Zenphoto
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 2.
Pour tous les thèmes que je vois dans la démo ( http://www.zenphoto.org/demo/album2/ ), c'est un design de largeur fixe, et en l’occurrence un qui utilise moins du quart de la largeur de mon écran.
Bon, je sais que ça fait 3 ou 4 fois que je fais mon malin avec mon gros écran en une entrée de forum, mais tant qu'à avoir plein de mégapixels dans son appareil photos, et d'autres pleins de mégapixels sur son écran, c'est dommage de les utiliser pour afficher des images de 600px de large …
[^] # Re: Gallery, PhotoShow, MediaGoblin
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 1.
Sur la démo en ligne http://www.photoshow-gallery.com/demo/ par exemple
http://www.photoshow-gallery.com/demo/?f=Australia%2FAustralia10.jpg
Affiche en fait l'image réduite (1000x665, pas ridicule, mais pas mal flou une fois upscalé en 1695x1164 par exemple chez moi):
http://www.photoshow-gallery.com/demo/?t=Img&f=Australia%2FAustralia10.jpg
J'ai testé sur une instance auto-hébergée, j'ai des résultats un peu différents (1200 px) mais toujours de l'upscaling côté client.
J'ai l'impression que le « 1200 » est en dur dans le code, dans src/classes/Provider.php :-(.
[^] # Re: Non-libre
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 1.
Oui, tiens, j'avais vu passer ça sans essayer. Je viens de le faire.
Bon, je ne suis pas vraiment convaincu, je dois être difficile. Pas de moyen simple de télécharger tout un album pour un visiteur (j'ai vu qu'on pouvait télécharger soi-même l'album, et partager le lien de téléchargement, c'est mieux que rien, mais je trouve ça important que les visiteurs puissent le faire sans mon intervention).
Pour l'affichage des photos en plein écran, par défaut l'affichage est limité à 1600px de large, il faut modifier les préférences de chaque galerie pour mettre « Maximum display size = original » si on veut que les visiteurs heureux possesseur d'un grand écran aient du vrai plein écran.
C'est clairement conçu pour les photographes qui veulent vendre leurs photos plus que pour les amateurs qui veulent les donner, mais ça reste intéressant pour un amateur.
Bon, ceci dit, c'est vrai que c'est drôlement bien foutu. L'interface rappelle celle de flickr, mais en beaucoup plus personnalisable. Pas sûr que je craque pour $40/an, mais c'est tentant ;-).
[^] # Re: Gallery, PhotoShow, MediaGoblin
Posté par Matthieu Moy (site web personnel) . En réponse au message (Auto) Hébergement de galeries photos. Évalué à 1.
Merci, mais j'étais déjà passé par ceux là, et je les ai éliminés assez vite :
Gallery: http://galleryproject.org/ « Gallery is going into hibernation. The Gallery team has decided to take a step back from actively maintaining this project. » :-(.
PhotoShow: Même problème que PhotoFloat : on télécharge une image de 800px de large et le navigateur upscale. Sur un grand écran, c'est flou. Je ne suis pas fan de la présentation par défaut (les vignettes volontairement toutes pâles), mais je vois que c'est thémable depuis peu, donc c'est sans doute contournable.
Mediagoblin : je n'ai pas trop creusé, mais j'ai vraiment du mal avec l'interface. Tous les thèmes que j'ai vu ont plein de fioritures et un affichage de la photo tout petit.
[^] # Re: Pascal...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
Oui, tu peux parler d'entiers infinis, vu que sur l'intervalle -2n .. 2n - 1, ça coïncide avec les entiers, et en dehors de l'intervalle, le compilateur a le droit de faire ce qu'il veut. Mais uniquement avec les entiers signés.
Lire par exemple ceci, très intéressant sur les undefined behavior et leurs conséquences : http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
[^] # Re: Pascal...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
Euh, non, dans le deuxième cas le compilateur est en droit d'optimiser parce que a+b qui déborde est un comportement indéfini.
La même chose avec des unsigned int (arithmétique modulo 2n) et le compilateur n'a plus le droit (enfin, sur cet exemple en particulier, a+b 1 && b > 1 && a+b < 2) par exemple).
Un compilateur qui optimise avec une sémantique différente de celle de l'exécution ne serait pas très utile…
# Bouleversement
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git 2.0. Évalué à 10.
Pas vraiment de « Bouleversement », mais la numérotation 2.0 est surtout là pour marquer le fait qu'il y a cassage de compatibilité sur certains points. Le plus important est sans doute push.default qui passe de "matching" à "simple" (i.e. un push sans argument ne pousse que la branche courante pour faire court).
[^] # Re: mais encore
Posté par Matthieu Moy (site web personnel) . En réponse au journal CodeLauncher: un petit serveur maison pour exécuter rapidement du code C ou Python. Évalué à 3.
Je ne teste pas non plus (ce n'est pas par flème …), mais il me semble qu'il y a un cas particulier dans le code de GNU rm qui refuse de s'exécuter sur /. Après, on peut trouver des variantes tout aussi dangereuses et acceptées par rm ;-).
# Très bonne analyse
Posté par Matthieu Moy (site web personnel) . En réponse au journal Google moins?. Évalué à 2.
Tout est dit là : http://xkcd.com/1361/
[^] # Re: Ça me ferait beaucoup rire
Posté par Matthieu Moy (site web personnel) . En réponse au journal Google moins?. Évalué à 3.
Google reader plutôt je pense (lecteur RSS).
[^] # Re: Mensongeries
Posté par Matthieu Moy (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Bah non … je n'ai jamais eu l'occasion de tester en vrai, mais je viens de vérifier, « git clone --depth 1 » me donne bien un repo avec le même sha1 pour HEAD, j'ai pu commiter et pusher (le push n'est pas supporté d'après la doc par contre, ça marche « des fois mais pas toujours »). Bien sûr, un « git log » s'arrête là où l'historique local s'arrête.
Ça n'est pas parce que le commit parent est absent qu'on ne peut pas utiliser son sha1 comme référence. Git sait juste qu'il a une référence qu'il ne peut pas suivre parce qu'il n'a pas l'objet dans sa base locale.
[^] # Re: J'ai pas trouvé...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
Pour l'instant en tous cas, et à ma connaissance, le MPPA ne vise pas vraiment marché de masse avec des processeurs pas cher. Ça vise surtout les applications (embarquées) spécifiques pour lesquelles l'état de l'art est le FPGA voire ASIC ou le GPU.
[^] # Re: Celles qui m'ont marquées jusque là
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche darktable 1.4. Évalué à 1.
Pareil ici. Pour l'instant, je fais du Digikam (et au pire, dans 20 ans j'aurai toujours des JPEG triés par répertoires même si j'ai changé d'OS et d'applications entre temps. Il coulera de l'eau sous les ponts avant que JPEG soit illisible) et j'utilise « Open in DarkTable » pour développer mes RAW (puis export depuis DarkTable vers Digikam pour récupérer le JPEG), mais j'aimerais un workflow mieux intégré. DarkTable a l'air vraiment bien …