The first six bytes contain information used to restore the image--the first
word contains the width of the image, the second word contains the height, and
the third word is reserved (for what I have no idea). Actually, the values
stored for width and height are one less than the actual width and height.
The rest of the image contains the image data, but it is not quite as
straightforward as one might expect. If you want to know how much storage your
image will occupy, you have to round the width of the image up to the nearest
eight pixels. In other words, Turbo stores the rows of the image in eight
pixel chunks, with the rows following one after the other in memory. So
depending on how many bits per pixel are used, the storage requirements for
each row must be rounded up--to the nearest b bytes, where b is the number of
bits per pixel (1 for a 2-color mode, 2 for a 4-color mode, 4 for a 16-color
mode, and 8 for a 256-color mode). This had me seriously thrown off for the
longest time, but with many comparisons of image sizes in various modes, I
finally recognized the pattern. So if I'm not mistaken, ImageSize(x1,y1,x2,y2)
works out to be
(x2-x1+1 rounded up to the nearest 8)*(y2-y1+1)*(bitsperpixel/8), or
((x2-x1) div 8+1)*8*(y2-y1+1)*bitsperpixel div 8
I believe these results are correct. If anyone else has played around with
the BGI who can confirm or deny it, please share your knowledge.