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

[risc]

On Mon, Jul 31, 2006 at 10:03:27PM +0200, Jonas Lindqvist wrote:
> 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?

256x256

> * How does the size of the original images affect the result?  

images are stretched/shrunk down to this resolution, so i imagine some 
distortion may skew matching..

> (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?)

larger images will be shrunk, so you'll lose some time, thats about it.

> * 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?

from what i can tell, no, it dosent use the images after feature extraction.

> * Are the parameters for the various algorithms described anywhere?

the feature extractor uses gabor filtering, and also includes histograms of 
blocks,
and average color for blocks.

> * 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.  

if you need help with patch generation, lemme know. i've screwed it up enough 
times. ;)

> (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.

diff -u. ;)

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

getting my speedup patches in has been a challenge. i cant speak for wolfgang, 
but i think auditing cleanup patches would be worse, and more time lagged.

> 
> 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
> 
> 


Ask away. I think we all read everything, so even if theres multi-day lag, just 
remember, the professors are very busy. ;)

Julia Longtin <address@hidden>