>>> 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
_______________________________________________
help-GIFT mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gift
