[Top][All Lists]

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

Re: [help-GIFT] Adding and removing images to/from gift

From: Kamil Wencel
Subject: Re: [help-GIFT] Adding and removing images to/from gift
Date: Wed, 13 Sep 2006 08:27:37 +0200
User-agent: Thunderbird (Windows/20060719)

>>> I would need a --no-image-paths option to make it not store the image
>>> paths in the url2fts.xml file, since I just need the image names to
>>> be presented by the gift server.

>> I thought you can get a behavior close to that by the proper choice of
>> prefixes (empty) in

I have tried the "empty prefix" but gift inserted a default file:/usr/local/gift/share value instead. Now I am using / as image and thumbnail prefix and then str_replace / in the gift MRML output.

But this can only be a workaround. Since my target application is very close to Jonas's I have pretty much the same "requirements" he does.

From my point of view, Jonas's list of suggested modifications / options have a real world value and would make gift much more versatile.

Unfortunately my perl knowledge is nowhere near the level,where I could just hop into the code and make the suggested modifications easily. I'll try, though ;)

Currently I still scratch my head about HOW
I merge the "small inverted file" with the big one. Or can I use both
together in conjunction within the same collection ?

Recent work suggests that you have a hierarchy of inverted files. Each file smaller by a factor than the previous one. You use them in parallel, i.e. you are running several queries at the same time on different query engines. Then you merge the results.

A good approximation of such behavior could be achieved by properly hacking :-) and properly using the GIFT's elaborate query engine construction mechanism in gift-config.mrml. The missing bit in such an approach would be that the statistics about each feature would not be shared among the huge/large/small/tiny inverted files. This would be not so good for the ranking, but nothing a small hack couldn't cure ;-) .

hmm. I have no idea how to implement that kind of scenario seamlessly into my plattform. I barely got it to work with one collection and get troubled by the following two points even then:

- After getting a random set, I chose 3 images which i like, requery, select 3 more images gift found I could like. Now there is nothing more I like soi start "deselecting" the other 4 unwanted images, requeryand get 4 new images. But when I requery again, gift brings back the 4 images i deselected before. After what I've seen this is not the gifts fault as such, it's more of a workflow problem because gift obviously doesn't know anymore what it server one request before. It would be nice if gift itself could track in the session, which images are queried wanted / unwanted and never show the unwanted in that session again. I think it could improve accuracy.

The way it is currently working I would have to store the users query into a db, send the request to gift, store its answer and remerge something else out of the request I sent and the answer gift gave.

- The second thing is matching algorithm. Currently I get the feeling that my gift is fixed on color more than on shape / texture. sometimes I get perfect results ( e.g. gift finding all appropriate matches I know of ) but sometimes it doesn't even show an image it most definitely should be supposed to. How can I tweak my system to try different methods or make it more sensitive for shape / texture than color ?


reply via email to

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