[wxPython-dev] img2py script

Robin Dunn robin at alldunn.com
Tue Nov 20 11:20:04 PST 2007


Anthony Tuininga wrote:
> On Nov 14, 2007 6:07 PM, Robin Dunn <robin at alldunn.com> wrote:
>> Anthony Tuininga wrote:
>>> Hi everyone. I thought I would ask this question about the img2py
>>> script since it seems to me this would be an improvement -- but
>>> perhaps I'm missing something. :-)
>>>
>>> The current script generates fairly ugly code -- which bugs me even
>>> though it doesn't matter since its generated. :-) The generated code
>>> is also quite lengthy thanks to binary data being encoded with four
>>> characters in most cases. Finally the generated code is fairly
>>> intrusive in terms of namespace since three methods are generated for
>>> each image. My suggestion handles all of these, I believe, but I'd
>>> appreciate feedback.
>>>
>>> A class could be created (wx.PyImage?) that would encompass the
>>> routines for getting the data, bitmap and image (see attached) which
>>> would clear up the namespace intrusiveness. Then using base64 encoding
>>> dramatically reduces the size of the generated script (see attached
>>> for an example). The names, case, style, etc. are all subject to
>>> change if the concept is accepted, of course.
>>>
>>> Comments?
>> In general I like it, although I think I would prefer if the embedded
>> images were all instances of the same class, instead of individual
>> classes derived from the same base and using classmethods.
> 
> I have no objection to using a single class and instances of each as in
> 
> class PyImage(object):
> 
>     def __init__(self, data):
>         self.data = data
> 
>     def GetBitmap(self):
>         return wx.BitmapFromImage(self.GetImage()
> 
>     def GetImage(self):
>         data = base64.b64decode(self.data)
>         stream = cStringIO.StringIO(data)
>         return wx.ImageFromStream(stream)
> 
> 
> Checked = PyImage( \
>         "iVBORw0KGgoAAAANSUhEUgAAAA0AAAANCAYAAABy6+R8AAAABHNCSVQICAgIfA" \
>         "hkiAAAAKlJREFUKJFjlAls+M9AImBhYGBgODYxFi7AyMjEwMQEwczMzAxMTMxw" \
>         "momJiUEzrp+BCdkEQhqYmCDKmYjRYLDBCCrHjNBESAMDAwPcNrgmmAarXXZYNc" \
>         "DUMDIyompiZoZYbbrVAkPDjYjrDIyMjKg2wUyGAVwaGBlRnAdx0oWAcyjxga4B" \
>         "xXnIwXol5BJODWh+QsQDExMzXg0YoQfTjE8DAwMDAyM5aQ8AoE8ebApv5jgAAA" \
>         "AASUVORK5CYII=")
> 
> I can provide patches if you'd like -- unless you have further
> comments or changes or you'd prefer to implement it yourself?

Yes, please do provide a patch.  Some comments:

* The name of the class should be something like PyEmbeddedImage because 
the naming convention used elsewhere of PySomething where Something is a 
C++ class usually means that PySomething is a wrapper that knows how to 
redirect C++ virtual method calls to Python methods.  Since this is not 
the case here it should have a more unique name.

* There should be a GetIcon method.

* You could also provide properties for these getter methods, (Bitmap = 
property(GetBitmap), etc.)

* Since the data string is inside () you don't need the \ at the end of 
the lines.

* Please also change the various places in the wx.lib packages that use 
embedded images and make that part of the patch too.


> 
>> Using base64 is also a good idea.  IIRC that module wasn't available, or
>> at least not part of the standard build, when img2py was first
>> conceived.  Have you looked at how much space savings that using zlib is
>> buying?  At the beginning when the embedded format was XPM then
>> compressing gained us quite a bit in size reduction, but since the
>> format has been switched to PNG which is already at least RLE compressed
>> it may be possible that the gain is not worth the decompression time.
> 
> I did some checking on that. In some instances the compressed data is
> smaller but in quite a few cases the compressed data is larger. And if
> the image is smaller than 10k, the likelihood of the compressed data
> being larger is very high. 

I suspected that this would be the case, which is why I asked about it.



> I'd suggest dropping the compression
> entirely. 

I agree.

> Its also possible that for those few situations you could
> have another class PyCompresedImage which changes its GetImage() to
> add the zlib.decompress() call -- but I'm not sure its worth the
> trouble. Comments?

It's probably not worth the effort.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!





More information about the wxpython-dev mailing list