What is the format of GET graphics data?

If you have questions about any aspect of QBasic programming, or would like to help fellow programmers solve their problems, check out this board!

Moderators: Pete, Mods

Post Reply
shlafferty
Newbie
Posts: 4
Joined: Thu Aug 30, 2012 5:38 am

What is the format of GET graphics data?

Post by shlafferty »

Hi,
I need to convert data from the graphics screen into the PBM file format for external use. However, I haven't been able to find out exactly the format which the GET command uses when storing graphics data in an array, despite consulting books and the Web.

The screen mode is 11, for max resolution monochrome graphics. (This is a scientific app.) So there is just one bit/pixel and one plane, 640x480. I gather that GET uses a raster scan. However, the formula for the total amount of data suggests that there is more to it than just the raw raster bits:
#bytes = 4 + 480 * 1 * INT( (640 * 1/1 + 7)/8 ) = 38404

This suggests that there may be four header bytes and that each raster row may have seven extra pixel positions for something. Then there is the question of the order the pixel bits are packed into the integers in the target array.

Can anyone tell me the exact format of the data obtained by the command:
GET (0,0) - (639,479) arrayname# (for SCREEN 11)

Thanks,
Steve
User avatar
burger2227
Veteran
Posts: 2466
Joined: Mon Aug 21, 2006 12:40 am
Location: Pittsburgh, PA

Post by burger2227 »

The four header bytes are the INTEGER values of the width and depth of the GET area. SCREEN 13 multiplies the width by 8.

7 is added to make sure it is a certain width multiple.

The rest is pixel data as INTEGERS. PBM is a black and white format that just reads each pixel value as black or white bits(on or off). I gather that is why you are using SCREEN 11. You can only GET 1/3 of a screen 11 or 12 image to an INTEGER array in Qbasic! 160 X 640 max.

The extra pixels are for bit padding in the file. From what I have seen the width is padded to a 4 byte width(32 bits) multiples. This prevents image skewing.
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
shlafferty
Newbie
Posts: 4
Joined: Thu Aug 30, 2012 5:38 am

Post by shlafferty »

Thanks, Burger.

That only leaves the question of whether the pixels are packed into the MSB first, or not, in the integers. I'm going to assume so and try it.

Will also assume that the raster data is read L->R, then T->B.

It finally dawned on me that adding 7 inside the INT just counts an extra byte if the number of bits in a line goes over a multiple of 8.

The reason I'm using SCREEN 11 is to get the max hor and vert resolution for the data graphs. I'm using PBM as the output file format because that is the simplest generally supported format that I know of.

Thanks,
Steve
User avatar
burger2227
Veteran
Posts: 2466
Joined: Mon Aug 21, 2006 12:40 am
Location: Pittsburgh, PA

Post by burger2227 »

Each byte of the data is read from MSB down L to R. It says in documentation that a bit on is black and off is white:

http://www.daubnet.com/en/file-format-pbm

Bitmaps are read from the bottom to top, but not in PBM apparently.
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
shlafferty
Newbie
Posts: 4
Joined: Thu Aug 30, 2012 5:38 am

Post by shlafferty »

Right; I'm familiar with the PBM format. The questions are about the format of QB's GET graphics data in the integer array. It sounds like you are implying that the QB data is read from bottom to top. Is that right?

Thanks,

Steve
User avatar
burger2227
Veteran
Posts: 2466
Joined: Mon Aug 21, 2006 12:40 am
Location: Pittsburgh, PA

Post by burger2227 »

No, It is top to bottom in GET data but that kind of file writes each bit as a value of either 1 or 0. That's not very efficient and difficult to convert to a QB image.

Let's say you have the following data:

0 0 0 1 0 0 0 1

That could be expressed as 00010001 in binary or 17 decimal which could be placed as one byte in a file using one ASCII character. When done with 8 bits each, the file could be much smaller.

Code: Select all

bin$ = "00010001"

FOR i = 7 TO 0 STEP -1
  c = c + 1
  IF MID$(bin$, c, 1) = "1" THEN total = total + 2 ^ i
NEXT
PRINT total
The GET data is INTEGERS of color attribute values where 0 is black.

Do you have images you want to save to a file simply? QB64 can PUT # a GET array directly to a file. Qbasic can use BSAVE.
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
shlafferty
Newbie
Posts: 4
Joined: Thu Aug 30, 2012 5:38 am

Post by shlafferty »

I have done some experiments and solved the GET graphics format for SCREEN 11, so I am presenting the findings for anyone else who needs the information:

- SCREEN 11 is a 640 x480 1-bit/pixel mode with only one plane.
- "GET (0,0) - (639,479) array%" puts the screen data in array%.
- The first four bytes are header, giving the width and height.
- Pixel data is read from the screen L=>R and then T=>B.
- Pixel bits are packed into the integers in the array as follows:
- If the integer bits are 0 (LSB) to 15 (MSB), the order of the pixel bits is:
- 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8
- The next integer in the array is then filled.
It turns out, that the order in a PBM format file is exactly the same. So to write the data into a PBM file, you can write the header and then load the integer array containing the pixel data, directly into the file. Note that PBM-file black/white polarity is inverted from QB but that's good because black lines on white background is what you want, if you make a hardcopy from the file.

Steve L.
User avatar
burger2227
Veteran
Posts: 2466
Joined: Mon Aug 21, 2006 12:40 am
Location: Pittsburgh, PA

Post by burger2227 »

I found something odd about the GET size. The first integer to read changes with the GET size. Increase 19 to 29 and the values move to the next integer. The GET below shows the low byte of array index 3 as 0:

Code: Select all

SCREEN 11
DIM array(100) AS INTEGER

FOR i = 1 TO 17
  PSET (i, 1), 15
NEXT

GET (0, 0)-(19, 19), array() 'change to 29, 29
PUT (100, 100), array()

LOCATE 10, 1
FOR n = 0 TO 10
  PRINT array(n);
NEXT
PRINT
FOR n = 2 TO 10
  IF array(n) THEN
    PRINT "Index:"; n,
    FOR i = 7 TO 0 STEP -1
      IF array(n) AND 2 ^ i THEN PRINT "1"; ELSE PRINT "0";
      PRINT " ";
    NEXT
    FOR i = 15 TO 8 STEP -1
      IF array(n) AND 2 ^ i THEN PRINT "1"; ELSE PRINT "0";
      IF i > 0 THEN PRINT " ";
    NEXT
    PRINT
  END IF
NEXT
GET changes the array indexes to 4 and 5. At 60, 60 it skips 4 integers.

To ignore the low byte at the beginning of a GET array when an INTEGER has a value, you could use:

Code: Select all

IF array(n) AND 255 THEN 'check low byte if it holds data
  FOR i = 7 TO 0 STEP -1
    IF array(n) AND 2 ^ i THEN PRINT "1"; ELSE PRINT "0";
    PRINT " ";
  NEXT
END IF
Then read the high byte whether it holds data or not.

This exponent code can be adapted to PRINT # the data to your files.
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
Post Reply