I'm in the middle of making a program to convert a .8ci file to a .png and vice versa. I found this: https://gist.github.com/MCJack123/fdf2594065f1e65bb4828aa107862434, and for the most part, I copied some constants.

One specific constant was the 74 from line 61:

Code:

I was just wondering if since if might not always be 74 bytes, is there a way to tell what size the header is? I'm guessing somewhere in those bytes there would be the size of the header; I'm just not sure where/if that exists.

After the header is the pixel data. From my understanding, the Pic vars are 265x165, and there are two pixels per byte, so each pixel is on a 4-bit boundary. This leaves an extra 4 bits at the end of each row because the width is an odd number; I've checked every row and there does indeed seem to be a padding of 4 bits.

After all the pixels, there's an extra two bytes that I can't quite figure out. They're different if I have the same image in two Pic vars. They're also different if I swap the Pic vars by using a sequence of StorePic and RecallPic, and then swap back. My questions for these two bytes are as follows:
1) What do they represent?
2) If they were removed from the file and sent back to the calculator, would TI Connect refuse the file because it doesn't find what it expects?
3) Could I just replace them with 0x0000 and have everything still work?

The "header" or packaging up to "meaningful" image data in 8ci and 8ca files is always 74 bytes.

As for the ending word [two bytes] on each row, no one knows. To my knowledge its value has no effect on anything. Something is required to be there, that's just how packages and pre-defined lengths work.

So…
1) No one knows.
2) Haha, yes. It would not accept the file, even assuming you set the size fields correctly.
3) Yes.

Follow up question, I've noticed that the 62nd byte is the number that the Pic var is except one less, meaning Pic1 is 0, Pic2 is 1, and Pic0 is 9. Aside from that difference, the packaging stays the exact same across all Pic vars, even with different images.

Opening a Pic var in notepad++ shows more. Most of the packaging is either information such as which program made the file or just a bunch of zeros. I'm curious as to what the other non-zero bytes in between mean, if anything, and are they useful?

Might I point you in the direction of the linkguide: http://merthsoft.com/linkguide/ti83+/fformat.html
Is this is for monochromes? Yes.
Is the file format consistent? Yes.
Are the variable formats consistent? Most of them.
Is the comment zero-terminated? No.

Have fun and feel free to ask any other questions you might have.

From my testing, TI Connect does in fact reject the file even if only the last word was changed to 0x0000. I also took a look at the linkguide you provided and it seems to me that the last word is, in fact, relevant. Although it is not 100% certain, I believe that I can follow the pattern from the other file types; that pattern being that the last word is a the lower 16 bits of a checksum of some portion of the file. Changing the checksum would obviously invalidate the file to anything that tried to read it because the data it got did not match the expected value. This explains why TI Connect refused to transfer the file.

Every file format is the same on color calculators, except that pictures are larger. The others are still the same.