BDS Software - Graphic Formats

Graphic Formats

Let us design a map consisting of 400 squares laid out in a 20x20 grid, and let the square numbering be zero-based; i.e. 0-19 in the x-direction and 0-19 in the y-direction. Further, let us define square position numbers in (nx, ny) form.

Then, let the interior of each square (not including the borders) be 31x31 pixels, so that there is a distinct center at pixel (15, 15) relative to the upper-left corner of that interior space (pixel numbering being zero-based as well). Also, let us generally define pixel locations as (x, y) relative to the upper-left corner of the entire map.

Then, let there be borders all around the map and between squares, of width = 1 pixel each.

Thus, the North-South (NS) border at the left of the entire map is at x = 0 relative to the upper-left corner of that entire map.

The NS border on the right of the first column of squares will then be at x = 32 relative to the upper-left corner of the map. The right NS border of the second column will be at x = 64. etc.

In general, for square x-positions numbered nx = 0 through 19, the x-coordinate of the right NS border will be x = (nx + 1) * 32. e.g., for square x-position = nx = 19, x = (19 + 1) * 32 = 20 * 32 = 640.

The y-coordinates of the East-West (EW) borders will be calculated similarly.

Thus, the entire map image, all borders included, will require a space of 641x641 pixels.

[Incidentally, for square x-positions numbered nx = 0 through 19, the x-coordinate of the upper left corner of the interior space (i.e. just "inside" the borders) will be x = 1 + (nx * 32), i.e. 1, 33, 65, 97 ... 545, 577, 609; and similarly for the y-coordinates.]

We have a .bmp image, BlankSector.bmp, previously made to these specifications, which is of size 1.17 MB (1,233,338 bytes).

I used Corel Paint Shop Pro 9 to convert this to a .png image of size 2.79 KB (2,859 bytes), an exceptional reduction in size! [0.23% of the .bmp].

I then imported BlankSector.png into Inkscape 0.91 and saved it to an .svg image of size 5.51 KB (5,648 bytes). [0.46% of the .bmp]. This was a surprising result, since I had expected the .svg file to be smaller than the .png file. Inspecting the image, I also noticed apparent doubling of the rightmost and bottom-most borders, i.e. at x = 640 and at y = 640, i.e. seemingly as a drop shadow.

I then imported BlankSector.bmp into Inkscape and saved it to BlankSector2.svg, an image of size 6.28 KB (6,432 bytes). [0.52% of the .bmp]. Intriguing! In Inkscape, this image also showed the drop-shadow.

So, without using Inkscape, I proceeded to specify the .svg file in the TextPad 4.7.0 text editor, as follows:

I placed this code in a separate editor window and saved it as BlankSector3.svg with a resulting file size of 3.86 KB (3,958 bytes). [0.32% of the .bmp]. Fascinating! When loaded into Inkscape, this image also shows the drop-shadow. I thus suspect that to be a display artifact of the Inkscape program itself. Also, although this is the smallest of the three .svg files, it is still larger than the .png file.

So, I will plan to use BlankSector.png as the base map for all games I develop around the 20x20 grid.

-----

However, I also suspected that the different file sizes encountered above might be influenced by the lack of complexity of the simple gridline layout of the image.

So I made a similar test run, starting with a somewhat more complex 578x601 ChessBoard.bmp image which has a file size of 1.02 MB (1,077,046 bytes).

ChessBoard.png = 88.3 KB (90,459 bytes). [8.40% of the .bmp].

ChessBoard.svg (starting with ChessBoard.png; in Inkscape) = 121 KB (126,966 bytes). [11.79% of the .bmp].

ChessBoard2.svg (starting with ChessBoard.bmp; in Inkscape) = 139 KB (142,605 bytes). [13.24% of the .bmp].

Given the increased complexity of the ChessBoard image, I didn't try to code an .svg image in TextPad.

So, the ChessBoard.bmp reductions are not as dramatic as those with BlankSector.bmp, but they are still quite significant. Again the .png reduction is superior to the .svg reduction.

-----

Going for even more complexity, I pulled up a 578x771 pixel photograph tree.jpg of file size 149 KB (153,110 bytes). To maintain a parallel comparison methodology, I used Paint Shop Pro to convert it to tree.bmp with a file size of 1.27 MB (1,338,510 bytes). [874.21% of the .jpg].

tree.png = 748 KB (766,356 bytes). [57.25% of the .bmp]. [500.53% of the .jpg].

tree.svg (from tree.png) = 0.98 MB (1,037,010 bytes). [77.48% of the .bmp]. [677.30% of the .jpg].

tree2.svg (from tree.bmp) = 1.12 MB (1,175,125 bytes). [87.79% of the .bmp]. [767.50% of the .jpg].

-----

Which leads me to conclude that, as the complexity goes up, the .png and .svg reductions from .bmp go down. But the .png images seem to be consistently smaller than the .svg images.

Thus, except where I may need to avail myself of the scaling capabilities of .svg images, .png images will be better for situations in which the image will not have to change size.

Also, .jpg images will continue to generally be superior for photographic images and other images of similar complexity.

-----

Please feel free to download and inspect any of these images for yourself:

BlankSector.bmp

BlankSector.png

BlankSector.svg

BlankSector2.svg

BlankSector3.svg

ChessBoard.bmp

ChessBoard.png

ChessBoard.svg

ChessBoard2.svg

tree.jpg

tree.bmp

tree.png

tree.svg

tree2.svg

M.D.J. 2018/06/23