Questions and code...

Okay, hi again!
Thanks for the replies on my previous posts.


First, some questions:
* What's the ideal size (in pixels) of the images to be indexed?
* How does the size of the original images affect the result?  
(Indexing thumbnails would probably be pretty pointless, but is it  
always better to use a monster-sized image? Would it take a longer  
time to index?)
* 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)?
* How much RAM does it use for N images?
* 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?
* 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  
GIFT?


Then, over to the issue of code:
I work professionally as a C++ systems developer since 6 years, but I  
have never (yet) participated actively in an open source project.
I haven't used CVS in several years, so I'm not really up to date on  
the subject of creating patches for you to merge into the code-tree.  
(I use SVN mostly, and am pretty used to being able to commit my  
changes myself.., :-) If you have any instructions on how to create  
the patches in a way that will make your life easier, I will gladly  
follow them.
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.)

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.

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.

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.

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... :-)



/Jonas