Re: GIFT does not find a query image relevant to itself when returning results.

--0016e64bde32110cfe04899d4ada
Content-Type: multipart/alternative; boundary=0016e64bde32110cf704899d4ad8

--0016e64bde32110cf704899d4ad8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Henning,
I've used the config file you emailed me. I just ran a comparison using you=
r
configuration without change ( I changed the collection configs, but not th=
e
algorithm config ).

I can confirm that the behaviour is different between the version of gift I
had checked out from cvs and gift-0.1.14.

I have a total of 1670 images in my collection. Of them, in the cvs
version,  282 images return a different image than itself when used as the
query. In gift-0.1.14, all the images are the first in the results list. Th=
e
config file used is identical in both cases and I am attaching it just in
case you want to have a look.

Let me know if I should be doing something else.

Thank you
Nabeel


On 21 June 2010 17:11, Henning M=FCller <[email protected]> wrot=
e:

> Hi Nabeel,
>
> this sounds indeed a bit weird, particularly that there are clear
> differences between the two versions!
> In principle it can happen well that two images have no features in commo=
n
> and then the number of retrieved images will not be the size of the
> collection. This can particularly happen if you only use texture.
>
> Which weighting do you use? Do you use the standard configuration file?
>
> Cheers, Henning
>
> Nabeel Mohammed (Infotech) wrote:
>
>> Hello,
>> I am trying to use GIFT for the research work associated with my PhD. I
>> had checked out the latest version from cvs to do my work and ran into a
>> problem.
>>
>> I have an algorithm configured in my gift-config.mrml which uses just th=
e
>> global texture features ( extracted using the bank of 12 Gabor filters )=
. I
>> was getting odd results from my test scripts. Looking into the problem a=
 bit
>> more I realised that when I am querying with a single query image, the f=
irst
>> image returned (the most relevant) in the results is not the image itsel=
f.
>>  Infact the top relevant image seems to have a relevance of less than 1.=
 I
>> have a total of 1670 images in my collection ( a modified version of the
>> VisTex database ), and this happens for 368 of them (I wrote a script to=
 go
>> through and do the sanity  check for every single image). My supervisor =
(
>> Dr. David Squire) had .fts files for the same collection, and using them
>> also did not alter the behaviour ( I regenerated the inverted files).
>>
>> There is another issue where when for a query image I ask for 1670
>> results, for some images I don't always get back all 1670 (  about 1300 =
or
>> so is returned). I can see how it may happen
>> theoretically, but it seemed odd to me.
>>
>> My environments are Ubuntu 9.10 running on Virtual Box on a windows
>> machine and a Mac. Both installations show the same issue.When installin=
g
>> the pre-requisites I used the latest version of the Ubuntu packages for =
my
>> version of Ubuntu, instead of using the version numbers mentioned in the
>> readme file. Overall the compilation and installation was relatively
>> painless.
>>
>> On the advice of David, I downloaded gift-0.1.14 and tried to compile it
>> on my environment. After a few changes I had it up and running. Using th=
e
>> old collections still gave me the odd results.
>> However, when I added a new collection using the same images using
>> gift-add-collection.pl <http://gift-add-collection.pl>, the insane
>> behaviour went away for the new collection. Also gift-0.1.14 behaves san=
ely
>> when I use the .fts files given to my by David and regenerate the invert=
ed
>> files.
>>
>>
>> Also, for each image, gift-0.1.14 always returns all 1670 images, when I
>> ask for that result size.
>>
>>
>> I've noticed that the code used to generate the Gabor features have
>> markedly changed in the cvs version since gift-0.1.14. I am not entirely
>> sure the two versions generate the same .fts files (I can check, but hav=
en't
>> done so yet!). I think there is a problem in the inverted file generatio=
n
>> which causes gift to behave in such a way, but thats my guess. I am
>> wonderring if anyone knows of this problem,
>> or has checked for it or knows how to solve it? If it is something I am
>> doing wrong, then I am hoping someone can tell me how to fix it.
>>
>> Thank you
>> Nabeel
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> bug-GIFT mailing list
>> [email protected]
>> http://lists.gnu.org/mailman/listinfo/bug-gift
>>
>

--0016e64bde32110cf704899d4ad8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Henning,<br>I&#39;ve used the config file you emailed me. I just ran =
a comparison using your configuration without change ( I changed the collec=
tion configs, but not the algorithm config ).<br><br>I can confirm that the=
 behaviour is different between the version of gift I had checked out from =
