Hi everybody ^^

I'm quite a newbie in loading image file, so I've try to improve myself by loading the TGA image structure (You can found it at http://en.wikipedia.org/wiki/Truevision_TGA , I'm quite believe in the information there)

My problem is after loading and draw it onto the screen using OpenGL ES, it's seem the image lost some stuff of... color chanel... I don't know how to describe this exactly but would you like to see my work compared to esUtil's feature and give me some advices ?

As you can see... The beautiful image is the result I want (converted from TGA to png), and the "green sky" lies with the ground up is my... creation >"<...

Dani AI

Generated

Two quick points that explain what you saw: a miscomputed start offset will shift every pixel (so channels and rows look wrong), and TGA files have an 18‑byte header plus optional fields you must skip before the image data. 's binary‑mode check is a good first step, and 's fix of "adding two header bytes" strongly points to an off‑by‑offset rather than a shader bug. ()

Checklist to debug and fix (do these in order):

  • Parse the full 18‑byte header and extract the ID length, color‑map length and color‑map entry size (the entry size is in bits).
  • Compute the color‑map byte size as (colorMapLength colorMapEntrySize) / 8, then set dataOffset = 18 + idLength + colorMapByteSize. Seek to dataOffset and read widthheight*(pixelDepth/8) for uncompressed true‑color images; handle RLE if image type requires it.
  • Verify by printing the first 16–32 image bytes from the file and comparing them to expected RGB triplets.

Example pseudocode:

headerSize = 18
colorMapBytes = colorMapLength * (colorMapEntrySize / 8)
dataOffset = headerSize + idLength + colorMapBytes
fseek(file, dataOffset, SEEK_SET)
read pixel data...

Paul Bourke's TGA notes cover the header/entry sizes and byte ordering. ()

OpenGL ES notes: many TGAs store pixels as B,G,R (and B,G,R,A for 32‑bit), so you often need to swap R/B before uploading (ES2 does not support GL_BGR as an input format). Also set the unpack alignment to 1 to avoid row padding problems, and respect the image‑descriptor origin bit (flip rows when origin is top). These steps commonly resolve the green/shifted image symptoms you described. (docs.gl)

Recommended Answers

All 3 Replies

Hi everybody ^^

I'm quite a newbie in loading image file, so I've try to improve myself by loading the TGA image structure (You can found it at http://en.wikipedia.org/wiki/Truevision_TGA, I'm quite believe in the information there)

My problem is after loading and draw it onto the screen using OpenGL ES, it's seem the image lost some stuff of... color chanel... I don't know how to describe this exactly but would you like to see my work compared to esUtil's feature and give me some advices ?

As you can see... The beautiful image is the result I want (converted from TGA to png), and the "green sky" lies with the ground up is my... creation >"<...

[ATTACH]22495[/ATTACH]

[ATTACH]22496[/ATTACH]

[ATTACH]22497[/ATTACH]

[ATTACH]22498[/ATTACH]

Try reading in binary mode by adding a "b". I'm guessing that's your problem.. the other two possibilities are that you're out of alignment when reading your bytes (i.e. if you didn't get the last byte of the header). Or that XOR thing isn't working--which seems a weird thing, but I don't have time to examine it closely. Let me know.. I'll bbl.

file = fopen(tgaName, "rb");

I've get last byte of the header but it 's seem... losing color chanel in other way :))
But... Amazing thing happened when I add two last bytes of the header to the front of my raw data : it worked !
Thank you for your advice, though I still want to know why we must add these bytes to our image data... All we have to do is just get all bytes in the "data" block of the TGA, don't we ?

I've get last byte of the header but it 's seem... losing color chanel in other way :))
But... Amazing thing happened when I add two last bytes of the header to the front of my raw data : it worked !
Thank you for your advice, though I still want to know why we must add these bytes to our image data... All we have to do is just get all bytes in the "data" block of the TGA, don't we ?

I *may* see the problem.

for (int i = 17 + skipSize; i < 17 + skipSize + datasize; i ++)

In order to skip the header portion, you would ignore 0 through 17. Meaning you would start at 18. Plus your skipsize. So if I'm right, when you added the last two bytes of the header to the front of your raw data, your first pixel is garbage since that's still part of the color map--you just didn't notice it because it alligned the rest of your raw data and the rest of the picture worked.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.