[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] Optimizing

From: risc
Subject: Re: [help-GIFT] Optimizing
Date: Thu, 17 Aug 2006 16:37:29 -0500
User-agent: Mutt/1.4.1i

I don't find the branch idea to be a great one, because what appears to be 
already happening is everyone is using their own branches, and the one in the 
tree, which is the one that people new to the project will use, is being left 
to rot. David's criticism of that optimization is valid, I'll be adding a 
MAX_WIDTH and MAX_HEIGHT, so that both of us are satisfied. All of my 
allocation changes are already in tree, and this one is the only one that we 
both agree was a "badly implemented idea". David's right to call me on it. 
thats why we put the "mail-patches" policy in place, right?

The reason i haven't jumped on your idea, is I didn't find it very unixy at 
all, first read through. To me, interprocess communication UNIX-style is done 
by chaining lots of pipes together. and what you're talking about sounded more 
bi-directional than the normal UNIX softwares. XML and unixy don't quite go 
hand-in-hand, but now that i re-read your mail, i agree that something along 
the described lines would certainly be better than what we have.

I agree the feature extractor should be working in lists, but I've been 
avoiding structural changes, so as to get something in the tree everyone can 
agree on.
In an ideal world, the command line arguments, and the input streams for the 
feature extractor, the re-sizer, and the thumb-nailer should be close to 

If its desired, once I'm done putting in my optimizations to the feature 
extractor, instead of increasing the feature extractor's resolution, I'll work 
on a re-sizer and a thumb-nailer, and re-build the front-end to the feature 
extractor along these lines.

Technically, its working against my own interests (all my images are way bigger 
than 256x256), but it'll possibly be of more use to others, and I am new here, 
so. ;)

that said, how goes the 64bit work? I've got an associate who'd love to play 
with gift, but cannot, due to 64bit problems...

anyone have any comments on my 70-* and 80-* optimizations? 80 is the real 
brain twister.

Julia Longtin <address@hidden>

On Thu, Aug 17, 2006 at 09:36:00PM +0200, address@hidden wrote:
> Hi,
> Just very shortly: I did not read the whole discussion I do see both sides a 
> bit and I find the branch idea not bad. Even better I would find if someone 
> would look at and hack it in the way I suggested 
> some while back (having a feature extraction server doing pipe-based IPC with 
> a perl script feeding it image lists). I think this would give *much* more 
> than a factor of two in speed, and probably some of the nastier optimisations 
> in question would get at least partly obsolete, as allocation would take only 
> at the beginning of the FE process.
> Julia and others, for testing this would mean that you come up with a file 
> format for lists of filenames (e.g. one file, one line, or something 
> XML-based) and then extract features for all files in the list. Equally 
> welcome would be a resizer and a thumbnailer that would work in a similar 
> fashion. So we would get something quite gnunixy, small tools doing IPC and 
> working together.
> Any comments?
> Cheers,
> Wolfgang
> P.S. I will be even less online starting tomorrow evening (latest).
> _______________________________________________
> help-GIFT mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]