8-bit BITD issues

[MrBrax]

So the converter doesn't work properly for the files i have, it skips a third of the height, and the length of the files does not correspond to (width*height) so there has to be some kind of compression (RLE?).

I've almost completed a python script that can extract text, WAV & AIFF, and BITD is the one i'm stuck on, been working on this thing almost every wake hour for a couple of weeks now, and just found this project. Really interesting stuff!

Since the converter only has 24 & 32 depth selectable, I'm assuming the format hasn't been deciphered yet?

oh and also, exported bmp's from director all have the same palette (in-game images always have palette set to -1) so i'm thinking the bytes aren't corresponding to colors but palette positions?

[MrBrax]

I almost have a working 8-bit extractor now, just gotta fix it leaving out some pixels at the end

[tomysshadow]

I haven't had a chance to look at a lower bitdepth BITD yet, that's all. However from what Brian tells me the lower bitdepth BITDs use colour palettes in the form of Photoshop's CLUT format, which are in different chunks. Multiple can exist in one file, and I'm not sure yet how those BITDs are linked with their CLUT. Either way, I'll add it in at some point - the BITD Reader is still quite new.

[MrBrax]

It's quite an interesting format. It uses linear & rle encoding in the same way, but with palette entries instead of rgb yeah.

My script can put out proper bitmaps of most bitd files, but some get distorted like so:

Setting the X coordinate to (length - j) in the loop fixes it:

But breaks all the other files. Must be a value somewhere defining this.

[tomysshadow]

That distorted image looks to me like the width is just one pixel off. I'm going to have to try implementing 16-bit images, to see if I get similar problems. It may be something implicit. Perhaps the rightmost pixel is getting cut off because it's all the same colour. If you hadn't already noticed, alpha values are sometimes reversed if alpha isn't used in a 32-bit image.

I am aware of how the format works. I figured it out in a hex editor in order to write SeismoGRAPH.

[MrBrax]

Figured it out with a tip from a friend. If the width is even, go to x -1 instead of 0 on the line change!

Works great, using the palette from a BMP extracted with Director. Transparency is gonna be a pain though, since it's on the sprite itself and not the bitmap.

[tomysshadow]

So you're suggesting the width is always even and if it isn't an extra column of pixels is added? I'll have to add that in. I wonder what your code looks like in comparison to mine, it's probably more advanced considering it is actually inspecting the entire file. We're currently in the process of switching over to using Haxe instead, since with JavaScript which we've been using thus far we won't be able to load Xtras. That's why SeismoGRAPH is disconnected from everything else.

If the image is 32-bit then alpha transparency is just another channel before the red, green and blue. If it's using JPEG compression, which is completely different of course, it's in a separate ALFA chunk.

[MrBrax]

It's difficult to explain. I uploaded my script here: https://gist.github.com/MrBrax/1f3ae06c9320863f1d7b79b988c03e60

[Brian151]

palettes are generally linked by their cast member ID. However, there's an issue I've had with specifying a palette from another cast. (fun fact: this seems to crash Director when attempting to edit said bitmap) The linkage is done in the bitmap 'specificData' block of a bitmap member. the CLUT chunks should be linked to their respective palette cast members like everything else? The linking of CASt header chunks (i won't call them meta-data because the INTENDED meaning of this is "extra data not needed by program", CASt are quite important, and specify the type of information typically found in a header) to the actual data chunks is something I need to start working on again...

As for the bitmap data itself, my efforts can confirm that at least the 8 bit BITD CAN be uncompressed. I have yet to explain how it differentiates between the two, or what would cause it to use either. One of my sample files (I imported MineCraft textures) compressed the 8-bit bitd. I later tried to create an 8-bit bitmap from something that actually would benefit from compression. No such luck. Director outright REFUSED to compress the bitmap. I tried many times and got raw indexed 8BPP data in my BITD. On my compressed sample, I tried finding any indicator how that worked, and no particular luck. And then my desktop started acting up. I suspect hardware failure is really the cause, at this point. Anyways, I'm back on my parent's computer. No Director (or a lot of my latest progress/samples), but Git works, at least.

All I'll say about BITD's is I HATE them... I just can't come to understand them, and I'm glad you two can. embedded resources are easy, W3D will be a challenge to parse/display, and the CLUT things, well... only thing I don't understand is the second value. But, I feel confident I can ignore it for the time being.

[MrBrax]

It's the worst! I've been trying to extract all the CXT/DXR resources from a game and it's coming along pretty good, except now some images come up corrupted (png are converted, ignore):

And just as i'm writing this, i'm noticing that this: https://github.com/Brian151/OpenShockwave/blob/master/docu/FormatNotes.txt#L235 could infact indicate if the image has alpha somehow, i dunno really.

There's also the "Sprite" object thing, is that bound to the CAST, or is it a separate object somewhere? Would maybe explain the "Ink" feature and more.
scratch that, they use the "score" list thing

[Brian151]

alright

This observation is among the progress I have lost. Sadly, I once again can't actually check that kind of stuff out in Director, so...

[MrBrax]

Can't you install the Director trial? But i guess if it's not your PC then it's not very appropriate.

I think there's something wrong with the Director UI or dirOpener's conversion of the files, because except for a few bitmaps, it says it's 8-bit and no alpha, but because i can't convert those files like i can with all the other ones, there has to be something different.

[MrBrax]

My god, it was this line all along, that i used: https://github.com/Brian151/OpenShockwave/blob/master/tools/BitdReader/js/BitdReader.js#L72

I changed it to 0x100 and now it works.

[tomysshadow]

It shouldn't? I specifically had to use 0x101. Does it work in all cases?

[MrBrax]

Yes, but it might be for 8-bit only. 1-bit bitmaps are still corrupted (which i haven't gotten to yet).

[Brian151]

It's a matter of disk space and CPU/RAM that I won't... Pretty sure this computer couldn't handle it. As is, my computer kinda struggled running it.