Blog & White

Une recette d'Owi Owi Fouette-moi dont la cuisson a été modifiée.

Ingrédients

• 125 g farine
• 1/4 c. à café poudre à lever
• 1 pincée sel
• 25 g cacao
• 70 g eau bouillante
• 85 g huile d'olive sans trop de goût
• 90 g chocolat noir fondu
• 1 œuf
• 140 g sucre brun
• 55 g sucre blanc
• 1 c. à café extrait de vanille

• 1 moule carré de 20 cm de coté chemisé de papier sulfurisé
• 1 «  caleçon à brownie  » adapté au moule

Le caleçon à brownie est une bande de plusieurs épaisseurs de tissu placée mouillée autour du moule pour empêcher le gâteau de cuire par les bords. De cette manière, les bords ne sont pas plus cuits que le centre.

Préparation

Préchauffer le four à 160 °C.

Mélanger au fouet dans un saladier la farine, la poudre à lever et le sel. Dans un second saladier, fouetter à la main le cacao avec l'eau. Ajouter

l'huile et fouetter. Ajouter le chocolat fondu et fouetter. Ajouter l'œuf et fouetter jusqu'à obtenir une préparation d'aspect uniforme. Ajouter les sucres et l'extrait de vanille, fouetter. Ajouter en une fois le mélange de farine et l'incorporer avec une spatule jusqu'à ce qu'on ne voie plus de farine.

Verser la préparation dans le moule chemisé, réparir à l'aide de la spatule. Mouiller le caleçon à brownie, l'essorer et le placer sur la grille du four, puis y placer le moule. Faire cuire 30 min. À la sortie du four, saupoudrer de flocons de sel.

Laisser refroidir sur une grille, puis démouler le brownie avec le papier sulfurisé.

