bug-gift
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-GIFT] GIFT does not find a query image relevant to itself when


From: David Squire
Subject: Re: [bug-GIFT] GIFT does not find a query image relevant to itself when returning results.
Date: Tue, 22 Jun 2010 18:00:32 +0530
User-agent: Thunderbird 1.5.0.14 (Macintosh/20071210)

I think it's pretty clear we have a major problem here (and also with the bug I reported a few weeks ago, which might be related). Sometime between 2006 and now, behaviour has deviated significantly from what it should be. I suspect we should roll back to a release based on 0.1.14 (with minimal modifications to get it to compile with the latest gcc and automake tools).

The next step should be to write a set of tests (verifying fts files, inverted files, query results, etc.) that can be used as regression tests so that we can be confident that any changes (re)introduced in the aim, say, of performance gains, don't actually break the existing system.

Of course we should always have had these...

Regards,

David


Nabeel Mohammed (Infotech) wrote:
Hello Henning,
I've used the config file you emailed me. I just ran a comparison using your configuration without change ( I changed the collection configs, but not the algorithm config ).

I can confirm that the behaviour is different between the version of gift I had checked out from cvs and gift-0.1.14.

I have a total of 1670 images in my collection. Of them, in the cvs version, 282 images return a different image than itself when used as the query. In gift-0.1.14, all the images are the first in the results list. The config file used is identical in both cases and I am attaching it just in case you want to have a look.

Let me know if I should be doing something else.

Thank you
Nabeel


On 21 June 2010 17:11, Henning Müller <address@hidden <mailto:address@hidden>> wrote:

    Hi Nabeel,

    this sounds indeed a bit weird, particularly that there are clear
    differences between the two versions!
    In principle it can happen well that two images have no features
    in common and then the number of retrieved images will not be the
    size of the collection. This can particularly happen if you only
    use texture.

    Which weighting do you use? Do you use the standard configuration
    file?

    Cheers, Henning

    Nabeel Mohammed (Infotech) wrote:

        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 <http://gift-add-collection.pl>
        <http://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


        ------------------------------------------------------------------------

        _______________________________________________
        bug-GIFT mailing list
        address@hidden <mailto:address@hidden>
        http://lists.gnu.org/mailman/listinfo/bug-gift


------------------------------------------------------------------------

<?xml version="1.0" standalone="no"?>
<!DOCTYPE mrml SYSTEM "file:/usr/local/share/mrml.dtd">
<!-- This file has become quite a free interpretation of MRML the above !DOCTYPE is rather for the use of psgml than
     a promise that the following is pure MRML. In fact the
     parser does not validate.

This is a configuration file for the server. It contains
information about collections, algorithms and
property sheets.


THIS FILE NEEDS CLEANING. ABOUT HALF OF THE LINES HERE ARE
LEGACY CODE. HOWEVER, IT IS NOT YET TESTED HOW THINGS BEHAVE
WHEN YOU REMOVE THE LEGACY CODE. SO, FOR A WHILE YOU HAVE
TO LIVE WITH QUITE A NUMBER OF OBSOLETE TAGS.

-->
<mrml>
  <cui-configuration>
    <algorithm-list>
    <!--COMMENT The new definiton of the default algorithm
                The default algorithm performs in fact a meta
                query of several inverted file queries.
                Each sub-query of the meta query is
specialised on one of the feature groups
                Color histogram
                Color block
                Gabor histogram
                Gabor block

                Each one of them is pruned in adifferent way.
                (this is the goal of the operation)
      -->
      <algorithm algorithm-id="adefault" algorithm-type="adefault" algorithm-name="Separate Normalisation" collection-id="c-30-23-11-25-3-110-0-114-0" 
cui-block-color-histogram="no" cui-block-color-blocks="no" cui-block-texture-histogram="no" cui-block-texture-blocks="no" 
cui-pr-percentage-of-features="70" cui-base-type="multiple" cui-weighting-function="ClassicalIDF">
      <algorithm algorithm-id="sub1" algorithm-type="sub1" algorithm-name="sub1" cui-block-color-blocks="yes" 
cui-block-texture-histogram="yes" cui-block-texture-blocks="yes" cui-pr-percentage-of-features="100" 
cui-base-type="inverted_file"/>
      <algorithm algorithm-id="sub2" algorithm-type="sub2" algorithm-name="sub2" cui-block-color-histogram="yes" 
