da scritch net works - Mot-clé - rss - Commentaires

Progressivement en ‹img /› - Da Scritch

Da Scritch — Wed, 18 Jun 2014 08:38:14 +0200

Boris, tu spoiles le chapitre suivant sans le savoir ;)

Progressivement en ‹img /› - Boris

Boris — Wed, 18 Jun 2014 08:35:04 +0200

1) Merci pour tes articles, c'est très intéressant et agréable à lire

2) Merci Frédéroc, j'ai aussi appris plein de choses dans ton commentaire

3) Quelques petites réflexions sur ce que j'ai pu lire ci-dessus sur le LazyLoading :

"Si votre javascript ne se charge pas ou plante brusquement, les images n'apparaissent absolument pas"
Contre le plantage du JS, point de salut car il n'y a pas vraiment de reprise sur incident. En revanche, il est très possible d'utiliser la balise <noscript> pour avoir une image en fallback en cas de désactivation de JavaScript.

"L'indexation des images par ces mêmes moteurs ne se fait plus ;"
Encore une fois, l'usage d'une balise <noscript> peut compenser ce problème.

"Cela gâche l'impression d'une page, puisque les images ne sont pas chargées par défaut, il faut faire défiler entièrement la page dans son navigateur avant, et encore… ;"
Tout dépend comment les images sont chargés, elles peuvent être pré-chargées en suivant une certaine distance par rapport au viewport (par exemple, 300px sous la ligne de flottaison). Si tu ne scrolles pas comme un grand malade de l'index, ça devrait faire l'affaire.

"En cassant le web sémantique, on casse aussi l'usage de services tiers comme les flux RSS, ou encore les lecteurs différés comme Wallabag ou Pocket puisque les images n'y apparaîtront jamais ;"
<noscript> !

"Je me suis rendu compte que la plupart des sites qui utilisent de genre d'artifice ont du texte au kilomètre, suivi d'un nombre très conséquent d'images, le tout préfixé par un titre dans le genre « Les 500 images de clowns se cassant la gueule qui font rire » ce qui leur assure un fort trafic."
Non, tu as aussi un véritable besoin de LazyLoading dans les vitrines e-commerce qui affichent plusieurs dizaines de produits en mosaïque sur une même page. On le trouve aussi de plus en plus dans les WebDoc, ces formats longs de la Presse en ligne.

"Déjà, enlève 50% de tes javascripts de pubs, tasse tes assets, optimise la compression de tes images"
Et si mon business model repose sur la pub, que le reste est déjà fait et que quand je simplifie ma maquette, la transformation e-commerce est moins bonne. Cas vécu, validé et testé ;)

Bon allez, si ça se trouve, tu dis tout ça dans la suite !

Progressivement en ‹img /› - Da Scritch

Da Scritch — Wed, 18 Jun 2014 08:30:46 +0200

Y'en avait qu'un. Je ne cautionne pas le meurtre de masse.

Progressivement en ‹img /› - Boris

Boris — Wed, 18 Jun 2014 08:24:17 +0200

Je ne sais pas si mon premier commentaire est passé, il y a une faute dans "Sauf quelque SEO-LOL qui me soutenait" <= il manque le pluriel à "quelque" et "soutenait". Ou alors il n'y en avais qu'un :) ?

Progressivement en ‹img /› - Boris

Boris — Wed, 18 Jun 2014 07:52:39 +0200

Relecture : "sauf quelque SEO-Lol..." il manque le pluriel à quelques et la conjugaison qui va avec.

Progressivement en ‹img /› - Da Scritch

Da Scritch — Wed, 11 Jun 2014 07:39:04 +0200

Hello Frédéric,

C'est un plaisir de se faire "corriger" par vous car vos interventions sont toujours fort à propos

J'avoue que j'ai pas repris mes tests faits en 2003, mais à l'époque, le gain de poids oscillait entre 5% et 20% sur un Photoshop 5.5.
Pour ce qui est des vaguelettes plutôt que du cosinus discret, je plaide coupable : la blague à base de vaguelettes est plus facile

Progressivement en ‹img /› - Frédéric Kayser

Frédéric Kayser — Wed, 11 Jun 2014 04:42:00 +0200