cvs and gift-0.1.14.<br>
<br>I have a total of 1670 images in my collection. Of them, in the cvs ver=
sion,=A0 282 images return a different image than itself when used as the q=
uery. In gift-0.1.14, all the images are the first in the results list. The=
 config file used is identical in both cases and I am attaching it just in =
case you want to have a look.<br>
<br>Let me know if I should be doing something else.<br><br>Thank you<br>Na=
beel<br><br><br><div class=3D"gmail_quote">On 21 June 2010 17:11, Henning M=
=FCller <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]=
h" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nabeel,<br>
<br>
this sounds indeed a bit weird, particularly that there are clear differenc=
es between the two versions!<br>
In principle it can happen well that two images have no features in common =
and then the number of retrieved images will not be the size of the collect=
ion. This can particularly happen if you only use texture.<br>
<br>
Which weighting do you use? Do you use the standard configuration file?<br>
<br>
Cheers, Henning<br>
<br>
Nabeel Mohammed (Infotech) wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
Hello,<br>
I am trying to use GIFT for the research work associated with my PhD. I had=
 checked out the latest version from cvs to do my work and ran into a probl=
em.<br>
<br>
I have an algorithm configured in my gift-config.mrml which uses just the g=
lobal texture features ( extracted using the bank of 12 Gabor filters ). I =
was getting odd results from my test scripts. Looking into the problem a bi=
t more I realised that when I am querying with a single query image, the fi=
rst image returned (the most relevant) in the results is not the image itse=
lf. =A0Infact the top relevant image seems to have a relevance of less than=
 1. I have a total of 1670 images in my collection ( a modified version of =
the VisTex database ), and this happens for 368 of them (I wrote a script t=
o go through and do the sanity =A0check for every single image). My supervi=
sor ( Dr. David Squire) had .fts files for the same collection, and using t=
hem also did not alter the behaviour ( I regenerated the inverted files).<b=
r>


<br>
There is another issue where when for a query image I ask for 1670 results,=
 for some images I don&#39;t always get back all 1670 ( =A0about 1300 or so=
 is returned). I can see how it may happen<br>
theoretically, but it seemed odd to me.<br>
<br>
My environments are Ubuntu 9.10 running on Virtual Box on a windows machine=
 and a Mac. Both installations show the same issue.When installing the pre-=
requisites I used the latest version of the Ubuntu packages for my version =
of Ubuntu, instead of using the version numbers mentioned in the readme fil=
e. Overall the compilation and installation was relatively painless.<br>


<br>
On the advice of David, I downloaded gift-0.1.14 and tried to compile it on=
 my environment. After a few changes I had it up and running. Using the old=
 collections still gave me the odd results.<br></div>
However, when I added a new collection using the same images using <a href=
=3D"http://gift-add-collection.pl" target=3D"_blank">gift-add-collection.pl=
</a> &lt;<a href=3D"http://gift-add-collection.pl" target=3D"_blank">http:/=
/gift-add-collection.pl</a>&gt;, the insane behaviour went away for the new=
 collection. Also gift-0.1.14 behaves sanely when I use the .fts files give=
n to my by David and regenerate the inverted files.<div>

<br>
<br>
Also, for each image, gift-0.1.14 always returns all 1670 images, when I as=
k for that result size.<br>
<br>
<br>
I&#39;ve noticed that the code used to generate the Gabor features have mar=
kedly changed in the cvs version since gift-0.1.14. I am not entirely sure =
the two versions generate the same .fts files (I can check, but haven&#39;t=
 done so yet!). I think there is a problem in the inverted file generation =
which causes gift to behave in such a way, but thats my guess. I am wonderr=
ing if anyone knows of this problem,<br>


or has checked for it or knows how to solve it? If it is something I am doi=
ng wrong, then I am hoping someone can tell me how to fix it.<br>
<br>
Thank you<br>
Nabeel<br>
<br>
<br></div>
------------------------------------------------------------------------<br=
>
<br>
_______________________________________________<br>
bug-GIFT mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><=
br>
<a href=3D"http://lists.gnu.org/mailman/listinfo/bug-gift" target=3D"_blank=
">http://lists.gnu.org/mailman/listinfo/bug-gift</a><br>
</blockquote>
</blockquote></div><br>

