While adding support for overscanned/underscanned .PI1 images for the next version (1.15) of my Atari ST Plus Picture Viewer, I had a need for a bunch of samples of those .PI1s. So I created them myself: I took existing images, (1) used IrfanView for resizing them in 24-bit format, (2) used my own Qu program for quantising them to 16 colours and dithering (or not) in 8 different ways, keeping the best result, (3) used a special version of my Atari ST Plus Picture Viewer for creating .PI1s from them.

The version of my viewer currently under development already displays all of them perfectly, although I do not know if all of them would actually be displayed correctly on an Atari. Here are some samples. I will upload more if people are interested.

## Overscanned uncompressed DEGAS low-resolution images (.PI1)

**Moderator:** Moderator Team

### Overscanned uncompressed DEGAS low-resolution images (.PI1)

You do not have the required permissions to view the files attached to this post.

- FedePede04
- Atari God
**Posts:**1216**Joined:**Fri Feb 04, 2011 12:14 am**Location:**Denmark-
**Contact:**

### Re: Overscanned uncompressed DEGAS low-resolution images (.P

Thank you very much,

I am also i need of Picture samples, for my program,

most of them i could view correctly. but not all of them

can i ask how you check for the x,y size of the picture. i think it there my fails.

/Peter

I am also i need of Picture samples, for my program,

most of them i could view correctly. but not all of them

can i ask how you check for the x,y size of the picture. i think it there my fails.

/Peter

Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend

sometime my English is a little weird, Google translate is my best friend

### Re: Overscanned uncompressed DEGAS low-resolution images (.P

When decoding an image, 8 bytes at a time are processed. Low-resolution mode is 4 bits per pixel, so 8 bytes hold 16 pixels. This is why the screen data always has to have a width that is a multiple of 16 pixels, or padded to be a multiple of 16. For low-resolution, this then means that the number of bytes for the screen data has to be a multiple of 8 bytes. Given a 34 byte header for an uncompressed DEGAS file, this means that the filesize minus 34 has to be a multiple of 8. This helps to quickly eliminate a lot of possibilities.FedePede04 wrote:can i ask how you check for the x,y size of the picture. i think it there my fails.

The maximum possible (visible) width on an ST/STe is 416. So we are left with examining all widths from 16 through 416 (both inclusive) in steps of 16 (so 16, 32, 48, ... , 400, 416). So take the filesize minus 34 and multiply the result by 2 (because in low-resolution, there are 2 pixels per byte). Call the result N. Try dividing N by the widths just mentioned, so N/16, N/32, N/48, etc. and since the height has to be an integer number, this means that the remainder of the division has to be 0. Again, many possibilities are easily eliminated this way.

For the remaining possibilities, look at how well a line matches the next line, assuming some given width. I'll give an example of how to do that:

Let's take a standard 32,034 byte PI1 file. Subtract 34 and multiply by 2. Result: 64,000. Of course this fits the standard 320x200 size, but there are more possibilities. 64,000 is also evenly divisible by 160 for instance (160x400). So let's assume a width of 160. We compare each byte of the screen data with the one 80 bytes (160/2, because of 2 pixels per byte) further on, and such repeatedly for the entire image:

Take the square of the difference between the 1st byte and the 81st byte, add the square of the difference between the 2nd and 82nd byte to the result, and so on, and finally divide that sum by the number of pairs we have looked at. So when assuming a 160x400 image (so 80x400 bytes of screen data), we would look at 80x(400-1) pairs of bytes. So the sum of the squares of differences in this case should be divided by 80x(400-1).

Do this for every possibility that we have. So for 320x200, we would compare pairs that are 320/2 = 160 bytes apart and the sum of the squares of differences would be divided by 160x(200-1).

The best match is the one with the lowest result.

Note that this only works in case the last line of the image is complete, not truncated.

Meanwhile, here are some more overscanned sample pictures.

You do not have the required permissions to view the files attached to this post.

### Re: Overscanned uncompressed DEGAS low-resolution images (.P

impressive. like the animals

- FedePede04
- Atari God
**Posts:**1216**Joined:**Fri Feb 04, 2011 12:14 am**Location:**Denmark-
**Contact:**

### Re: Overscanned uncompressed DEGAS low-resolution images (.P

Many thanks for the explanation.

it was something like that I was afraid for.

I think I have to read, how to find the width a few more times, before i understand it.

but it would have been so much easier, if they had add two word to the bottom of the file, containing the width and height.

but it should clearly not be easy

btw it is some really great picture, you have uploaded, and i am looking forward to your next version of your viewer.

/Peter

it was something like that I was afraid for.

I think I have to read, how to find the width a few more times, before i understand it.

but it would have been so much easier, if they had add two word to the bottom of the file, containing the width and height.

but it should clearly not be easy

btw it is some really great picture, you have uploaded, and i am looking forward to your next version of your viewer.

/Peter

Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend

sometime my English is a little weird, Google translate is my best friend

### Re: Overscanned uncompressed DEGAS low-resolution images (.P

There is one thing I still have to mention here. Checking for a height of 1 (so 16x1, 32x1, 48x1, 64x1, ... 416x1) does not work with my algorithm since I divide by "height minus 1" at the end. If height is 1, this would lead to a division by zero. A height of 1 can only safely be assumed in case of 16x1, but not with other widths because 32x1 = 16x2, 48x1 = 16x3, 64x1=16x4, 80x1=16x5, etc., so there are other possibilities for all other widths that are multiples of 16, except for width 16. I do not consider this a drawback since images of height 1 are not very interesting, are they?

The next version of my Atari ST Plus Picture Viewer (1.16) will take the above fully into account (not just for 16x1). For the current (1.15, as of this writing) version of my Windows viewer, see the forum link or the direct link. (The latter is where I upload new versions first.)

The next version of my Atari ST Plus Picture Viewer (1.16) will take the above fully into account (not just for 16x1). For the current (1.15, as of this writing) version of my Windows viewer, see the forum link or the direct link. (The latter is where I upload new versions first.)