wow. i look away for 1 sec, and all this activity. ;)
On Thu, Apr 13, 2006 at 04:45:31PM +0100, David Squire wrote: > Wolfgang Müller wrote: > > [snip] > >>It is the GIFT > >>feature extraction that *requires* the rescaling to 256x256. > >> > > > >Yes, I remember the discussion. Many things the GIFT does are due to > >decisions that seemed reasonable at the time. > Well, the original source of this decision was that the first image > collection we used it on was one from Television Suisse Romande, in > which all the images were 256x256. Rescaling to this was a hack to allow > other images to be indexed with minimal changes to the code. > >Makes me think of this article you quoted > >at the time that was about the lifetime of engineering decisions. > > > > > Are you thinking of the one ultimately linking the diameter of the Space > Shuttle's booster rockets to the width of a horse :) > > > BTW, I do think that not rescaling will cause serious problems, since > the feature extraction code is premised on 16x16 blocks at the lowest > level, and using images of different sizes will result in the same block > feature ID being used to refer to different image locations for > different images. IDs are assigned simply by counting. > > Regards, > > David having looked through the code, the real trick is that gift does multiple passes at "quarter scale". the algorithm should work the same for 256x256 (256->16->4->1) as for 1 024x1024 (1024->256->16->4->1). having said that, i've been working in that direction, but i'm still honoring the origional 256x256 resolution. plus, as i said earlier, my feature files, and the files gift "works" from in gift_home are bitwise identical. so no david, i havent broken it. just kicking arround ideas. ;) Julia Longtin <[EMAIL PROTECTED]> _______________________________________________ help-GIFT mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gift
