Re: [help-GIFT] Ping!

[Wolfgang Müller]

> i would disagree. ;)
>
> i think the URL centricness of gift has been a pain, to me. i've had to
> hack up my Client.php to re-write some URLs.
> then again, i may be misconfigured.

You can configure pretty far which URLs will be generated. If you do not like 
the URLs the easiest way to change them is to do some sed -e s/././g business 
on url2fts.xml. This file is generated for every image collection.

> however, i like the present method of the feature extractor.
> if i were to make a change, i'd work on a batch mode.

Well I think it is a pain in the sense that we have many useless disk 
accesses. First we do an image conversion, write it somewhere, then this 
generates features. OK. It would save some time to get rid of that and it 
could still be a normal batch process.

But without further optimisation of the code we could get twice or more as 
fast if we could avoid having to reinstantiate convert and 
gift-extract-features for each image whose features we want to extract.

> unix utilities are commonly written to accept input on stdin, and output on
> stdout. if i were to make a modification to the feature extractor, i'd make
> it perform as that, then you dont need a "plugable system". the only change
> i ever made to switch between my version and yours was in
> gift-add-collection.pl, to change the executable name.

Yes, I was proposing to exchange lists of files that way. The advantage is 
that the feature extractor is thus not limited to one single file. Of course, 
we could also do that by  creating a simple tagged file format that allows 
the feature extractor to send over lists of byte sequences in stdin, and the 
aggregator then distributes the stuff over several files. This does have the 
advantage of cleanliness, however, I do think that the other approach will 
not be much dirtier but it will be much faster, as we are not piping stuff 
from c to perl.

> to me, it seems ideal to ship multiple 'feature extractors', and pass the
> name of the feature extractor to use to gift-add-collection.pl

Yes I do think that I have written about just that.

> the "isolated nature" of the feature extractor code is part of what let me
> make these improvements. i'm no c++ programmer. ;)

Granted.

> mine would be more hackish, but "fits better" with unix philosophy.

Unix philosophy is nice, but I am mainly concerned with what a feature 
extractor might want to do. And I do think that it might want to generate 
several files. It seems unnatural to me to lump all these files into one 
stream and then parse this stream in order to generate the files. 

For example, the inverted file feature extractor might want to 

- generate the feature file
- generate a thumbnail that visualizes the filter responses before extracting 
the texture histogram.
- generate a thumbnail that visualizes the quantized colors

It might even want to generate the "normal" thumbnail, as it already loads the 
image from a temp file and resizes it. A cleaner approach would be to popen a 
separate thumbnailer application and pipe locations of images to be 
thumbnailed into it.

Does this convince you? If not, please complain.

> > It would be good to think about this over the next few weeks/months. I
> > think an extension in this direction would really improve the usability
> > of the framework (cf. the "symbols discussion earlier today). There
> > could be a default set of provided similarity calculators (based on what
> > is already there), and perhaps a provision for users to provide others
> > (possibly plugins again, but perhaps also by providing subclasses and
> > editing a nice clear source file that delegates these things).

Well, as you know the feature weighters are already subclasses of a base 
class, and there is also a plugin generator nobody used so far that generates 
a plugin frame. Mabe this could be used as a base.

But I do agree that it would be good to go over that code and locate the parts 
that one should factor out in a way that one can easily point at them and say 
"hack this file and leave the other stuff alone".

>
> i'm excited to hear about this. ;)

;) ?

Cheers,
Wolfgang

-- 
Dr. Wolfgang Müller
LS Medieninformatik
Universität Bamberg
Check out the SIG MM web site http://www.sigmm.org