| Newsgroups |
gmane.comp.gnu.gift.general |
| Message-ID |
<[email protected]> |
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]>