[ImageJ-devel] ImageCanvas Rotation in ImageJ2.0 ?

Thu Jan 6 13:41:21 CST 2011

Hi Karen,

I am CCing the ImageJDev mailing list, since your question may be on
interest to others.

   From reading the Image2.0 website, it appears that one of your main goals
> is the decouple the image data from the image display and that rotating the
> image display might be much easier to accomplish than in ImageJ1.xx. Is this
> something that is already implemented in ImageJ2.0, or is it in the roadmap,
> or if not, would such a feature be reasonable to implement in 2.0?
>

Yes, this is a major feature we plan to implement for ImageJ2. It is
definitely on the roadmap. The idea is to allow a many-to-one mapping of
data to display, so that you can visualize multiple images overlaid in the
same display, with each one mapped by an arbitrary affine transform. That
way you can have images as tiles in a display, and/or do Photoshop-style
image layers.

This feature is important for applications such as TrakEM2, which perform
image registration. Right now, if you download Fiji (which is just ImageJ
1.x with a bunch of extra plugins), you can use TrakEM2 to perform the
arbitrary rotation you seek, and much more.

At the moment, ImageJDev uses a very simple image display class called
NavigableImagePanel, which you can browse at:

http://dev.imagejdev.org/trac/imagej/browser/trunk/ij2-gui/src/main/java/imagej/gui/display

It was adapted from an article on java.net by Slav Boleslawski:
  http://today.java.net/article/2007/03/23/navigable-image-panel

We are still exploring whether to continue adapting this display by adding
features similar to TrakEM2, to adapt some TrakEM2 code more directly, or a
combination of the two, in order to achieve our ultimate goals described
above. There is also a library called VisAD we plan to utilize to create 2D
and 3D displays in ImageJ—the ImageJDev architecture will allow for multiple
distinct display plugins, depending on the type of image data.

I look forward to your feedback since I need to make a decision on whether
> to create yet another specific purpose release stream of ImageJ1.xx or start
> migrating to IJ2.0.
>

