BitMask Changes

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

BitMask Changes

dadkins
Administrator

All –

 

I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.

 

Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.

 

Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.

 

Pros:

All existing plug-ins function exactly the same with this change

 

Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.

 

 

2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().

 

Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().

 

Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.

 

 

3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().

 

Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.

 

Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.

 

 

I favor the second solution, but further discussion and new ideas are welcome.

 

Thanks,

Dustan

 


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: BitMask Changes

tclarke
Administrator
RE: BitMask Changes

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

I like the first solution initially with another extended solution (perhaps at a later date). The problem is, when isOutsideSelected() is true, the extents are infinite…this may not be explicitly documented (it should be added if not) but that is the interpretation. The “real” extents are highly specific to the context…sometimes we can imply a context (if the AoiElement is a child of a RasterElement it may be safe to assume the RasterElement defines the extents) but this is not always the case…for example, if there are multiple raster elements with different extents, the effective extents of the AOI are different depending on while RasterElement is accessed.



I suggest changing the documentation to state that isOutsideSelected() implies no bounding box and the bounding box getters access the bounding box for the unselected portion of the AOI. The second part (again, this is probably longer term) would make it easier to use AOIs in a common use case. We would modify DataAccessorImpl (or create a second Impl with the different behavior) and allow a developer to request a DataAccessor over a RasterElement with an AOI mask. nextRow() and nextColumn() would not always increment by 1 but would move to the next active point in the AOI (or we could add nextMasked() instead). We’d also need to add methods to the DataAccessorImpl to obtain the current row/column position. (this is already tracked, there’s just no accessor for that info).



________________________________

From: Adkins, Dustan [[hidden email]]
Sent: Monday, April 07, 2008 12:09 PM
To: [hidden email]
Subject: BitMask Changes



All –



I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.



Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.



Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.



Pros:

All existing plug-ins function exactly the same with this change



Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.





2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().



Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.





3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.



Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.





I favor the second solution, but further discussion and new ideas are welcome.



Thanks,

Dustan





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)

iD8DBQFH+knc+xUTKUxH/LkRAooqAJ9Vo3ZVY/ssJzlTWU2UqyzClRqkywCeNLIl
IuaF9uq/4yA+4gTZe3uHtDE=
=MZKX
-----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 (18K) Download Attachment
PGPexch.htm.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: RE: BitMask Changes

Sulgrove, David
RE: BitMask Changes

Perhaps an alternative approach is to create a new BitMaskIterator object in the PlugInUtilities library that uses extents passed into the constructor to iterate over all selected pixels, taking the outside flag into account.  This would maintain both binary compatibility and functional compatibility.

 

David Sulgrove

Ball Aerospace & Technologies Corp.

 

 


From: Clarke, Trevor [mailto:[hidden email]]
Sent: Monday, April 07, 2008 12:21 PM
To: [hidden email]
Subject: RE: BitMask Changes

 

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

I like the first solution initially with another extended solution (perhaps at a later date). The problem is, when isOutsideSelected() is true, the extents are infinite…this may not be explicitly documented (it should be added if not) but that is the interpretation. The “real” extents are highly specific to the context…sometimes we can imply a context (if the AoiElement is a child of a RasterElement it may be safe to assume the RasterElement defines the extents) but this is not always the case…for example, if there are multiple raster elements with different extents, the effective extents of the AOI are different depending on while RasterElement is accessed.



I suggest changing the documentation to state that isOutsideSelected() implies no bounding box and the bounding box getters access the bounding box for the unselected portion of the AOI. The second part (again, this is probably longer term) would make it easier to use AOIs in a common use case. We would modify DataAccessorImpl (or create a second Impl with the different behavior) and allow a developer to request a DataAccessor over a RasterElement with an AOI mask. nextRow() and nextColumn() would not always increment by 1 but would move to the next active point in the AOI (or we could add nextMasked() instead). We’d also need to add methods to the DataAccessorImpl to obtain the current row/column position. (this is already tracked, there’s just no accessor for that info).



________________________________