cui-block-texture-histogram="yes" cui-block-texture-blocks="yes" cui-base-type="inverted_file"/>
      <algorithm algorithm-id="sub3" algorithm-type="sub3" algorithm-name="sub3" cui-block-color-histogram="yes" 
cui-block-color-blocks="yes" cui-block-texture-blocks="yes" cui-pr-percentage-of-features="100" 
cui-base-type="inverted_file"/>
      <algorithm algorithm-id="sub4" algorithm-type="sub4" algorithm-name="sub4" cui-block-color-histogram="yes" 
cui-block-color-blocks="yes" cui-block-texture-histogram="yes" cui-base-type="inverted_file"/>
        <query-paradigm-list>
           <query-paradigm/><!-- match anything -->
        </query-paradigm-list>
        <property-sheet property-sheet-id="cui-p-1" property-sheet-type="subset" send-type="none" 
minsubsetsize="0" maxsubsetsize="1">
          <property-sheet property-sheet-id="cui-p0" caption="Modify default configuration" 
property-sheet-type="set-element" send-type="none">
          <property-sheet property-sheet-id="cui-p15" caption="Prune at % of features" property-sheet-type="numeric" 
send-type="attribute" send-name="cui-pr-percentage-of-features" from="20" to="100" step="5" send-value="70"/>
          <property-sheet property-sheet-id="cui-p1" property-sheet-type="subset" send-type="none" 
minsubsetsize="1" maxsubsetsize="4">
            <property-sheet property-sheet-id="cui-p12" send-boolean-inverted="yes" caption="Colour blocks" 
property-sheet-type="set-element" send-type="attribute" send-name="cui-block-color-blocks" send-value="yes"/>
            <property-sheet property-sheet-id="cui-p14" send-boolean-inverted="yes" caption="Gabor blocks" 
property-sheet-type="set-element" send-type="attribute" send-name="cui-block-texture-blocks" send-value="yes"/>
            <property-sheet property-sheet-id="cui-p13" send-boolean-inverted="yes" caption="Gabor histogram" 
property-sheet-type="set-element" send-type="attribute" send-name="cui-block-texture-histogram" 
send-value="yes"/>
            <property-sheet property-sheet-id="cui-p11" send-boolean-inverted="yes" caption="Colour histogram" 
property-sheet-type="set-element" send-type="attribute" send-name="cui-block-color-histogram" send-value="yes"/>
            </property-sheet>
          </property-sheet>
        </property-sheet>
     </algorithm><!-- a-cidf  -->
    </algorithm-list>
    <cui-algorithm-id-list-list>  
      <cui-algorithm-id-list cui-algorithm-id-list-id="ail-inverted-file">
        <cui-algorithm-id cui-algorithm-id="a-cidf"/>
      </cui-algorithm-id-list>
    </cui-algorithm-id-list-list> 
    <collection-list listid="1">

<!-- xxyx gift-add-collection xyxx DEPENDS ON THIS LINE -->
<collection collection-id="c-30-23-11-25-3-110-0-114-0" collection-name="VisTex" cui-algorithm-id-list-id="ail-inverted-file" 
cui-number-of-images="1670" cui-base-dir="/home/nabeel/gift-indexing-data/VisTex/" cui-inverted-file-location="InvertedFile.db" 
cui-offset-file-location="InvertedFileOffset.db" cui-feature-description-location="InvertedFileFeatureDescription.db" 
cui-feature-file-location="url2fts.xml">
   <query-paradigm-list>
   <query-paradigm type="inverted-file"/>
   <query-paradigm type="perl-demo"/>
   </query-paradigm-list>
   </collection>

</collection-list>
  </cui-configuration>
</mrml>
<!-- this is for xemacs to make it start up in the right mode.
     it does the right thing, but complains
-->
<!-- ;;; Local Variables: *** -->
<!-- ;;; mode: sgml       *** -->
------------------------------------------------------------------------

_______________________________________________
bug-GIFT mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-gift


--
Dr David McG. Squire,  Senior Lecturer
Clayton School of Information Technology, Monash University, Australia
CRICOS Provider No. 00008C       http://www.csse.monash.edu.au/~davids/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]