(Publié à l'origine sur Mastodon)

J'ai été appelé du contingent dans la cavalerie, au sein de cette grande institution nécessairement bien organisée.

J'ai reçu un papier me disant de me rendre à la gare de Colmar le lendemain de mon anniversaire. Je me dis

«  oh y sont sympas, y m'appellent pas le jour de mon anniv, alors que normalement ça aurait dû être ce jour là.  »

À la gare de Colmar, y'a personne. Un peu plus tard, y'a un autre gars qui arrive, tout aussi paumé que moi. Puis deux autres. Puis quelques autres. Et on attend. Au bout de quelques heures, arrivent des militaires qui appellent des noms, mais pas le mien ni celui de 3 autres gars. Alors on leur demande ce qu'on est censés faire. Ils savent pas, mais nous emmènent à la caserne de Colmar (nous 4 on est censés aller dans diverses casernes de la brigade franco-allemande, en Allemagne donc). On passe la nuit à la caserne de Colmar, juste nous 4 dans un dortoir pour 16. Et la journée aussi. L'après-midi, des militaires de la caserne de Donaueschingen viennent nous chercher et on part en minibus (sjmsb). On arrive l'après-midi à la caserne, c'est là que 2 des gars devaient aller. Ils appellent la caserne d'Immendingen pour que quelqu'un vienne me chercher (je suppose qu'ils ont fait pareil pour le 4è gars qui devait aller je sais pas où). Je passe quelques heures au poste de garde, puis le soir deux militaires arrivent en P4 et m'emmènent à mon nouveau chez-moi. On est vendredi soir, 22h passées, après l'extinction des feux. On me met dans une chambre avec 3 autres gars tout aussi paumés que moi. Sauf qu'eux sont arrivés avant le week-end, quand le magasin du corps était encore ouvert. Donc ils ont eu leur paquetage, y compris leurs treillis. Moi pas. Donc j'ai passé le week-end habillé en civil dans une caserne, à me retrouver en queue de colonne parce que j'étais pas habillé pareil que les autres et que ça faisait désordre. Le lundi, j'ai eu mon matériel, et pour je sais plus quelle raison je me suis changé dans un bureau, pas dans ma chambre. Après c'est un peu flou, mais je suis passé devant l'officier orienteur, je lui ai dit que j'avais un diplôme d'ingé en informatique et au bout de 2 jours j'ai changé d'escadron, passant d'un escadron de combat à celui de commandement et de logistique (ECL). Quand les autres gens partaient quelques semaines faire leurs classes, moi bizarrement je suis resté.

Dans la cellule OPEX (opérations extérieures) du BOI (bureau de machin et de trucs, j'ai oublié) il y avait un appelé qui savait utiliser un ordinateur et qui finissait son service deux mois plus tard. Je devais le remplacer. C'est lui qui, dans le bureau, m'a appris à saluer et à faire des quarts de tour et des demi-tours. Les grades, je les ai appris sur le tas. La cellule OPEX avait besoin d'un outil informatique pour gérer les personnels, et on comptait sur moi pour l'écrire.

Dans le bureau, il y avait aussi un adjudant et un maréchal-des-logis chef (promu plus tard adjudant) qui fumaient comme des cheminées d'usine (alors que c'était interdit de fumer dans les bureaux, bien sûr). L'adjudant avait le dos tout pété d'avoir passé 10 ans dans des blindés et attendait la retraite. C'était un fainéant comme moi. Il m'avait appris à ouvrir l'armoire blindée qui contenait les passeports des personnels (et les horaires de bus, aussi). L'armoire blindée était juste derrière la porte du bureau, donc on fermait la porte à clé pour ne pas qu'une ouverture intempestive de cette dernière ne vienne taper dans le gros bouton chiffré de la porte de l'armoire. Un jour que l'autre adjudant était absent, on a ouvert l'armoire pour avoir une raison de verrouiller le bureau, on s'est assis face à face et on s'est amusés a lancer des mines de stylos dans la tasse de l'autre à l'aide du mécanisme à ressort des agrafeuses.

Mais en fait, j'étais pas habilité à ouvrir l'armoire blindée. L'adjudant m'a dit

«  si on te demande de l'ouvrir, tu dis que tu sais pas faire.  »

Le chef de la cellule OPEX c'était un lieutenant qui bossait à l'étage. Il était sympa, et je donnais des cours de maths à sa fille en échange de bons dîners préparés par sa femme. Un soir j'étais en civil, seul dans mon bureau, à attendre le lieutenant pour qu'il m'emmène chez lui. Arrive alors le second du chef de corps. Le lieutenant-colonel me demande d'ouvrir l'armoire blindée pour sortir un truc. Je lui réponds, comme l'adjudant m'a dit, que je ne connais pas la combinaison. Arrive alors le lieutenant, mon chef, à qui le colon demande le truc en question. Le lieutenant, qui sait que je connais la combinaison, se tourne vers moi et dit «  Weber, ouvre l'armoire blindée  ». Alors je dis «  Oui, mon lieutenant  » et j'obtempère, sous les regard intrigué du colon, qui dit rien. Petit moment de solitude.

L'armée, depuis la toute fin des années 90, c'est une armée de professionnels (j'étais parmi les derniers appelés). Les soldats sont censés protéger la France, tout ça, tmtc. Un jour on est allé s'entrainer au tir. J'étais à coté d'une engagée volontaire (une pro, donc) qui n'arrivait pas à toucher la cible. Après une brève discussion, j'ai compris qu'elle ne savait pas viser. Il faut aligner deux trucs de l'arme aver la cible, mais elle n'alignait que le truc du bout du canon

L'armée, c'est aussi du matériel de pointe. J'ai appris de mon adjudant que dans les chars AMX 30 B2, les supports pour les obus ont juste la bonne taille pour y ranger des bouteilles de Bordeaux. Et si tu mets des chiffons mouillés dans la clim, tu peux y rafraichir des canettes de bière. Les camions Berliet fonctionnent au choix au gazole et à l'essence, on en change en pressant un simple bouton. Aussi, le siège du passager vibre tellement que ça fait bander (j'ai testé).

Une dernière pour la route. Je sais plus ce que j'avais dit à mon adjudant, mais il avait répondu «  c'est ça, appelle-moi con !  ». En bon soldat, j'ai évidemment rétorqué «  À vos ordres, mon adjudant !  » :)

Adaptée de la recette Serious Eats.

Pour 6 petits pains de 12 cm de diamètre.

Ingrédients

• 113 g lait tiède
• 170 g eau tiède
• 2 c. café levure sèche (5g)
• 1,5 c. soupe sucre en poudre (5g)
• 550 g farine
• 2 c. café sel (10g)
• 3 œufs
• 60 g beurre

• 2 plaqueis à four et papier cuisson
• pinceau

Préparation

• Délayer la levure dans le lait, l'eau et le sucre et attentre 5 min que ça mousse..
• Placer la farine et le sel lans le mixeur, ajouter le liquide et mélanger.
• Ajouter 2 œufs, un par un, en mélangeant.
• Ajouter le beurre en deux fois. Mixer 2 – 3 min.
• Ajouter de la farine au besoin, la pâte doit coller au fond, pas aux bords du bol. Mixer 5 – 6 min de plus.
• Couvrir le bol et laisser pousser 2 h.
• Former 6 boules (de 160 – 170 g chacune), les placer sur deux plaques avec du papier de cuisson. Brosser avec de l'huile et couvrire. Laisser reposer 2 h.
• Préchauffer le four à 200 °C en chaleur tournante. Appuyer sur les boules pour réduire leur épaisseur à 3 cm. Passer les boules à l'œuf battu avec 1 c. à soupe d'eau.
• Cuire 7 min. Repasser à l'œuf et cuire 13 min de plus.

Commentaires

• Les petits pains se conservent plusieurs jours dans une boite hermétique

I run my own instance of Mastodon on a server with little memory, i.e. not enough to be able to run ElasticSearch in addition to Mastodon. This means that I cannot do a full-text search on my toots (which would have come handy from time to time).

As an alternative solution, I have implemented a full-text search on database. It is most probably not suitable to use on a large instance, as the implementation uses an SQL query with multiple LIKE conditions ORed together. That's not the most efficient way of querying a database, but for a small enough number of statuses (40k at the moment), it's probably good enough.

This feature is (and will probably forever remain) experimental, but if you want to give it a try, and assuming that you have installed Mastodon from Git like me in /home/mastodon/live and run v4.1.0, here's how to do it.

As user mastodon, run:

$ cd /home/mastodon/live
$ git remote add db_search https://weber.fi.eu.org/software/mastodon
$ git fetch db_search
$ git checkout v4.1.0+db_search.1
$ echo "FULL_TEXT_DB_SEARCH=true" >> .env.production

Then restart the mastodon-web service by running as root:

systemctl restart mastodon-web.service

Reload the mastodon Web UI in your web browser. When you click on the search box, you should now see a message like “Simple text returns posts you have written…” and searching with words you know you have written should display matching toots.

EDIT: I expanded the search to also consider the descriptions of media attachments. The updated version is available as tag v4.1.0+db_search.1.

La quête du repose-bras idéal passe par le confort, et donc par la quête de la mousse idéale. J'ai d'abord essayé de la mousse pour l'isolation phonique, très dense, mais malgré sa faible épaisseur d'1 cm, elle s'enfonce à peine sous la pression du bras, et surtout elle surélève mes poignets au point où ils ne reposent plus suffisamment sur les repose-poignets du clavier. J'ai alors essayé de la mousse « ordinaire » de la même épaisseur, utilisée dans l'ameublement, et j'ai découpé un espace pour que l'avant bras ne soit pas soutenu ; le fond est recouvert d'une mousse d'emballage fine, récupérée dans un colis que j'ai reçu. J'ai ensuite collé la mousse à la colle chaude, exception faite de la partie qui recouvre les vis, pour pouvoir remonter le bazar une fois que c'est terminé.

Le coté droit est plus complexe, j'y ai ajouté un repose-poignet pour le trackball en empilant deux épaisseurs de mousse d'isolation phonique. Ce repose-poignet n'est pas collé, encore une fois pour avoir accès aux deux vis cachées dessous.

J'ai ensuite recouvert la mousse de tissus noir que j'avais acheté il y a longtemps pour fabriquer un sac pour des dés de Super Mario Dice. Les cotés rectilignes étaient faciles à gérer, mais le coté concave a demandé un peu d'efforts de couture : tout comme on ne peut pas recouvrir parfaitement une orange (sphérique) d'un feuille de papier (plane), on ne peut pas non plus recouvrir le repose-bras de tissus non-extensible (et le tissus extensible, c'est galère à utiliser, donc je n'ose même pas y penser).

Le dessous est nettement plus simple: le tissus est agrafé (merci à Aku qui m'a prêté l'outil idoine).

Le coté droit est plus compliqué à cause du repose-poignet qui ajoute un deuxième bord concave et une épaisseur supplémentaire. J'ai fini par comprendre (à force d'essayer de poser le tissus à plat sur toutes les parties où placer la deuxième couture. L'angle entre le repose-poignet et le bord supérieur par contre est très moche, j'ai dû y faire une découpe que j'ai recouverte d'un morceau de tissus collé à la colle chaude (c'est trop petit pour que j'arrive à y coudre une pièce). Enfin, le tissus est collé sous le repose-poignet, c'est très moche aussi mais personne n'ira regarder.

Le résultat final.

Modification du 2022-08-18: j'ai collé deux morceaux de silicone (découpés dans un tapis de pâtisserie en silicone qui était abimé de coups de couteau) sous les parties du repose-bras qui prennent appui sur la surface du bureau, pour éviter qu'il ne glisse. Coller du silicone, c'est pas facile, la colle néoprène tient très bien sur le bois mais pas du tout sur le silicone. Le joint silicone en tube en revanche fait l'affaire (même si on pourrait le décoller en tirant fort dessus).

Pour rendre mon poste de travail plus confortable, je voulais y ajouter un repose-bras. Comme tous ceux que j'ai vus en ligne étaient trop étroits et mordaient sur le bord du bureau là où je veux mettre le trackball, j'ai décidé d'en construire un moi-même. How hard can it be? comme y disent (oui je sais le bord du repose-bras du commerce pourrait être utilisable pour remplacer celui du trackball, mais j'avais pas envie d'essayer pour me rendre compte que finalement, bah non, c'est pas top).

Celui que j'ai construit est composé de deux parties en contreplaqué de 12 mm (qui coûte justement un bras en ce moment, 36 €/m², il doit être plaqué or à l'intérieur) fixées à un tasseau de 28 mm par six vis auto-taraudeuses 3x30 (à tête Torx, le Torx c'est bien, mangez-en. Je ne vois pas pourquoi on utiliserait encore du Pozidriv de nos jours ; d'ailleurs à Stark, on ne trouve plus que du Torx).

Le repose-bras est fixé au bord du bureau par un ingénieux système de crochets en acier, ce qui permet de l'enlever et le remettre rapidement. Je les ai trouvés sur ergostar.fi quand je regardais les modèles de repose-bras. Je ne suis pas sûr comment je l'aurais fixé si je n'avais pas trouvé ces crochets. Ces derniers sont ensuite vissés sur les bords du repose-bras (sous les parties que mordent justement sur le bureau) grâce à des écrous à frapper M5 (dont j'ai découvert l'existence en me promenant sur motonet.fi pour justement regarder comment je pourrais fixer le bazar en question) qui s'adaptent pile-poil aux vis M5 fournies avec les crochets.

Prochaine étape : trouver de la mousse pas trop épaisse pour rembourrer le dessus et la couvrir avec du tissus.

There was Mastermind_(board_game) where you have to guess the correct colors in the correct order. Then came Wordle, where you have to guess the correct letters in the correct order to make an actual word. And then came Nerdle where you have to guess the correct arithmetic identity, using digits from 0 to 9, the four usual operations and the “equal” sign.

That was fun the couple of first times, but then came the itch to write a solver for it (like I did a long time ago with the Sudoku: same kind of repetitive puzzle, same geek reflex).

$ python3 nerdle.py
([c]orrect [i]ncorrect [a]bsent
8+7*6=50 > iiaaaiai
10+2-4=8 > cccacaci
10+1-8=3 > cccccccc
10+1-8=3

The user interface is trivial: the solver prompts a solution, type it in the Nerdle web interface, then type the colored hints back into the solver: green is “c” for Correct, purple is “i” for Incorrect and black is “a” for Absent (as indicated by the solver when you start it).

It always starts with the same first attempt, that is composed of 8 of the 15 possible symbols. Then based on the hints, it computes possible next solutions and ranks them based on the diversity of the symbols it contains and the amount of yet-unused ones (assuming that the actual solution contains as wide a variety of symbols as possible, and that unused symbols need to be tried).

One thing I liked when coding this little tool is that I got to use sets a lot, and implement a lot of the logic using set operations.

Proportions de base pour la pâte à pizza:

• 250 g farine
• 150 g eau à 43 °C
• 4 g sel
• 1,5 c. à café levure sèche
• 3 c. à soupe huile d'olive

Ce qui fait 440g de pâte en tout. D'après tonton-pizza il faut un pâton de 230 g pour une pizza de 29 cm, ça tombe bien c'est juste adapté à la taille de la pelle à pizza. Donc on peut faire 2 pizza (à 4% près) avec cette quantité de pâte.

Mais comme je ne sais apparemment pas calculer la quantité de pâte pour faire 5 pizzas (je me suis retrouvé samedi dernier avec exactement la quantité nécessaire pour en faire 3), voilà une liste des quantités en fonction du nombre de pizzas.

1 pizza

• 125 g farine
• 75 g eau
• 2 g sel
• 3/4 c. à café levure sèche
• 1,5 c. à soupe huile d'olive

2 pizzas

• 250 g farine
• 150 g eau
• 4 g sel
• 1,5 c. à café levure sèche
• 3 c. à soupe huile d'olive

3 pizzas

• 375 g farine
• 225 g eau
• 6 g sel
• 2,25 c. à café levure sèche
• 4,5 c. à soupe huile d'olive

4 pizzas

• 500 g farine
• 300 g eau
• 8 g sel
• 3 c. à café levure sèche
• 6 c. à soupe huile d'olive

5 pizzas

• 625 g farine
• 375 g eau
• 10 g sel
• 3,75 c. à café levure sèche
• 7,5 c. à soupe huile d'olive

6 pizzas

• 750 g farine
• 450 g eau
• 12 g sel
• 4,5 c. à café levure sèche
• 9 c. à soupe huile d'olive

7 pizzas

• 875 g farine
• 525 g eau
• 14 g sel
• 5,25 c. à café levure sèche
• 10,5 c. à soupe huile d'olive

Several months ago, the leffakone infrared receiver started to misbehave. There were a lot of errors in syslog about spikes in the signal, and the problem seemed to come from the serial port on the motherboard rather than from the homebrew IR receiver, connected to the serial port, that I had built in 2002 or 2003 and that I had been using with lirc ever since. One of the symptoms was that unloading the lirc-serial kernel module caused the computer to freeze, while testing the receiver with an oscilloscope seemed to show that it was working correctly. For many months, I was too lazy to do something about it, as using a keyboard with a long enough cord was enough to control leffakone. During the last autumn vacation, I tried to test the receiver with the serial port on minikone, but the latter seems to deliver only 1.2V signals, when the receiver expects at least 7V to power its onboard voltage regulator. So that was not very conclusive.

At the same time, I had the idea of building a CO₂ monitor using a Jeenode I had lying around, and somehow I wondered if the IR receiver module would not just fit into one of the Jeenode's ports. Guess what? It fits perfectly, allowing to use the IRQ pin as the input, which is exactly what the Arduino-IRremote library suggests to use. Writing the software was a bit of a headache, because the library assumes that the compiler would run with the -flto option (and the compilation ends with an error if it is not set), but my custom Makefile somehow fails to compile the code correctly if I enable that option. Thankfully, you can get around the problem with #define SUPPRESS_ERROR_MESSAGE_FOR_BEGIN. After that, the program is quite straightforward: configure it for the RC5 protocol (as this is what my remote control produces), read a code and write it to the serial port if it matches the RC5 address. I also added a new feature: if the code is the power on button, it would set a pin to HIGH for a short while, allowing to switch the computer on. I used the Jeenode USB as it has an on-board USB-to-serial adatpter, which makes it perfect to connect to a modern computer. I had one reed relay left from the timer and despite being rated for a 5V control voltage, it works with the Jeenode's 3.3V signal. The Jeenode is connected to the computer with a USB cable where I have replaced the USB Type A connector with a Molex connector so that I can use one of USB headers on the motherboard. Crimping the very small contacts was difficult as I don't have a crimping tool, but the connections seem to be working despite having done quite a poor job of it.

Yesterday, I installed the extra reed relay and the Jeenode onto the PCB that holds the relays of the timer, and now it's inside leffakone and working well. And since I forgot to take a picture, there is no image of what it looks like. In addition, I'm quite happy I have been able to do this project by using only bits and pieces I already had (the Jeenode, the headers, the reed relay, the IR receiver module, the USB cable, the Molex contacts and housing).

The last issue of Make: magazine had an article about building a CO₂ monitor. The concentration of CO₂ is apparently a good estimator for the concentration of SARS-CoV-2 in the air, which is correlated to the risk of transmission. The article suggests keeping the concentration of CO₂ under 800 ppm when people are wearing masks.

The Make: article proposes a green-yellow-red light indicator, where the light is green when the concentration is below 1000 ppm, yellow above that level and red when it goes above 2000 ppm. These values are rather about indoors air quality and not directly related to limiting the transmission of SARS-CoV-2.

An article from NIST however indicates that the 1000 ppm limit has no basis whatsoever so I decided to use the 800 ppm limit instead and a rather arbitrary limit of 1300 ppm based on looking at Figure 2 in this article which seems to indicate that some cognitive abilities drop around that concentration.

Description

The device itself is quite simple: it has an on/off switch and a single two-color LED indicator, red and green. The yellow color is obtained by turning on both green and red colors at the same time. It also has a small hole where a paperclip can be inserted for triggering the calibration procedure. The holes next to the power switch expose the CO₂ sensor and its temperature/humidity sensor.

Inside the box there is an Arduino-like Jeenode I had lying around with an AA Power board (I have no idea if these are still sold, I've had them around for over ten years). The AA Power board is meant for a single AA battery, but it cannot provide enough current, so I removed the battery clips and connected it to a 2-AA battery holder, via the switch. It seems to be working well with two NiMH rechargeable batteries.

The CO₂ sensor is a Sensirion SCD30. It is quite expensive (about 50 EUR), but has an easy to use I2C interface and is the most accurate of the sensors presented in the Make: article. The software is quite trivial (if you except the calibration procedure, see below), and available here. The device automatically makes a measurement ever two seconds, the program reads it and updates the LED accordingly. That's it.

Calibration

There is an automatic calibration procedure that requires to keep the sensor powered for at least 7 days and put it in fresh (outdoors) air at least an hour per day. This is not very practical given that I've estimated that the batteries would last about 25 hours (20 mA for the ATmega, 17 mA for the SCD30, 10 mA for the LED at 3.3 V, with maybe a 80% efficiency for the power board with two 1900 mAh batteries at 2.4 V). There is however also the possibility to expose the sensor to air with a known CO₂ concentration and tell it the actual value it is measuring. It then uses this value as a reference point for subsequent measurements. The device is apparently sensitive to changes in shape (e.g. when subjected to mechanical stress during transport) so as a portable device it probably needs to be regularly re-calibrated.

The calibration procedure is simple: place the device outdoors, wait about 2 minutes for it to settle, then introduce a paperclip into the hole and press the button underneath it; the LED will be flashing red. The device will take repeated measurements every 2 seconds, and when a succession of 10 measurements is considered stable enough (i.e. the absolute value of the difference between the first and last of those is at most 1, and the sum of the absolute values of each measurement with its previous one is at most 10), it sets the calibration value to 416 ppm (which seems to be about the average value in 2021). As the device is accurate to +/- 30 ppm, the exact value does not matter so much. The device then returns to its normal operation mode, showing a green, yellow or red light.

What next?

Put a sticker on it with some indications about the LED colors and the reset button hole.

As I cannot find any Blair's Original Death Sauce in shops, I decided to reverse-engineer it, from memory. This is the result.

Ingredients

• 25 g carrot
• 11 g freshly grated garlic
• 3.5 g fresh coriander leaves
• 5 g mineral salt (Seltin)
• 1.5 g powdered paprika
• 0.2 g smoked paprika
• 4 g sugar
• 1.5 g powdered onion
• 0.5 g dried parsley
• 10 g tomato concentrate
• 15 mL lemon juice
• 150 mL Poppamies Habanero sauce (1 bottle)
• water

Tools

• 1 very small saucepan and matching kitchen stove
• 1 0.1 g-precision scale
• assorted measuring spoons (15 mL , 50 mL)
• 1 clean and empty habanero sauce bottle (or another container for the leftover sauce).
• 1 clean small funnel that fits into the bottle
• 1 electric kettle

Preparation

Chop the carrot finely, rinse and chop the coriander leaves.

In a very small saucepan, boil 1/2 dL water and add the carrots. Let it boil, then add the garlic, coriander, salt, paprika, smoked paprika, sugar, powdered onion and dried parsley. Let boil until the carrots are soft, stirring from time to time (keep an eye on it, it takes only a few minutes). If the water evaporates too quickly, just add more water and let it boil again. Then add the tomato concentrate, lemon juice and habanero sauce and boil once more.

Blend the preparation with an immersion blender until smooth and set aside.

Rinse the empty habanero sauce bottle, and preferably get a second bottle, as there will be more than 150 mL sauce.

Boil water in a kettle and use it immediately to fill the bottles and the screw caps to sterilize them. Also pour some of that water in and outside of a small funnel. Estimate the thickness of the sauce, add boiled water and stir to make it thinner. I added 30 mL water, maybe 20 mL would have been enough? Then empty the bottles (careful, they are hot) and pour the sauce into them with the funnel. Put the screw caps and store in the refrigerator. I use on such batch over several months, it seems to be keeping well.

Gmail started to complain recently that the messages forwarded by the trivial mailing-list hosted on my server did not pass the ARC validation. As Google already considers e-mail coming from my domain as spam (but strangely, not the emails forwarded by the mailing list on the same domain), I did not want to risk to see my e-mail treated as even less worthy to be delivered to the Valued Customers of Gmail (i.e., probably half the world) than it is now. And I wanted to look into ARC anyway. But the installation is not trivial, there are no official Debian packages, and no clear tutorial on the Web, so here's what I did. It may work for you or not.

This tutorial assumes you already have configured postfix with opendkim, and they are running on a single computer on a Debian 10. The configuration example expects postfix to run as chroot and uses the private key configured for opendkim.

All the following commands need to be run as root or through sudo.

Install the package

Add an apt source by creating the file /etc/apt/sources.list.d/openarc.list and write:

deb https://download.opensuse.org/repositories/home%3A/andreasschulze/Debian_10 /

Then run:

curl https://download.opensuse.org/repositories/home:/andreasschulze/Debian_10/Release.key | apt-key add -
apt update
apt install openarc

If you don't want to run curl as root, you can run that command instead:

curl https://download.opensuse.org/repositories/home:/andreasschulze/Debian_10/Release.key | sudo apt-key add -

This will install openarc 1.0.0 beta3-3, but the package's post-installation script has a bug, so the installation fails. To fix it, edit /var/lib/dpkg/info/openarc.postinst and comment-out line 62 which contains

  ln -s ../../var/lib/supervise/openarc-milter /etc/service/

Then run as root apt install openarc again.

Configure OpenArc

Create /etc/openarc/keys and copy the key from opendkim (e.g., /etc/opendkim/keys/example.private) into /etc/openarc/keys/. Then copy /etc/opendkim/TrustedHosts into /etc/openarc/.

Create /etc/openarc.conf (or create one such file based on /usr/share/doc/openarc/openarc.conf.sample.gz) and modify the following directives (without the quotes around the values, of course):

• AuthservID: the name of the server (e.g., “server.example.com”)
• Canonicalization: the value “relaxed/simple”
• Domain: the domain namd (e.g., “weber.fi.eu.org”)
• FinalReceiver: the value “no”
• InternalHosts: the value “/etc/openarc/TrustedHosts” (if there is a such a file)
• KeyFile: the path to the private key (e.g., “/etc/openarc/keys/example.private”)
• OversignHeaders: the value “From”
• PidFile: the value “/var/run/openarc.pid”
• Selector: the value of the opendkim selector (see Selector in opendkim.conf)
• Socket: the value “local:/var/spool/postfix/var/run/openarc/openarc.sock”
• Syslog: the value “Yes”

Create /var/spool/postfix/var/run/openarc that will contain the socket:

mkdir /var/spool/postfix/var/run/openarc
chown openarc:openarc /var/spool/postfix/var/run/openarc
chmod 750 /var/spool/postfix/var/run/openarc

Add the postfix user to the openarc group so that postfix can access the socket (run as root):

usermod -a -G openarc postfix

Create a systemd service file /etc/systemd/system/openarc.service with the following content:

[Unit]
Description=OpenARC Authenticated Received Chain (ARC) Milter
Documentation=man:openarc(8) man:openarc.conf(5) https://openarc.org/
After=network.target nss-lookup.target·
 
[Service]
Type=forking
PIDFile=/var/run/openarc.pid
UMask=0002
ExecStart=/usr/sbin/openarc -c /etc/openarc.conf
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

The UMask directive is especially important, so that /var/spool/postfix/var/run/openarc/openarc.sock is readable and writable by the members of the openarc group (i.e., postfix). OpenDKIM has a UMask directive, but OpenARC does not.

You can now start the service with

systemctl start openarc

Configure postfix

Edit /etc/postfix/main.cf and add the socket to the smtpd_milters and non_smtpd_milters lists (you may already have other milters configured, such as OpenDKIM):

smtpd_milters = unix:/var/run/opendkim/opendkim.sock,
                unix:/var/run/openarc/openarc.sock
 
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock,
                    unix:/var/run/openarc/openarc.sock

Finally, restart postfix:

systemctl restart postfix

You can now test your OpenARC setup with the tools provided by openarc.org.

For quite a while, I've been wondering what to do with movies or games which have been rated with a small number of people, such as the ones found on IMDb or BoardGameGeek: users can give a 0 – 10 rating to items, and the users' average is then shown. Is an obscure movie rated 8 by 42 people actually worth an 8?

Putting aside the actual usefulness of those ratings, I wanted to know how much uncertainty there is on those values, knowing only the arithmetic mean and the number of people who have voted.

Given population (i.e., all the users who have seen the film or played the game and who could vote), when we take a sample (i.e., the users who have rated the item) of size n, we get a sample mean m. But if another sample had been taken, we would have gotten a slightly different sample mean. How much much different would these two values be? In other words, how close is this value from the value we would get if the whole population would have rated the item?

The standard error of the mean indicates how much the sample mean m can vary by calculating its standard deviation s_m = s/√n. The problem is that it is based on the standard deviation s of the population, which is unknown. Given that we do not know the users' individual ratings, we cannot either calculate the standard deviation of the sample.

All is not lost, however: since the ratings are always between 0 and 10, we can estimate the maximum value of the standard deviation. My best guess is that this value is maximal when half the ratings are 0 and the other half are 10, leading to a standard deviation of 5.

Given that the means of 96% of the samples of size n falls within ±2s_m of the population's mean, we know that the mean of the population is very likely to be between m−10√n (but no less than 0) and m+10√n (but no more than 10). So this obscure movie rated 8 by 42 users is worth between 6.5 and 9.5. Given that on IMDb movies rated above about 7 are reasonably good, the obscure movie may be worth watching.

Mise à jour du Noursella v2 avec de la vanille et adaptée à de nouveaux ingrédients, disponibles en Finlande.

Ingrédients

• 56g chocolat noir (Pirkka luomu reilun kaupan tumma suklaa 72%)
• 250g pâte de noisette (100% noisette, Rapunzel Haselnussmus 100% Haselnüsse)
• 70g cacao en poudre (Callebaut Cocoa Powder CP-E0-776, 22/24% matière grasse)
• 110g sucre glace (Dan Sukker tomusokeri)
• 30g sucre vanillé (à base de sucre glace, Dan Sukker Vaniljasokeri)
• 20-30g huile végétale neutre (Apetit rypsiöljy)

Préparation

Faire fondre le chocolat (cassé en petits morceaux, 2 min au micro-ondes), y mélanger la pâte de noisette (d'abord l'huile qui surnage, puis la partie solide) jusqu'à obtenir un appareil homogène. Placer le cacao, le sucre glace et le sucre vanillé dans un tamis à farine, et ajouter en plusieurs fois dans le mélange chocolat-noisette, en mélangeant bien à chaque étape. Ajouter finalement de l'huile en fonction de la texture souhaitée: 20g d'huile donne une pâte plus difficile à tartiner sur une crêpe, 30g d'huile donne un pâte plus liquide mais une petite partie de l'huile va remonter à la surface au bout d'une semaine.

Conservation

Dans un pot en verre (propre…), plusieurs semaines dans un placard à température ambiante.

Des chiffres

Masse totale: 540g

• Lipides: 42g pour 100g
• Glucides: 31g pour 100g (sucres: 30g pour 100g)
• Protéines: 10g pour 100g
• Fibres: 5.5g pour 100g

Prix: 16,42 EUR (30,41 EUR/kg)

A couple of months ago, I discovered D100 Dungeon, a free print-and-play (at least up to version 2.2) dungeon crawling game where most aspects of the game are randomly generated by rolling dice. While it is yet-another game where you walk into a room, kill the monster and loot the treasure, I was especially enthusiastic about generating the dungeon's map randomly (look at the pictures on BoardGameGeek, some people have taken the time to even make very nice looking maps) I've played a few games before feeling the itch to design such a game myself (game design is something that has been itching every now and then, but without much result until now).

Roll through the Dungeon (RttD) is the result of scratching that itch. The structure of the game is very much inspired by D100 Dungeon, but I changed some of the mechanisms that I didn't like with what I consider better ones.

Inspired by the James Bond 007 role-playing game I played as a teenager in the early '90s, skill tests have an associated success grade, indicating how well your character succeeds in doing a given action. This success grade then determines how much time is spent on doing the action, and in case of fights, how much damage is inflicted to the opponent. This contrasts with D100 Dungeon's two-step fights, where the skill test tells you whether you have hit the opponent, but an second, unrelated roll determines the damage. I find it more intellectually satisfactory that the damage depends on how successful the action has been, rather than being an independent event, but I am aware it is nothing more than a design decision and it does not model reality any better than the two-step model. I'm particularly proud of the nomogram I have designed for computing the success grade, but I must admit that it is actually not very practical (the table is much faster to use, as it does not require manipulating a ruler). But I did it for fun, and that is the kind of geeky stuff I consider fun :)

Another important difference between D100 Dungeon and RttD is the construction of the dungeon's map. The map is a grid of adjacent squares rooms, and in the former game, a single D100 roll determines most of the characteristics in a square: the three exits from the room (corridor, door or wall) and what you find in it (a feature, a monster or nothing). This leads to paradoxical maps, where on one side of a room is a door, but the same side seen from the adjacent room is a solid wall. RttD solves this at the cost of more dice rolls: room sides are determined by independent D10 rolls, and the room's content is yet another roll. That means that you need to roll up to four D10 instead of one D100.

Many design decisions from D100 Dungeon have become apparent when trying to solve the same problems, and have led to the same solutions, reinforcing the similarity between the two games: roll tables are ordered, with the not-go-good stuff at the beginning of the table, and the best stuff at its end. This way, it is possible to get better stuff in some circumstances by offsetting the dice roll (i.e., adding 10 to the D100 roll). This is especially important when searching the rooms: feature rooms may contain a trap, so when searching a feature room, you add 5 to your roll to make it impossible to find a second trap in the same room, as well as increasing the chances to find better stuff.

The hardest thing for me in working on this game has been (and still is) to invent thematic elements, such as monsters, quests, room features, treasures. I tried not to simply copy D100 Dungeon (partly because it's copyrighted, and partly because I wanted to prove myself that I could do it), but it has been really hard. Most monsters and features are coming straight from the NetHack wiki, monster HP and damage are generated by a script to create a progression in the difficulty, but the hardest has been (and still is) quests. Some are more or less direct adaptations from the quests in D100 Dungeon, a few are from my own imagination (especially in the “Ridicule does not kill” they say chapter), but the list of quests is still incomplete (actually, it's the only thing that justifies not releasing a version 1.0 of the game).

I have now played about 25 games of RttD to test the game, fix the problems and try and improve it. I'm a bit sad to say that the novelty is wearing off and that the game feels quite repetitive (it is, by design). What has been the most fun until now has been to use LaTeX again to produce the PDF booklet and to develop macros for generating some parts of the tables and making cross-references. It is nothing fancy, but as a software developer, it's the kind of things I enjoy doing.

I feel like running out of steam about RttD so I don't know how long I will continue working on it; certainly I won't anymore spend several hours daily as I have in the beginning. But as the game is released under Creative Commons BY – SA, anyone can work on it, write changes, and generally improve it. The PDF booklet has a section about developing the game, if you are interested. Among the things that are not implemented yet are curses and blessings (which D100 Dungeon already has), I was considering making them more like NetHacks curses i.e., items you find may be cursed and detrimental to your character if worn or used.

I have over forty Ni-MH low self-discharge rechargeable batteries (mostly Eneloops, and a few Vartas and GPs) and I have noticed that some of them tend to not keep the charge very well. In order to find out which ones are worth throwing away to be recycled, I needed a device that would measure their capacity.

The principle is very simple: recharge the battery, discharge it through a resistor with a known value, measure the current while it discharges, and integrate the current over time. This will give you the battery's capacity. A few things need to be taken into account: how do you know that a battery is depleted and what discharge current should be used? From what I could gather by reading a few Web forums, the battery is considered to be depleted when its voltage goes below 1.0 V or 0.9 V (I settled on 1.0 V), and the current should be such that the battery discharges in about five hours (for a 2000 mAh battery, that would be about 400 mA). If the current is too high, the battery's voltage while it is discharging will be very close to 1.0 V already at the beginning of the process and the capacity measurement will probably be biased. I noticed this in the first iteration of the device where I had a 1 Ω resistor and a 1 A current, and decided to change for a 3.3 Ω resistor after reading about the “discharge in 5 hours” rule.

The device

The prototype I built is very simple. The battery discharges through a 3.3 Ω ±1% 0.6 W resistor, and the voltage is measured using the Arduino's ADC (more on that below). A MOSFET (STMicroelectronics VNP35NV04-E, quite expensive but it turns fully On with only 2.5 V_GS and its On resistance is only 13 mΩ, which is below the tolerance of the main resistor and the accuracy of what the Arduino can measure, so it can simply be ignored) controls the discharge and cuts the current once the “depleted” threshold has been reached to prevent damaging the battery. A 10 kΩ resistor acts as a pull-down for the MOSFET's gate, and a 110 Ω limits the gate current (whether it's really needed or not seems to depend whom you ask on Web forums, but since I had some lying around I decided to use them). There are two instances of the circuit on the prototype board, so I can test two batteries in parallel.

Accuracy of the Arduino's ADC

The Arduino's ADC has a maximum precision of 10 bits, meaning that the value read from e.g., A0 is translated to a value between 0 and 1023 included, by comparing A0 to a reference voltage that by default is the Arduino's supply voltage. It is however possible to get (reasonably) accurate voltage measurement with the Arduino (see this Web post titled Secret Arduino Voltmeter) by measuring first the supply voltage accurately against the ATMega328's internal band-gap reference. To do so, you need to first measure the band-gap reference's correct value (it's about 1.1 V, it's very stable over time and temperature, but it's exact value differs from one ATMega328 to the next).

The process therefore goes like this.

1. With a trusted voltmeter, measure the Arduino's supply voltage V_CC as accurately as possible.
2. Using the code snippet in the blog post, measure the band-gap's value with the ADC; that gives you a number N_ref. For better accuracy, compute the arithmetic mean of 1000 measurements to get rid of the random fluctuations in the measurement.
3. Calculate V_ref = N_ref × V_cc / 1024 (and not 1023 as stated in the blog post). In my case, V_ref = 1.089 V ±0.001V.
4. Hardcode the V_ref you have found in your Arduino program.

Then when you want to actually measure a voltage V with the Arduino's ADC, do as follows.

1. Measure N_ref with the ADC and compute the value of V_cc = V_ref × 1024 / N_ref (again, take the average of 1000 measurements).
2. Measure N with the ADC and compute the value V = N × V_cc / 1024 (once again, average over 1000 measurements).

If my uncertainty calculations are correct, I get a 0.12% uncertainty on the value of V_cc (compounding the uncertainty of the voltmeter and the ADC), which is less than the 1% uncertainty on the discharge resistor value. I tried to accurately measure the 3.3 Ω resistor value, but my amperemeter is not accurate enough for currents above 200 mA, so that's the best I can hope to achieve.

Take a look at the code if you want to know the details of the implementation (especially computing in millivolts in order to use only integers instead of floats).

What about those batteries, then?

I measured the capacity of 27 batteries so far: 2 GPs, 3 Vartas and 22 Eneloops (6 of generation 1, 7 of generation 2, 2 of generation 3 and 7 of generation 4). All have a nominal capacity of 1900 mAh.

Both GPs have a capacity of 1 mAh, so they are useful only as paperweights. The Vartas have capacities of 870, 450 and 250 mAh, so they are only marginally more useful than the GPs.

One Eneloop is in really bad shape (200 mAh), but the others have capacities between 1660 and 1900 mAh, with a mean of 1790 mAh.

This is a typical battery, in good shape (1890 mAh). The voltage quickly drops to around 1.2 V and remains stable for a while before dropping again.

This one is definitely good for nothing (200 mAh). I remember accidentally dropping batteries on the floor a couple of times in the past, maybe this one suffered from it?

This one is a first generation eneloop, bought probably around 2011. It still has a capacity of 1660 mAh, but the shape of the curve is different from the typical one, maybe due to old age?

For quite a while I have been dreaming about a lamp for reading in bed that would be equally usable when lying on my belly or sitting with my back on the wall. It would be wide enough to uniformly light an open comic book (slightly larger than an A3 paper sheet) without causing a glare on the paper, meaning that it should light from above. Finally it must be made of a strip of warm white LED, its brightness must be adjustable and must consume no power when it's off.

And because making things is fun, I wanted to make it myself. There it is.

It's made of 60 cm of LED strip glued on the inside of a 15×15 mm aluminium profile, and it's powered by a 12 V, 500 mA power supply, via a dimmer (that has also silly features like strobe effect, blinking and pulsating, but that's no good for reading). The power supply is connected to the mains via a wire equipped with a switch (that effectively cuts the power to the power supply when it's off).

To meet the requirement of reading in two different positions, the angle of the aluminium profile can be changed by rocking it. I had to solder thinner wires to the LED strip to prevent it from acting like a spring and holding the lamp back when rocking it.

Given a week number, it's not easy to know when it is located in the calendar. And to add to the confusion, there are three definitions of the week number (ISO-8601; Middle Eastern; North-American and Islamic). The EU and most European countries use the ISO-8601 definition, according to Wikipedia.

The following method is quite approximative so the actual definition does not matter so much, but it should help placing a week number in the calendar without having to look it up:

1. Divide by 4
2. Subtract 10%
3. Add 1

The integer part (before the decimal separator) of the result is the number of the month, and the fractional part (after the decimal separator) times three tells you near what day of the month it is located.

For example:

• Week 1: 1/4 is 0.25, minus 10% is about 0.2, plus 1 is 1.2; 2 times 3 is 6: it's around January 6th (Jan. 1-5, 2019 actually).
• Week 7: 7/4 is 1.75, minus 10% is about 1.6, plus 1 is 2.6; 6 times 3 is 18: it's around February 18th (Feb. 10-16, 2019 actually).
• Week 14: 14/4 is 3.5, minus 10% is about 3.2, plus 1 is 4.2; 2 times 3 is 6: it's around April 6th (Mar. 31-Apr. 6, 2019 actually).
• Week 42: 42/4 is 10.5, minus 10% is about 9.5, plus 1 is 10.5; 5 times 3 is 15: it's around October 15th (Oct. 13-19, 2019 actually).
• Week 35: 35/4 is 8.75, minus 10% is about 7.9, plus 1 is 8.9; 9 times 3 is 27: it's around August 27th (Aug. 25-31, 2019 actually).
• Week 52: 52/4 is 13, minus 10% is about 11.7, plus 1 is 12.7; 7 times 3 is 21: it's around December 21st (Dec. 22-28, 2019 actually).

Suite à des discussion sur la distance focale équivalente d'un objectif monté sur des appareil photo numériques équipés de capteurs de différentes tailles et sur des notions exotiques comme l'ouverture équivalent et la sensibilité équivalente évoquées par Richard Butler sur dpreview.com, je me suis penché sur la question de la pertinence de ces concepts. Les articles suivants publiés précédemment sur mon blog présentent les résultats de mes réflexions.

1. L'angle de champ
2. La profondeur de champ
3. La perspective
4. La sensibilité
5. Le temps de pose
6. L'affichage d'une photo

Je ne m'intéresse à la photo que sous l'angle de l'optique, et comme je ne suis pas photographe pour deux sous, j'ai peut-être écrit des énormités ; si c'est le cas, on peut poster des commentaires sous les articles et tenter de me convaincre que je me suis trompé.

Caractériser une photo

Une photo est souvent caractérisée par le modèle d'appareil ayant servi, ainsi que par la distance focale de l'objectif utilisé, le nombre d'ouverture et le temps de pose. Étant donné la confusion créée par la notion de distance focale équivalente, je me suis demandé si la distance focale était vraiment pertinente pour caractériser une photo. Mais caractériser quoi, exactement ? Et caractériser dans quel but ?

Je fais l'hypothèse que caractériser une photo sert à reproduire la photo, autant que possible à l'identique, avec le même appareil ou avec un autre appareil. Ce qu'on peut chercher alors à reproduire c'est l'angle de champ, les distances limites de la profondeur de champ (c'est à dire la distance du premier plan net et du dernier plan net) et le cas échéant un effet voulu de sur- ou sous-exposition, ou de flou de mouvement. On peut décrire ces caractéristiques par des paramètres ayant davantage de sens que le trio focale, diaphragme et temps de pose ?

L'angle de champ est une combinaison de la distance focale et la taille du capteur, donc indiquer seulement la distance focale en laissant le soin au lecteur de deviner la taille du capteur en fonction du modèle de l'appareil est possible, mais on peut faire mieux en indiquant directement la valeur de l'angle de champ au moment de la prise de vue. Il est ensuite possible de recréer cet angle de champ avec n'importe quelle combinaison judicieuse de capteur et d'objectif.

De même, la profondeur de champ dépend de la distance focale, de l'ouverture du diaphragme, de la taille des pixels du capteur et de la distance de mise au point. Au lieu de détailler les trois premières valeurs, on peut les combiner sous la forme de la distance hyperfocale. Les distances des premier et dernier plans nets sont alors deux fonctions simples de la distance de mise au point et de la distance hyperfocale. Reproduire la profondeur de champ devient alors simplement une question de prendre la même distance hyperfocale et de faire la mise au point sur la distance donnée.

Si le photographe ne cherche pas d'effet d'exposition particulier, la sensibilité du capteur est une fonction des autres paramètres pour une valeur d'exposition idéale, standard. En revanche si la photo a été volontairement sur- ou sous-exposée, il faut indiquer la sensibilité utilisée au moment de la prise de vue.

Le flou de mouvement enfin est particulier car il dépend du temps, et le temps de pose est le seul paramètre qui en dépende également. Dans de cas d'une exposition standard, le temps de pose a une valeur minimale qui dépend de la distance focale, et on peut supposer que cette valeur sera choisie car elle permet d'utiliser la sensibilité la plus faible possible et ainsi réduire le bruit. En revanche si un flou de mouvement est voulu par le photographe, ou au contraire si l'objet se déplace rapidement et que le but est de le « figer », il faut alors indiquer le temps de pose.

En conclusion, au lieu de caractériser une photo par le modèle d'appareil, la distance focale, le nombre d'ouverture et éventuellement le temps de pose et la sensibilité, on peut caractériser une image de manière plus générique et descriptive en indiquant l'angle de champ, la distance hyperfocale, la distance de mise au point et éventuellement la sensibilité et le temps de pose. Bien que ces nouvelles caractéristiques soient moins connues que celles utilisées jusqu'à présent, calculer leurs valeurs ne pose pas de problème aux appareils photos numériques et pourraient donc être incluses dans les métadonnées des images. Et je suis certain que la signification des caractéristiques « classiques » n'est pas mieux comprise par la plupart des photographes que les caractéristiques proposées ici, remplacer en ensemble de valeurs hermétique par un autre ensemble de valeurs hermétiques ne devrait donc pas poser de problème une fois vaincue la résistance naturelle de l'être humain au changement.

Applications numériques

Pour se faire une idée des valeurs numériques des caractéristiques décrites plus haut, voici des applications numériques de diverses formules pour trois appareils photos de référence : un compact, un boitier APS-C et un plein format avec 3 objectifs.

Appareils photo de référence

Appareil	Pixels	Capteur	Objectifs
A	21,1 Mpix	6,17×4,55 mm (1/2,3)	4,3-172,0 mm, f/3,3-f/6,9
B	25,0 Mpix	23,5×15,6 mm (APS-C)	16 mm, f/2,8 ; 18-135 mm, f3,5-5,6
C	27,1 Mpix	36×24 mm (plein format)	16-35 mm, f/4 ; 35-70mm, f/2,8; 70-200mm, f/2,8

Dimensions d'un pixel

Appareil	ε	Surface	Densité
A	1,15 μm	1,33 pm2	752 000 px/mm2
B	3,83 μm	14,7 pm2	68 200 px/mm2
C	5,65 μm	31,9 pm2	31 400 px/mm2

Angles de champ

Appareil	θ (rad)	θ (°)
A	1,45-0,446	83-2,55
B	1,45 1,33-0,208	83 76,2-11,9
C	1,86-1,11 1,11-0,599 0,599-0,215	107-63,4 63,4-34,4 34,4-12,4

Distances hyperfocales

Appareil	F (m)	f/N (mm)
A	2,01-3730	4,3/8-172/6,9
B	3,04-23,9 3,85-850	16/22-16/2,8 18/22-135/5.6
C	2,06-54,2 9,86-310 39,4-2530	16/22-35/4 35/22-70/2,8 70/22-200/2,8

Sensibilité

En admettant que les capteurs des appareils A, B et C ne diffèrent que par la taille de leurs pixels (ce qui est loin d'être évident) et en fixant un niveau de bruit à ne pas dépasser dans l'image obtenue, on peut comparer leur « sensibilités » relatives.

• A est 11 fois moins sensible que B et 24 fois moins sensible que C.
• B est 11 fois plus sensible que B et 2,2 fois moins sensible que C.
• C est 24 fois plus sensible que A et 2,2 fois plus sensible que B.

On peut aussi comparer, à distance focale et temps de pose égaux, de combien de crans il faut ouvrir ou fermer le diaphragme pour obtenir la même exposition et le même niveau de bruit.

• A doit ouvrir de 3,5 crans par rapport à B et de 4,6 crans par rapport à C.
• B doit fermer de 3,5 crans par rapport A et ouvrir de 1,1 crans par rapport à C.
• C doit fermer de 4,6 crans par rapport à A et de 1,1 crans par rapport à B.

Affichage

• Moniteur 16:10 24" FullHD : 2,30 Mpx ; taille d'un pixel : 405 μm
• Moniteur 16:9 32" 4k : 8,29 Mpx ; taille d'un pixel : 265 μm
• Moniteur 16:9 27" 5k : 14,8 Mpx ; taille d'un pixel : 167 μm
• Télévision 16:9 40" FullHD : 2,07 Mpx ; taille d'un pixel : 661 μm
• Télévision 16:9 55" 4k : 8,29 Mpx ; taille d'un pixel : 455 μm
• Télévision 16:9 85" 8k ; 33,2 Mpx ; taille d'un pixel : 351 μm

• Impression papier à 300 dpi :taille d'un pixel : 84,7 μm
• Impression à 300 dpi en 10×13 cm : 1,81 Mpix
• Impression à 300 dpi en 10×15 cm : 2,09 Mpix
• Impression à 300 dpi en 20×30 cm : 8,37 Mpix
• Impression à 300 dpi en 40×60 cm : 33,5 Mpix
• Impression à 300 dpi en 76×115 cm : 122 Mpix

Taille d'un point d'affichage

La notion de flou qui est importante pour la profondeur de champ et le flou de bougé ne dépend pas tant de la taille des pixels du capteur que de la taille des pixels au moment de l'affichage, que ce soit sur un écran ou sur un support physique comme le papier. En effet, utiliser la taille d'un pixel comme taille maximale ε d'une tache de flou donne une garantie que le flou n'est pas perçu par le capteur et donc n'est pas enregistré dans l'image, mais puisque l'image est destinée à être regardée par un humain, ce qui importe in fine c'est la capacité de l'humain à percevoir le flou. On peut donc définir une nouvelle valeur de ε utilisé dans les calculs de profondeur de champ et de bougé en fonction de la manière d'afficher l'image.

Pour un affichage sur écran, on peut calculer la taille d'un pixel ε (en mètres) en fonction de la diagonale D (en pouces), du format R (par exemple 16/9) et du nombre de pixels par ligne n:

ε = 0,0254 × D√(1 + 1 / R) / n

Pour un affichage sur papier, on peut calculer la taille d'un point ε (en mètres) en fonction de la définition de l'impression d (en points par pouce, dpi):

ε = 0.0254 / d

Agrandissement maximal

Pour éviter les effets de crénelage lors de l'affichage, il faut aussi veiller à ne pas afficher l'image à une trop grande taille par rapport à la résolution de l'image numérique. En d'autres termes, le nombre de pixels N de l'affichage ne doit pas être plus grand que le nombre de pixels de l'image (c'est à dire du capteur si on ne retaille pas l'image). On suppose ici que l'intégralité de l'image est affichée sur l'écran ou le papier, c'est à dire qu'on ne va pas zoomer dans l'image.

Pour un écran, le nombre de pixels N vaut

N = n2 / R

Pour un tirage papier de densité d points par pouce, N vaut

N = 0,155 × l2d2 / R

où l est la largeur du papier et R est le rapport largeur sur hauteur.

On peut aussi calculer N en fonction de la largeur l et la hauteur h du papier :

N = 0,155 × lhd2

Exposition et temps de pose

Du point de vue pratique, l'exposition d'une photo dépend du nombre d'ouverture du diaphragme, de la sensibilité du capteur et du temps de pose. On peut comprendre cette exposition comme la quantité de lumière nécessaire pour que chaque pixel du capteur CCD reçoive suffisamment de photons pour produire une valeur « raisonnable » de ce pixel. On a alors le choix d'exposer ces pixels à un flot de lumière important pendant un temps court, ou au contraire un flot de lumière plus faible pendant un temps plus long pour recevoir le même nombre de photons, et donc obtenir le même résultat.

Plus formellement, l'exposition lumineuse H est définie par H = Et, où E est l'éclairement lumineux c'est à dire le flot de lumière et t est le temps de pose.

En faisant l'hypothèse d'un système idéal d'une lentille mince parfaitement transparente uniformément éclairée par l'objet photographié, on peut définir l'éclairement lumineux comme E = Lπ / (4(N / (1 - f / l))²) où L est la luminance de l'objet, f est la distance focale de l'objectif, l est la distance de l'objet et N est le nombre d'ouverture du diaphragme. Dans le cas courant où la distance focale est négligeable par rapport à la distance à l'objet, on peut simplifier cette définition en E = Lπ / (4N²).

Par ailleurs, la sensibilité est définie par S = H₀ / H où H₀ est une valeur d'exposition de référence, constante. En considérant que la luminance de l'objet est elle aussi constante, on obtient la relation

St / N2 = 4H0 / (Lπ)

qui indique bien que si l'un des trois paramètres N, S ou t varie alors l'un au moins des deux autres paramètres doit varier pour que l'égalité soit toujours vérifiée.

Flou et temps de pose

Si le sujet ou l'appareil photo se déplacent pendant la prise de vue, on comprend aisément qu'un point de l'objet donne une image qui se déplace sur le capteur, qui enregistre alors plusieurs points contigus.

Parmi tous les mouvements possibles de l'appareil photo qui conduisent à un flou de bougé, un mouvement simple à modéliser est une rotation de l'appareil photo autour du centre optique O. On considère que durant la prise de vue, le point A s'est déplacé en B, et que le temps de pose est assez long pour que le capteur enregistre toutes les positions prises par ce point entre A' et B'. L'image du point, au lieu d'être un point, est alors un trait de longueur h'. On peut exprimer h' en fonction de θ

h' = tan(θ)lf/(l-f)

Lorsque la distance focale f est négligeable devant l et que θ est inférieur à 0.5 radians (soit 29°, ce qui fait que l'erreur d'approximation de tan(θ) est inférieure à 10%), on peut simplifier en

h' = fθ

En considérant que l'angle θ est le résultat d'une rotation de vitesse angulaire ω durant un temps t, c'est-à-dire θ = ωt on peut écrire

h' = fωt

En notant ε la hauteur d'un pixel et en reprenant l'hypothèse que le flou est invisible si la taille h' de la « tache » de flou est plus petite qu'un pixel, on peut écrire que le flou de bougé est invisible si

t < ε/(fω)

On retrouve ici l'approximation dite « de l'inverse de la focale », à savoir que pour éviter le flou de bouger,

« le temps de pose minimum a la même valeur numérique que l'inverse de la distance focale exprimée en millimètres. »

Cette approximation suppose que ε/ω = 1/1000 m·s·rad^-1. On peut supposer que pour un photographe moyen, la vitesse ω de ses mouvements involontaires est constante, mais on voit que cette approximation dépend directement de la taille ε d'un pixel qui peut beaucoup varier d'un capteur à l'autre.

Le bruit

Chaque pixel d'un capteur CCD d'appareil photo numérique est un transducteur qui transforme une quantité de lumière reçue Q en une différence de potentiel électrique u₀ qui est proportionnelle à Q selon un facteur f :

u0 = fQ

Dans un situation idéale, une valeur donnée de Q devrait donner systématiquement la même valeur nominale u₀. En réalité, à cause du bruit, des mesures répétées d'une même valeur d'exposition donneront des valeurs différentes de u

u = u0 + ε

où ε est une erreur de mesure aléatoire. Cela signifie que chaque mesure répétée de u aura une valeur différente de ε, mais aussi que deux pixels voisins qui sont exposés de la même manière donneront des valeurs de u différentes.

Si on considère qui le bruit est un bruit blanc (ce qui est probablement faux mais suffisamment similaire à la réalité pour être utile à cette explication), alors les valeurs de ε sont couramment proches de zéro (et donc u est proche de u₀), mais ε peut parfois, plus rarement, être nettement plus grand que zéro et donc la valeur de u est nettement différente de u₀.

La sensibilité d'un capteur numérique

Les valeurs typiques de u sont très petites et il est donc nécessaire de les amplifier avant de les numériser. Ainsi une valeur v de pixel (typiquement entre 0 pour la valeur la plus sombre et 255 pour la valeur la plus lumineuse) est obtenue en effectuant

v = Au si Au ≤ vmax
v = vmax si Au > vmax

où A est le facteur d'amplification. Comme la valeur de v ne peut dépasser v_max, on comprend que si l'amplification A choisie est trop élevé par rapport à u, l'intervalle de valeurs possibles pour un pixel n'est pas suffisant pour représenter la valeur correcte de ce pixel, et on arrive à la saturation.

En faisant varier A, on peut faire varier la « sensibilité » du capteur et obtenir des valeurs élevées de v (donc un pixel très lumineux) à partir d'une valeur faible de u (par exemple en photographiant dans une situation de faible luminosité).

Cependant, comme v contient aussi le bruit ε, ce dernier est amplifié de la même manière :

 v = Au0 + Aε

Ainsi, plus la « sensibilité » du capteur est élevée, c'est à dire plus le facteur d'amplification A est élevé, plus le bruit est élevé et devient perceptible pour l'observateur.

Par exemple pour une image d'un objet noir, on s'attend à ce que v soit proche de zéro pour tous les pixels même pour une grande valeur de A parce que u₀ est justement proche de zéro. Mais il peut arriver que ε soit bien plus grand que u₀, ce qui conduit à ce que la valeur v du pixel soit essentiellement égale à Aε. Ceci se traduit par des pixels brillants au milieu de pixels sombres, typiques du bruit des photos prises en faible lumière avec une sensibilité élevée.

Comparaison de capteurs

Dans des conditions d'éclairage uniforme dans l'espace et le temps d'une surface s pendant un temps t (le temps de pose d'une photo), on peut définir les grandeurs suivantes :

• l'exposition lumineuse H est définie par H = Et,
• l'éclairement lumineux E est défini par E = Φ / s,
• le flux lumineux Φ est défini par Φ = Q / t

où Q est la quantité de lumière c'est à dire approximativement le nombre de photons qui arrivent sur la surface s. En combinant ces trois définitions, on obtient

Q = Hs

c'est à dire que la quantité de lumière qui arrive sur un pixel est proportionnelle à la surface de ce pixel. Autrement dit, à exposition H égale, un pixel plus grand reçoit une plus grande quantité de lumière qu'un pixel plus petit.

En reprenant définition de u₀ plus haut, on a

u0 = fHs

et donc, en ignorant pour le moment le bruit ε on a

v = AfHs

Ainsi, pour obtenir la même valeur v avec deux capteurs (capteur 1 et capteur 2) dont les pixels ont respectivement des surfaces s₁ et s₂, on a besoin d'un facteur d'amplification A₁ sur le capteur 1 et A₂ sur le capteur 2 tels que

A2 = A1s1 / s2

On a vu plus haut que le bruit est amplifié. Cela se traduit par

A2ε = A1εs1 / s2

c'est à dire que le bruit dans l'image obtenue par le second capteur est s₁ / s₂ fois plus élevé que le bruit dans l'image obtenue par le premier capteur.

Qualitativement, cela signifie que pour obtenir deux photos exposées de manière identiques avec deux appareils différents, l'un muni d'un capteur à grands pixels et le second muni d'un appareil à petits pixels, celui dont les pixels sont petits a besoin d'un facteur d'amplification plus élevé et produit donc une image plus bruitée.

Sensibilité

La sensibilité est définie par S = H₀ / H où H₀ est une valeur d'exposition de référence.

Un photographe s'attend à ce que lorsqu'on prend la même photo avec deux appareils (dont les capteurs sont équivalents à l'exception de la taille des pixels, et donc de leur nombre), l'image obtenue est exposée de la même façon (en supposant que la distance focale, le nombre d'ouverture, le temps de pose et la sensibilité sont les mêmes). Une conséquence est que les facteurs d'amplification des deux appareils doivent être différents puisque les tailles des pixels sont différentes, et que l'image de l'appareil dont les pixels sont plus petits contiendra donc plus de bruit.

Réciproquement, si on cherche à produire avec les deux appareils des images contenant une quantité de bruit identique, il faut changer les paramètres d'exposition de l'appareil produisant le plus de bruit de sorte à

• diminuer la sensibilité S d'un facteur s₁ / s₂ afin d'utiliser le même facteur d'amplification dans les deux appareils, et
• augmenter l'exposition H d'un facteur s₁ / s₂ afin de compenser la diminution de la sensibilité.

On peut parvenir à ce dernier point en augmentant le temps de pose ou en augmentant la surface de la pupille du diaphragme d'un facteur s₁ / s₂.

Selon le modèle simplifié utilisé ici, à tailles de capteurs égales, un capteur de plus haute définition (donc comportant un plus grand nombre de pixels) produira donc des images contenant plus de bruit.

Si on décide de considérer qu'avec une exposition de référence H_ref la sensibilité S_ref maximale d'un capteur de référence dont les pixels ont une surface s_ref représente une quantité de bruit de référence, on peut considérer qu'à quantité de bruit identique, un capteur de plus haute définition dont les pixels ont une surface s aura donc une « sensibilité équivalente » S_eq plus faible nécessitant une exposition H_eq. En effet S_ref = H₀ / H_ref et H_eq = s_ref / sH_ref, donc

Seq = Srefs/sref

Il faut noter que la sensibilité équivalente, qui dépend de la surface des pixels, n'a rien à voir avec la focale équivalente qui dépend des dimensions du capteur et non de celles de ses pixels.

Le grandissement

La hauteur h' de l'image d'un objet de hauteur h situé à une distance l d'un objectif de distance focale f est donnée par h' = hf / l. Le rapport des tailles entre l'objet et l'image s'appelle le grandissement γ, et en supposant que f est négligeable devant l, γ est défini par

γ = h' / h = f / l

Le grandissement dépend donc uniquement de la distance à l'objet et de la distance focale de l'objectif.

La perspective

On peut donner une valeur chiffrée à la perspective en comparant les tailles des images de deux objets de même taille mais situés à des distances différentes. En supposant que la profondeur de champ est suffisante pour que les images des deux objets soient nettes, on peut noter h'₁ et h'₂ les hauteurs de ces images et l₁ et l₂ les distances des objets, puis calculer le rapport h'₁ / h'₂

h'1 / h'2 = l2 / l1

On constate que le rapport des hauteurs des images dépend seulement du rapport des distances des deux objets. En particulier, il ne dépend pas de la distance focale de l'objectif (si cette dernière est négligeable devant les distances aux objets).

Une conséquence de ce constat est qu'un objectif à longue focale n'« écrase » pas davantage les perspectives qu'un objectif à courte focale (si on ignore les déformations sur les bords de l'image dûs aux courtes focale). Cette conclusion est cohérente avec le fait qu'un objectif à courte distance focale associée à un capteur de petite taille donnera la même image (avec la même perspective) qu'un objectif de plus longue distance focale associé à un capteur plus grand (lorsque le rapport des distance focales de ces deux objectifs est égal au crop factor des deux capteurs).

Le flou

Lorsque la mise au point d'un système optique (simplifié) a été effectuée, l'image d'un objet ponctuel A situé à une distance l de l'objectif est un point A'. La mise au point est cependant imparfaite pour un objet B situé à une distance L plus (ou moins) loin que l : les rayons lumineux convergent en B' au lieu de A', continuent leur course et vont s'étaler autour de A' dans une zone de largeur ε. Sur le capteur d'un appareil photo, l'image B' de B est donc une tache circulaire dont le diamètre ε dépend de L, de la distance de mise au point l, de la distance focale f de la lentille et du diamètre d de la pupille, c'est-à-dire le trou circulaire par lequel la lumière entre dans la lentille, délimitée par le diaphragme. On considère ici que la pupille est suffisamment grande pour négliger les effets dûs à la diffraction.

On considère que l'image d'un point est net lorsque l'observateur (humain, en général) est incapable de faire la différence entre un « vrai » point et une tache. Le diamètre ε maximal d'une telle tache est lié au pouvoir de séparation de l'œil de l'observateur, qui est lié non seulement à la taille de la tache mais aussi à la distance à laquelle se situe l'observateur : plus l'observateur est éloigné, plus il est difficile de distinguer une petite tache d'un « vrai » point. La valeur de cet ε maximal n'est pas universelle, car elle dépend in fine de l'affichage de la photo (sur écran ou en tirage papier) et de la manière dont on regarde cette photo : il sera par exemple plus facile de remarquer un flou en regardant de près une image tirée en grand format qu'en regardant de loin une image tirée en petit format.

La profondeur de champ

D'après l'article de Wikipedia sur la Profondeur de champ, les limites de distance où les objets donneront une image considérée comme nette, une fois choisie un valeur ε maximale sont

L = l / (1 ± εl/df)

Les objets dont la distance est située entre ces limites auront une image considérée comme nette, car la tache de diamètre ε est trop petite pour être distinguée d'un « vrai » point net. On remarque que pour photographier un objet donné situé à une distance l en utilisant un objectif de distance focale f donnée, ces deux valeurs limites ne dépendent que du diamètre de la pupille, et pas du tout de la taille du capteur de l'appareil photo. Plus précisément, si les pixels du capteur sont plus grands que ε il n'y aura aucun flou car la tache circulaire sera contenue dans un seul pixel. Si les pixels sont plus petits que ε mais que les pixels à l'affichage de la photo (sur écran ou sur papier) sont plus grands que la tache circulaire, alors il n'y aura aucun flou à l'affichage, mais on pourra voir le flou en zoomant dans l'image (ce qui revient à dire que les pixels d'affichage deviennent plus petits que la tache circulaire).

Le nombre d'ouverture et la focale équivalente

La taille d de la pupille est exprimée dans la pratique non pas en millimètres, mais en fraction 1/N de la distance focale de l'objectif : d = f / N. N est le nombre d'ouverture et vaut donc N = f / d.

Si considère qu'en utilisant un objectif de distance focale f sur un capteur de taille différente on a une distance focale équivalente f_eq = kf, alors on peut écrire

N = feq / kd

où k est appelé « crop factor », soit

kN = feq / d

En introduisant la notion de nombre d'ouverture équivalent N_eq défini par N_eq = kN, la formule précédente devient

Neq = feq / d

qui est a la même forme que la définition du nombre d'ouverture, mais en utilisant le nombre d'ouverture équivalent et la focale équivalente.

Hyperfocale

On peut définir F = df/ε. En remplaçant le diamètre de la pupille d par son expression utilisant la distance focale et le nombre d'ouverture, on obtient

F = f2/εN

Les distances limites de la profondeur de champ deviennent alors

L = lF / (F ± l)

La distance hyperfocale F est la distance l minimale pour laquelle tous les objets entre F/2 et l'infini sont nets. Un corrolaire est que lors d'une mise au point à l'infini, tous les objets situés au delà d'une distance F sont nets.

Si on utilise la distance hyperfocale comme unité de distance de mise au point photographié, on peut représenter, de manière générique pour n'importe quelle combinaison de capteur, distance focale et nombre d'ouverture, les distances limites entre lesquelles les objets forment des images nettes (en supposant toujours que la distance focale est négligeable par rapport à la distance de mise au point).

En notant l = qF, on peut exprimer L en fonction de q et F:

L = qF / (1 ± q)

Le diagramme ci-contre indique les limites minimum et maximum de netteté pour une mise au point égale à une fraction de la distance hyperfocale F. On remarque que vers 0,9F, la limite maximum de netteté est déjà à 10F, et tend vers l'infini lorsqu'on se rapproche de 1F. Si on fait la mise au point à une valeur supérieure à F, la limite maximum de netteté reste à l'infini alors que la limite minimale n'augmente comparativement que très peu.

Le diagramme ci-contre représente les limites de netteté pour des distances de mise au point inférieures à 0,5F. On remarque que lors d'une mise au point à 0,5F, les objets situés au delà de F ne sont plus nets.

Le modèle simplifié

On peut simplifier un objectif d'appareil photo en le considérant comme une lentille mince de centre O et de distance focale f. L'axe optique de la lentille passe par O et est perpendiculaire à cette dernière. Les points F et F', situés de part et d'autre de la lentille à une distance f sont les points focaux de cette dernière. L'objet AB, situé à une distance l de la lentille donne alors une image A'B' sur le capteur de l'appareil photo. La hauteur de l'objet est h et la hauteur de l'image est h'.

Les règles de l'optique géométrique sont simples :

• les rayons lumineux passant par le centre O de la lentille ne sont pas déviés, donc AA' et BB' sont des lignes droites ;
• les rayons lumineux qui arrivent sur la lentille parallèlement à l'axe optique ressortent de la lentille en passant par le point focal F', tel le rayon BCB' ;
• les rayons lumineux qui arrivent sur la lentille en passant par le point focal F ressortent parallèlement à l'axe optique, tel le rayon BDB'.

L'angle de champ

L'angle sous lequel l'objectif voit l'objet AB est l'angle θ. On a tan θ = h / l et tan α = h / (l - f) =  h' / f. On en déduit que tan θ = (l - f)h' / lf, que l'on peut simplifier (lorsque f est négligeable devant l) en tan θ = h' / f.

Si on considère que l'image A'B' et son symétrique (qui n'est pas représenté sur le diagramme) sont ensemble suffisamment grands pour couvrir l'intégralité de la diagonale du capteur, on sait que la hauteur h' de l'image représente la moitié de la diagonale d du capteur. Cela signifie que l'angle θ est la moitié de l'angle de champ du système objectif-capteur. On a alors

tan(angle de champ / 2) = d / 2f

Ceci montre que l'angle de champ dépend seulement de la distance focale de l'objectif et de la taille du capteur (lorsque f est négligeable devant l, soit en pratique lorsque la distance à l'objet est au moins dix fois plus grande que la distance focale).

Angle de champ et taille de capteur

Pour deux capteurs de tailles différents et avec un objectif donné, le rapport des tangentes des demi-angles de champ est égale au rapport des tailles des capteurs. Pour des angles de champ de moins de 53° (c.-à-d. lorsque la valeur de la tangente est proche de la valeur de l'angle, en radians), c'est à dire lorsque la distance focale est plus grande que la diagonale du capteur, on peut faire l'approximation que le rapport des angles de champ est égal au rapport des tailles des capteurs, avec une erreur de moins de 10%, soit

angle1 / angle2 = diagonale1 / diagonale2

Ainsi par exemple un capteur deux fois plus grand qu'un autre capteur donnera un angle de champ deux fois plus grand lorsque ces capteurs sont munis d'objectifs de même distance focale.

Si on veut une approximation qui fonctionne aussi pour de grands angles, il devient nécessaire de comparer les tangentes des demi-angles de champ, par exemple

tan(angle1 / 2) / tan(angle2 / 2) = diagonale1 / diagonale2

ou de faire intervenir les arctangentes, par exemple

angle1 / angle2 = arctan(diagonale1 / 2f) / arctan(diagonale2 / 2f)

ce qui est nettement moins pratique à évaluer de tête.

La distance focale équivalente

Supposons que l'on a un capteur de référence dont la diagonale est d_ref (par exemple un capteur 24×36 mm) et un objectif de distance focale f.

Lorsqu'on utilise cet objectif avec un autre capteur dont la diagonale est d, on a un angle de champ θ défini par

tan(θ / 2) = d / f

On veut alors savoir quelle serait la distance focale équivalente f_eq d'un objectif fictif donnant le même angle de champ θ si on utilisait cet objectif fictif avec le capteur de référence. On a

tan(θ / 2) = d / f =  dref / feq

et donc

feq = f × dref / d

(cette valeur est correcte si f est négligeable par rapport à l et par rapport à ld / d_ref).

Comparée à l'angle de champ, le calcul de la distance focale équivalente n'est pas limitée à des angles de champ suffisamment petits. La distance focale équivalente fait cependant appel à un facteur caché, la taille du capteur de référence.

For years, the comments were systematically rejected on the blog because most of them were spam, and I didn't have a good way of filtering them out. A CAPTCHA would have been a solution, but I read that the ones based on warped text are easily defeated, and I didn't want to bother with images anyway.

I recently rediscovered the idea of a CAPTCHA based on arithmetics, which I now have implemented. The poster of a comment must do a simple arithmetics operation involving two single digit numbers and one operator. It should not be difficult to defeat, but arithmetics CAPTCHAs are apparently uncommon, so it is likely that most bots don't implement such solvers. It has already repelled a couple of spam comments today.

Supposons qu'on joue à la roulette dans un casino. La roulette est honnête, donc tous les chiffres ont la même probabilité de sortir. Cette roulette comporte 18 numéros rouges, 18 numéros numéros noirs et un zéro qui n'est ni rouge ni noir. Les paris se font par tranche de 1 Euro, et sont limités à 100 Euros. On entre au casino avec 127 Euros en poche, et on parie toujours sur le rouge et on ne réinvestit pas ce qu'on a gagné, c'est à dire qu'on arrête de jouer une fois qu'on a perdu les 127 Euros de départ.

À chaque jeu on a donc p = 18/37 chances de gagner (soit un peu moins d'une chance sur deux).

Si on fait n = 127 paris de 1 Euro, la probabilité de gagner k fois (0 <= k <= n) est de P(X = k) = Comb( n, k) p ^k (1 - p) ^{n - k} (il s'agit d'une Loi binomiale). Les gains après k victoires sur n parties sont de 2 k - n. On peut donc calculer la somme des P(X = k) pour tous les k tels que 2 k - n > 0, ce qui donne la probabilité de quitter le casino avec en poche plus d'Euros que lorsqu'on y est entré. Cette probabilité est de 0,38, c'est à dire qu'on a 38% de chance de quitter le casino avec au moins 128 Euros et au plus 254 Euros. Cela signifie aussi qu'on a 62% de chance de n'avoir rien gagné, voire perdu tout ou partie des 127 Euros initiaux. En fait, on peut s'attendre, en moyenne, à perdre 3,43 Euros.

Jouer une martingale consiste à doubler la mise si on perd, afin que le gain couvre les pertes passées. La table de roulette ayant une limite de 100 Euros, on peut donc miser au plus m = 7 fois de suite en doublant la mise à chaque jeu, soit 1 + 2 + 4 + 8 + 16 + 32 + 64 = 127 Euros (ça tombe bien, c'est justement la somme qu'on avait en entrant au casino). La probabilité de gagner au bout de i jeux (donc de perdre i - 1 fois puis de gagner une fois) est P(X = i) = (1 - p) ^{i - 1} p (il s'agit d'une Loi géométrique). On peut donc calculer la somme de ces probabilités pour i = 1 … m, qui représente la probabilité de gagner 1 Euro en utilisant la martingale. Cette probabilité est de 1 - (1 - p) ^m = 0,99. Cela signifie qu'on a 99% de chance de gagner 1 Euro, et donc 1% de chance de perdre 127 Euros. On peut donc s'attendre à perdre en moyenne 0,21 Euro.

Si on joue la martingale plusieurs fois de suite aussi longtemps que l'on ne perd pas, on peut espérer gagner à répétition, mais la probabilité de ne jamais perdre diminue à mesure que l'on joue (il s'agit encore une fois d'une loi géométrique, cette fois avec avec p = 0,99). Si on parvient à gagner en jouant la martingale au moins 128 fois de suite, alors on est certain qu'au moment où la chance tourne et que l'on perd, on ne perd que 127 Euros, et donc qu'on quitte le casino avec en poche au moins 1 euro de plus que lorsqu'on y est entré. Cette probabilité est de 0,298. Cela signifie qu'on a 29,8% de chance de sortir du casino avec au moins 128 Euros en poche. Cela signifie aussi qu'on a 70,2% de chance de perdre entre 0 et 127 Euros. En fait, on peut s'attendre à perdre en moyenne 21,8 Euros. Si on compare cette méthode avec la précédente qui consiste à miser 127 fois 1 Euro sur le rouge, on voit que le chances de ne pas perdre d'argent sont plus élevées si on n'utilise pas la martingale, et que les gains moyens sont moins mauvais lorsqu'on n'utilise pas la martingale (ils sont cependant toujours négatifs, c'est à dire qu'on y perd toujours de l'argent, en moyenne).

Jouer la martingale a cependant une utilité : la probabilité de gain élevé est plus grande avec la martingale que sans. Par exemple la probabilité de gagner au moins 10 Euros est de 11,6% sans martingale et 27,1% avec la martingale. Pour 20 Euros ou plus, la probabilité est d'à peine 1.9% sans martingale et de 24,7% avec la martingale, et on a encore environ 10% de chances de gagner au moins 115 Euros avec la martingale alors que cette probabilité est de moins d'une sur cent milliards sans martingale.

The economic value of a Youtube video

The Youtube platform has been designed for the purpose of making all of its videos are available to anyone at anytime. Given its large amount of content, its suggestion algorithm and the ability to automatically play the next suggested video, a user of Youtube can consider that the stream of videos he wants to watch is limitless. This makes the stream a nonscarce resource i.e., a free good which, from an economics point of view has no value.

Asking users to pay for watching videos would indeed be a bad business move for Youtube, as many user would refuse to pay for watching content they currently get at no cost. Even the Youtube Red subscription, according to an Ars Technica article and related user comments, seems to be valuable not for it exclusive content, but for the extra features provided by the mobile player (download for offline viewing and background playing). Interestingly, these features are already provided by non-standard software, which is freely available. The exclusive content being apparently of little interest according to the article, the subscription seems to rather be “tax” on people who don't know they could legitimately get the same service for free.

Youtube being a business, it needs to get revenue, at least to support the cost of its large IT infrastructure. Since users are not charged any money, Youtube's revenue comes (exclusively?) from advertising (I guess that the collection of user behavioural data and their profiling is also sold to advertisers). Youtube's content therefore has value only insofar as it attracts potential consumers and exposes them to advertisement. The content itself does not matter to the platform, as long as users are drawn to it.

This is thus the foundation of the Web platforms and the Attention Economy, where the users' attention is the actual product being sold by the platforms. User profiling and Big Data is only a tool used for maximising the amount of attention being captured.

Advertisers are gamblers, you don't need to let them win

In 2004, Patrick Le Lay, then CEO of the French TV channel TF1 said “what we sell to Coca-Cola is available human brain-time.” One aspect of this is that TV channels sell advertisers the opportunity to reach the channel's viewers and attempt to influence them into buying the advertised products.

From the point of view of the advertisers, it is a gamble: they bet money (the cost of producing the TV commercial and the price paid to the TV channel to show the commercial) and hope to gain from it (when viewers buy their products because they have seen the commercial and have been influenced by it). This gamble is two-fold: the viewers may or may not see the commercial, and they may or may not be receptive to the influence techniques used in the commercial.

In social media, advertisement can be considered from the same angle: the website sells advertisers display space on its pages, and the advertisers gamble that users of the website will see the commercial and be influenced by it.

While everybody agrees that you don't have a moral obligation to buy a product after you have seen a commercial, it seems less obvious that you don't either have any moral obligation to view the commercial. For example, you could close your eyes and plug your ears to ignore the commercial; you could even use tools that automatically hide the commercial from you.

Putting the advertisers' money to uses I approve of

As I want to protect myself from the influence of advertisers, I normally use automated tools that prevent me from seeing advertisement. I record television programs and skip the commercials (automatically when the tool works as intended, otherwise manually), and I use ad blockers in my Web browser to prevent commercials from being displayed on my screen.

The difference between TV and the Web is that the TV channel gets paid for broadcasting the commercials and cannot control whether or not I skip them while advertisers on the Web pay the websites only if the commercial is being fetched i.e., only if I allow the Web browser under my control to display the commercial. In that case, my preferred solution would be to fetch the commercial as if it would be displayed, without actually displaying it. And since advertisers not only display commercials but also track the users across websites, it is necessary to isolate each commercial so that the tracking is not possible.

I would not normally care about websites not being paid by their advertisers, but in the particular case of Youtube, I use tools that allow me to watch content without having to view any commercial, meaning that the content's creators cannot hope to get payment from Youtube. I therefore dream of a tool that would allow me to channel advertisers' money to the content creators without having to view any commercial, thus letting the advertisers gamble, but strongly shifting the odds of this gamble in my favor. I consider this to be retribution for the advertisers' attempt at influencing me for their profit.

The Solarized color scheme redefines some of the standard basic ANSI colors, making some color combinations unsuitable for display. In particular, bright green, bright yellow, bright blue and bright cyan are tones of grey instead of the expected colors.

Also, some terminals interpret bold text as bright colors, turning e.g, bold green into a shade of grey instead of the expected green. At least in URxvt, setting intensityStyles: False will prevent bold text from being displayed in bright colors (but will still be displayed in a bold font).

When redefining color schemes for terminal applications using ANSI colors, these are possible combinations, using the usual ANSI color names. Note that bright colors are usually not available as background colors.

Solarized Light default background (ANSI white)

Normal: black red green yellow blue magenta cyan (light)grey

Bright: black/grey red green yellow blue magenta cyan white

ANSI (Light)Grey background

Normal: black red green yellow blue magenta cyan (light)grey

Bright: black/grey red green yellow blue magenta cyan white

Solarized Dark default background (ANSI bright black/grey)

Normal: black red green yellow blue magenta cyan (light)grey

Bright: black/grey red green yellow blue magenta cyan white

ANSI Black background

Normal: black red green yellow blue magenta cyan (light)grey

Bright: black/grey red green yellow blue magenta cyan white