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 <[EMAIL PROTECTED]> _______________________________________________ help-GIFT mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gift
