Coop – Code Bare pour des Champignons Shitake

Les codes barres de la Coop

Coop – Code Bare pour des Champignons Shitake

Les codes barres sont une de ces choses omniprésente qu’on ignore facilement : on passe à la caisse, la caissière passe le code devant la laser, ça fait bip et le prix est sur le ticket. Sur la majorité des codes barres, le prix n’est pas encodé dans le code, le code est simplement l’identificateur du produit, assigné par le fabricant. Si un produit est présent dans deux magasins, on peut très bien le sortir du magasin A et le mettre dans le magasin B, et le prix sera toujours celui du magasin B.

Une exception à cette règle sont les codes barres à la pesée, clairement ma sélection de champignons shitake de 44 grammes ne se trouve pas dans la base de donnée du magasin. Les informations sont donc codées dans le code barre. En dessous du code barre se trouve sa représentation numérique :


Si on regarde les chiffre de plus près, on peut remarquer certaines choses.

  • Le code comporte 13 chiffres
  • Le prix en centimes est représenté sur les chiffres 8 à 12.
  • Le code commence toujours par les chiffres 02 ou 05.

Le préfixe 02 désigne des codes à usage restreint, c’est à dire qu’ils n’ont de signification que dans le magasin qui les a émis. Ils sont typiquement utilisé pour les produits en quantités variables, pesé au magasin, exactement comme mes champignons. Ces codes barres n’auront pas de sens, ou un sens différent dans un autre magasin. Le préfixe 05 est techniquement réservé pour les coupons de rabais. Leur utilisation pour un produit à la pesée est techniquement une violation de la spécification. Je suppose que la Coop n’accepte pas de coupons avec le préfixes 05, sinon elle va au devant de bricoles techniques.

Le dernier nombre est le check digit, il est calculé en prenant les chiffres depuis l’avant dernier et en les multipliant alternativement par 3 et par 1. Pour le code 0540226001752, il se calcule de la manière suivante: 5 × 3 + 7 + 1 × 3 + 0 × 1 + 0 × 3 + 6 × 1 + 2 × 3 + 2 × 1 + 0 × 3 + 4 × 1 + 5 × 3 = 108. On garde le dernier chiffre de 108 → 8, et ont fait le complément à 10, i.e. 10 – 8 = 2. Ce qui correspond bien au dernier chiffre.

Les quatre premier nombres semblent indiquer le type de produit, et les trois suivants le produit exact. J’ai pour l’instant relevé la structure suivante :

  • 0540 – fruits & légumes à la pesée.
  • 0580 – fromages, viande pré-découpée (poulet).
  • 0220 – viande
  • 0210 – produit pré-emballés: charcuterie, légumes en barquette, etc.

À noter que pour les fruits & légumes le code du produit ne correspond pas au numéro sur la balance. Les bananes sont au n°1 sur la balance, mais leur code est 313.

Ce qui est un peu bizarre, c’est que le code de la carte Supercard commence par un 2, et se trouve ainsi dans une autre zone réservée aux produits à la pesée (à noter que la carte Cumulus de la Migros aussi).

Flattr this!


New Consoles

PlayStation 3 Slim Model

Computer gaming these days tends to be split between console gaming and PC gaming. Those two system tend to be used in different ways, for different games, and have very different economical models. Gaming consoles are typically in the living room connected to something like a big TV with reasonably low resolution (full HD), and used with joystick like controllers. PC games tend to be played at a desk, with mouse & keyboard on a monitor that can display much higher resolution. Technically you can always connect a keyboard to a console, or a joystick to a PC, but the default controller defines the assumptions of the games.

While the two models are pretty different, they are competing for the gamer’s money, and the attention of game developers, a game build for a console often does not feel right when ported to PC, and reciprocally. What system is winning out? It really depends how you look at it, because this week saw news that are in appearance contradicting each-other.

Ars Technica had an interesting article about mouse and keyboard loosing the First Person Shooter market. First person shooter have historically been the privileged domain of PC gaming, but some new FPS games are now designed for the console first, and maybe not even ported to Windows. Sony also announced the Playstation 4 and gave an overview of the technical specifications : an x86 machine designed to work in the living room. If you frame the gaming world as a war, the natural question is, who is winning, but as often the real question is, who is loosing, and what.

Console have lost their hardware model. When the PS3 came out it had very powerful, custom CPU and a blue-ray disk which was very expensive at that point. The general expectation was that the hardware would be top notch on the release day and be able to stay in the market for a long time: the PS3 came out in 2006 and is still sold. The problem of this model is that consoles have become very expensive, and despite this, manufacturers have to sell their console at a loss and make money back on the price of games. This also pushes manufacturers to make sure that people who buy their system also buy games, and there is little incentive to make the console work well as a general computing device, as that usage is brining no money. If you look at the hardware specs of the new PS4, Ars Technica describes the machine as a honest mid-range gaming PC, but it is doubtful that this machine will shop shelves in 2019.

