[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