cosmetic + bla

This commit is contained in:
tTh 2024-08-28 22:41:47 +02:00
parent 556e1ad825
commit f473a58f75

View File

@ -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 ».
% -------------------------------------------------------------------