GIFT does not find a query image relevant to itself when returning results.

--===============1446182049==
Content-Type: multipart/alternative; boundary=0016363107893859190489842abf

--0016363107893859190489842abf
Content-Type: text/plain; charset=ISO-8859-1

Hello,
I am trying to use GIFT for the research work associated with my PhD. I had
checked out the latest version from cvs to do my work and ran into a
problem.

I have an algorithm configured in my gift-config.mrml which uses just the
global texture features ( extracted using the bank of 12 Gabor filters ). I
was getting odd results from my test scripts. Looking into the problem a bit
more I realised that when I am querying with a single query image, the first
image returned (the most relevant) in the results is not the image itself.
Infact the top relevant image seems to have a relevance of less than 1. I
have a total of 1670 images in my collection ( a modified version of the
VisTex database ), and this happens for 368 of them (I wrote a script to go
through and do the sanity  check for every single image). My supervisor (
Dr. David Squire) had .fts files for the same collection, and using them
also did not alter the behaviour ( I regenerated the inverted files).

There is another issue where when for a query image I ask for 1670 results,
for some images I don't always get back all 1670 (  about 1300 or so is
returned). I can see how it may happen
theoretically, but it seemed odd to me.

My environments are Ubuntu 9.10 running on Virtual Box on a windows machine
and a Mac. Both installations show the same issue.When installing the
pre-requisites I used the latest version of the Ubuntu packages for my
version of Ubuntu, instead of using the version numbers mentioned in the
readme file. Overall the compilation and installation was relatively
painless.

On the advice of David, I downloaded gift-0.1.14 and tried to compile it on
my environment. After a few changes I had it up and running. Using the old
collections still gave me the odd results.
However, when I added a new collection using the same images using
gift-add-collection.pl, the insane behaviour went away for the new
collection. Also gift-0.1.14 behaves sanely when I use the .fts files given
to my by David and regenerate the inverted files.

Also, for each image, gift-0.1.14 always returns all 1670 images, when I ask
for that result size.


I've noticed that the code used to generate the Gabor features have markedly
changed in the cvs version since gift-0.1.14. I am not entirely sure the two
versions generate the same .fts files (I can check, but haven't done so
yet!). I think there is a problem in the inverted file generation which
causes gift to behave in such a way, but thats my guess. I am wonderring if
anyone knows of this problem,
or has checked for it or knows how to solve it? If it is something I am
doing wrong, then I am hoping someone can tell me how to fix it.

Thank you
Nabeel

--0016363107893859190489842abf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<br>I am trying to use GIFT for the research work associated with my =
PhD. I had checked out the latest version from cvs to do my work and ran in=
to a problem. <br><br>I have an algorithm configured in my gift-config.mrml=
 which uses just the global texture features ( extracted using the bank of =
12 Gabor filters ). I was getting odd results from my test scripts. Looking=
 into the problem a bit more I realised that when I am querying with a sing=
le query image, the first image returned (the most relevant) in the results=
 is not the image itself.=A0 Infact the top relevant image seems to have a =
relevance of less than 1. I have a total of 1670 images in my collection ( =
a modified version of the VisTex database ), and this happens for 368 of th=
em (I wrote a script to go through and do the sanity=A0 check for every sin=
gle image). My supervisor ( Dr. David Squire) had .fts files for the same c=
ollection, and using them also did not alter the behaviour ( I regenerated =
the inverted files).<br>
<br>There is another issue where when for a query image I ask for 1670 resu=
lts, for some images I don&#39;t always get back all 1670 (=A0 about 1300 o=
r so is returned). I can see how it may happen<br>theoretically, but it see=
med odd to me.<br>
<br>My environments are Ubuntu 9.10 running on Virtual Box on a windows mac=
hine and a Mac. Both installations show the same issue.When installing the =
pre-requisites I used the latest version of the Ubuntu packages for my vers=
ion of Ubuntu, instead of using the version numbers mentioned in the readme=
 file. Overall the compilation and installation was relatively painless. <b=
r>
<br>On the advice of David, I downloaded gift-0.1.14 and tried to compile i=
t on my environment. After a few changes I had it up and running. Using the=
 old collections still gave me the odd results.<br>However, when I added a =
new collection using the same images using <a href=3D"http://gift-add-colle=
ction.pl">gift-add-collection.pl</a>, the insane behaviour went away for th=
e new collection. Also gift-0.1.14 behaves sanely when I use the .fts files=
 given to my by David and regenerate the inverted files.<br>
<br>Also, for each image, gift-0.1.14 always returns all 1670 images, when =
I ask for that result size.<br><br><br>I&#39;ve noticed that the code used =
to generate the Gabor features have markedly changed in the cvs version sin=
ce gift-0.1.14. I am not entirely sure the two versions generate the same .=
fts files (I can check, but haven&#39;t done so yet!). I think there is a p=
roblem in the inverted file generation which causes gift to behave in such =
a way, but thats my guess. I am wonderring if anyone knows of this problem,=
<br>
or has checked for it or knows how to solve it? If it is something I am doi=
ng wrong, then I am hoping someone can tell me how to fix it.<br><br>Thank =
you<br>Nabeel<br>

--0016363107893859190489842abf--


--===============1446182049==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bug-GIFT mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gift

--===============1446182049==--