RasterLayer::readFilterBuffer

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RasterLayer::readFilterBuffer

Tim Harris-4
I've just upgraded to Opticks 4.2.0 and I noticed some of our code that uses RasterLayer::readFilterBuffer has stopped working. I'm calling this method on a layer that should just be grayscale. I get back twice as many pixels as I ask for, and it looks like every other one might be an alpha value. My data is unsigned short, and every other value that I get back is 65535. I see that GpuImage.cpp has changed recently to use GL_LUMINANCE_ALPHA instead of GL_LUMINANCE. Is there anything I can do to just get back the image data without the alpha values?

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RasterLayer::readFilterBuffer

Johnson, Todd

The change to GL_LUMINANCE_ALPHA was necessary to fix a crash. You are correct that the data is interleaved data, alpha, data, alpha, etc. You will need to strip out the alpha values from the return.

 

Note that I have submitted a Severity-1 bug report against this feature as OPTICKS-176.

Todd Johnson
Ball Aerospace
937-320-4190


From: Harris, Timothy R. [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 2:45 PM
To: [hidden email]
Subject: RasterLayer::readFilterBuffer

 

I've just upgraded to Opticks 4.2.0 and I noticed some of our code that uses RasterLayer::readFilterBuffer has stopped working. I'm calling this method on a layer that should just be grayscale. I get back twice as many pixels as I ask for, and it looks like every other one might be an alpha value. My data is unsigned short, and every other value that I get back is 65535. I see that GpuImage.cpp has changed recently to use GL_LUMINANCE_ALPHA instead of GL_LUMINANCE. Is there anything I can do to just get back the image data without the alpha values?


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RasterLayer::readFilterBuffer

John Prikkel

So we aren’t running the GPU-based unit tests? How can we make sure this happens in the future?

 

Thanks

John

 


From: Johnson, Todd [mailto:[hidden email]]
Sent: Wednesday, June 25, 2008 8:41 AM
To: [hidden email]
Subject: RE: RasterLayer::readFilterBuffer

 

The change to GL_LUMINANCE_ALPHA was necessary to fix a crash. You are correct that the data is interleaved data, alpha, data, alpha, etc. You will need to strip out the alpha values from the return.

 

Note that I have submitted a Severity-1 bug report against this feature as OPTICKS-176.

Todd Johnson
Ball Aerospace
937-320-4190


From: Harris, Timothy R. [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 2:45 PM
To: [hidden email]
Subject: RasterLayer::readFilterBuffer

 

I've just upgraded to Opticks 4.2.0 and I noticed some of our code that uses RasterLayer::readFilterBuffer has stopped working. I'm calling this method on a layer that should just be grayscale. I get back twice as many pixels as I ask for, and it looks like every other one might be an alpha value. My data is unsigned short, and every other value that I get back is 65535. I see that GpuImage.cpp has changed recently to use GL_LUMINANCE_ALPHA instead of GL_LUMINANCE. Is there anything I can do to just get back the image data without the alpha values?


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RasterLayer::readFilterBuffer

Kip Streithorst
Administrator

This functional break should have at a minimum appeared in the release notes or been discussed on the mailing list.  I apologize that neither of those occurred.  The tests to which John refers to are currently closed-source unit tests for Opticks.  We eventually want to open-source those unit tests but resources are strained at the moment.  To answer John’s question, there is no unit test written that tests RasterLayer::readFilterBuffer() and this was no doubt part of the reason that the problem wasn’t caught.

 

Thanks,

Kip

 


From: Prikkel, John [mailto:[hidden email]]
Sent: Wednesday, June 25, 2008 9:14 AM
To: [hidden email]
Subject: RE: RE: RasterLayer::readFilterBuffer

 

So we aren’t running the GPU-based unit tests? How can we make sure this happens in the future?

 

Thanks

John

 


From: Johnson, Todd [mailto:[hidden email]]
Sent: Wednesday, June 25, 2008 8:41 AM
To: [hidden email]
Subject: RE: RasterLayer::readFilterBuffer

 

The change to GL_LUMINANCE_ALPHA was necessary to fix a crash. You are correct that the data is interleaved data, alpha, data, alpha, etc. You will need to strip out the alpha values from the return.

 

Note that I have submitted a Severity-1 bug report against this feature as OPTICKS-176.

Todd Johnson
Ball Aerospace
937-320-4190


From: Harris, Timothy R. [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 2:45 PM
To: [hidden email]
Subject: RasterLayer::readFilterBuffer

 

I've just upgraded to Opticks 4.2.0 and I noticed some of our code that uses RasterLayer::readFilterBuffer has stopped working. I'm calling this method on a layer that should just be grayscale. I get back twice as many pixels as I ask for, and it looks like every other one might be an alpha value. My data is unsigned short, and every other value that I get back is 65535. I see that GpuImage.cpp has changed recently to use GL_LUMINANCE_ALPHA instead of GL_LUMINANCE. Is there anything I can do to just get back the image data without the alpha values?


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

Reclipping Geographic Feature Potentially Takes Too Long

rgoffena
In reply to this post by Johnson, Todd

Has the following been noted in JIRA?

 

1) Start Application.

2) Load dataset.

3) Georeference dataset.

