ImageCache class

Pablo d'Angelo pablo at mathematik.uni-ulm.de
Mon Aug 25 00:20:36 BST 2003


Hi!

> Am 23.08.03, 10:19 +0200 schrieb Pablo d'Angelo:
> 
> > therefore the ImageCache class should check how much memory it consumes
> > and then remove pictures from the cache, depending how much RAM is still
> > available. I will probably use a simple "remove the olded" strategy.
> 
> The idea with releasing unneeded memory is great.
> 
> Why would You prefere to unload the picture and not let it stay in swap
> space? The difference would be (IMO) to unpack the one and reread from
> swap space the other. In the best situation this would bring no time
> savings. (I expect swap space on disk is no problem at all.)

Actually sometimes it is ;) I'm not sure if I want to keep more than 100
of image cache (worst case, with some of my pano's having more than
20 pics). The "find region" function in CPEditor also creates
multiresolution steps of the images, stored in the cache, leading to extra
memory usage.

PTSticher will be run in parallel, and also use some ram. I'm quite
sure that I can blow my virtual memory (320 MB), or at least take away
memory that I might want to use for other applications.

I do not want to repartion my harddrive, when my swapspace is sufficend
for all other work ;)

> > A while ago I tried to implement a reference counting with proxy
> > objects, but it became quite messy.
> 
> Does this mean, every funtion has to tell when it internally dont need
> this picture anymore or is this somewhat automatic ?

the idea was to automate this, by providing a smart pointer that will
notifiy the cache when it is deleted, so that the cache knows that the
image is not in use anymore and could be deleted, if space becomes tight.
Well the joys of memory management ;)

smart pointers are tricky things and I don't think my first try was
safe or working correctl, so I commented it out
(the strange stuff in ImageCache.h ;)

> > there are places that need them across multiple functions then I would
> > have to implement the reference counting.
> >
> > Otherwise I can skip this issue and just remove pics from the cache :)
> 
> This should work.

Ok, I'll add the "remove unneeded images" from cache sometime.

> Mostly the gui needs some attributes of the image to rebuilt the table
> list again. At the moment I ask allways the wxImage directly for height
> and name ...  The only which really needs the whole wxImage is the
> controlpoint editor.

The control point editor also copies the image, because it needs them in
the device dependant wxBitmap format. the search region etc. functions
will also ask for an image whenever they need one, so it shouldn't be a
problem.

> I suggest to store the attributes in ImageCache so
> the gui can read it without the need to reload the whole thing. I would
> like to help switching all list funtions and so on ;-)

oh, acutally, the widht and height should be stored in the Panorama
model as well, so it probably easier to just read it from there.

> As long as the "*_small" image remains in the cache for thumbnails, this
> should work.

Acutally I rewrote that function so that it creates the thumbnail if its
not already in the cache. I think it is easier if the cache knows how to
produce an image it was asked for. (Previously, getSmallImage() depended
on getImage() to be called first). This also fixed the problem of
geting black thumbnails. I haven't investigated why, but it works now.

> The functions, nedded by the gui, could be called
> getHeight(), getWidth(), getName(), getCount() .

What would getCount() do?

> The gui makes no use of exif data after the first loading. If You plan to
> reload exif data later, please store them as well separetly without
> erasing.

Hmm, currently all exif data is stored inside the Panorama model, and
not in ImageCache, so changes to ImageCache will not influence it in any
way. If the exif data changes, then the PT::Lens will change, and a
the classes listening to updates will be notified.

Currently the exif data is only read once, during adding the image.
I haven't thougt about rereading the exif data. Is there a use case that
needs this feature?

ciao
  Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP


More information about the ptX mailing list