Je me sens obliger de corriger légèrement l’article surtout concernant la partie affichage entrelacé et progressif.
Pour commencer l’explication de l’entrelacement du gif est légèrement fausse ou pas claire.
Si dans un gif non-entrelacé les lignes qui constuent l’image sont enregistrées dans l’ordre 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15, dans un gif entrelacé on aurait (0,8) (4,12) (2,6,10,14) (1,3,5,7,9,11,13,15), les parenthèses matérialisent les 4 passes successives. Une façon mathématique de voir la chose est de mettre dans la première passe les lignes qui sont multiples de 8, dans la deuxième les multiples de 4 (mais sans les multiples de 8 qu’on déjà transmis), dans la troisième les multiples de 2 (mais sans les multiples de 4 et 8) et dans la dernière passe ce qui reste (les lignes impaires en fait).

En suite et c’est le point sur lequel je tiens vraiment à corriger l’article, une image entrelacée ou progressive ne produit pas nécessairement un fichier plus gros. Il faut toutefois tenir compte du format d’image utilisé si l’on veut essayer de généraliser.

PNG) Oui, les images entrelacées occupent généralement plus de place dans le fichier, c’est même pratiquement toujours le cas (sauf cas clinique).

GIF) Ça fait un moment que je n’ai pas tenté l’expérience, mais l’entrelacement ne nuit pas nécessairement à la compression, le logiciel d’optimisation ImageOptim dont la réputation n’est plus à faire sur OS X réalise d‘ailleurs deux appels distincts à gifsicle, une fois sans entrelacement et une fois avec (cf. https://github.com/pornel/ImageOpti...) :
} else if (fileType == FILETYPE_GIF) {
if ([defs boolForKey:@"GifsicleEnabled"]) {
GifsicleWorker *w = [[GifsicleWorker alloc] initWithFile:self];
w.interlace = NO;
[runLater addObject:w];

w = [[GifsicleWorker alloc] initWithFile:self];
w.interlace = YES;
[runLater addObject:w];
}

JPEG) Là clairement non, un enregistrement progressif ne sera que rarement plus gros.
Il faut bien comprendre qu’un JPEG séquentiel et un JPEG progressif contiennent exactement les mêmes informations, il n’y a pas de données supplémentaires ajoutées pour réaliser l’effet progressif. En fait tout ce qui change est l’ordre dans lequel on transmet les informations :
Dans un JPEG séquentiel chaque "data-unit" (en gros une matrice de 8x8 contenant un coefficient DC et 63 coefficients AC) est transmis intégralement, les data-units sont regroupés en MCU (ou macro-block), chaque MCU permet de reconstituer une petite surface de l’image souvent 8x8, 16x8 ou 16x16 pixels (c’est lié au sous-échantillonnage chroma) et contient donc généralement tous les composants « couleur ». Comme le JFIF fonctionne dans un espace YCbCr (et non RVB comme on le croit parfois), sans sous-échantillonnage chroma un MCU contient un data-unit pour le composant Y et de même pour Cb et Cr donc 3 data-units en tout, avec un sous-échantillonnage chroma de type 4:2:0 un MCU contient 4 data-units pour le composant Y, et un data-unit pour Cb et Cr donc 6 data-units en tout (ce qui permet de reconstruire un carré de 16x16 pixels, contre 8x8 précédemment). Dans le fichier les MCU se suivent et décrivent l’image de gauche à droite et de haut en bas.
Dans un JPEG progressif on va fractionner les data-units en regroupant des coefficients semblables dans différentes passes (ou scans), la première passe contient nécessairement le coefficient AC seul, très souvent on regroupe les trois composants dans cette passe*, celle-ci contient donc en gros 1/64ème des données de l’image. Après le format JPEG offre une liberté énorme pour transmettre le reste de coefficients, il n’y pratiquement que deux contraintes, une passe ne peut désormais plus que contenir un seul composant (Y ou Cb ou Cr), si plusieurs coefficients sont envoyés ils doivent se suivre le long du chemin en zig-zag qui décrit la matrice de 8x8. On peut donc imaginer des centaines voire des milliers de façons différentes d’envoyer le reste des données, les deux extrêmes étant :
- 3 passes (une pour Y, une pour Cb et une pour Cr) avec à chaque fois la totalité des coefficients AC (avec la première passe pour DC, on a donc un minimum de 4 passes)
- 189 passes (63 pour Y, 63 pour Cb et 63 pour Cr) avec dans chacune un seul coefficient AC.

