From db715485a2ae84bd362815d8fc5d8d0ca5268def Mon Sep 17 00:00:00 2001 From: tth Date: Thu, 20 Feb 2020 02:31:06 +0100 Subject: [PATCH] encore un peu de mieux dans la doc --- doc/the_floatimg_hack.tex | 86 +++++++++++++++++++++++++++++---------- lib/fimg-file.c | 5 +++ 2 files changed, 70 insertions(+), 21 deletions(-) diff --git a/doc/the_floatimg_hack.tex b/doc/the_floatimg_hack.tex index c2440a83..c75c0acf 100644 --- a/doc/the_floatimg_hack.tex +++ b/doc/the_floatimg_hack.tex @@ -110,9 +110,10 @@ basiques en C, gérant la structure des données d'image en mémoire et sur disque. Ça a été imaginé de façon presque empirique, 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. +Nous allons donc directement rentrer au cœur du problème, +en écrivant quelques lignes de code. -Pour commencer par quelques chose de simple, +Pour commencer par quelque chose de simple, nous allons créer une image RGB\index{RGB} complètement noire, puis l'enregistrer dans un fichier \texttt{.fimg}\index{.fimg}, un format complètement inconnu, puisque je viens de l'inventer @@ -295,9 +296,9 @@ pas être la même chose dans l'avenir. \subsection{Les fondations}\index{lib/} -La première chose à voir est la gestion dynamique de la mémoire occupée -par tous ces pixels flottants, ce est un sujet parois -délicat\footnote{GC}. +La première chose que nous devons absolument voir est la gestion +dynamique de la mémoire qui sera occupée par tous ces pixels flottants, +ce qui est un sujet parfois délicat\footnote{GC or not GC ?}. Elle est donc faite, à la base, par ces deux fonctions~: \begin{verbatim} @@ -306,7 +307,7 @@ int fimg_destroy(FloatImg *fimg); \end{verbatim} L'appelant doit lui-même gérer le descripteur d'image (une structure -C décrite plus haur) en le considérant comme un type semi-opaque dont +C décrite plus haut) en le considérant comme un type semi-opaque dont la forme peut varier. Certains membres de cette structure sont documentés dans ce document, et les autres sont dangereux à toucher. Les types d'images actuellement gérés sont les trois grands @@ -326,18 +327,27 @@ Recharger une image depuis un fichier nécessite que celle-ci et l'image de destination en mémoire ait précisément les mêmes caractéristiques (taille, type...), donc l'image en ram doit être -pré-allouée. Mias comment peut-on connaitre ces valeurs ? - -\begin{verbatim} -int fimg_fileinfos(char *fname, int datas[3]); -\end{verbatim} +pré-allouée. On peut connaitre ces valeurs en appelant +\texttt{int fimg\_fileinfos(char *fname, int datas[3])}. Si tout s'est bien passé (valeur retournée égale à 0), on va trouver la largeur dans \texttt{datas[0]}, -la hauteur dans \texttt{datas[1]} et le type dans \texttt{datas[2]}. +la hauteur dans \texttt{datas[1]} et le type dans +\texttt{datas[2]}\footnote{La fonction +\texttt{fimg\_type\_is\_valid(int type)} peut vous aider}. + +Je sais aussi que certains d'entre vous aiment la facilité, aussi +je vais vous révéler l'existence d'un nouveau truc bien plus +simple, une fonction qui enchaine ces deux actions +(allocation, puis lecture), et s'utilise +comme ça : + +\begin{verbatim} +FloatImg head; +memset(&head, 0, sizeof(FloatImg)); +foo = fimg_create_from_dump("lena.fimg", &head); +\end{verbatim} -La fonction \texttt{fimg\_type\_is\_valid(int type)} peut -vous aider. % _________ @@ -436,22 +446,26 @@ Et le résultat est très moyen : il n'y a pas d'interpolation. % ---------------------------------- -\subsection{Exportation}\index{export}\label{export} +\subsection{Exportation \& Importation}\index{export}\label{export} Notre format de fichier étant totalement inconnu, il nous faut bien exporter nos images en quelque chose de plus connu. Bien entendu, c'est toujours affaire de compromis entre précision de valeurs et taille des fichiers. -Il faut aussi reconnaitre que c'est un peu la jungle dans les -formats de fichiers d'image\dots +Et dans le sens inverse, il serait bien de savoir importer +le monde extérieur dans nos sombres caves à pixel. +Il faut quand même reconnaitre que c'est un peu la jungle dans les +formats de fichiers d'image, ce qui explique le retard +dans ce domaine\dots \subsubsection{Vers PNM}\index{PNM} Nous avons ici 16 bits par composante, mais au prix -d'une taille énorme sur les fichiers. D'autre coté, +d'une taille énorme sur les fichiers. D'un autre coté, l'utilisation du codage \textsc{ascii}\index{ascii} -(alors qu'on pourrait mettre du binaire, plus compact) y est pour quelque chose. +(alors qu'on pourrait mettre du binaire, plus compact) y est +pour quelque chose. \begin{verbatim} int fimg_save_as_pnm(FloatImg *head, char *fname, int flags); @@ -463,29 +477,58 @@ Le bit \texttt{0} du paramètre \texttt{flags} mis à \texttt{1} demande Et si il est à zéro, c'est la fonction de recherche de valeur maximale (cf page \pageref{contraste}) qui est utilisée. +Le bit \texttt{1} permettra bientôt\index{vaporware} de demander +l'enregistrement de métadonnées\index{metadata} pertinentes, telle +que l'epochtime de l'enregistrement. + Les autres bits ne sont pas utilisés et doivent être à zéro. \subsubsection{Vers PNG}\index{PNG} Actuellement, on peut enregistrer uniquement en mode RGB, 8 bits par composante, mais on a quand même une bonne compression, ça compense. +J'utilise \textsl{libpnglite} avec qui j'ai un peu de mal à suivre. +Mais je me soigne. Le mode 16 bits va bientôt arriver. \begin{verbatim} int fimg_save_as_png(FloatImg *src, char *outname, int flags); \end{verbatim} + \subsubsection{Vers TIFF}\index{TIFF} +Le format canonique de la PAO\index{PAO} du siècle dernier. Il permet +de gérer une foultitude de formats numériques. C'est aussi un format +classique proposé par les scanners corporates. + To be done\index{XXX} +\subsubsection{Vers FITS}\index{FITS} + +Essentiellement des images d'astronomie. + +To be done\index{XXX} + + \subsection{Utilitaires} +Commençons par quelques petits trucs pour nous faciliter la vie +dans des domaines annexes, +tels que l'interprétation d'arguments dans la ligne de commande ou un +fichier de configuration. + \begin{verbatim} int parse_WxH(char *str, int *pw, int *ph) int parse_double(char *str, double *dptr) -int format_from_extension(char *fname) \end{verbatim} + +La fonction \texttt{int format\_from\_extension(char *fname)} examine un +nom defichier tel que \texttt{lena.xxx}, et retourne, si la partie +\texttt{xxx} un éventuel nombre positif, dont les valeurs sont dans floatimg.h +le valeureux. +Les extensions connues sont : fimg, png, pnm et tiff. + To be continued\index{XXX} @@ -504,7 +547,8 @@ int fimg_killcolors_b(FloatImg *fimg, float fval); \subsection{Filtrages} -To be done\index{XXX} +To be done\index{XXX}, et il faut que je réfléchisse au traitement +des bords d'image. % ---------------------------------- diff --git a/lib/fimg-file.c b/lib/fimg-file.c index 74d6413e..1281ee25 100644 --- a/lib/fimg-file.c +++ b/lib/fimg-file.c @@ -160,6 +160,11 @@ FimgFileHead filehead; fprintf(stderr, ">>> %-25s ( '%s' %p )\n", __func__, fname, head); #endif +/* + * may be we can crash coredump here if the head + * descriptor is not blank ? + */ + fp = fopen(fname, "r"); if (NULL==fp) { perror(fname);