| Newsgroups |
gmane.comp.gnu.gift.general |
| Message-ID |
<[email protected]> |
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]>