Ticket #818 (closed defect: fixed)
Opened 2011-10-12T12:47:25-05:00
Last modified 2012-05-25T15:20:33-05:00
Overlays do not interact well with crop
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Plugins | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1143 |
Description
Crop interacts with overlays poorly:
- when a selection is made and then crop run the selection does not move to the origin
- since the selection does not move it is left on screen at old location
- and the size of the view encompasses the cropped image and the original selection
- multiple overlays further complicate the shape of the view. only the active overlay affects which pixels are copied (which is correct I think)
What should happen is the selection should move to the origin. The overlays that are not wholly contained in the crop region should go away. Others could go away or could just be shifted relative to the new origin.
Change History
comment:2 Changed 2011-10-14T13:22:05-05:00 by bdezonia
In b4fe0ad96b0e616ea0f727116bcca83cd90df8cb implemented a new version of CropImage that interacts better with overlays. For now all overlays are deleted from the display. The panel resizes to new dimensions. That sometimes fails but it detailed in a new bug #826.
Will address the rest of this ticket later after some discussion with others.
comment:3 Changed 2011-12-01T10:02:02-06:00 by bdezonia
Discussed with Curtis. Overlays that intersect crop window should be translated relative to new origin. Window would be sized to include these overlay extents. That's fine.
comment:4 Changed 2012-01-19T12:07:25-06:00 by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:5 Changed 2012-02-13T15:42:32-06:00 by bdezonia
- Milestone changed from imagej-2.0-beta2 to imagej-2.0-beta1
comment:6 Changed 2012-02-27T11:00:58-06:00 by curtis
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:8 Changed 2012-05-22T12:21:08-05:00 by bdezonia
We need to determine how we want to handle the duplication of ROIs. When user runs crop on a selected region the existing ROIs need to be duplicated and moved to new origin. I have done some play implementations. They all eventually reach the limitations of the Imglib RegionOfInterest definitions. One needs to define duplicate() and move() in the base classes. Note that move() will be broken for the Img-based BinaryMaskedRegionOfInterest. Using PointSets would simplify things here. Need further discussion with Imglib folks.
comment:9 Changed 2012-05-25T15:20:33-05:00 by bdezonia
- Status changed from new to closed
- Resolution set to fixed
With commit 192365bdbc3b77c02b348bfb1be6e8c18e03705d an initial implementation of code that allows Overlays to be moved and duplicated is in place. It could be further frefined but we'll wait for discussions with others. Closing this ticket.