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?
One specific constant was the 74 from line 61:
Code:
in.seekg(74); // this may or may not always hold true
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?