4) Overlay a shapefile via Geographic Features.

5) Via Windows Tab of Session Explorer, right-mouse click on layer displaying shapfile and select Properties.

6) Click on the Clipping Tab of the resulting Properties window.

7) Swap the values for East and West.  (Believe this is the problem step.)

8) Click Apply.

9) Note Application executes a lot longer to reload/redraw the shapefile again.  Hundreds/thousands of polygons are created instead of 10-20 polygons.

 

Step 9 seems more pronounced the larger the shapefile used in step4 is.

Step 9 seems more pronounced the smaller the original field of view is.

 

Using data from my project would have caused the reload/redraw to take at least 10 minutes (i terminted the application after 10 minutes).

 

 


Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email: 
[hidden email]


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: Reclipping Geographic Feature Potentially Takes Too Long

tclarke
Administrator
RE: Reclipping Geographic Feature Potentially Takes Too Long

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are you using the arc importer or the shapelib importer? If it’s the arc importer, we pass those clipping parameters directly to arcengine. I suspect it’s treating it as an invalid clip region and is thus disabling clipping and loading the entire feature set. I don’t believe there’s anything in JIRA to prevent the user from doing this but we might be able to detect this in the GUI and disallow it.



________________________________

From: Goffena, Robert [[hidden email]]
Sent: Tuesday, July 01, 2008 3:56 PM
To: [hidden email]
Subject: Reclipping Geographic Feature Potentially Takes Too Long



Has the following been noted in JIRA?



1) Start Application.

2) Load dataset.

3) Georeference dataset.

4) Overlay a shapefile via Geographic Features.

5) Via Windows Tab of Session Explorer, right-mouse click on layer displaying shapfile and select Properties.

6) Click on the Clipping Tab of the resulting Properties window.

7) Swap the values for East and West.  (Believe this is the problem step.)

8) Click Apply.

9) Note Application executes a lot longer to reload/redraw the shapefile again.  Hundreds/thousands of polygons are created instead of 10-20 polygons.



Step 9 seems more pronounced the larger the shapefile used in step4 is.

Step 9 seems more pronounced the smaller the original field of view is.



Using data from my project would have caused the reload/redraw to take at least 10 minutes (i terminted the application after 10 minutes).






Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]



This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFIapKd+xUTKUxH/LkRApNTAJ4lBE2cju8637JOmw8Z4x4+SFNeHACgvUo0
yLPrM50hL+brVwAdzAG7zDM=
=k6f9
-----END PGP SIGNATURE-----


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

PGPexch.htm (14K) Download Attachment
PGPexch.htm.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: RE: Reclipping Geographic Feature Potentially Takes Too Long

rgoffena
RE: Reclipping Geographic Feature Potentially Takes Too Long

I am using shapelib importer.  The shapefile is 45 megabytes.

 


Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email: 
[hidden email]


From: Clarke, Trevor [mailto:[hidden email]]
Sent: Tuesday, July 01, 2008 4:25 PM
To: [hidden email]
Subject: RE: Reclipping Geographic Feature Potentially Takes Too Long

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are you using the arc importer or the shapelib importer? If it’s the arc importer, we pass those clipping parameters directly to arcengine. I suspect it’s treating it as an invalid clip region and is thus disabling clipping and loading the entire feature set. I don’t believe there’s anything in JIRA to prevent the user from doing this but we might be able to detect this in the GUI and disallow it.



________________________________

From: Goffena, Robert [[hidden email]]
Sent: Tuesday, July 01, 2008 3:56 PM
To: [hidden email]
Subject: Reclipping Geographic Feature Potentially Takes Too Long



Has the following been noted in JIRA?



1) Start Application.

2) Load dataset.

3) Georeference dataset.

4) Overlay a shapefile via Geographic Features.

5) Via Windows Tab of Session Explorer, right-mouse click on layer displaying shapfile and select Properties.

6) Click on the Clipping Tab of the resulting Properties window.

7) Swap the values for East and West.  (Believe this is the problem step.)

8) Click Apply.