The PC side is loosing the deployment war. While game installation on PC has certainly improved from the days when one was asked to configure the interrupts of the sound-card, game writers still have to grapple with an extremely heterogenous set of target machines. Games therefore need to be designed in a way that gracefully degrades for machines with lower performances, but this introduces complexity. Each different hardware variant can cause new bugs, which requires additional engineering and support.

Of course, the elephant in the room is phone and tablet gaming, which has stolen both attention and money from both PC and console games. Phone games are generally much cheaper and moved the attention from impressive graphics back to gameplay. Fun has never been a linear function of the hardware capabilities, so improving the hardware is giving diminishing returns.

Flattr this!

Shifting vs. Scaling


With the advent of the web, colours expressed in numerical form have become much more prevalent, while CSS supports named colours, the most common way is to use the hexadecimal RGB (Red Green Blue) format. A pure blue colour would be represented as #F00000 or #F00. The first format represents the colour as three 8 bit values, the second as three 4 bit values. People often use the 4 bit format because it is shorter and the difference are very minor.

If you look at the box on the side, it contains sixteen red blocks, specified each with a slightly different shade of red, the darkest at the top-left edge, the lightest at the bottom right. Many mobile screen cannot display 24 (3×8) bits colour, but handle a more conservative 15 (3×5) bits. The old web-safe colour table further restricted the set of colours to six hex values per channel: 0, 3, 6, 9, C and F, for a total of 216 colours.

Converting from 8 bit data to 4 bits is very easy, you just shift right and drop the superfluous bits. So the binary 11110000 becomes 1111. How do you do the reverse conversion? The naive version is to simply shift to the left, so 1111 becomes 11110000. This is a very bad solution, imagine you are converting from a 2 bit per channel model to 8 bit per channel model. So you convert 11 to 11000000 so a red block would become dark red instead of bright red .

So instead of shifting, the proper way is do scaling. This can of course be done mathematically, in this case, if c is your 4 bit colour, then your 8 bit colour is 256 × (c ÷ 4). The quick way to do this with bit manipulation is to replicate the short bit sequence in the long format, so the new binary value would be 11111111, first the shifted bits 11, then the same bits replicated for each sequence of two bits.

Flattr this!


The flow of coding…

After some more hacking around, my code to handle IFF/ILBM images in HTML5 is reasonable complete, that is, it handles most of the image files I found, some exotic graphical modes.

The code is, of course, far from perfect, it was more a personal exercise than something useful – the image format that it handles is both obsolete and inefficient. One could ask me why I do this kind of things, and the obvious answer would be because it is fun. While this answer is valid, it is not very useful, in the sense that it does not explain what motivates me to do such coding, after all, coding is already my work, so why would I do it during my free time?

First, this coding that is pretty different from what I do for work: the scales are very different, a bit like an architect doodling houses as hobby. This code manipulates old data-structures where things were manipulated at a low-level, individual bits are manipulated around. At works, I rarely code at such a granularity, so it is an refreshing experience. Cracking open an old format like this is pretty much like a puzzle, trying to align the various instructions until the image look right.

This particular puzzle links images and data structures from the time I first learnt coding with much more modern technologies, spanning in time a good chunk of my coding experience.

While there is a strong technical basis, coding relies a lot on practice: quirks and idiosyncrasies are common, and without some intuition it is difficult to handle the monstrous complexity of the different frameworks and languages. Each time I have to learn a new one, there is this mixture of dread and excitement not unlike when one is at a foot of a mountain, about to try to climb on it. Small coding exercises like this one are a bit like a Sunday stroll on the small mountain close to my house.

Coding has certainly something in common with martial art practice – leading some to the concept of code dōjo. Like in martial arts, practice is important, but even more important is the notion of being in the flow, to be concentrated on the task at hand while at the same time being relaxed. Coders tend to express this as being in the zone, different words for a similar idea: at least for me, being in the flow while doing Aikidō is eerily similar to being in the zone at work.

Flattr this!

For this © Vector (Szalkai Peter)

ILBM Animations

I have been hacking around on my small javascript library to load ILBM/IFF files, once I had fixed HAM decoding the next logical step was to add support for animations. This was for me a good opportunity to learn about animations in Javascript, in particular window.requestAnimationFrame. I’m not 100% sure that the code is correct, as the rare specs I found about the CRNG chunk are pretty thin on details, I have something that seems to work and does not kill the CPU of my laptop completely.

The animation on this page is For This, an ILBM file with an animated colour palette, created by Vector (Peter Szalkai). Interestingly this image has a pixmap of 320 × 256 which hints to a PAL Amiga.

