xpm versus png load time

I am creating a set of 16x16 icons for the PPM. Following zigbert's advice, I have got icons working in the PPM main window, and can have a unique icon for each package. That's another topic, I'll announce that soon.

The icons though... if we are going to have an icon for each package, installed or not, that is a lot of icons. Hundreds of them. But, I thought, if I can make the icons small enough, it won't increase the size of puppy much (and, I need to make their usage optional in the PPM).

I found a nice collection of SVG application icons in the Open Icon Library:
http://openiconlibrary.sourceforge.net/downloads.html

I wrote scripts to convert them all to tiny xpm 16x16 images. I will bundle those scripts together here for the record:
for ONESVG in `find open_icon_library-full/icons/svg/apps -type f -name '*.svg' | tr '\n' ' '`

do
ONEBASE="`basename $ONESVG .svg`"
echo "$ONEBASE"
rsvg-convert -w 16 -h 16 -o png-16x16/${ONEBASE}.png $ONESVG
sync
done

for ONEPNG in `find png-16x16 -type f -name '*.png' | tr '\n' ' '`
do
ONEBASE="`basename $ONEPNG .png`"
echo "$ONEBASE"
pngtopnm $ONEPNG | pnmquant 16 | ppmtoxpm > xpm-16x16/${ONEBASE}.xpm
sync
done

for ONEXPM in `find xpm-16x16 -type f -name '*.xpm' | tr '\n' ' '`
do
ONEBASE="`basename $ONEXPM .xpm`"
echo "$ONEBASE"
sPTN='s%" c black"%" c None"%'
sed -e "$sPTN" $ONEXPM > xpm-16x16-alpha/${ONEBASE}.xpm
sync
done


I have a fondness for xpm images, although I realise they are "yesterday's technology'. I like being able to open the file in a text editor!

I was wondering how these tiny images compare, xpm versus png. taking abiword image as an example, sizes in bytes (using default compression factors):

abiword.xpm 663
abiword.xpm.gz 382
abiword.xpm.xz 412

abiword.png 258
abiword.png.gz 277
abiword.png.xz 316


Xz does not do well with such small files, but in a .sfs file would probably get much smaller size.

Well, comparing abiword.xpm.gz and abiword.png, the former is slightly bigger. I wonder if abiword.xpm would get closer to abiword.png size with a bigger data-set as in a squashfs? As it stands, png is the winner here.

But, what about loading time, that is, to read the file and render it on-screen? Given that png images will have to be fed through a decompression routine, I always assumed them to be inherently slower to load than xpm. Xpm does of course need translation of the text, so it also has an overhead. I hunted around on the web couldn't find any comparison data. Perhaps the difference is negligible, and I should just choose the smaller png files.

Regarding size, so far I have created 294 xpm images. If I convert those to png, each about 250 bytes, the total size is about 75000 bytes, about 73KB. That's not too bad. Note, in a squashfs .sfs file there is no such thing as a minimum file size (as when stored separately on a drive), tiny files are packed together and there is no wasted space.

Note, I am not going to put these images into Woof! They will go into a PET. Woof already has too many images. The PET can then be optionally used in a Puppy build.


Posted on 28 May 2012, 18:37


Comments:

Posted on 28 May 2012, 23:39 by technosaurus
xpm v. png
I have actually tested this before. If you had a large directory of .xpm, xz compressed in a tarball, it was smaller than the same set of .png images in an xz compressed tarball.

The other note was that mtpaint does not fully support saving to xpm - you are limited to 64 colors instead of 93 to have single byte colors. Though for 16x16, 64 colors should be plenty & it cuts the size in half even compared to 65 colors (via mtpaint)

There is a set of xpm icons in AIcon that share a color pallette - that significantly improved the compressibility, since it had a small fixed number of repeated strings.


Posted on 30 May 2012, 2:24 by zigbert
xpm vs svg
Whatever format you support it might be smart to add support for alternative icons in svg format. I made a test-icon for Pburn, and I don't think you'll get the bloat-fever of it.



<svg width="665" height="665">

<path style="fill:#FFEEB0;fill-opacity:1;stroke:#000000;stroke-width:3"
d="m 332.50892,16.375045 c -178.16411,0 -322.7161778,144.552035 -322.7161778,322.716035 0,178.1643 144.5520678,322.81313 322.7161778,322.81313 178.16413,0 322.81317,-144.64883 322.81313,-322.81313 0,-178.164 -144.649,-322.716035 -322.81313,-322.716035 z m 0,238.571355 c 46.47201,3.1e-4 84.24163,37.67262 84.24163,84.14468 3e-5,46.47206 -37.76953,84.24178 -84.24163,84.24178 -46.47215,0 -84.14468,-37.76941 -84.14468,-84.24178 -3e-5,-46.47206 37.67259,-84.14468 84.14468,-84.14468 z"/>
<path style="fill:#FFD600;fill-opacity:1;stroke:#999999;stroke-width:4"
d="m 332.24847,31.453326 c -168.77023,0 -305.766897,136.997044 -305.766928,305.767114 0,168.77037 136.996628,305.76708 305.766928,305.76677 168.77027,0 305.66688,-136.9964 305.66685,-305.76677 0,-168.7704 -136.89664,-305.767114 -305.66685,-305.767114 z m 1.10096,166.545414 c 77.46716,0 140.32252,62.85551 140.32252,140.32249 -7e-5,77.46731 -62.85536,140.32251 -140.32252,140.32251 -77.4671,3.3e-4 -140.32249,-62.8552 -140.32249,-140.32251 -1e-4,-77.46698 62.85535,-140.32249 140.32249,-140.32249 z"/>
<path style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="m 293.88535,660.50994 c 68.29597,5.51622 171.75966,1.26129 245.81026,-75.42656 52.0605,-56.58712 98.87168,-199.27322 -9.19622,-301.96164 12.7803,106.66579 -21.06278,148.65224 -82.14458,196.74235 27.2519,-55.1409 29.05532,-129.77173 2.93672,-183.86048 C 419.29903,229.75057 337.65587,148.83851 336.15234,79.053774 285.65909,103.31541 244.37844,172.0631 267.36485,239.05245 311.99381,369.11479 241.24048,383.07502 219.86733,395.47022 224.26457,316.71747 199.40165,300.73655 183.62414,276.04547 171.71315,359.68175 64.396262,397.01064 74.591562,501.68629 c 6.30234,64.70619 68.119328,107.15237 126.945178,133.17993 -0.17552,-67.9558 11.44986,-81.11448 79.92387,-121.37536 35.26792,-20.73658 47.382,-55.91727 63.3572,-88.82098 9.94353,29.06357 12.88231,74.16635 -52.94885,145.29481 -26.93073,29.09781 -17.13418,63.29432 2.01639,90.54525 z"/>
</svg>




Posted on 30 May 2012, 13:23 by Tman
xpm vs png
I prefer .png files becuase it is supposed to be a lossless format and when uncompressed, they are smaller than .xpm files. A trick that I found is that; if you rename a .png file and give it a .xpm extension, it will still work be displayed in Puppy.
That is how I managed to create smaller Icewm themes.


Posted on 3 Jun 2012, 22:59 by ttuuxxx
xpm vs png
as icons go png is the best, they do shadows they are smaller in file size, transparent quality of png are second to none, also about 2 yrs ago I pm'd you a tar.gz of png icon's that I reduced in file size and removed unused Icons in the /usr/local/lib/X11/mini-icons directory and updated the png files, its a shame you didn't use those.
puppy would of looked more modern and have a smaller icon directory/file size total.
ttuuxxx