le champs max de l'entête doit être la valeur max du codage et non du contenu. ex : une image2d<int_u8> réduite à un unique point dont le niveau est 12 => champs max à 255 (et non 12)
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud wrote:
le champs max de l'entête doit être la valeur max du codage et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur pourrait aussi etre presente): Index: olena/oln/io/pnm_write_2d.hh --- olena/oln/io/pnm_write_2d.hh Sat, 27 Sep 2003 18:30:39 +0200 burrus_n (oln/u/44_pnm_write_ 1.4 600) +++ olena/oln/io/pnm_write_2d.hh Fri, 31 Oct 2003 16:13:02 +0100 jb (oln/u/44_pnm_write_ 1.4 600) @@ -129,9 +129,7 @@ pnm2d_info info; info.cols = im.ncols(); info.rows = im.nrows(); - oln::utils::f_minmax<oln_value_type(I)> f; - traverse(f, im); - info.max_val = f.max(); + info.max_val = ntg_max_val(oln_value_type(I)); if (info.max_val > ntg::to_ntg(65535U)) return false;
mandor <mandor@lrde.epita.fr> writes:
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud wrote:
le champs max de l'entête doit être la valeur max du codage et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur pourrait aussi etre presente):
Non, il n'y a pas de vrai problème. Juste la sauvegarde des images sur 32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus sain d'obliger l'utilisateur a convertir en 16 bits lui même si il veut sauver, plutôt que d'accepter puis de refuser de temps en temps si il a une valeur trop grande.
Nicolas Burrus wrote:
mandor <mandor@lrde.epita.fr> writes:
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud wrote:
le champs max de l'entête doit être la valeur max du codage et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur pourrait aussi etre presente):
Non, il n'y a pas de vrai problème.
si ! prenons une image dont tous les pixels valent 127 et dont le type des données est int_u8 : - qd le header est 255, on sait donc en re-chargeant l'image qu'elle contient des int_u8 et elle apparaît en gris moyen (avec xv, gimp, etc.) - qd le header est 127, on ne connaît plus son codage et elle apparaît en blanc sous xv, gimp, etc. !!! pour les codages "non signés entiers", le champ max doit valoir max< int_u<n> >::ret
Juste la sauvegarde des images sur 32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus
les images en 32 bits ne resou rien bien au contraire c'est un format batard que les logiciels gèrent mal ou ne gèrent pas ; en revanche, c'est possible qu'on les sauvegarde en pnm de façon homogène.
sain d'obliger l'utilisateur a convertir en 16 bits lui même si il veut sauver, plutôt que d'accepter puis de refuser de temps en temps si il a une valeur trop grande.
l'option "sauver quand même en pnm sachant que seule olena pourra les relire" est très acceptable sachant qu'olena peut fournir une conversion 32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
Thierry Géraud <thierry.geraud@lrde.epita.fr> writes:
Nicolas Burrus wrote:
mandor <mandor@lrde.epita.fr> writes:
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud wrote:
le champs max de l'entête doit être la valeur max du codage et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur pourrait aussi etre presente): Non, il n'y a pas de vrai problème.
si !
prenons une image dont tous les pixels valent 127 et dont le type des données est int_u8 :
- qd le header est 255, on sait donc en re-chargeant l'image qu'elle contient des int_u8 et elle apparaît en gris moyen (avec xv, gimp, etc.)
- qd le header est 127, on ne connaît plus son codage et elle apparaît en blanc sous xv, gimp, etc. !!!
pour les codages "non signés entiers", le champ max doit valoir max< int_u<n> >::ret
On est d'accord, je disais juste qu'il n'y avait pas de vrai probleme a appliquer le patch de mandor ! :)
Juste la sauvegarde des images sur 32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus
les images en 32 bits ne resou rien bien au contraire
c'est un format batard que les logiciels gèrent mal ou ne gèrent pas ; en revanche, c'est possible qu'on les sauvegarde en pnm de façon homogène.
sain d'obliger l'utilisateur a convertir en 16 bits lui même si il veut sauver, plutôt que d'accepter puis de refuser de temps en temps si il a une valeur trop grande.
l'option "sauver quand même en pnm sachant que seule olena pourra les relire" est très acceptable sachant qu'olena peut fournir une conversion 32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
Mouais, si on veut sauver ces images la directement, autant dire clairement que c'est notre propre format d'image (qui peut etre du pgm etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images de float, de complexes, etc. Mais faire semblant d'etre du pnm classique avec une extension en .pgm, je trouve pas ca terrible.
Nicolas Burrus wrote:
[...] Thierry Géraud <thierry.geraud@lrde.epita.fr> writes:
[...] l'option "sauver quand même en pnm sachant que seule olena pourra les relire" est très acceptable sachant qu'olena peut fournir une conversion 32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
Mouais, si on veut sauver ces images la directement, autant dire clairement que c'est notre propre format d'image (qui peut etre du pgm etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images de float, de complexes, etc. Mais faire semblant d'etre du pnm classique avec une extension en .pgm, je trouve pas ca terrible.
on est d'accord ; pnm = { pbm, pgm, ppm } tels que définis partout. je n'ai pas dit qu'on voulait les écrire en "pgm" (avec le 'g') ! mais si, sur le modèle des formats existants, on crée par exemple des pfm pour les images en flottants, des pcm pour les complexes, etc. on se retrouve avec un format "p*m". Sachant que le 'n' de "pnm" veut dire "any", j'ai confondu "pnm" et "pnm étendu". rmq : il faut qu'on s'intéresse à "pam" ; la solution est peut-être par là : http://netpbm.sourceforge.net/doc/pam.html
Thierry Géraud <thierry.geraud@lrde.epita.fr> writes:
Nicolas Burrus wrote:
[...] Thierry Géraud <thierry.geraud@lrde.epita.fr> writes:
[...] l'option "sauver quand même en pnm sachant que seule olena pourra les relire" est très acceptable sachant qu'olena peut fournir une conversion 32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec. Mouais, si on veut sauver ces images la directement, autant dire clairement que c'est notre propre format d'image (qui peut etre du pgm etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images de float, de complexes, etc. Mais faire semblant d'etre du pnm classique avec une extension en .pgm, je trouve pas ca terrible.
on est d'accord ; pnm = { pbm, pgm, ppm } tels que définis partout.
je n'ai pas dit qu'on voulait les écrire en "pgm" (avec le 'g') !
mais si, sur le modèle des formats existants, on crée par exemple des pfm pour les images en flottants, des pcm pour les complexes, etc. on se retrouve avec un format "p*m". Sachant que le 'n' de "pnm" veut dire "any", j'ai confondu "pnm" et "pnm étendu".
rmq : il faut qu'on s'intéresse à "pam" ; la solution est peut-être par là : http://netpbm.sourceforge.net/doc/pam.html
J'ai mis ca dans http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/OlenaSuggestions vu qu'il n'est pas prévu d'ajouter de fonctionnalités importantes pour l'instant.
participants (4)
-
mandor -
Nicolas Burrus -
Nicolas Burrus -
Thierry Géraud