Mais ce n’est pas tout, ce que je viens de décrire est juste l’approche « spectrale » de l’enregistrement progressif, car il est également possible de ne pas envoyer la totalité d’un coefficient, mais juste une fraction de celui-ci (les bits les plus forts), le reste (les bits les plus faibles) seront envoyés dans des passes ultérieures… et nécessairement un seul à la fois. Ceci constitue l’aspect « raffinement progressif ».
Je me doute bien qu’à ce point vous êtes très probablement complètement largués surtout sans illustrations… Maintenant pourquoi une image progressive prendrait-elle en définitive moins de place, en fait lorsqu’on émet juste quelques coefficients qui se suivent il y a un peu plus de chances pour qu’ils soient semblable (si ce n’est en valeur au moins en grandeur) et l’étape suivante de la compression (la réduction de l’entropie) va un peu mieux fonctionner dans ce cas, en gros en cassant les data-units en différents groupes de coefficients, on associe ces derniers à leurs semblables et ce regroupement facilite légèrement la compression.
C’est pourquoi des scripts comme JPEGrescan tentent quelques dizaines de façons différentes de produire un JPEG progressif et gardent la méthode qui produit le plus résultat pour un fichier donné (désormais mozjpeg fait ça tout seul).

Ce qui c’est passé historiquement (et c’est un peu triste), les spécifications JPEG n’étaient pas encore finalisées et publiées mais l’attente vis-à-vis de ce format était telle que diverses implémentations ont commencées à fleurir dès le début des années 90, comme les specs ne définissaient pas à proprement parler un format de fichier et étaient totalement agnostiques vis-à-vis des espaces colorimétriques C-Cube a proposé un format d’échange : le JFIF qui est rapidement devenu un standard de fait et qui est officiellement devenu la partie 5 des spécifications JPEG en… 2013. Le format connait donc un succès fulgurant aidé par l’apparition d’une bibliothèque libre (libjpeg d’IJG) permettant de décoder et d’encoder des images JPEG, au début seul le JPEG séquentiel et même de manière encore plus restrictive le JPEG "baseline" est supporté, comme l’article l’a expliqué la lenteur des moyens de communication numérique de l’époque poussent à l’adoption du JPEG progressif (ce dernier étant largement plus complexe il a fallu un peu plus de temps pour disposer d’en/décodeurs pleinement inter-opérables*), donc en quelques années un boom énorme se produit des images par millions, plein de logiciels qui se proclament à même de gérer du JPEG (et une énorme majorité à l’aide la libjpeg d’IJG)… mais à vrai dire, à ce point, on a juste un tiers des spécifications qui sont réellement exploitées; si vous lisez les specs un jour (c’est un gros pavé tout de même, aujourd’hui il est gratuit ça aide… car au début c’était payant) vous remarquerez que certains chapitres vont vous sembler très étranges car on ne croise pas souvent de JPEG dotés de :
- la compression sans perte de données (ce n’est pas une grande perte, c’était pas terrible et désavoué par JPEG-LS -un cousin assez éloigné du JPEG pur jus- et JPEG-XT… le petit nouveau de cette année)
- une profondeur de 12-bits par composant (des images HDR)
- l’encodage arithmétique (des fichiers 7% plus petit, mais protégé par des brevets d’IBM qui sont tombés depuis, la libjpeg version 7 permet de l’utiliser)
- l’enregistrement hiérarchique (des images dont la définition ou la résolution augmentent progressivement d’un facteur deux, un seul fichier peut par exemple contenir la même image en 320x200, 640x400 et 1280x800 chaque taille reposant sur les données de la précédente pour ne pas prendre trop de place, un truc jugé inutile il y a une quinzaine d’années…)

Aujourd’hui il est malheureusement trop tard pour espérer rajouter tout ça vu les incompatibilités que cela provoquerait ; mais au moins vous ne serez plus dupe : aucun logiciel ne supporte pleinement le JPEG. Il y a peut-être un effet pervers lié au succès et la situation de quasi monopole de la libjpeg (et dérivés -turbo) qui fait très bien ce qu’elle fait, mais ce qu’elle fait ne couvre malheureusement pas la totalité des spécifications.