9) Note Application executes a lot longer to reload/redraw the shapefile again.  Hundreds/thousands of polygons are created instead of 10-20 polygons.



Step 9 seems more pronounced the larger the shapefile used in step4 is.

Step 9 seems more pronounced the smaller the original field of view is.



Using data from my project would have caused the reload/redraw to take at least 10 minutes (i terminted the application after 10 minutes).






Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]



This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFIapKd+xUTKUxH/LkRApNTAJ4lBE2cju8637JOmw8Z4x4+SFNeHACgvUo0
yLPrM50hL+brVwAdzAG7zDM=
=k6f9
-----END PGP SIGNATURE-----


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

Geographic Feature Clipping Question

rgoffena
RE: Reclipping Geographic Feature Potentially Takes Too Long

Hi all,

 

Does clipping of geographic features only work properly for orthorectified raster elements?

 

In one test, I was displaying a geographic feature over a non-orthorectified raster element, and everything seemed fine.

In a subsequent test, i tried displaying the same geographic feature over the same non-orthorectified raster element after having animated 75% of the way through the raster element's frames.  The geographic feature did not clip to the scene correctly for the subsequenttest.  The raster element in question is georeferenced per frame.

 

I think FeatureClass::getClipping method is potentially responsible for this behavior.


Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email: 
[hidden email]


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: Reclipping Geographic Feature Potentially Takes Too Long

tclarke
Administrator
In reply to this post by rgoffena
RE: Reclipping Geographic Feature Potentially Takes Too Long

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We do clipping with QRectF.contains() in the shapelib importer. I suspect it will return false of the left and right clip points are reversed. Again, we could do a check somewhere to fix this but AFAIK we don’t have a bug submitted for this problem.



________________________________

From: Goffena, Robert [[hidden email]]
Sent: Tuesday, July 01, 2008 4:32 PM
To: [hidden email]
Subject: RE: RE: Reclipping Geographic Feature Potentially Takes Too Long



I am using shapelib importer.  The shapefile is 45 megabytes.




Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]

________________________________

From: Clarke, Trevor [[hidden email]]
Sent: Tuesday, July 01, 2008 4:25 PM
To: [hidden email]
Subject: RE: Reclipping Geographic Feature Potentially Takes Too Long



- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are you using the arc importer or the shapelib importer? If it’s the arc importer, we pass those clipping parameters directly to arcengine. I suspect it’s treating it as an invalid clip region and is thus disabling clipping and loading the entire feature set. I don’t believe there’s anything in JIRA to prevent the user from doing this but we might be able to detect this in the GUI and disallow it.



________________________________

From: Goffena, Robert [[hidden email]]
Sent: Tuesday, July 01, 2008 3:56 PM
To: [hidden email]
Subject: Reclipping Geographic Feature Potentially Takes Too Long



Has the following been noted in JIRA?



1) Start Application.

2) Load dataset.

3) Georeference dataset.

4) Overlay a shapefile via Geographic Features.

5) Via Windows Tab of Session Explorer, right-mouse click on layer displaying shapfile and select Properties.

6) Click on the Clipping Tab of the resulting Properties window.

7) Swap the values for East and West.  (Believe this is the problem step.)

8) Click Apply.

9) Note Application executes a lot longer to reload/redraw the shapefile again.  Hundreds/thousands of polygons are created instead of 10-20 polygons.



Step 9 seems more pronounced the larger the shapefile used in step4 is.

Step 9 seems more pronounced the smaller the original field of view is.



Using data from my project would have caused the reload/redraw to take at least 10 minutes (i terminted the application after 10 minutes).






Robert Goffena
Ball Aerospace & Technologies Corp.
2875 Presidential Dr.

Fairborn, OH 45324-6269
Phone:  (937) 320-4096
Fax:  (937) 429-1687
Email:  [hidden email]



This message and any enclosures are intended only for the addressee.  Please
notify the sender by email if you are not the intended recipient.  If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful.  Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please
notify the sender by email if you are not the intended recipient.  If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful.  Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please
notify the sender by email if you are not the intended recipient.  If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful.  Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFIapKd+xUTKUxH/LkRApNTAJ4lBE2cju8637JOmw8Z4x4+SFNeHACgvUo0
yLPrM50hL+brVwAdzAG7zDM=
=k6f9
- -----END PGP SIGNATURE-----



This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFIa4o7+xUTKUxH/LkRAngsAJ97W3JBRsgouiAr/T+hBEP8+5BXUwCfS69X
wqIBX3vvyfN0FFGht0PbpME=
=o0Yo
-----END PGP SIGNATURE-----


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

PGPexch.htm (16K) Download Attachment
PGPexch.htm.asc (270 bytes) Download Attachment