2017-10-10 4 views
0

J'essaye d'écrire un TGA-Loader simple et j'ai trouvé que la lecture de certaines images a produit beaucoup de zéros non désirés après un certain point. Il y a six images que je suis en train de tester: Chacune d'elles a 32x32 pixels avec des couleurs BGR. Maintenant, quatre images sont bien lues, tandis que les deux restantes sont seulement lues jusqu'au 17ème octet. A partir de là, ils se composent de valeurs nulles, ce qui ressemble à ce qui suit:Lecture TGA montre des nulls au lieu de données de couleur

0: 220 164 55
1: 232 173 57
2: 241 177 51

... 16: 252 181 41
17: 249 180 41
18: 0 0 0
19: 0 0 0

ifstream myFile(filePath); 

// Read Header 

struct tgaHeader *header = new struct tgaHeader; 

myFile.read((char *) &header->imageIDlength, 1); 
myFile.read((char *) &header->colormapType, 1); 
myFile.read((char *) &header->imageType, 1); 

myFile.read((char *) &header->colormapBegin, 2); 
myFile.read((char *) &header->colormapLength, 2); 

myFile.read((char *) &header->sizeOfEntryInPallette, 1); 

myFile.read((char *) &header->xOrigin, 2); 
myFile.read((char *) &header->yOrigin, 2); 
myFile.read((char *) &header->width, 2); 
myFile.read((char *) &header->height, 2); 

myFile.read((char *) &header->bitsPerPoint, 1); 
myFile.read((char *) &header->attributeByte, 1); 

// Test if Format is supported 

if(header->imageIDlength != 0 || 
    header->colormapType != 0 || header->colormapBegin != 0 || header->colormapLength != 0 || 
    header->imageType != 2  || header->xOrigin != 0  || header->yOrigin != 0  || 
    !(header->bitsPerPoint == 24 || header->bitsPerPoint == 32)) 
{ 
    myFile.close(); 
    throw runtime_error("image format is not supported"); 
} 

// Since only TGA-files with no Image-ID and no Colormap are supported, 
// here immediatly the image data can be read. 

uint16_t bytesPerPoint = header->bitsPerPoint/8; 
unsigned long long imSize = static_cast<long long> (header->width) * header->height * bytesPerPoint; 

vector<uint8_t> * pixels = new vector<uint8_t> (imSize); 
myFile.read((char *) pixels->data(), imSize); 

unsigned long long i; 
for(i=0; i < imSize; i+=3) { 

    uint8_t t0 = pixels->at(i+0);  // swap from BGR to RGB 
    uint8_t t1 = pixels->at(i+1); 
    uint8_t t2 = pixels->at(i+2); 

    (*pixels)[i+0] = t2; 
    (*pixels)[i+1] = t1; 
    (*pixels)[i+2] = t0; 

} 

// Further Meta-Data following the image data are ignored. 

myFile.close(); 

return pixels; 

TgaHeader est une structure définie qui contient uint8_t et les champs uint16_t. J'ai supprimé la gestion des exceptions pour plus de clarté, je n'ai jamais reconnu aucune erreur lors de la lecture des données. IrfanView et Gimp ont été capables d'ouvrir les images problématiques et dans un visionneur binaire, aucun zéro n'a été trouvé. J'ai choisi seulement des images sans image-ID et sans en-têtes de colormap et équivalents, ainsi ceci ne devrait pas être un problème non plus.
Alors pourquoi ces zéros sont-ils là?

+0

Peut-être que les images sont tout simplement noir à partir de ce moment-là. Peut-être que les fichiers sont tronqués ou cassés pour une raison quelconque. Vous ne semblez pas vérifier si l'un des 'read()' réussit réellement. – kolrabi

+0

J'ai vérifié si les 'read()' font leur travail, et tout semble bien lire. –

Répondre

0

Enfin, j'ai trouvé le problème: Pour des raisons que je ne peux pas voir la position ifstream sauté à ca. 450. De là, l'en-tête pouvait être lu même si les informations d'en-tête se trouvaient dans les 18 premiers octets. En conséquence, après avoir lu l'en-tête que je simplement définir la position ifstream au point étaient les données de couleur ont commencé:

vector<uint8_t> * imRawData = new vector<uint8_t> (imSize); 

myFile->seekg(ios_base::beg + 18); 
myFile->read((char *) imRawData->data(), imSize);