Converting raw Amiga bitplane image data into an image

[Argh]

Hi, I’m currently coding a Python tool to spot structured data in binary files and ideally to rip graphics data from old Amiga files. This is mainly to satisfy my own curiosity and to learn, I have no background in graphics programming, and my knowledge about the Amiga’s hardware is pretty rudimentary.

So, I managed to rip 5 bit arrays from a file (screenshot attached) which look like different layers of a final image -- I suppose these represent the 5 bitplane data for the Amiga’s 32 color mode?

My question is: how to combine these bitplanes into a regular RGB image? And would I get only indexes referring to a palette table (which I also would have to get somehow) or are these the colors itself?

I’m out of my depth here, so I’d be happy if someone could point me into the right direction

[paraj]

Going the other way round. Say you have an indexed-colored row of 32 pixels (i.e. one where each value represents a color value) from 0 to 31: [0, 1, ... 31] or in binary 0b00000, 0b00001, 0b11111. When represented as bitplanes the data is transposed:

01010101010101010101010101010101 bitplane 0
00110011001100110011001100110011 bitplane 1
00001111000011110000111100001111 bitplane 2
00000000111111110000000011111111 bitplane 3
00000000000000001111111111111111 bitplane 4

To get the palette index of the first pixel you read down the left most column (and read 0b00000), to get the right most similarly to get (0b11111).
As an aside, the first representation (where bits that belong together are read together) is often called "chunky", and the bitplane representation is called "planar".

To go from one to the other representation, you transpose the bits. In practical terms take the most significant bit of each bitplane and combine them to form a single palette entry for the first pixel, the next most significant bits for the second entry and so forth. When you run out of bits in a byte you move to the next byte.

So something like (not tested, and not optimal):

for x in range(image_width):
    bit0 = (bitplane0[x//8] >> (7 - (x&7) % 8)) & 1 # extract bit from bitplane
    # Same for the other planes
    palette_entry = bit4 << 4 | .. | bit0

One extra thing to keep in mind is that there are (at least) two competing ways of storing images in planar format: interleaved and non-interleaved. Your example shows the non-interleaved format. The alternative (interleaved) stores each row of the image togther (so you have row 0 bitplane 0, row 0 bitplane 1, ..., row 1 bitplane 0, ... rather than row 0 bitplane, row 1 bitplane 0, ... row 0 bitplane 1 like in your example).

[Argh]

Many thanks for taking the time, paraj! I think I have a better grasp of what to do now. 2 questions remain for me, though:

1. When you run out of bits in a byte you move to the next byte.

   Does this mean that, when writing the final data, I would directly concatenate the 5-bit blocks instead of complete bytes ("padded" with zeroes to form a complete byte)?
   
2. If I understand correctly, the result will be a list of palette indexes per pixel. Was there some kind of typical way Amiga software stores the actual palettes, as separate files or as part of the actual program code?

[paraj]

1. Hmm, no, maybe I don't understand your question or my explanation was not clear. Each bitplane is a long sequence of bits, and that was just trying to describe how to get them from bytes in the source data. The Hardware Reference Manual (HRM) http://amigadev.elowar.com/read/ADCD.../node0063.html has a perhaps better explanation.
For each pixel in the output image you take one bit from each bitplane. How you output the final data is up to you. You could store each pixel as a byte (with 3 bits left clear) or you could do the palette lookup before storing and output a RGB triplet.

2. There is no standard way. Sometimes you have one palette per image (e.g. for a splash screen), but often you will find that many images share a common palette (e.g. tiles in a platform game). The palette can also be changed dynamically (using the copper) so you might encounter images where the palette isn't fixed. That's not even discussing various screen modes (HAM, dual play field etc.), but that's not worth considering at the start If you're heuristically searching for palettes it'll often be 8/16/32 words in a row with the most significant nibble set to zero (since OCS/ECS only supports 4 bits per channel).

[jotd]

get my python module "bitplanelib.py" at https://github.com/jotd666/amiga68ktools.git

It is able to convert amiga bitplanes to PNG and the other way round. I'm using it for all my arcade conversions.

Try to dump a simple PNG to amiga bitplanes, then you can analyze the output data format

[Argh]

Thanks everybody, I think I have all the pieces I need now

get my python module "bitplanelib.py" at https://github.com/jotd666/amiga68ktools.git

Thanks, bitplanes_raw2image() did the trick!

If you're heuristically searching for palettes it'll often be 8/16/32 words in a row with the most significant nibble set to zero (since OCS/ECS only supports 4 bits per channel).

Thanks for the hint, I tweaked my Python tool a little following this tip and I think I spotted what looks like palette data in the game’s binary