Comment utiliser le PNG IDAT morceau?

J'essaie de comprendre comment les données sont stockées dans IDAT morceau. Je suis en train d'écrire une petite classe PHP et je peux récupérer la plupart des morceaux de l'information, mais ce que je reçois pour IDAT ne correspond pas à les pixels de mon image :

Comment utiliser le PNG IDAT morceau? Il est de 2×2px truecolor avec alpha (bitdepth 8).

Mais quand je interpréter IDAT de données comme ceci:

current(unpack('H*',gzuncompress($idat_data)));

- Je obtenir

00000000ffffff00ffffff000000

Je ne comprends pas comment il peut correspondre pixels. Ou est-ce mon code qui corrompt les données?

Merci pour votre aide!

EDIT: je obtenir

08d705c101010000008010ff4f1750a93029e405fb

que hex données compressées, donc il semble que je la perte de plusieurs octets après la décompression.

Comment utiliser le PNG IDAT morceau?

OriginalL'auteur MatTheCat | 2011-09-03

  1. 8

    Utilisation gzinflate mais passer les 2 premiers octets et le dernier 4 premiers.

    $contents = file_get_contents($in_filename);
$pos = 8; //skip header
$color_types = array('Greyscale','unknown','Truecolour','Indexed-color','Greyscale with alpha','unknown','Truecolor with alpha');
$len = strlen($contents);
$safety = 1000;
do {
list($unused,$chunk_len) = unpack('N', substr($contents,$pos,4));
$chunk_type = substr($contents,$pos+4,4);
$chunk_data = substr($contents,$pos+8,$chunk_len);
list($unused,$chunk_crc) = unpack('N', substr($contents,$pos+8+$chunk_len,4));
echo "chunk length:$chunk_len(dec) 0x" . sprintf('%08x',$chunk_len) . "h<br>\n";
echo "chunk crc   :0x" . sprintf('%08x',$chunk_crc) . "h<br>\n";
echo "chunk type  :$chunk_type<br>\n";
echo "chunk data  $chunk_type bytes:<br>\n"  . chunk_split(bin2hex($chunk_data)) . "<br>\n";
switch($chunk_type) {
case 'IHDR':
list($unused,$width,$height) = unpack('N2', substr($chunk_data,0,8));
list($unused,$depth,$Color_type,$Compression_method,$Filter_method,$Interlace_method) = unpack('C*', substr($chunk_data,8));
echo "Width:$width,Height:$height,depth:$depth,Color_type:$Color_type(" . $color_types[$Color_type] . "),Compression_method:$Compression_method,Filter_method:$Filter_method,Interlace_method:$Interlace_method<br>\n";
$bytes_per_pixel = $depth / 8;
break;
case 'PLTE':
$palette = array();
for($i=0;$i<$chunk_len;$i+=3) {
$tupl = bin2hex(substr($chunk_data,$i,3));
$palette[] = $tupl;
if($i && ($i % 30 == 0)) {
echo "<br>\n";
}
echo '<span style="color:' . $tupl . ';">[' . $tupl . ']</span>';
}
echo print_r($palette,true) . "<br>";
break;
case 'IDAT':
$compressed = substr($chunk_data,2,$chunk_len - 6); //2 bytes on the front and 4 at the end
$decompressed = gzinflate($compressed);
echo "decompressed chunk data " . strlen($decompressed) . " bytes:<br>\n"  . chunk_split(bin2hex($decompressed),2 + $width * $bytes_per_pixel * 2) . "<br>\n";
for($row=0; $row<$height; $row++) {
for($col=1; $col<=$width; $col++) {
$index = (int)substr($decompressed,((int)$row*($width+1)+$col),1);
echo '<span style="color:' . $palette[$index] . ';">' . $index . '</span>';
}
echo "<br>\n";
}
//TODO use filters described here:
//http://www.w3.org/TR/PNG/#9Filters
//first byte of scan line is filter type
break;
}
$pos += $chunk_len + 12;
echo "<hr>";
} while(($pos < $len) && --$safety);
    merci, gonfler fonctionne maintenant, mais j'obtiens un "00000000ffffff00ffffff000000" (14 octets), comment sont-ils utilisés pour obtenir des pixels?
    Afin d'obtenir une bonne compression, le format PNG applique des filtres avant la compression. Les filtres de faire des choses comme: si deux lignes de balayage de l'un sur l'autre sont presque les mêmes, les pixels sur la ligne inférieure qui correspondent le pixel ci-dessus, se changé de zéros. Ainsi, lorsque vous avez terminé, vous avez une merde tonnes de zéros et de la compression est vraiment bon. Si vous avez besoin pour inverser cette tendance et de annuler les filtres après la décompression. voir w3.org/TR/PNG/#9Filters
    Droit, et le filtre "transforme la séquence d'octets dans un scanline pour une même longueur de la séquence d'octets précédée par un filtre de type byte". Donc, je ne devrais pas avoir de 18 octets de données non compressées (1 "bytedepth" * 4 canaux * 4 pixels + 2 filtres)?
    Me semble bon. Peut-être qu'il n'est vraiment pas un canal alpha??? Si le premier octet a une autre signification et il n'y a pas un alpha alors que vous auriez 00(le mystère de l'octet) 000000(rvb) ffffff(rvb) + un autre mystère de l'octet + ffffff et 000000. Alors peut-être que chaque ligne de balayage des octets pour décrire le filtre schéma de la ligne. Désolé, ça fait trop longtemps que je n'ai aucune connaissance sur ce sujet.
    Ça y est! Mon erreur a été de penser Gimp enregistré mon image avec un canal alpha. Mais l'image est de type 2 pour "Truecolor", c'est donc seulement 3 canaux (R,V,B). Mystère octets sont le type de filtre utilisé pour chaque scanline (aucune dans ce cas). Merci!

    OriginalL'auteur Charlie

  2. 4
    00000000 ffffff00 ffffff00 0000xxxx
