[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-GIFT] Ping!
From: |
Wolfgang Müller |
Subject: |
Re: [help-GIFT] Ping! |
Date: |
Thu, 4 May 2006 10:11:13 +0200 |
User-agent: |
KMail/1.9.1 |
> 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
- [help-GIFT] Ping!, risc, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, risc, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, David Squire, 2006/05/03
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/03
- Re: [help-GIFT] Ping!, risc, 2006/05/03
- Re: [help-GIFT] Ping!,
Wolfgang Müller <=
- Re: [help-GIFT] Ping!, Wolfgang Müller, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/04
- Re: [help-GIFT] Ping!, risc, 2006/05/03