Ticket #526 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

Handle loading of images that cannot come in at 1:1 scale

Reported by: bdezonia Owned by: gharris
Priority: major Milestone: imagej2-b1-initial
Component: Display API Version:
Severity: serious Keywords:
Cc: Blocked By:


Since the adoption of JHotDraw the code that handled the loading and display of images that were not at 1:1 scale has not been relocated. Determine which changes need to take place and make them.

(Is the current design limited to 1:1 initial scale requiring a lot of memory to create and load an ARGBScreenImage?)

Change History

comment:1 Changed 8 years ago by bdezonia

  • Status changed from new to accepted

comment:2 Changed 8 years ago by bdezonia

  • Milestone changed from biweekly-2011: May-09 to May-20 to imagej-2.0-beta1

Right now in CompositeXYProjector::rebuild() the created ARGBScreenImage is sized to be 1:1 with a given ImgPlus. So we should intercept here to make sure screen image fits on screen, allocate an appropriate size, and set the Display's associated ImageCanvas's CanvasHelper's initial scale setting.

Another issue: it appears that map() is written to assume ARGBScreenImage and data source match in x and y coordinates. Ideally we need a view/projection here so that we can support non-1:1 image scaling. (Note that the x & y scale factors would need to be propagated to api users who need to know actual onscreen scale).

Also want a view and smaller allocation of ARGBScreenImage such that we can have tiles of ARGBScreenImages and only draw to visible ones. Or have one ARGBScreenImage and some other kind of tiles each with their own projector. The visible tiles just draw to portions of the single ARGBScreenImage.

Maybe all of this is violates the definition of an XYProjector and requires all new classes.

comment:3 Changed 8 years ago by bdezonia

Curtis idea: in our abstract AWT window class override setBounds() (or setSize()?) and make sure that if passed something larger than screen resize so it fits.

Right now if you zoom and then draw a roi the window is resized. If you're zoomed in a lot the window created is huge.

comment:4 Changed 8 years ago by curtis

  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-alpha5

comment:5 Changed 8 years ago by bdezonia

  • Owner changed from bdezonia to curtis
  • Status changed from accepted to assigned

comment:6 Changed 8 years ago by curtis

  • Owner changed from curtis to gharris

comment:7 Changed 8 years ago by curtis

As a first cut, we should just shoot for the image window bounds to be sized reasonably, with the image set to an appropriate zoom level, similar to IJ1. We should worry about the inherent memory use of large image planes in a separate ticket (see #19).

comment:8 Changed 7 years ago by gharris

This now works for 2D images, but needs yet to handle multi-dim. with sliders (Related to #526, #471.)

comment:9 Changed 7 years ago by gharris

  • Status changed from assigned to closed
  • Resolution set to fixed

Now accomodates dimensional sliders.

comment:10 Changed 7 years ago by curtis

Which commit(s) fixed this bug?

Note: See TracTickets for help on using tickets.