black    white    white    black

    C'est ce que je peux dire (qui est correcte) ... mais il vous manque 2 octets à la fin.

    Je pensais qu'il y avait un filtre de type octet de chaque ligne de numérisation? Pourrait manquant octets viennent de mauvais algorithme de décompression?
    Je ne suis pas de lire sur PNG à tous vraiment, mais les données présentes semblent correspondre à ce que vous devriez obtenir, sauf que ce n'est pas tout ... donc, personnellement, je ne peux pas vous aider avec pourquoi ce qui se passe: w3.org/TR/PNG/#11IDAT @leonbloy peut-être raison sur plusieurs IDAT blocs, mais je trouve étrange qu'un bloc de si petits détails... êtes-vous sûr de décompression de tous les octets?
    Merci mais w3.org/TR/PNG/#4Concepts.EncodingFiltering il semble que les types de filtres doivent être présents dans les données, de sorte que plus d'octets serait absente?? (Je sais il n'y a qu'un IDAT morceau dans mon cas ^^)
    Méthode de filtre est la partie de la IHDR bloc, pas la IDAT bloc, il semble... mais je ne suis pas en mesure de décoder la description de la façon dont les filtres fonctionnent réellement bien. w3.org/TR/PNG/#11IHDR
    Le premier byte de chaque ligne est 00 ici (le PNG filtre de ligne). Après cela, vous obtenez deux triplets RVB: 00 00 00 et ff ff ff pour la première ligne, ff ff ff et 00 00 00 pour le 2ème.

    OriginalL'auteur Andreas

  3. 3

    À ajouter à @Andreas (+1) de l'analyse, deux choses sont à noter:

    1. Un fichier PNG peut avoir (et souvent) beaucoup de IDAT morceaux, ils doivent être concaténés pour récupérer la compression zlib flux. http://www.w3.org/TR/PNG/#10CompressionFSL

    2. Gzip/Compresser/Dégonflage sont tous liés, mais ne sont pas exactement les mêmes. Le format PNG utilise dégonfler/gonfler. Je vais essayer avec gzdeflate/gzinflate

    J'ai essayé, mais j'obtiens une erreur de données lors de l'utilisation de gzinflate =/ (mon image n'a qu'un seul IDAT morceau)
    J'ai mis en place PNG en lecture/écriture à l'aide de Java Deflater/Infalter classes et cela a fonctionné parfaitement. Peut-être que vous essayez de décapage, les deux premiers octets? gzinflate(substr($idat_data, 2) ? php.net/manual/en/function.gzinflate.php#70875
    Je viens de remarquer que la longueur de la partie de IDAT morceau est plus petite que la longueur de ses données, je pense que c'est d'où vient le problème mais je ne peux pas deviner pourquoi
    longueur de la partie de IDAT? Je n'arrive pas à trouver quoi que ce soit sur qui?
    ici: w3.org/TR/PNG/#5Chunk-layout

    OriginalL'auteur leonbloy