diff --git a/doc/the_floatimg_hack.tex b/doc/the_floatimg_hack.tex index f4352b97..3756f95a 100644 --- a/doc/the_floatimg_hack.tex +++ b/doc/the_floatimg_hack.tex @@ -27,8 +27,8 @@ \usepackage[verbose]{layout} \usepackage{ulem} -\setlength \parskip {0.15em} -\setcounter{tocdepth}{1} % XXX à regarder un de ces jours ? +\setlength \parskip {0.18em} +\setcounter{tocdepth}{2} % XXX à regarder un de ces jours ? \makeatletter % explication de ce truc ? @@ -54,11 +54,9 @@ \section*{Une image flottante ?} -\textsl{Back in a far past part of history.} - +\vspace{2em} \textsl{Mais de quoi parle-t-on exactement ?} - -% XXX XXX XXX\vspace{1em} +\vspace{2em} Traditionnellement, les valeurs des pixels dans les images informatiques sont mémorisées sur 8 bits, un octet\index{octet}, @@ -112,7 +110,8 @@ numériques quand certains ont songé à passer du flou mental à la grille physique. Les détails techniques sur cette représentation sont en page -\pageref{FloatImg desc}, avec des pointeurs dedans. +\pageref{FloatImg desc}, avec des pointeurs et des +tableaux dedans. Ah, les pointeurs, la pire chose du monde, mais pourquoi s'en passer\dots \subsubsection*{quelques rappels de comment on acquiert et numérise une image} @@ -159,7 +158,8 @@ la glisser dans le capitalisme de surveillance. Pour le moment, seule la quête de l'empirisme absolu a été visée. Les justifications mathématiques attendront le retour -du schmod777. Ceci dit, rien ne nous empêche d'aller consulter +de monsieur Schmod777. +Ceci dit, rien ne nous empêche d'aller consulter Wikipedia, afin de mieux connaitre ces nombres flottants que nous allons utiliser~: @@ -193,7 +193,8 @@ effectuée afin d'éviter les potentiels inconvénients. Ceci dit, le standard \textsl{ieee754}\index{ieee754} nous indique qu'il y a 23 bits pour la mantisse, ce qui nous propose déja -plus de huit millions de valeurs. Considérons un cas typique~: +plus de huit millions de valeurs possibles. +Considérons un cas typique~: le cumul de $N$ images ayant un niveau maximum $Vm$. \subsection{Pixel négatif ?} @@ -217,7 +218,7 @@ mais nous sommes tous là pour améliorer les choses, dans la mesure de nos moyens. Nous allons donc directement rentrer au cœur du problème, en écrivant quelques lignes de code montrant le fonctionnement -général de la chose. +général de la chose vu du coté de la machine. \subsection{L'idée} @@ -242,8 +243,8 @@ en mémoire centrale, l'initialisation des valeurs de chaque pixel à 0.0 (une valeur que certains associent au noir complet, et d'autres à une impossibilité quantique), et pour conclure, l'enregistrement de cette image dans un -fichier\footnote{Au format -ésotérique, mais très véloce.} binaire. +fichier\footnote{Au format ésotérique, mais très véloce.} +binaire. \begin{lstlisting} memset(fimg, 0, sizeof(FloatImg)); @@ -260,7 +261,6 @@ if (foo) { } \end{lstlisting} - Une fois ce code enrobé dans un \texttt{main()}, compilé puis exécuté, nous pouvons entrevoir, grâce au logiciel \texttt{fimgstats} (décrit en page \pageref{fimgstats}), @@ -299,7 +299,8 @@ une distribution Debian\index{Debian} récente (amd64 et x86), mais ça marche quasiment pareil avec Fedora\index{Fedora} 64, et probablement Raspbian\index{Raspbian}, modulo les éventuels -soucis de boutisme. +soucis de boutisme que j'ai absolument négligés de prendre +en compte. \textit{Attention, ça va devenir un peu gore\dots} \subsection{Prérequis} @@ -475,17 +476,18 @@ toucher. Les types d'images actuellement gérés sont les trois grands classiques : niveau de gris, rouge-vert-bleu et rgb avec un canal alpha, et expliquées quelques lignes plus haut. +XXX\index{XXX} raconter fimg\_clone + Comme vous allez le voir plus loin, il y a plein de fonctions qui prennent en argument deux images: la source et la destination. Dans la plupart des cas, ces deux images doivent être compatibles, -c'est à dire même type et mêmes dimensions. +c'est à dire de même type et de mêmes dimensions. \begin{lstlisting} /* return 0 if pictures are compatible */ int fimg_images_not_compatible(FloatImg *a, FloatImg *b); \end{lstlisting} - C'est bien beau d'être enfin une image résidente en mémoire centrale, mais pouvoir aussi exister à long terme en étant stocké dans la matrice est tout aussi pertinent. @@ -532,12 +534,13 @@ intégral\footnote{Un vrai désastre, même...}. \subsection{Dessiner} -Bon, vous avez une image latente, et vous souhaitez dessiner dessus -(ou dedans ?) avec vos encres flottantes ? -Il y a des fonctions pour ça, par exemple~: +Bon, vous avez en mémoire centrale une image latente, +et vous souhaitez dessiner dessus (ou dedans ?) avec vos encres flottantes ? +Il y a actuellement deux fonctions pour ça, légèrement différentes~: \begin{lstlisting} int fimg_plot_rgb(FloatImg *head, int x, int y, float r, float g, float b); +int fimg_put_rgb(FloatImg *head, int x, int y, float rgb[3]); \end{lstlisting} Les paramètres sont explicites, mais leur validité doit être @@ -676,10 +679,11 @@ aux bonnes dimensions (échange W et H). D'un design très empirique, c'est certainement à revoir pour l'avenir. La force du \textsl{legacy} va-t-elle dominer le monde ? -Il faudrait normaliser l'endianess et le packing dans les structs% -\footnote{Directives du compilateur ?}, et surtout l'ajout +Il faudrait normaliser l'endianess et le packing dans les +structuress\footnote{Directives du compilateur ?}, et surtout l'ajout de données sur la prise de vue, du genre type de capteur, date et heure, -réglages divers\dots +réglages divers. Nous appelerons ça les metadonnées, et +nous en parlons dans quelques pages.\dots \begin{lstlisting} typedef struct { @@ -924,7 +928,8 @@ int fimg_filter_3x3(FloatImg *src, FloatImg *dst, FimgFilter3x3 *filtr) Comme dans la plupart des cas, la gestion des valeurs négatives de pixel est laissé au hasard, qui fait souvent du portnawak. Quoique, il doit bien exister -quelques solutions de contournement : clamping ou shift ? +quelques solutions de contournement : +valeur absolue, clamping ou shiftup ? \textsl{To be continued\index{XXX}\dots} @@ -937,8 +942,8 @@ le répertoire \texttt{funcs/}. Elle aura donc accès aux \textsl{internals}% \footnote{que je peux décider de changer n'importe quand} de \textsc{FloatImg}, -une chose qui est en principe interdit aux programmes -\textsl{enduser}. Soyez prudents. +une chose qui est en principe interdite aux programmes +\textsl{enduser}. Soyez donc prudents. Cette fonction va faire quelque chose à partir d'une image source et d'une valeur, et écrire le @@ -981,14 +986,17 @@ de fonctions prévues à cet effet, mais il fallait rester simple\dots % =================================================================== \section{Les outils}\label{outils} -\textsf{3615mavie} : sur des projets comme celui-ci, qui travaillent -in-fine sur des objets que l'on peut considérer comme « physiques », +\textsf{3615mavie} : pour des projets comme celui-ci, qui travaillent +\textit{in-fine} sur des objets que l'on peut considérer +comme « physiques », il est important de passer à une utilisation -normale\footnote{Il y a une vie en dehors de git.} et construire -des trucs qui mettent en action le code primitif pour partir -sur des bases saines. +normale\footnote{Il y a une vie en dehors de git et des compilations.} +et construire +des briques de base qui mettent en action le code primitif pour +partir sur des bases stables, documentées (ahem\dots), et +directement utilisables. -Ces machins ont en commun quelques options bien pratiques~: +Ces cliwares\index{cliware} ont en commun quelques options bien pratiques~: \texttt{-h} pour avoir un résumé des options disponibles, \texttt{-v} qui augmente la puissance de bavardage, et \texttt{-K nn.nn} pour un paramètre flottant. @@ -1227,7 +1235,8 @@ après la grande pandémie\dots Cet outil accumule\index{cumul} une quantité d'images flottantes (de même taille et de même type) afin d'obtenir -un flou temporel de meilleure qualité. Aucune mise à l'échelle n'etant +un flou temporel de meilleure qualité. +Aucune mise à l'échelle n'etant effectuée, les pixels de sortie peuvent atteindre des valeurs considérables\footnote{Faut-il prévoir une gestion des \textsf{overflows} ?} @@ -1615,7 +1624,8 @@ des choses essentielles comme la liste des résolutions disponibles. Ajustement \textsl{Brightness Contrast Saturation Hue\dots} -Probablement pilotable au joystick\index{joystick}. +Probablement pilotable au joystick\index{joystick} et surtout +par OSC (Open Sound Control). % =================================================================== \section{À l'extérieur} @@ -1625,6 +1635,8 @@ il est souvent nécessaire de pouvoir communiquer facilement avec eux. Nous avons déja quelques possibilité d'exportation, mais passer par cette étape intermédiaire est parfois délicat à gérer dans un \textsl{pipedeprod} autrement bien huilé. +De même, nos capacités d'importation sont vraiment trop +réduites, Jpeg et PNG étant les deux priorités. \subsection{ImageMagick}\index{ImageMagick} @@ -1700,7 +1712,8 @@ ces images. Mais ce n'est qu'une façon déguisée de faire du cumul. C'est à ce moment que nous changeons l'axe de vue du défi. Par ailleurs, il m'a semblé pertinent d'inclure dans le projet une -foultitude d'effets spéciaux. +foultitude d'effets spéciaux% +\footnote{\textsl{aka} IBM\index{IBM} (image brotching module)}. Qui manquent cruellement de possibilités de paramétrage. Mais peuvent être enchainés dans ce que j'appelle des \textsl{filter-chains}~: ces effets seront appliqués dans @@ -1800,8 +1813,9 @@ usage: Il n'y a pas de moyenne mobile, pas d'interpolation, mais un facteur de répétition qui permet de dupliquer $N$ fois une image dans le flux de -sortie. Si vous globez \texttt{frames/????[02468]}, vous prenez -une image sur deux, alors un facteur de répétition à $2$ conservera +sortie. Si vous globez \texttt{rush/????[02468]}, vous prenez +en compte une image sur deux de la séquence capturée, +alors un facteur de répétition à $2$ conservera la 'vitesse' de la séquence, mais avec une petite saccade régulière de bon aloi \textit{:)} @@ -1829,12 +1843,18 @@ et sans but précis. Je le \textit{runne} et je le \textit{re-runne} un gazillion de fois dans mon cerveau processique. Quel va être son facteur $O$ ? Je fais donc des essais. +\subsection{movepixels} + +\subsection{muxplanes} + % =================================================================== \section{Et pour la suite ?} En fait, je fait de la photo par la méthode du « cumul »\index{cumul} -depuis plusieurs années. Une webcam\index{webcam}, +depuis plusieurs années, au début avec vgrabbj et convert, +puis avec floatimg et ses satellites. +Une webcam\index{webcam}, un Linux\index{Linux}, et ça \textsl{juste marche}. Sauf que c'est quand même un peu galère à déplacer, il faut avoir un shell pour déclencher, c'est pas facile à utiliser @@ -1843,8 +1863,9 @@ en mode portnawak\dots L'idée est donc de construire un appareil autonome, basé sur un Raspi et une webcam \textsc{usb}\index{USB}, pilotable par \textsc{lirc}\index{LIRC}, alimenté par une (grosse) batterie et permettant d'aller -faire des images au bord d'un lac ou dans la campagne de l'Ariège. -Et, comme le dit la sagesse populaire : « fimg at 11 ». +faire des images au bord d'un lac ou dans la campagne du Gers% +\footnote{Aux Bourtoulots, par exemple.}. +Et comme le dit la sagesse populaire : « fimg at 11 ». % -------------------------------------------------------------------