Notices by Tulip ?️‍⚧️ (domi@donotsta.re)

do you ever just decide to hexdump a file and reverse-engineer your way through how it’s encoded without looking at any docs?

no? just me? alright

so far i’m most flabbergasted that BMPs load from the bottom up. like, i knew that, but it still caught me off guard

the hell is a cbSize. i know hungarian convention at an “intermediate” level (read: I try to understand the name instead of getting angry at the naming scheme) but I can’t remember what cb stood for

so, I have:

• magic
• cbSize (ignored by the decoder in feh)
• a mysterious empty u32
• two mysterious non-empty u32’s
• width
• height
• palette?
• image itself

the palette is interesting because it looks like half of it is just null data:

it divides nicely into 24 u32 values, but I don’t think this is just a palette; the image is supposed to be 4bpp, which gives us 0b1111 (15)… 16 possible values.

so the leading 8 u32’s are probably something else (which would also explain why they’re all zeroes.

the first 0x01000400 actually defines the bit depth! nice

i wonder what the first 2 bytes from it are for

after swapping a few values in the presumed palette, my redbrick.bmp became more of a grnbrick.bmp

interesting observation: the original was 32x32, I changed that to 28x35, expecting it to skew. but it didn’t! it just cut off one of the edges

this means that there has to be an end marker on each pixel line

so i didn’t find an end marker but I managed to skew my picture by replacing some nullbytes with 0xff. hmm.

the cool part about 4bpp is that one pixel directly correlates to one character in a hexdump. this makes math much easier

anyways I decided to split it into lines for easier reading. you can see the brick if you squint real hard

okay, there are no restart markers, i can make it skew if I touch only one coordinate

now, for a curiosity: if the image declares to be longer than it actually is, most decoders will show it like the pic on the left. but feh for whatever reason just reads along, probably dumping some of its memory? :neocat_0_0:

i like the pretty lines on the top, but they’re not my creation - and they differ on every startup of feh!

lmfao why is the image width/height in this format a signed value. what is the purpose of a BMP that’s -1 pixel

okay so I experimentally determined that the max size that feh wants to see in any direction is 32767 (0xff7f0000). but it doesn’t have checks for negative values, so I can ask it to display a 32768 x -1 file, with interesting results

oh, better! it does check the value properly, but only the width. height can be negative.

and oh my gosh @mothcompute was right. if I set the values to 0x20000000, 0xe0ffffff (32 x -32) then we get a flipped image, where the top of the file ACTUALLY is the top of the file!!

… at least in GIMP and firefox. feh just ignores it

more feh weirdness: the arbitrary data leak only really happens with an image that’s 32x32. i can’t trigger it with anything else

back to the encoder itself, I added some automata to convert the image size and count the cbSize (roughly).

I also looked into what the extra fields right after this one do; unsurprisingly, most of them are special attributes, and at least one seems to be unused. Setting all of them to 0xffffffff results in this hilarious outcome:

I especially like the “4294967295 important colors”, reads like a line from the BORN TO DIE template

wrr, i hate self-referencing formats. wdym i need to know the data offset when writing the header out, i don’t yet know how long the header will end up being! /j

@kaia @grillchen solder with the best

die like the rest

@linusgroh a bit less here, but the difference is probably the counting algo and me forgetting to have my 3ds on me all the time

still cool! :D

@puniko @asahi_xp literally translated it would be to yellow a geese consciousness