help-gift
[Top][All Lists]
Advanced

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

Re: [help-GIFT] Searching for similarities


From: Wolfgang Mueller
Subject: Re: [help-GIFT] Searching for similarities
Date: Wed, 17 Oct 2001 23:32:54 +0200

On Wednesday 17 October 2001 16:21, Andreas Enge wrote:
> On Wed, 17 Oct 2001, MUELLER Henning wrote:
> > for the first question you are basically right: It is a front end
> > problem. Submitting images from an external source is not possible with
> > the Java Interface SnakeCharmer, but we also have a PHP Interface that
> > you can test out on our webpage http://viper.unige.ch/ when you go to
> > the demo section. There you can submit an image URL or submit an image
> > directly from the harddisk.
>
> Wolfgang Müller wrote:
> > This is known as the page 0 problem in the literature (how to start the
> > search if you do not have a suitable first image).
>
> Well, it is not quite true that I would like to submit an image from
> an external source.
But it _is_ true that I did not read your mail carefully enough :-(
> It would rather be an image from within my
> collection. So instead of starting with a random portfolio of images,
> the interface would have to allow to enter the file name of the
> start image, for which usually an inverted file already exists.
> May I formulate this as a feature request? I presume it should be rather
> trivial to implement, more or less like an "open file" dialogue.

Yes.

Quite an amount of things you describe would fit well with the project goals 
of the Fer de Lance project (http://www.fer-de-lance.org, FdL), a project I 
pursue in my copious leisure time. FdL's goal is to make intelligent 
retrieval services accessible to the desktop and to integrate them with the 
desktop. it currently lives at SourceForge

http://sourceforge.net/projects/fer-de-lance/

The first artefact of the project is Carsten Pfeiffer's kmrml, an MRML client 
that is integrated with konqueror (a kio slave, to be precise). If I am not 
mistaken, kmrml allows exactly the "get similar for file" queries you 
describe. We are still looking for people who like to hack the desktop and 
who have some GNOME or KDE knowledge. kmrml can be obtained at the cvs of the 
FdL project. If you have any questions about kmrml or FdL please either 
contact Carsten or the mailto:address@hidden 
list.

FdL asks for quite an amount of things from the GIFT, notably adding files 
during runtime. Viper (the current standard query engine of the gift) is not 
yet able to do these things, and they would be relatively difficult to add 
without ripping things apart to quite an extent. bothrops (a new query engine 
soon coming up) has been designed with FdL in mind. A very alpha version of 
bothrops worked for my thesis defense, but there is still some cleaning to do 
till I can release that code (to CVS). 

>
> This might be a solution to my first question as well. Is there a ready
> to use script which takes as input two file names (or the inverted files,
> I never looked at how gift works) and outputs a score of similarity?
No. There is something quite-ready-to-use which for one image gives you a 
sorted list of images with scores.

> Maybe the one you mentioned?
Yes, the one Henning mentioned.
> I never programmed in perl, so I hesitate
Strange language, definitely not everybody's taste, but people who like it 
usually like it a lot. 
> to dive into it, but once such a script exists it could be called from
> outside by a C programme or anything else.  so I am not ready to
> test anything shortly, but of course I may reinstall a day I have more
> time...

The protocol which you need to talk to the GIFT is MRML. It is an XML-based 
communication protocol that is described at http://www.mrml.net. You can 
speak to it using any language you like, provided this language is able to 
open tcp/ip sockets.

> I must admit that I dropped
> gift from my hard drive due to space restrictions,

Try to strip the gift. This helps disk problems a lot. But yes, the index 
files are big, and the code is not optimized for binary code size. 
Unfortunately, bothrops' disk requirements are rather above that of Viper 
(surely something to be improved). In both bothrops and Viperprobably we also 
should give an option to skip the generation of thumbnails for people who 
want to use the gift locally only.

> I might give it a try, although I am somewhat sceptical about the
> outcome. At least it is simple to test...

...and it does not work (I tested it with resizing to 10x10, and it fails 
miserably, so in the very least, you have to choose the parameters 
carefully). So you won't get around doing some feature extraction. However, I 
doubt that Viper's features are really the best for what you want to do (at 
least in terms of value for processor time).

David "Viper features" McG. Squire might have something to say to that? 

> Thanks for your fast 
We do what we can :-)
> and helpful replies,
I hope getting the same thing viewed from different angles provides you with 
some added value :-)

Cheers,
Wolfgang



-- 
Dr. Wolfgang Müller, assistant == teaching assistant
Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html 
Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift)




reply via email to

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