* En fait on arrive toujours pas décoder universellement du JPEG, essayez d’ouvrir cette image dans Adobe Photoshop : http://frdx.free.fr/champilampe-kil... (illustration de ce qui se passe si l’on ne met pas les trois composants dans la première passe d’un JPEG progressif)

Petite démo relative de la taille inférieure des JPEG progressifs.
Image séquentielle :
http://frdx.free.fr/champilampe-seq...
16567 octets

Image progressive (produite à partir de la précédente avec jpegtran -progressive) :
http://frdx.free.fr/champilampe-pro...
16193 octets

Image progressive optimisée par mozjpeg (jpegtran -mais celui de mozjpeg-) :
http://frdx.free.fr/champilampe-moz...
16160 octets

Si vous êtes super curieux vous pouvez analyser les différentes passes des images précédentes avec JSK (JPEG Scan Killer) et également trouver quelques illustrations liées à l’encodage JPEG ici :
http://encode.ru/threads/1800-JSK-J...

Et par pitié ne pas parler de vaguelettes concernant JPEG car c’est un concept propre à JPEG2000, JPEG repose sur la DCT (Transformée en Cosinus Discrète) qui permet de passer d’une représentation spatiale (des pixels en 2D) à une représentation spectrale (des coefficients), la transformation inverse produisant… l’inverse et si l’on a un peu raboté les coefficients entre temps l’image sera peut-être qu’un peu déformée, mais si ça se trouve les coefficients rabotés sont assez facile à stocker sous forme compressée… et on peut peut-être régler la profondeur du coup de rabot pour en faire un paramètre de qualité permettant de choisir entre une image relativement fidèle mais lourde et une image altérée mais plus légère, c’est fou ce truc !

Petite discussion entre podcasteurs - gnieark

gnieark — Sat, 14 Apr 2012 11:54:59 +0200

Hello

Merci surtout à toi de ta participation, Guru du podcast ;). Tu peux évidemment reprendre le son su podcast sur ton blog.

Le Web a 20 ans - Da Scritch

Da Scritch — Sun, 07 Aug 2011 12:01:04 +0200

Oui, mais j'ai rappelé à un ami que les tables, et donc le align="char" qui me manque tant http://dascritch.net/post/2008/10/2... est utilisé par Open Office et dans les buffers de copié-collé en environnement Unix. Là, on est bien au-delà du web.

Le Web a 20 ans - JcDenis

JcDenis — Sun, 07 Aug 2011 11:34:41 +0200

Sympa,
Juste que pour le dernier je pense qu'il revient en force notament avec des applis et de OS en (?)html

[ping] Del.icio.us via rss - da scritch net works

da scritch net works — Fri, 15 Apr 2011 17:05:12 +0200

Les sites des codeurs sont les plus mals codés

Oh mince... y'a un accroc dans mon plan. Cela s'appelle une transition à l'arrache....

Badges - Da Scritch

Da Scritch — Thu, 20 Jan 2011 00:11:39 +0100

Et effectivement, moi tout comme le WhatWG et d'autres considèrent que le status de "buzzword" abusé pour HTML5 est susceptible de devenir une nuisance en mélangeant les genres http://gigaom.com/2011/01/19/the-tr...

Badges - Da Scritch

Da Scritch — Wed, 19 Jan 2011 23:09:01 +0100

paulrouget Yesterday, the w3c proposed a HTML5 logo (with a big 5). Today, the WHATWG renames HTML5 HTML. Hmmmm.... http://blog.whatwg.org/?p=12300

dascritch @paulrouget I would like to comprendre quelque chose, là...

paulrouget "ça va troller chérie"

paulrouget @dascritch bah moi aussi...

dascritch @paulrouget Déjà, pourquoi réduire au HTML alors qu'il y a de la CSS, du SVG, du XML, du Javascript et du header HTTP...

dascritch @paulrouget Faudrait un nouveau badge : <HTML5> <?>

Les coulisses du site en Septembre - Solarus

Solarus — Mon, 08 Feb 2010 13:26:24 +0100

Elle est courageuse cette Anne Onyme pas vraiment Onyme. Elle s'est faite avoir par les ruses de sioux de Apache. :D

Les coulisses du site en Septembre - xylpho

