Re: Adding and removing images to/from gift

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

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 
> gift-add-collection.pl :-) 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 ?

--K