From: Adkins, Dustan [[hidden email]]
Sent: Monday, April 07, 2008 12:09 PM
To: [hidden email]
Subject: BitMask Changes



All –



I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.



Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.



Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.



Pros:

All existing plug-ins function exactly the same with this change



Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.





2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().



Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.





3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.



Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.





I favor the second solution, but further discussion and new ideas are welcome.



Thanks,

Dustan





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)

iD8DBQFH+knc+xUTKUxH/LkRAooqAJ9Vo3ZVY/ssJzlTWU2UqyzClRqkywCeNLIl
IuaF9uq/4yA+4gTZe3uHtDE=
=MZKX
-----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
|

RE: RE: RE: BitMask Changes

Kip Streithorst
Administrator
RE: BitMask Changes

I like this solution provided it’s accompanied with the original solution 1, ie. update the documentation on BitMask to indicate the interpretation of getCount(), getBoundingBox() and getMinimalBoundingBox() in relation to isOutside().  This maintains binary and functional compatibility which I think are very good things to maintain at the moment. It also provides a much cleaner API (ie. BitMaskIterator) that plug-in developers can use without having to understand the nuances of BitMask.

 

Thanks,

Kip

 


From: Sulgrove, David [mailto:[hidden email]]
Sent: Monday, April 07, 2008 3:50 PM
To: [hidden email]
Subject: RE: RE: BitMask Changes

 

Perhaps an alternative approach is to create a new BitMaskIterator object in the PlugInUtilities library that uses extents passed into the constructor to iterate over all selected pixels, taking the outside flag into account.  This would maintain both binary compatibility and functional compatibility.

 

David Sulgrove

Ball Aerospace & Technologies Corp.

 

 


From: Clarke, Trevor [mailto:[hidden email]]
Sent: Monday, April 07, 2008 12:21 PM
To: [hidden email]
Subject: RE: BitMask Changes

 

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

I like the first solution initially with another extended solution (perhaps at a later date). The problem is, when isOutsideSelected() is true, the extents are infinite…this may not be explicitly documented (it should be added if not) but that is the interpretation. The “real” extents are highly specific to the context…sometimes we can imply a context (if the AoiElement is a child of a RasterElement it may be safe to assume the RasterElement defines the extents) but this is not always the case…for example, if there are multiple raster elements with different extents, the effective extents of the AOI are different depending on while RasterElement is accessed.



I suggest changing the documentation to state that isOutsideSelected() implies no bounding box and the bounding box getters access the bounding box for the unselected portion of the AOI. The second part (again, this is probably longer term) would make it easier to use AOIs in a common use case. We would modify DataAccessorImpl (or create a second Impl with the different behavior) and allow a developer to request a DataAccessor over a RasterElement with an AOI mask. nextRow() and nextColumn() would not always increment by 1 but would move to the next active point in the AOI (or we could add nextMasked() instead). We’d also need to add methods to the DataAccessorImpl to obtain the current row/column position. (this is already tracked, there’s just no accessor for that info).



________________________________

From: Adkins, Dustan [[hidden email]]
Sent: Monday, April 07, 2008 12:09 PM
To: [hidden email]
Subject: BitMask Changes



All –



I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.



Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.



Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.



Pros:

All existing plug-ins function exactly the same with this change



Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.





2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().



Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.





3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.



Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.





I favor the second solution, but further discussion and new ideas are welcome.



Thanks,

Dustan





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)

iD8DBQFH+knc+xUTKUxH/LkRAooqAJ9Vo3ZVY/ssJzlTWU2UqyzClRqkywCeNLIl
IuaF9uq/4yA+4gTZe3uHtDE=
=MZKX
-----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.

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: RE: BitMask Changes

Johnson, Todd
RE: BitMask Changes

I agree with Kip – the iterator sounds like a good approach since (in addition to maintaining binary and source compatibility) it keeps the bitmask from needing to know the extents of any other objects.

 