Flattr this!



Un mot anglais qui manque à mon avis cruellement en français est narrative, il est généralement traduit par narration, mais cela efface la distinction – importante – entre le fait de narrer, et ce qui est narré. Comme souvent, le français brouille la distinction entre l’acteur et l’acte. J’ai souvent l’impression que ma vie aurait besoin d’une meilleure narrative, mais pas d’une narration.

Je n’ai pas besoin d’une voix off qui raconte ce qui se passe. On dit souvent chercher le sens de la vie, cela implique quelque chose de profond, de philosophique – je me contenterais d’une fil narratif cohérent ; bref, que ma vie soit une histoire un tant soit peu crédible.

Pourquoi cette obsession par la narration ? S’il y a une chose que j’ai réellement réalisé ces dernières années, c’est à quel point les gens pensent en termes d’histoire. Si un fait est en contradiction avec le film que se joue l’interlocuteur, il aura de la peine à y croire et surtout à l’intégrer. Le fait qu’il soit correct et étayé par des faits importe peu. C’est le problème des gens religieux : ils sont pris dans une narration épique qui prend beaucoup de place. De manière amusante, en allemand, Narr décrit le fou que ce soit à la cour ou sur les lames de tarot – l’étymologie est cependant différente.

Cet état de fait est particulièrement fascinant lorsque, comme moi, on a passé une bonne partie de sa vie à raconter des histoires durant des parties de jeu de rôle, et qu’on travaille dans une entreprise technique par excellence, où de telles considérations littéraires ne devraient pas avoir cours. Pourtant si l’on veut qu’un projet ait une certaine cohérence, un impact, il faut se concentrer sur une idée centrale, sous peine de se retrouver avec d’un côté une longue liste de fonctionnalités et l’autre un système difficile à appréhender, vu qu’il est impossible à raconter.

Flattr this!


Ham decoding fixed

After sharing my library for displaying ILBM/IFF files, Amiga Graphics correctly pointed out that the HAM image handling was buggy, this is now fixed: I was not making a copy of the palette colour used in Hold & Modify, so it was getting modified, i.e. corrupted.

The following image, Angel, by Dennis Jacobson/JAKE Productions is a ILBM/IFF Hold and Modify image based on a picture of Karen Velez from 1985. Note that the source pixmap is 400 × 320 pixels with a rendering ratio of 20 ÷ 11, the Amiga had strange video modes.

Flattr this!


Amiga ILBM files

This image (MEDUSABL.IFF) is one of the few Atari ST IFF files I could find on the web, it is quite typical of the graphics of the time: low resolution, 4 bit palette.

The next big thing after the Commodore 64 was, of course the Amiga. While a 16 bit processor with a 8 Mhz clock is something you use for a washing machine today, in those days it was something awesome. The Amiga was renowned for its graphical capacities as it could display more than the 16 fixed colours of the C64.

One graphical mode that was particular interesting was Hold and Modify (HAM), which enabled the display of up to 4096 colours in a fixed image using only 8 bits per pixel. HAM is basically a hack, where each pixel can either be looked-up in a colour table (the standard way of doing things in those days), or re-use (hold) the colour of the previous pixel and modify the value one of one of the channels (Red, Green, or Blue), hence the name Hold and Modify.

The graphical image format of the Amiga was , a particular instance of the . I wanted to see if I could write a parser for the IFF/ILBM format that would read directly the original file and display it in an HTML5 canvas. It was a fun project, as the ILBM format stores image data in a way that is completely different from the way things are done nowadays: instead of storing all the bits for a given pixel together, they are split between bitplanes, each pixel is represented by a single bit in multiple bitplanes. This was related to the way Denise, the graphical chip of the Amiga, handled graphics. I also had to write code to decompress the data.

Interestingly this format shares some technology with the Macintosh: IFF reuses the idea of 32 bit type codes adopted by the Mac, and in return the Mac used a IFF based format for sounds, AIFF. ILBM also uses the compression introduced by Apple. The IFF format still survives in a way: the WebP format uses the RIFF container, which is basically the little endian version of IFF.

Anyway, I managed to get something that works, the code can load and display both palette and HAM ILBM files. I could not write code that handles HALFBRITE format because I did not find any example image. My code parses the palette animation tables, but does not perform the animation, although it looks like it is possible: this blog post shows some impressive colour table animations using the gorgeous art of Mark Ferrari, it also uses ILBM files as a source, but pre-converts the data in JSON.

You can find the standalone image visualisation web page here and the javascript library that does the work here, the library is distributed under the BSD license.

Edit: changed the frame page code to be a bit more generic.
Edit: the library now has its own page, it now supports animations and EHB images.

Flattr this!