--0016e64bde32110cf704899d4ad8--
--0016e64bde32110cfe04899d4ada
Content-Type: text/x-mrml; charset=US-ASCII; name="gift-config.mrml"
Content-Disposition: attachment; filename="gift-config.mrml"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gaqov14n0

PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8IURPQ1RZUEUgbXJtbCBTWVNU
RU0gImZpbGU6L3Vzci9sb2NhbC9zaGFyZS9tcm1sLmR0ZCI+CjwhLS0gVGhpcyBmaWxlIGhhcyBi
ZWNvbWUgcXVpdGUgYSBmcmVlIGludGVycHJldGF0aW9uIG9mIE1STUwgCiAgICAgdGhlIGFib3Zl
ICFET0NUWVBFIGlzIHJhdGhlciBmb3IgdGhlIHVzZSBvZiBwc2dtbCB0aGFuCiAgICAgYSBwcm9t
aXNlIHRoYXQgdGhlIGZvbGxvd2luZyBpcyBwdXJlIE1STUwuIEluIGZhY3QgdGhlCiAgICAgcGFy
c2VyIGRvZXMgbm90IHZhbGlkYXRlLgoKVGhpcyBpcyBhIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3Ig
dGhlIHNlcnZlci4gSXQgY29udGFpbnMKaW5mb3JtYXRpb24gYWJvdXQgY29sbGVjdGlvbnMsIGFs
Z29yaXRobXMgYW5kCnByb3BlcnR5IHNoZWV0cy4KCgpUSElTIEZJTEUgTkVFRFMgQ0xFQU5JTkcu
IEFCT1VUIEhBTEYgT0YgVEhFIExJTkVTIEhFUkUgQVJFCkxFR0FDWSBDT0RFLiBIT1dFVkVSLCBJ
VCBJUyBOT1QgWUVUIFRFU1RFRCBIT1cgVEhJTkdTIEJFSEFWRQpXSEVOIFlPVSBSRU1PVkUgVEhF
IExFR0FDWSBDT0RFLiBTTywgRk9SIEEgV0hJTEUgWU9VIEhBVkUKVE8gTElWRSBXSVRIIFFVSVRF
IEEgTlVNQkVSIE9GIE9CU09MRVRFIFRBR1MuCgotLT4KPG1ybWw+CiAgPGN1aS1jb25maWd1cmF0
aW9uPgogICAgPGFsZ29yaXRobS1saXN0PgogICAgPCEtLUNPTU1FTlQgVGhlIG5ldyBkZWZpbml0
b24gb2YgdGhlIGRlZmF1bHQgYWxnb3JpdGhtCiAgICAgICAgICAgICAgICBUaGUgZGVmYXVsdCBh
bGdvcml0aG0gcGVyZm9ybXMgaW4gZmFjdCBhIG1ldGEKICAgICAgICAgICAgICAgIHF1ZXJ5IG9m
IHNldmVyYWwgaW52ZXJ0ZWQgZmlsZSBxdWVyaWVzLgogICAgICAgICAgICAgICAgRWFjaCBzdWIt
cXVlcnkgb2YgdGhlIG1ldGEgcXVlcnkgaXMKICAgICAgICAgICAgICAgIHNwZWNpYWxpc2VkIG9u
IG9uZSBvZiB0aGUgZmVhdHVyZSBncm91cHMgCgogICAgICAgICAgICAgICAgQ29sb3IgaGlzdG9n
cmFtCiAgICAgICAgICAgICAgICBDb2xvciBibG9jawogICAgICAgICAgICAgICAgR2Fib3IgaGlz
dG9ncmFtCiAgICAgICAgICAgICAgICBHYWJvciBibG9jawoKICAgICAgICAgICAgICAgIEVhY2gg
b25lIG9mIHRoZW0gaXMgcHJ1bmVkIGluIGFkaWZmZXJlbnQgd2F5LgogICAgICAgICAgICAgICAg
KHRoaXMgaXMgdGhlIGdvYWwgb2YgdGhlIG9wZXJhdGlvbikKICAgICAgLS0+CiAgICAgIDxhbGdv
cml0aG0gYWxnb3JpdGhtLWlkPSJhZGVmYXVsdCIgYWxnb3JpdGhtLXR5cGU9ImFkZWZhdWx0IiBh
bGdvcml0aG0tbmFtZT0iU2VwYXJhdGUgTm9ybWFsaXNhdGlvbiIgY29sbGVjdGlvbi1pZD0iYy0z
MC0yMy0xMS0yNS0zLTExMC0wLTExNC0wIiBjdWktYmxvY2stY29sb3ItaGlzdG9ncmFtPSJubyIg
Y3VpLWJsb2NrLWNvbG9yLWJsb2Nrcz0ibm8iIGN1aS1ibG9jay10ZXh0dXJlLWhpc3RvZ3JhbT0i
bm8iIGN1aS1ibG9jay10ZXh0dXJlLWJsb2Nrcz0ibm8iIGN1aS1wci1wZXJjZW50YWdlLW9mLWZl
YXR1cmVzPSI3MCIgY3VpLWJhc2UtdHlwZT0ibXVsdGlwbGUiIGN1aS13ZWlnaHRpbmctZnVuY3Rp
b249IkNsYXNzaWNhbElERiI+CiAgICAgIDxhbGdvcml0aG0gYWxnb3JpdGhtLWlkPSJzdWIxIiBh
bGdvcml0aG0tdHlwZT0ic3ViMSIgYWxnb3JpdGhtLW5hbWU9InN1YjEiIGN1aS1ibG9jay1jb2xv
ci1ibG9ja3M9InllcyIgY3VpLWJsb2NrLXRleHR1cmUtaGlzdG9ncmFtPSJ5ZXMiIGN1aS1ibG9j
ay10ZXh0dXJlLWJsb2Nrcz0ieWVzIiBjdWktcHItcGVyY2VudGFnZS1vZi1mZWF0dXJlcz0iMTAw
IiBjdWktYmFzZS10eXBlPSJpbnZlcnRlZF9maWxlIi8+CiAgICAgIDxhbGdvcml0aG0gYWxnb3Jp
dGhtLWlkPSJzdWIyIiBhbGdvcml0aG0tdHlwZT0ic3ViMiIgYWxnb3JpdGhtLW5hbWU9InN1YjIi
IGN1aS1ibG9jay1jb2xvci1oaXN0b2dyYW09InllcyIgY3VpLWJsb2NrLXRleHR1cmUtaGlzdG9n
cmFtPSJ5ZXMiIGN1aS1ibG9jay10ZXh0dXJlLWJsb2Nrcz0ieWVzIiBjdWktYmFzZS10eXBlPSJp
bnZlcnRlZF9maWxlIi8+CiAgICAgIDxhbGdvcml0aG0gYWxnb3JpdGhtLWlkPSJzdWIzIiBhbGdv
cml0aG0tdHlwZT0ic3ViMyIgYWxnb3JpdGhtLW5hbWU9InN1YjMiIGN1aS1ibG9jay1jb2xvci1o
aXN0b2dyYW09InllcyIgY3VpLWJsb2NrLWNvbG9yLWJsb2Nrcz0ieWVzIiBjdWktYmxvY2stdGV4
dHVyZS1ibG9ja3M9InllcyIgY3VpLXByLXBlcmNlbnRhZ2Utb2YtZmVhdHVyZXM9IjEwMCIgY3Vp
LWJhc2UtdHlwZT0iaW52ZXJ0ZWRfZmlsZSIvPgogICAgICA8YWxnb3JpdGhtIGFsZ29yaXRobS1p
ZD0ic3ViNCIgYWxnb3JpdGhtLXR5cGU9InN1YjQiIGFsZ29yaXRobS1uYW1lPSJzdWI0IiBjdWkt
YmxvY2stY29sb3ItaGlzdG9ncmFtPSJ5ZXMiIGN1aS1ibG9jay1jb2xvci1ibG9ja3M9InllcyIg
Y3VpLWJsb2NrLXRleHR1cmUtaGlzdG9ncmFtPSJ5ZXMiIGN1aS1iYXNlLXR5cGU9ImludmVydGVk
X2ZpbGUiLz4KICAgICAgICA8cXVlcnktcGFyYWRpZ20tbGlzdD4KICAgICAgICAgICA8cXVlcnkt
cGFyYWRpZ20vPjwhLS0gbWF0Y2ggYW55dGhpbmcgLS0+CiAgICAgICAgPC9xdWVyeS1wYXJhZGln
bS1saXN0PgogICAgICAgIDxwcm9wZXJ0eS1zaGVldCBwcm9wZXJ0eS1zaGVldC1pZD0iY3VpLXAt
MSIgcHJvcGVydHktc2hlZXQtdHlwZT0ic3Vic2V0IiBzZW5kLXR5cGU9Im5vbmUiIG1pbnN1YnNl
dHNpemU9IjAiIG1heHN1YnNldHNpemU9IjEiPgogICAgICAgICAgPHByb3BlcnR5LXNoZWV0IHBy
b3BlcnR5LXNoZWV0LWlkPSJjdWktcDAiIGNhcHRpb249Ik1vZGlmeSBkZWZhdWx0IGNvbmZpZ3Vy
YXRpb24iIHByb3BlcnR5LXNoZWV0LXR5cGU9InNldC1lbGVtZW50IiBzZW5kLXR5cGU9Im5vbmUi
PgogIAkgIDxwcm9wZXJ0eS1zaGVldCBwcm9wZXJ0eS1zaGVldC1pZD0iY3VpLXAxNSIgY2FwdGlv
bj0iUHJ1bmUgYXQgJSBvZiBmZWF0dXJlcyIgcHJvcGVydHktc2hlZXQtdHlwZT0ibnVtZXJpYyIg
c2VuZC10eXBlPSJhdHRyaWJ1dGUiIHNlbmQtbmFtZT0iY3VpLXByLXBlcmNlbnRhZ2Utb2YtZmVh
dHVyZXMiIGZyb209IjIwIiB0bz0iMTAwIiBzdGVwPSI1IiBzZW5kLXZhbHVlPSI3MCIvPgogIAkg
IDxwcm9wZXJ0eS1zaGVldCBwcm9wZXJ0eS1zaGVldC1pZD0iY3VpLXAxIiBwcm9wZXJ0eS1zaGVl
dC10eXBlPSJzdWJzZXQiIHNlbmQtdHlwZT0ibm9uZSIgbWluc3Vic2V0c2l6ZT0iMSIgbWF4c3Vi
c2V0c2l6ZT0iNCI+CiAgIAkgICAgPHByb3BlcnR5LXNoZWV0IHByb3BlcnR5LXNoZWV0LWlkPSJj
dWktcDEyIiBzZW5kLWJvb2xlYW4taW52ZXJ0ZWQ9InllcyIgY2FwdGlvbj0iQ29sb3VyIGJsb2Nr
cyIgcHJvcGVydHktc2hlZXQtdHlwZT0ic2V0LWVsZW1lbnQiIHNlbmQtdHlwZT0iYXR0cmlidXRl
IiBzZW5kLW5hbWU9ImN1aS1ibG9jay1jb2xvci1ibG9ja3MiIHNlbmQtdmFsdWU9InllcyIvPgog
IAkgICAgPHByb3BlcnR5LXNoZWV0IHByb3BlcnR5LXNoZWV0LWlkPSJjdWktcDE0IiBzZW5kLWJv
b2xlYW4taW52ZXJ0ZWQ9InllcyIgY2FwdGlvbj0iR2Fib3IgYmxvY2tzIiBwcm9wZXJ0eS1zaGVl
dC10eXBlPSJzZXQtZWxlbWVudCIgc2VuZC10eXBlPSJhdHRyaWJ1dGUiIHNlbmQtbmFtZT0iY3Vp
LWJsb2NrLXRleHR1cmUtYmxvY2tzIiBzZW5kLXZhbHVlPSJ5ZXMiLz4KICAJICAgIDxwcm9wZXJ0
eS1zaGVldCBwcm9wZXJ0eS1zaGVldC1pZD0iY3VpLXAxMyIgc2VuZC1ib29sZWFuLWludmVydGVk
PSJ5ZXMiIGNhcHRpb249IkdhYm9yIGhpc3RvZ3JhbSIgcHJvcGVydHktc2hlZXQtdHlwZT0ic2V0
LWVsZW1lbnQiIHNlbmQtdHlwZT0iYXR0cmlidXRlIiBzZW5kLW5hbWU9ImN1aS1ibG9jay10ZXh0
dXJlLWhpc3RvZ3JhbSIgc2VuZC12YWx1ZT0ieWVzIi8+CiAgCSAgICA8cHJvcGVydHktc2hlZXQg
cHJvcGVydHktc2hlZXQtaWQ9ImN1aS1wMTEiIHNlbmQtYm9vbGVhbi1pbnZlcnRlZD0ieWVzIiBj
YXB0aW9uPSJDb2xvdXIgaGlzdG9ncmFtIiBwcm9wZXJ0eS1zaGVldC10eXBlPSJzZXQtZWxlbWVu
dCIgc2VuZC10eXBlPSJhdHRyaWJ1dGUiIHNlbmQtbmFtZT0iY3VpLWJsb2NrLWNvbG9yLWhpc3Rv
Z3JhbSIgc2VuZC12YWx1ZT0ieWVzIi8+CiAgICAgICAgICAgIDwvcHJvcGVydHktc2hlZXQ+CiAg
ICAgICAgICA8L3Byb3BlcnR5LXNoZWV0PgogICAgICAgIDwvcHJvcGVydHktc2hlZXQ+CiAgICAg
PC9hbGdvcml0aG0+PCEtLSBhLWNpZGYgIC0tPgogICAgPC9hbGdvcml0aG0tbGlzdD4KICAgIDxj
dWktYWxnb3JpdGhtLWlkLWxpc3QtbGlzdD4JCiAgICAgIDxjdWktYWxnb3JpdGhtLWlkLWxpc3Qg
Y3VpLWFsZ29yaXRobS1pZC1saXN0LWlkPSJhaWwtaW52ZXJ0ZWQtZmlsZSI+Cgk8Y3VpLWFsZ29y
aXRobS1pZCBjdWktYWxnb3JpdGhtLWlkPSJhLWNpZGYiLz4KICAgICAgPC9jdWktYWxnb3JpdGht
LWlkLWxpc3Q+CiAgICA8L2N1aS1hbGdvcml0aG0taWQtbGlzdC1saXN0PgkKICAgIDxjb2xsZWN0
aW9uLWxpc3QgbGlzdGlkPSIxIj4KCjwhLS0geHh5eCBnaWZ0LWFkZC1jb2xsZWN0aW9uIHh5eHgg
REVQRU5EUyBPTiBUSElTIExJTkUgLS0+Cjxjb2xsZWN0aW9uIGNvbGxlY3Rpb24taWQ9ImMtMzAt
MjMtMTEtMjUtMy0xMTAtMC0xMTQtMCIgY29sbGVjdGlvbi1uYW1lPSJWaXNUZXgiIGN1aS1hbGdv
cml0aG0taWQtbGlzdC1pZD0iYWlsLWludmVydGVkLWZpbGUiIGN1aS1udW1iZXItb2YtaW1hZ2Vz
PSIxNjcwIiBjdWktYmFzZS1kaXI9Ii9ob21lL25hYmVlbC9naWZ0LWluZGV4aW5nLWRhdGEvVmlz
VGV4LyIgY3VpLWludmVydGVkLWZpbGUtbG9jYXRpb249IkludmVydGVkRmlsZS5kYiIgY3VpLW9m
ZnNldC1maWxlLWxvY2F0aW9uPSJJbnZlcnRlZEZpbGVPZmZzZXQuZGIiIGN1aS1mZWF0dXJlLWRl
c2NyaXB0aW9uLWxvY2F0aW9uPSJJbnZlcnRlZEZpbGVGZWF0dXJlRGVzY3JpcHRpb24uZGIiIGN1
aS1mZWF0dXJlLWZpbGUtbG9jYXRpb249InVybDJmdHMueG1sIj4KICAgPHF1ZXJ5LXBhcmFkaWdt
LWxpc3Q+CiAgIDxxdWVyeS1wYXJhZGlnbSB0eXBlPSJpbnZlcnRlZC1maWxlIi8+CiAgIDxxdWVy
eS1wYXJhZGlnbSB0eXBlPSJwZXJsLWRlbW8iLz4KICAgPC9xdWVyeS1wYXJhZGlnbS1saXN0Pgog
ICA8L2NvbGxlY3Rpb24+Cgo8L2NvbGxlY3Rpb24tbGlzdD4KICA8L2N1aS1jb25maWd1cmF0aW9u
Pgo8L21ybWw+CjwhLS0gdGhpcyBpcyBmb3IgeGVtYWNzIHRvIG1ha2UgaXQgc3RhcnQgdXAgaW4g
dGhlIHJpZ2h0IG1vZGUuCiAgICAgaXQgZG9lcyB0aGUgcmlnaHQgdGhpbmcsIGJ1dCBjb21wbGFp
bnMKLS0+CjwhLS0gOzs7IExvY2FsIFZhcmlhYmxlczogKioqIC0tPgo8IS0tIDs7OyBtb2RlOiBz
Z21sICAgICAgICoqKiAtLT4K
--0016e64bde32110cfe04899d4ada
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bug-GIFT mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gift

--0016e64bde32110cfe04899d4ada--