The bitmask itself is infinite in extent. You can query the state of any pixel and the bitmask will respond appropriately. The bitmask’s bounding box indicates its area of potential non-uniformity. The bitmask guarantees that all pixels outside the bounding box have the same value. An interesting consequence of this is that inverting a bitmask will not change the bounding box because all of the pixels outside it remain uniform. The bitmask does not guarantee that the bounding box is minimal nor that the pixels inside the bounding box are non-uniform.

 

-Todd

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, April 07, 2008 3:55 PM
To: [hidden email]
Subject: RE: RE: RE: BitMask Changes

 

I like this solution provided it’s accompanied with the original solution 1, ie. update the documentation on BitMask to indicate the interpretation of getCount(), getBoundingBox() and getMinimalBoundingBox() in relation to isOutside().  This maintains binary and functional compatibility which I think are very good things to maintain at the moment. It also provides a much cleaner API (ie. BitMaskIterator) that plug-in developers can use without having to understand the nuances of BitMask.

 

Thanks,

Kip

 


From: Sulgrove, David [mailto:[hidden email]]
Sent: Monday, April 07, 2008 3:50 PM
To: [hidden email]
Subject: RE: RE: BitMask Changes

 

Perhaps an alternative approach is to create a new BitMaskIterator object in the PlugInUtilities library that uses extents passed into the constructor to iterate over all selected pixels, taking the outside flag into account.  This would maintain both binary compatibility and functional compatibility.

 

David Sulgrove

Ball Aerospace & Technologies Corp.

 

 


From: Clarke, Trevor [mailto:[hidden email]]
Sent: Monday, April 07, 2008 12:21 PM
To: [hidden email]
Subject: RE: BitMask Changes

 

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

I like the first solution initially with another extended solution (perhaps at a later date). The problem is, when isOutsideSelected() is true, the extents are infinite…this may not be explicitly documented (it should be added if not) but that is the interpretation. The “real” extents are highly specific to the context…sometimes we can imply a context (if the AoiElement is a child of a RasterElement it may be safe to assume the RasterElement defines the extents) but this is not always the case…for example, if there are multiple raster elements with different extents, the effective extents of the AOI are different depending on while RasterElement is accessed.



I suggest changing the documentation to state that isOutsideSelected() implies no bounding box and the bounding box getters access the bounding box for the unselected portion of the AOI. The second part (again, this is probably longer term) would make it easier to use AOIs in a common use case. We would modify DataAccessorImpl (or create a second Impl with the different behavior) and allow a developer to request a DataAccessor over a RasterElement with an AOI mask. nextRow() and nextColumn() would not always increment by 1 but would move to the next active point in the AOI (or we could add nextMasked() instead). We’d also need to add methods to the DataAccessorImpl to obtain the current row/column position. (this is already tracked, there’s just no accessor for that info).



________________________________

From: Adkins, Dustan [[hidden email]]
Sent: Monday, April 07, 2008 12:09 PM
To: [hidden email]
Subject: BitMask Changes



All –



I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.



Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.



Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.



Pros:

All existing plug-ins function exactly the same with this change



Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.





2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().



Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.





3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.



Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.





I favor the second solution, but further discussion and new ideas are welcome.



Thanks,

Dustan





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)

iD8DBQFH+knc+xUTKUxH/LkRAooqAJ9Vo3ZVY/ssJzlTWU2UqyzClRqkywCeNLIl
IuaF9uq/4yA+4gTZe3uHtDE=
=MZKX
-----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.

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: RE: RE: BitMask Changes

dadkins
Administrator
RE: BitMask Changes

It seems like everyone agrees on the BitMaskIterator solution, so this is what I will implement unless someone voices discontent in the next day or so.

 

--Dustan

 


From: Johnson, Todd [mailto:[hidden email]]
Sent: Monday, April 07, 2008 4:27 PM
To: [hidden email]
Subject: RE: RE: RE: RE: BitMask Changes

 

I agree with Kip – the iterator sounds like a good approach since (in addition to maintaining binary and source compatibility) it keeps the bitmask from needing to know the extents of any other objects.

 

