Re: [help-GIFT] Ping!

[risc]

mmmmm. programming debate. this is what i expected on this list. ;)


On Thu, May 04, 2006 at 10:11:13AM +0200, Wolfgang Müller wrote:
> > 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.
> 

granted. its been a pain, but not one i havent sedded arround.

> > 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.
> 

yepyep. agreed.
also remember, i'm looking at things from the festure extractors point of view.
the gabor wave array could be re-used between image runs, as the images are the 
same size by definition, and the filter dosent change.

> > 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.

my only concern in this, is that the programing to retrieve the URL not slow 
us down. retrieving everything through http using DNS can cause its own 
set of user configuration issues.

> 
> > 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.

Convinced. unix's "everything is a single file" approach sometimes shows its 
age. ;)

> 
> > > 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. ;)
> 
> ;) ?
> 

part of what i'm doing is trying to locate "a stamp" anywhere on an image. the 
ability
to make gift non-location-specific, but still find the "finer" features sounds 
like
fun to play with. 


Julia Longtin <address@hidden>