xylpho — Mon, 08 Feb 2010 12:47:55 +0100

Fear ! El vengeur masqué du Whois est dans la place ! Il faut _vraiment_ que tu corriges ce bug sur ton textarea c'est très pénible

Les coulisses du site en Septembre - Da Scritch

Da Scritch — Mon, 08 Feb 2010 12:26:25 +0100

Je me demande en quoi je suis contre la liberté ? Celle de spammer à tout va les gens ? c'est eux pardon vous qui prenez des libertés contre les autres. Et ça, c'est punissable par la loi.
Toutes ces boites sont en infraction caractérisées, et mon témoignage et expertise a même été sollicité par plusieurs DGRCCF. Dont au moins une fois sur la base de ce que je laisse entrevoir dans ce billet. Il y a bien une raison, non ?

Et vous voulez prouver quoi ? Que vous savez vous servir d'une base whois ? La belle affaire ! La même est parfaitement respectable, identifiée dans les lois Françaises, très bien gérée par mon prestataire et me fait suivre toutes les réclamations, ce qui n'était même pas le cas de la moitié de ces adresses. Bref, vos arguments n'ont aucun rapport, sinon vainement tenter de me faire peur.

Sur vous, je sais que vous êtes arrivé sur ma page en cherchant "Audrey Pagenel", que vous êtes abonné chez Free, dans la commune de Boulogne Billancourt, que vous bossez pour Barvit SA aka Sports Center, que votre ordinateur n'est dangereusement pas mis à jour (d'où le bandeau qui vous a fait prendre vapeur), et qu'une de vos licences logicielles semble avoir un souci. Et tout ça, je le fais uniquement à partir des informations que vous me laissez bien obligeamment et que je suis tenu de conserver par la loi LCEN. Je pourrais en écrire plus, mais votre candeur et votre réaction puérile n'en vaut pas la peine.

Les coulisses du site en Septembre - Anonyme

Anonyme — Mon, 08 Feb 2010 12:20:46 +0100

Je voulais laisser mon grain de sel, c.à.d. quelques informations à propos d'une des sociétés listées au-dessus, mais quand je me suis aperçu que vous étiez contre la liberté, j'ai décidé de vous dire adieu.
Si à l'avenir vous continuez à ne pas respecter vos visiteurs et ne les laissez pas utiliser l'explorateur qu'ils ont envie d'utiliser, je me ferai le plaisir de vous inscrire dans la liste des sites non respectueux de leurs visiteurs et qui portent atteinte à la liberté de chacun.
Je ne vous salue pas.

Et ce n'est pas la peine de montrer aux gens que vous savez fliquer vos visiteurs, j'en sait plus sur vous que vous n'en savez sur moi :
domain: dascritch.net
reg_created: 2004-09-28 14:48:02
expires: 2010-09-28 14:48:02
created: 2006-07-11 06:54:28
changed: 2009-11-10 11:20:32
transfer-prohibited: yes
ns0: a.dns.gandi.net
ns1: b.dns.gandi.net
ns2: c.dns.gandi.net
owner-c:
nic-hdl: XM178-GANDI
organisation: ~
person: Xavier MOUTON-DUBOSC
obfuscated: Obfuscated by Gandi
address: (Gandi) 15 place de la Nation
zipcode: (Gandi) 75011
city: (Gandi) Paris
country: (Gandi) France
phone: (Gandi) +33.170377666
fax: (Gandi) +33.143730576
Le tout est accessible (et bien plus encore) à tous sur www.whois.com

[ping] Appel à tests pour mobiles - da scritch net works

da scritch net works — Fri, 23 Oct 2009 21:36:10 +0200

♬ Dring Dring Dring ♩ ... ♬ Dring Dring Dring ♩

Vous vous êtes toujours demandé quel est le con qui a eu l'idée de commercialiser des sonneries stupides qu'on entend dans la rue sortir des téléphones portables ? Ben j'ai eu un peu ma contribution à ce grand apport culturel pour l'industrie du...

Les coulisses du site en Septembre - zaza

zaza — Wed, 08 Jul 2009 23:29:52 +0200

je suis dingue

Un point clair qui a cinq ans - ZeuBeuBeu

ZeuBeuBeu — Wed, 20 Aug 2008 00:32:17 +0200

Ayé, a écrit un truc :)