Tga image is green

robin1201 · **Joined:** Sun Aug 22, 2021 3:11 pm **Posts:** 14

Hi, I have written a uefi application that loads a tga image, which works as far as it goes, but the image I want to load has a green stitch in it. I have already tried a few things but the result is always the same.

Image: https://imgur.com/a/CJDFN4G

Github: https://github.com/rxbin1201/Bootloader

I hope anyone can help me.

sounds · **Joined:** Sat Feb 04, 2012 5:03 pm **Posts:** 81

At a quick glance, it appears the green value of every pixel is being set to the maximum.

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 4583

You're probably shuffling bytes around in the wrong order.

I'm pretty sure the bytes are already in the correct order inside the TGA file. Call Blt() with your file buffer + 0x12 (to skip the TGA header) and see what you get.

robin1201 · **Joined:** Sun Aug 22, 2021 3:11 pm **Posts:** 14

Octocontrabass wrote:

You're probably shuffling bytes around in the wrong order.

I'm pretty sure the bytes are already in the correct order inside the TGA file. Call Blt() with your file buffer + 0x12 (to skip the TGA header) and see what you get.

Unfortunately, the result is exactly the same.

reapersms · **Joined:** Fri Oct 04, 2019 10:10 am **Posts:** 47

First 32 bytes of the TGA

Code:

000000 00 00 02 00 00 00 00 00 00 00 00 00 56 05 00 03
000010 20 08 11 0f 15 ff 13 12 18 ff 13 13 19 ff 14 15

0 image ID len
0 color map type (none)
2 image type (uncompressed RGB)
no color map
0 x origin
0 y origin
0x556 width
0x300 height
0x20 bpp (32 bit)
0x08 descriptor (8 bit attribute, origin in lower left, non-interleaved)
pixel data for the lower left is (11 0F 15 FF), in BGRA order

Somehow your parse is stuffing the alpha value into your green channel.

You really should look into using structs, rather than that sea of magic numbers. I think your bug is the + 18 in line 35 of tga.c, which seems to be trying to skip past the header, but m already includes that. Thus your parse code is starting 4.5 pixels into the array, which being BGRA, means your packing code is seeing RABG, albeit from two different pixels each time.

robin1201 · **Joined:** Sun Aug 22, 2021 3:11 pm **Posts:** 14

reapersms wrote:

First 32 bytes of the TGA

Code:

000000 00 00 02 00 00 00 00 00 00 00 00 00 56 05 00 03
000010 20 08 11 0f 15 ff 13 12 18 ff 13 13 19 ff 14 15

0 image ID len
0 color map type (none)
2 image type (uncompressed RGB)
no color map
0 x origin
0 y origin
0x556 width
0x300 height
0x20 bpp (32 bit)
0x08 descriptor (8 bit attribute, origin in lower left, non-interleaved)
pixel data for the lower left is (11 0F 15 FF), in BGRA order

Somehow your parse is stuffing the alpha value into your green channel.

You really should look into using structs, rather than that sea of magic numbers. I think your bug is the + 18 in line 35 of tga.c, which seems to be trying to skip past the header, but m already includes that. Thus your parse code is starting 4.5 pixels into the array, which being BGRA, means your packing code is seeing RABG, albeit from two different pixels each time.

Thanks for this answer do you know a solution to fix this?

reapersms · **Joined:** Fri Oct 04, 2019 10:10 am **Posts:** 47

Strike that, that bug only applies to types 1 and 9.

Oh, that code came from the wiki, and is broken as all hell. I take back everything nice I ever said about bzt.

I would suggest looking over http://www.paulbourke.net/dataformats/tga/ and writing your own, rather than continuing to use this broken pile of junk, but at the risk of encouraging the cargo cult:

Line 43:

Code:

j = ((!o?h-y-1:y)*w*(ptr[16]>>3)) + m;

I strongly suspect case 1, 9, and 10 of that switch are completely broken.

robin1201 · **Joined:** Sun Aug 22, 2021 3:11 pm **Posts:** 14

reapersms wrote:

Strike that, that bug only applies to types 1 and 9.

Oh, that code came from the wiki, and is broken as all hell. I take back everything nice I ever said about bzt.

I would suggest looking over http://www.paulbourke.net/dataformats/tga/ and writing your own, rather than continuing to use this broken pile of junk, but at the risk of encouraging the cargo cult:

Line 43:

Code:

j = ((!o?h-y-1:y)*w*(ptr[16]>>3)) + m;

I strongly suspect case 1, 9, and 10 of that switch are completely broken.

I added + m at the end of the line and now it works fine. Thank you very much for your help.

robin1201 · **Joined:** Sun Aug 22, 2021 3:11 pm **Posts:** 14

robin1201 wrote:

reapersms wrote:

Strike that, that bug only applies to types 1 and 9.

Oh, that code came from the wiki, and is broken as all hell. I take back everything nice I ever said about bzt.

I would suggest looking over http://www.paulbourke.net/dataformats/tga/ and writing your own, rather than continuing to use this broken pile of junk, but at the risk of encouraging the cargo cult:

Line 43:

Code:

j = ((!o?h-y-1:y)*w*(ptr[16]>>3)) + m;

I strongly suspect case 1, 9, and 10 of that switch are completely broken.

I added + m at the end of the line and now it works fine. Thank you very much for your help.

I have to add that when I use an other tga image file the problem is with out the + m it works fine but when I use an other tga image it has the green stitch from before. My goal is it to make a menu to change the images. I also can't really fix the code for a png image either.

reapersms · **Joined:** Fri Oct 04, 2019 10:10 am **Posts:** 47

The other tga may have a different layout, image format, or a colormap. I would suggest writing new code from scratch for it rather than try to fix anything from the wiki.

Linking in a real image library is probably not feasible if you're targeting a bootloader environment, but you could also convert the image ahead of time into something easier for your bootloader to display.

OSDev.org

Tga image is green

Who is online