[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] Questions and code...

From: Wolfgang Müller
Subject: Re: [help-GIFT] Questions and code...
Date: Tue, 1 Aug 2006 12:42:31 +0200
User-agent: KMail/1.9.1

Hi again,
> * How well does the search engine's (/usr/local/bin/gift) performance
> scale as the number of images increase? RAM-wise as well as CPU-wise?
> O(1), O(n), O(n2)?

The RAM: if we do not count the leak (which is probably in the XML 
handling :-/ and that leaks after every query) the storage cost is 
proportional to the number of features that are present in at least one 
image. In the worst case this makes up for approximately 80K features. 
Information about these features are kept in ram for every collection that 
has been queried at least once. There is no expiry, so far.

> * How much RAM does it use for N images?

The cost does not depend on N. So doing one query on your collection should 
give you an idea.

> * Does the engine ever need the images for runtime comparisons? It
> keeps a "database" of paths to the images and the thumbnails, but to
> me this is just metadata, and I'd like to keep that apart from the
> search engine if possible. Is it safe to remove the images after
> indexing them?

Yes, it is safe. The information about where the image resides is just kept 
for the purpose of rendering query results.

> * Are the parameters for the various algorithms described anywhere?
> * Although I don't personally like the idea of software patents, I'm
> curious: Are there any software patents being used knowingly in the

Not that we know of. Otherwise it would have been hard to become a GNU 

> I know you have a list of functions you would like to have added, but
> I'm nog going to volunteer to any of that until I have gotten to know
> the code a bit better. However, I have an idea on how to get to know
> the code and do something useful at the same time.
> (I have no knowledge on image recognition and such, but I hope my C++
> skills can be of use anyway.)

They can be of very much use.

> One thing could to do is to stumble through the code and try to clean
> it up slightly.
> Someone on the mailing list described gcc as a "moving target", and I
> suppose that as they keep making gcc/g++ more standards compliant,
> that will be true. I have found various small things in the code that
> is not correct according to the standards, but is accepted in the
> current version of gcc. As I find that kind of silly stuff, I could
> fix it, and possibly make life easier whenever gcc is updated next.

Yes, this would be very much welcome.

> Also, I have found stuff that is not used. I know this is a matter of
> taste, but in my experience, unused code is usually not worth holding
> onto. The code may be buggy (it actually is in some code I found) and
> a new developer may think that the previously unused function
> "doNeatStuff()" will actually do neat stuff... Also it may still be
> compiled, causing a longer build time. I could point out unused code
> as I find it, and you could remove it from source control. If you
> like, of course.

I would like that. 

> Finally, when browsing through doxygen and source code, I can't help
> asking myself: "why?" on different subjects. I have found stuff that
> could possibly be dangerous if used the wrong way, and if you're
> interested, I could bring those things up for discussion, whenever I
> come across something interesting.

Of course, I am interested (given the usual constaints :-( )

> I'm aware that there is always a reason behind each line of code, so
> you could probably teach me a lot if I point out something as "wrong"
> when in fact it isn't... :-)

I am looking forwardt to discussing things.


Dr. Wolfgang Müller
LS Medieninformatik
Universität Bamberg
Check out the SIG MM web site

reply via email to

[Prev in Thread] Current Thread [Next in Thread]