Re: Optimizing

[email protected] wrote:

[snip]
>
> Replying to myself, just to make sure...
>
> David,
>
> Do you have any objections to the patch above, or the 70* and 80* patches i submitted last time arround?
>
> Speak now, cause as soon as my laptop is set up, i'm commiting. :)
>   

Hi Julia,

Go ahead and commit, I guess. Sorry for the delay.

As you know, I feel very unconfortable with hardcoding fixed sizes into
this code. The main reason I have been fiddling with
gift-add-collection.pl is that I wanted to get familiar with that code
in preparation for changing the way gift-add-collection.pl and the
feature extractor interact. This is the plan:

- first, change things so that the feature extractor can be launched so
that it expects a list of image filenames on stdin. The perl script will
then instantiated the feature extractor only once, which should save a
*lot* of overhead, and send it a list of images to process. Once this is
set up, we may be able to wind back some some of these hard-coded sizes,
e.g. the initial handshaking with the feature extractor could include
specifying max. width and max. height, which could then be used in a
one-off allocation of the various chunks of memory that will be used for
all the images to be processed.

- second, change gift-add-collection.pl so that a particular feature
extractor can be specified as a command line argument. This is because I
am doing some research at present using different sorts of
(collection-specific) texture features, and would like to be able to
plug this sort of thing into the framework more easily than at present.

Cheers,

David


-- 
Dr. David McG. Squire, Senior Lecturer. On sabbatical in 2006.
Caulfield School of Information Technology, Monash University, Australia
CRICOS Provider No. 00008C       http://www.csse.monash.edu.au/~davids/