Attached is a thumbnail browser that caches its images in a single file, thus avoiding littering the tree with thumbs.db. Downside is that it slows if the maximum is too big. It uses pickle, so no DB installation is needed.
Phil
browser.py (10.9 KB)
···
At 01:37 AM 3/21/2007, Andrea wrote:
Hi Brad,
On 3/21/07, Brad Allen wrote:
* support displaying thumbnails on TIF files that use group 4 compression
* how to improve performance to enhance UI responsiveness
* estimate the difficulty/development time in adding a feature for
drag-reordering of thumbnails
...
On the second item, performance, I am wondering if maybe a caching
scheme would be workable. The main user complaint is that every time
they select a folder, they have to wait for the images to re-render.
If we could cache the thumbnails in the filesystem, that might be
helpful.
Well, the first thing I can think of is to do what Windows does, which
means creating a "Thumbs.db" file in the visited directories and load
the images from there (if I understand correctly what Windows does).
Attached is a thumbnail browser that caches its images in a single file, thus avoiding littering the tree with thumbs.db. Downside is that it slows if the maximum is too big. It uses pickle, so no DB installation is needed.
Thanks, Phil. That is a helpful example.
···
At 7:15 AM -0800 3/21/07, Phil Mayes wrote:
At 7:48 AM +0200 3/21/07, Peter Damoc wrote:
2. This is not an easy issue. I've played with it trying various approaches, no solution so far. I believe that beside some kind of caching you also need multi-threading and when you go there.... things start to go wacko. I had a version that worked and looked ok.... most of the time... and the rest of the time.... it was hell.
The current ThumbnailCtrl does use multiple threads. If we introduced caching in a single thumbnails file, I suppose the threads could get into contention for that file, at least for writing. But in this case there is not much writing going on--just once when the users select a directory containing image files. So I am not sure if it would be a problem.
Phil, thanks for providing that example. I was able to use the same idea and get a big performance gain, though I discovered something that you might want to try. In pickle.dumps, I found that using protocol=2 as one of the parameters made reading the pickled data dramatically faster. (you have to open the file for writing in binary mode in order to use protocol=2, as in file(filepath, 'wb').
My subclass of ThumbnailCtrl is now reading the pre-cached thumbnail files into a dict in RAM and checks it before reading from the filesystem. That saves it from having to decompress the TIFF and create the thumbnail, at the expense of taking up more disk space (we will delete the fat thumbnail file during the archiving process).
I don't know if this approach is useful to anyone else, since it is mainly adapted to the specific business need we have in this project. The caches are not created in the wx application or in ThumbnailCtrl, but are generated as incoming faxes are processed. However, if anyone is interested let me know...
···
At 7:15 AM -0800 3/21/07, Phil Mayes wrote:
Attached is a thumbnail browser that caches its images in a single file, thus avoiding littering the tree with thumbs.db. Downside is that it slows if the maximum is too big. It uses pickle, so no DB installation is needed.
Has anyone had any luck installing wxPython on RHEL4? There are no official RPMs for it on the Red Hat Network, and the RPM on the wxPython download site is not working out well. Here is what happens:
Python 2.4.4 (#1, Apr 2 2007, 09:36:39)
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import wx
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/wx-2.8-gtk2-ansi/wx/__init__.py", line 45, in ?
File "/usr/lib/python2.4/site-packages/wx-2.8-gtk2-ansi/wx/_core.py", line 4, in ?
ImportError: /usr/local/python244/lib/python2.4/site-packages/wx-2.8-gtk2-ansi/wx/_core_.so: cannot open shared object file: No such file or directory
Did we miss an important dependency? Like maybe wxWidgets? I am not sure why the RPM would not have reported that dependency.
We are aware that RHEL is using Python 2.3 but we pointed the install to a non-system Python under /usr/local/python244.
At the moment one of our team is building wxPython from source but it would have been nice to have a working RPM.
We are really only trying to install wxPython on this Linux server because wxImage has a capability that PIL doesn't have, which is to read TIFF images with group 4 compression. If anyone knows a better way than using wxPython, I could really use a pointer.
Thanks!