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

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.

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.

agony_loader1.png

animals.png

Canyon.png

chateau.png

notacopy.png

Renaissance.png

6images.pi1.zip

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