⚠

NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #526 (closed defect: fixed)

Opened 2011-05-19T17:30:35-05:00

Last modified 2011-09-30T10:51:41-05:00

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:
Blocking:

Description

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 2011-05-19T17:32:58-05:00 by bdezonia

  • Status changed from new to accepted

comment:2 Changed 2011-05-20T09:17:44-05:00 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 2011-06-01T10:04:22-05:00 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 2011-07-27T15:11:29-05:00 by curtis

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

comment:5 Changed 2011-08-11T14:13:21-05:00 by bdezonia

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

comment:6 Changed 2011-09-09T11:24:27-05:00 by curtis

  • Owner changed from curtis to gharris

comment:7 Changed 2011-09-09T11:25:45-05:00 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 2011-09-25T20:48:38-05:00 by gharris

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

comment:9 Changed 2011-09-30T09:22:23-05:00 by gharris

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

Now accomodates dimensional sliders.

comment:10 Changed 2011-09-30T10:51:41-05:00 by curtis

Which commit(s) fixed this bug?