Unfortunately, it is still early days to be migrating to IJ2. Over the
course of this year things will really solidify. We hope to have a more
stable API against which third party folks can code by the fall. In the
meantime, if you are interested in participating in the design of said API,
you can join the ImageJX and/or imagej-devel mailing lists (see
http://imagejdev.org/mailing-lists). We would love to hear more details on
your requirements.

HTH,
Curtis

On Tue, Jan 4, 2011 at 2:06 AM, Karen Collins
<karen.collins at insightbb.com>wrote:

>  Hi Curtis,
>   I am developing a "professional" Astronomy environment for ImageJ
> building on top of the existing Astronomy package from Rick Hessman. Wayne
> suggested that I contact you regarding my request to him to add a feature to
> ImageJ that allows the ImageCanvas to be flipped in X and/or Y and to allow
> the ImageCanvas to be rotated (in steps of 90 degrees is enough for my
> astronomy purposes). I am specifying the ImageCanvas as opposed to the
> actual underlying image data because I need to be able to rotate just the
> display of the data (and associated ROI's), while leaving the underlying
> data in the same orientation.
>    From reading the Image2.0 website, it appears that one of your main
> goals is the decouple the image data from the image display and that
> rotating the image display might be much easier to accomplish than in
> ImageJ1.xx. Is this something that is already implemented in ImageJ2.0, or
> is it in the roadmap, or if not, would such a feature be reasonable to
> implement in 2.0? My analysis and preliminary work to add this capability to
> 1.xx is discussed below if you are interested in more detail. In summary, I
> have image flipping (in X and/or Y) implemented in 1.0, but I will need to
> do more work to complete the rotation capability.
>     I look forward to your feedback since I need to make a decision on
> whether to create yet another specific purpose release stream of ImageJ1.xx
> or start migrating to IJ2.0.
>
> Thanks,
>     Karen
>
> On 1/2/2011 12:12 PM, Rasband, Wayne (NIH/NIMH) [E] wrote:
>
>> Hi Karen,
>>
>> This sounds like more changes than I am willing to make. I am attempting
>> to keep ImageJ as small and simple as possible. There is a good chance,
>> however, that you can talk the ImageJDev people into incorporating you
>> changes into ImageJ 2.0 (http://imagejdev.org/). They are much more
>> receptive to changes than I am. I good person to contact would be Curtis
>> Rueden (ctrueden at wisc.edu). Another possibility would be to incorporate
>> your changes into SalsaJ (http://www.euhou.net/), a version of ImageJ
>> focused on Astronomy in education.
>>
>> Best regards,
>>
>> -wayne
>>
>>
>>
>> On Jan 2, 2011, at 2:44 AM, Karen Collins wrote:
>>
>>  Hi Wayne,
>>>       The description in my previous email was all based on flipping an
>>> ImageCanvas in the X and Y direction, but I had not seriously looked into
>>> rotating the Canvas by 90 degree steps. The changes to provide the ability
>>> to flip in X and Y do still seem to be limited to what I described below.
>>> However, after further work on rotating the canvas, I can't find a way to
>>> avoid passing both X and Y values as parameters in each of the
>>> screen-to-image mapping methods. In other words, these methods would need to
>>> be changed to something like screenX(int offX, int offY),  screenY(int offX,
>>> int offY), offScreenX(int screenX, int screenY),  offScreenY(int screenX,
>>> int screenY). Both values are required as parameters since with rotations of
>>> 0 or 180 degrees, screenX determines offScreenX, but in rotations of 90 or
>>> 270 degrees, screenY determines offScreenX, and vice-versa.
>>>       There are on the order of 30 occurrences of each of these, with
>>> most of them being in ImageCanvas and the ROI Classes. Would I be correct in
>>> assuming that this would be too much change for you to consider folding into
>>> the standard ImageJ release stream? Could the ImageJ user base in general
>>> benefit from having ImageCanvas rotation capability, or is this specific to
>>> astronomy?
>>>       If you are willing to include this capability into the base code, I
>>> am willing to do the coding and testing work. I would of course leave in the
>>> existing single parameter screenX/Y and offScreenX/Y ImageCanvas methods for
>>> backwards compatibility with plugins that only support the standard canvas
>>> orientation.  For standard ImageJ use, the new double parameter (X, Y)
>>> versions would of course return the same value as the single parameter
>>> versions and should be transparent to the operation of ImageJ as it exists
>>> today.
>>>
>>> Happy New Year!
>>> Karen
>>>
>>> -------- Original Message --------
>>> Subject:        ImageCanvas Rotation in ImageJ
>>> Date:   Thu, 30 Dec 2010 05:02:02 -0500
>>> From:   Karen Collins<karen.collins at insightbb.com>
>>> To:     Rasband Wayne<wsr at nih.gov>
>>>
>>>  Hi Wayne,
>>>       In connection with the Astronomy_Tool plugin that is still under
>>> development, I have been experimenting with ways to accomplish rotating
>>> an ImageCanvas (as opposed to rotating an ImagePlus). In astronomy, we
>>> often want to display an image such that North is up and East is to the
>>> left when viewed on the screen. However, images are often not exposed in
>>> this orientation on the sky, but are rotated by 90, 180, or 270 degrees
>>> and/or flipped in X or Y. We don't want to rotate the actual image
>>> dataset so that if it is modified and saved, the saved image is
>>> maintained in the original orientation, regardless of the display
>>> orientation.
>>>      Assuming that this feature may not be needed for non-astronomy
>>> ImageJ users, I have been investigating extending ImageCanvas to
>>> accomplish the rotations/flips. I am utilizing the Graphics2d Affine
>>> Transformations which keeps all the changes within ImageCanvas (or
>>> extension thereof), and leaves the Roi code unchanged. The changes
>>> needed are the insertion of the affine transformations in
>>> ImageCanvas.paint and ImageCanvas.paintDoubleBuffered methods and the
>>> modification of the offscreenX/Y and screenX/Y methods to accommodate
>>> the flips and rotates. The zoom indicator code also needs additional
>>> functionality to handle the different orientations and to add X and Y
>>> axis indicator arrows.
>>>     I have a working version implemented as a subclass of ImageCanvas,
>>> but I had to change some of the ImageCanvas method and variable
>>> modifiers from private to protected to be able to Override the
>>> ImageCanvas paint method from the subclass. I wanted to find out if it
>>> would be possible to change some of the modifiers in the base ImageJ
>>> code, so that I could avoid a non-standard release of ImageJ?
>>>
>>> The changes that would be needed in ImageCanvas are:
>>>
>>> private Image offScreenImage;  ->   protected Image offScreenImage;
>>> private int offScreenWidth = 0;   ->   protected int offScreenWidth = 0;
>>> private int offScreenHeight = 0;  ->   protected int offScreenHeight = 0;
>>>
>>> private void drawRoi(Roi roi, Graphics g)    ->   protected void
>>> drawRoi(Roi roi, Graphics g)
>>> void drawAllROIs(Graphics g)    ->   protected void drawAllROIs(Graphics
>>> g)
>>> void drawZoomIndicator(Graphics g)    ->   protected void
>>> drawZoomIndicator(Graphics g)
>>> void showFrameRate(Graphics g)    ->   protected void
>>> showFrameRate(Graphics g)
>>>
>>>
>>>
>>> There is one additional change that may be needed in ij.gui.Roi.
>>> ImageCanvas.paint() line 4 is:
>>>    if (roi!=null) roi.updatePaste();
>>> In Roi, roi.updatePaste() is currently unmodified, but would need to be
>>> public for me to be able access it outside the ij.gui package. I haven't
>>> been able to fully understand what this feature does, but assuming I
>>> need to keep it in the ImageCanvas.paint override code, could the
>>> Roi.updatePaste() modifier be changed to "public" if the above changes
>>> are also acceptable?
>>>
>>> If these changes are not appropriate for standard ImageJ releases, I
>>> will search for other solutions, although I'm not sure how to accomplish
>>> this otherwise without a special release of ImageJ. I will put in my
>>> disclaimer here: I am certainly not a Java guru, so I hope my analysis
>>> is sensible.  I am very open to other ideas if I am off track.
>>>
>>> If you are interested in offering canvas rotation in the standard ImageJ
>>> release, I am happy to contribute my work to the project by providing
>>> you an updated ImageCanvas.java file when I am finished, which in turn
>>> would avoid an ImageCanvas subclass for me. I currently have X/Y canvas
>>> flipping working, and will turn next to rotation. I think this will only
>>> require one more boolean to exchange X and Y coordinates, as it seems
>>> that all combinations of 90, 180, and 270 degree rotations and X/Y flips
>>> can be accomplished with a single 90 rotation combined with appropriate
>>> X and Y flips.
>>>
>>> Thanks,
>>>     Karen
>>>
>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110106/ff8b668a/attachment.html>