Morph-M

Tue, 12 Jun 2007 21:40:05 +0200 (CEST) (Tibs)
----------------------------------------------------------
Tout d'abord je crois bien qu'ImCopy est hors de cause (je viens de
commiter une série de tests unitaires qui chez moi en tout cas passent
tous).

Avec ça je suis pê en train de cerner le pb, aussi étonnant que ca puisse
paraittre c'est sans doute les fonction lecture/ecriture qui sont en
cause.

En fait la lecture/ecriture a l'air assez clean (une image créée dans
morphee et enregistrée est bien lisble par les autres lecteurs et quand on
la relit avec morphee tout se passe bien)

Alors un peu au pif je dirait que c'est un pb interlaced/non-interlaced et
pê que sur l'image qui a déclenché le bug, la methode utilisée n'est pas
supportée par morphee et la libpng sous jacentes (??) --> bref je vais
avoir une petite discution avec mon collègue de bureau qui utilise des
logiciels bizarres je crois ;)

#5 comment 13/06/2007 09:23 (Tibs)
---------------------------------------------------------------------------
Comment:
Voici les extraites de mails de Romain qui nous fait gentiment
profiter de ses
lumières:
Extrait 1 --> test avec une image problèmatique:
Alors, l'image que je vois sous XV (directement 16 bits) est en réalité
ce que Morphée voit dans le fichier modulo 256.
Typiquement pour y=0 les trois premiers pixels sont 45, 45, 46 , soit
31533%256, 31277%256 et 36910%256 (ou utiliser la fonction "hex").
Donc on affiche uniquement les bits de poids faible. Je ne sais pas si
c'est normal, et ça mérite réflexion.
Si ça se trouve il y a une spec PNG qu'on a ratée (faut dire qu'on
l'aurait pas bcp cherchée) qui dit qu'il faut swapper les octets...
Extrait2 --> solutions ?

http://www.libpng.org/pub/png/spec/1.2/PNG-DataRep.html#DR.Integers-and-byte-
order
http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3.7
"
PNG files store 16 bit pixels in network byte order (big-endian, ie.
most significant bits first). This code changes the storage to the
other
way (little-endian, i.e. least significant bits first, the way PCs
store
them):
if (bit_depth == 16)
png_set_swap(png_ptr);
"
Thibauld: Bref je vais regarder ca d'un peu plus près tut de suite
et voir si la
modif est aussi triviale qu'elle en a l'air

#6 13/06/2007 11:26 (Tibs)
---------------------------------------------------------------------------
Change: status: "accepted" -> "resolved"
Comment:
Modifications commitées : on swap les octets pour chaque pixel des
images PNG en
UINT16, en accordance avec les specs donc...
Les tests unitaires passent, la lecture/ecriture avec l'image
problématique
semblent marcher (morphee arrive a la lire/ecrire/relire
correctement et les
visualiseurs externes de ma machine semlent d'accord).
D'auter part j'ai ajouté une image (foreman_u16.png) dans
addons/Images/Gray qui
devrait permettre de faire des tests si le pb se représente.

Wed, 13 Jun 2007 19:31:27 +0200 T Retornaz
----------------------------------------------------
Kof Kof

Pour info
J'ai des images de tests dans users/retornaz/operationresiduel/test/Images
qui sont en png 16 bits et qui me permettent/permettaient de faire des
tests unitaires

Si tout ce passe normalement, ce module devrait planter dès demain

Wed, 13 Jun 2007 19:47:43 +0200 (CEST) (Tibs)
----------------------------------------------------
Pour Thomas et toute personne qui aurait créé et enregistré des png 16
bits avec Morphée et son ancienne version du pngFileWrite, voila ce que
vous pouvez faire pour convertir vos png 16 bit buggé en "bon" png 16
bits:

Si tu l'as pas déjà fait tu eux les convertir avec morphee en modifiant
un tout petit peu le fichier imageIOExt_PNG.cpp:

Tu remplace "morphee::imageIO::isLittleEndian()" pas "false" partout
dans le pngFileRead.

Tu laisse intact les isLittleEndian du pngfileWrite.

De cette facon (après compilation bien sur) tu pourras lire tes anciens
fichier correctement avec morphee et lorsque tu les réécrira en png, le
swap se fera. Après n'oublie pas de revenir à la version de reference du
fichier ;) .

Thibauld