[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[help-GIFT] Questions and code...
From: |
Jonas Lindqvist |
Subject: |
[help-GIFT] Questions and code... |
Date: |
Mon, 31 Jul 2006 22:03:27 +0200 |
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
- [help-GIFT] Questions and code...,
Jonas Lindqvist <=