The bitmask itself is infinite in extent. You can query the state of any pixel and the bitmask will respond appropriately. The bitmask’s bounding box indicates its area of potential non-uniformity. The bitmask guarantees that all pixels outside the bounding box have the same value. An interesting consequence of this is that inverting a bitmask will not change the bounding box because all of the pixels outside it remain uniform. The bitmask does not guarantee that the bounding box is minimal nor that the pixels inside the bounding box are non-uniform.

 

-Todd

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, April 07, 2008 3:55 PM
To: [hidden email]
Subject: RE: RE: RE: BitMask Changes

 

I like this solution provided it’s accompanied with the original solution 1, ie. update the documentation on BitMask to indicate the interpretation of getCount(), getBoundingBox() and getMinimalBoundingBox() in relation to isOutside().  This maintains binary and functional compatibility which I think are very good things to maintain at the moment. It also provides a much cleaner API (ie. BitMaskIterator) that plug-in developers can use without having to understand the nuances of BitMask.

 

Thanks,

Kip

 


From: Sulgrove, David [mailto:[hidden email]]
Sent: Monday, April 07, 2008 3:50 PM
To: [hidden email]
Subject: RE: RE: BitMask Changes

 

Perhaps an alternative approach is to create a new BitMaskIterator object in the PlugInUtilities library that uses extents passed into the constructor to iterate over all selected pixels, taking the outside flag into account.  This would maintain both binary compatibility and functional compatibility.

 

David Sulgrove

Ball Aerospace & Technologies Corp.

 

 


From: Clarke, Trevor [mailto:[hidden email]]
Sent: Monday, April 07, 2008 12:21 PM
To: [hidden email]
Subject: RE: BitMask Changes

 

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

I like the first solution initially with another extended solution (perhaps at a later date). The problem is, when isOutsideSelected() is true, the extents are infinite…this may not be explicitly documented (it should be added if not) but that is the interpretation. The “real” extents are highly specific to the context…sometimes we can imply a context (if the AoiElement is a child of a RasterElement it may be safe to assume the RasterElement defines the extents) but this is not always the case…for example, if there are multiple raster elements with different extents, the effective extents of the AOI are different depending on while RasterElement is accessed.



I suggest changing the documentation to state that isOutsideSelected() implies no bounding box and the bounding box getters access the bounding box for the unselected portion of the AOI. The second part (again, this is probably longer term) would make it easier to use AOIs in a common use case. We would modify DataAccessorImpl (or create a second Impl with the different behavior) and allow a developer to request a DataAccessor over a RasterElement with an AOI mask. nextRow() and nextColumn() would not always increment by 1 but would move to the next active point in the AOI (or we could add nextMasked() instead). We’d also need to add methods to the DataAccessorImpl to obtain the current row/column position. (this is already tracked, there’s just no accessor for that info).



________________________________

From: Adkins, Dustan [[hidden email]]
Sent: Monday, April 07, 2008 12:09 PM
To: [hidden email]
Subject: BitMask Changes



All –



I am considering making some modifications to the BitMask class and would like to elicit input from the community. The current documentation of the BitMask object causes some confusion in that certain methods (getCount(), getBoundingBox(), getMinimalBoundingBox(), and isOutside()) are tied to implementation details of the BitMask class which are not obvious.



Problem:

The problem occurs when the user toggles all pixels within a BitMask (for example, toggling an AOI via the AOI Toolbar’s “Toggle All” button). Toggling the BitMask sets a flag (queried by calling isOutsideSelected()) which indicates whether pixels outside of the bounding box (queried by calling getBoundingBox() or getMinimalBoundingBox()) should be marked as selected. Since the BitMask class has no way to track extents, the bounding box returned should not be used to iterate over an AOI and the number of selected pixels (queried by calling getCount()) is incorrect whenever the isOutsideSelected() method returns true.



Proposed Solutions:

1) Update the BitMask documentation to indicate that getBoundingBox(), getMinimalBoundingBox(), and getCount() should only be used when the isOutsideSelected() method returns false.



Pros:

All existing plug-ins function exactly the same with this change



Cons:

All plug-ins developers wishing to correctly determine which pixels are selected in a BitMask need to read the updated documentation and implement this functionality correctly.





2) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have two new methods: getExtents() and setExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-ins currently calling AoiElement::getSelectedPixels() followed by BitMask’s getBoundingBox(), getMinimalBoundingBox(), and getCount() methods work properly without being rebuilt regardless of the return value of isOutsideSelected().



Cons:

The functionality of getBoundingBox(), getMinimalBoundingBox(), and getCount() changes.

Plug-ins relying on the current undocumented behavior of these methods perform differently.





3) Create an extension class to BitMask, BitMaskExt1. The BitMaskExt1 class would have five new methods: getExtents(), setExtents(), getBoundingBoxWithExtents(), getMinimalBoundingBoxWithExtents(), and getCountWithExtents().



Pros:

These new methods add the necessary functionality to track extents.

Plug-in functionality remains unchanged.



Cons:

All plug-ins wanting to correctly iterate over a BitMask would need to perform a dynamic_cast on a BitMask to BitMaskExt1 to call the new methods.

BitMask’s existing getBoundingBox(), getMinimalBoundingBox(), and getCount() methods become deprecated and (eventually) removed.





I favor the second solution, but further discussion and new ideas are welcome.



Thanks,

Dustan





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)

iD8DBQFH+knc+xUTKUxH/LkRAooqAJ9Vo3ZVY/ssJzlTWU2UqyzClRqkywCeNLIl
IuaF9uq/4yA+4gTZe3uHtDE=
=MZKX
-----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.

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
|

<Ctrl>+w Closes Spatial Data Window

rgoffena
RE: BitMask Changes

When I click <Ctrl>+w, Opticks closes the active spatial data window.  Product windows can also be closed by clicking <Ctrl>+w.  I could not find any other Opticks windows (ie: dock windows, Wizard Builder) that close by clicking <Ctrl>+w.

 

Google searched the topic:

http://doc.trolltech.com/qtjambi-4.3.2_01/com/trolltech/qt/qkeysequence.html

 

Should the product views and spatial data views close by clicking <Ctrl>+w?  If so, should the other windows close by clicking <Ctrl>+w?

 

Something else to think about: If an analyst has the Confirm On Close configuration setting set to false, and accidentally clicks <Ctrl>+w, the analyst will lose work.

 


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.

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: <Ctrl>+w Closes Spatial Data Window

tclarke
Administrator
RE: <Ctrl>+w Closes Spatial Data Window

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

This is consistent with most windows applications. SDW and PW are MDI windows, dock windows behavior differently by design as they are not generally closed but hidden.



________________________________

From: Goffena, Robert [[hidden email]]
Sent: Friday, April 11, 2008 11:03 AM
To: [hidden email]
Subject: <Ctrl>+w Closes Spatial Data Window



When I click <Ctrl>+w, Opticks closes the active spatial data window.  Product windows can also be closed by clicking <Ctrl>+w.  I could not find any other Opticks windows (ie: dock windows, Wizard Builder) that close by clicking <Ctrl>+w.



Google searched the topic:

http://doc.trolltech.com/qtjambi-4.3.2_01/com/trolltech/qt/qkeysequence.html <http://doc.trolltech.com/qtjambi-4.3.2_01/com/trolltech/qt/qkeysequence.html>



Should the product views and spatial data views close by clicking <Ctrl>+w?  If so, should the other windows close by clicking <Ctrl>+w?



Something else to think about: If an analyst has the Confirm On Close configuration setting set to false, and accidentally clicks <Ctrl>+w, the analyst will lose work.




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.


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)

iD8DBQFH/35j+xUTKUxH/LkRAqDoAJ9kIdl8fEA0fnP/3Cna0gTHujdhxwCg0717
/JL3gf0probdmdQFcas0ZU0=
=vtbu
-----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 (13K) Download Attachment
PGPexch.htm.asc (270 bytes) Download Attachment