How do I read a "skewed" image?

[shakotay2]

EDIT: found some skewed ones! lol
59 and 63 are skewed.

Yep, skew=3 (Format 888 in TextureFinder)

I added a BMP header where color depth at 0x1C is set to 24 (18h).

A more exakt value would be shear(0.67,0).

[Sir Kane]

Getting closer, just gotta figure out if RLE images contain alpha data.
http://sktest.aruarose.com/TgaImages.7z


Converter (exe+source):
http://sktest.aruarose.com/imageconvert.7z

You got the skewing in that viewer of yours, because the RGB data width is aligned to 2 and alpha data is aligned to 4.

[finale00]

What do you mean by data width is aligned to n?

I'm interpreting that as byte alignment, but not sure how it affects the image.
At first I thought it was shifting pixels over, but if it's byte-alignment that probably isn't the case.

So say I have a 3x3 image at 24bpp.
Each pixel is 3 bytes, and so the first row is stored 9 bytes

r1 g1 b1 r2 g2 b2 r3 g3 b3

Since it's aligned to 2 bytes, does it actually do something like

r1 g1 b1 r2 g2 b2 0 0 0
r3 g3 b3

or maybe

r1 g1 b1 r2 g2 b2 0 0 0
0 0 0 r3 g3 b3

(btw I don't have VS2011 so I can't try the exe. I have 2010 though)

[Sir Kane]

Say your image is 11 pixels wide, the RGB data for each line actually contains 12 pixels then.

The alpha data has an align of 4, so you need to (width+3)/4*4 for the actual amount of data per line.

Best look at how I do it in FormatDecode_SplitRGB_A in the source.

Get http://www.microsoft.com/en-us/download ... x?id=30679 and it should run.

[finale00]

Thanks, I understand how it works now. I also see why it looks like pixels from the "end" of the first row are spilling over the second row. If I simply loop over the image height and width, it doesn't really reflect how the data is stored in a single array of bytes..

[Polefish]

Thanks, I understand how it works now. I also see why it looks like pixels from the "end" of the first row are spilling over the second row. If I simply loop over the image height and width, it doesn't really reflect how the data is stored in a single array of bytes..

Looks like I'm the only one who don't understood

11 pixels wide are 12 pixels now.Where does the other pixel come from? When you write (width+3)/4*4 for an align of 4 what do the 3 and 4*4 means?

[Sir Kane]

When the image is an odd number of pixels wide (1, 3, 5, etc.), the image data is padded to an even number of pixels per row (so you get 2, 4, 6, etc. pixels of data per row).

And say you have width 2, (2+3)/4*4 -> 5/4*4 -> 1*4 = 4. For width 4 you get (4+3)/4*4 = 4. For 5 you get (5+3)/4*4 = 2. Simple math to align numbers.

[finale00]

This is how I understand it.

There is potentially one extra pixel per row (usually black I believe), and if I don't read the data using the correct stride, my pointer will be placed before the actual row begins and start reading pixels from the previous row.

My initial assumption was that a 3x3 image would be stored in such a way that producing a bitmap would lead to

1 2 3 4
5 6 7 8
9 P P P

(for padding P)

But that doesn't make sense since it's no different from a regular RGB except with extra padding at the end, which isn't the case.

So then I thought of it like

1 2 3 P
4 5 6 P
7 8 9 P

And it was clearer.
If I took the naive approach of looping it over as a contiguous array of pixels with stride = width * bpp

Code: Select all

for x = 0 to height
  for y = 0 to width

Then the data I read would be

Code: Select all

1 2 3
P 4 5
6 P 7
8 9 P

And so this is where the skewing comes in: you'll see a nice diagonal black line worth of padding, and the rows seem to be shifted over and spill over to the next row.