Hi Karen,<br><br>I am CCing the ImageJDev mailing list, since your question may be on interest to others.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">


   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?<br></blockquote>
 <br>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.<br>


<br>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.<br>


<br>At the moment, ImageJDev uses a very simple image display class called NavigableImagePanel, which you can browse at:<br>  <a href="http://dev.imagejdev.org/trac/imagej/browser/trunk/ij2-gui/src/main/java/imagej/gui/display" target="_blank">http://dev.imagejdev.org/trac/imagej/browser/trunk/ij2-gui/src/main/java/imagej/gui/display</a><br>


<br>It was adapted from an article on <a href="http://java.net" target="_blank">java.net</a> by Slav Boleslawski:<br>  <a href="http://today.java.net/article/2007/03/23/navigable-image-panel" target="_blank">http://today.java.net/article/2007/03/23/navigable-image-panel</a><br>


<br>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.<br>


<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">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.<br></blockquote><br>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 <a href="http://imagejdev.org/mailing-lists" target="_blank">http://imagejdev.org/mailing-lists</a>). We would love to hear more details on your requirements.<br>


<br>HTH,<br>Curtis<br><br><div class="gmail_quote">On Tue, Jan 4, 2011 at 2:06 AM, Karen Collins <span dir="ltr">&lt;<a href="mailto:karen.collins@insightbb.com" target="_blank">karen.collins@insightbb.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 Hi Curtis,<br>
   I am developing a &quot;professional&quot; 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&#39;s), while leaving the underlying data in the same orientation.<br>



    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.<br>



     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.<br>
<br>
Thanks,<br>
     Karen<br>
<br>
On 1/2/2011 12:12 PM, Rasband, Wayne (NIH/NIMH) [E] wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Karen,<br>
<br>
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 (<a href="http://imagejdev.org/" target="_blank">http://imagejdev.org/</a>). They are much more receptive to changes than I am. I good person to contact would be Curtis Rueden (<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>). Another possibility would be to incorporate your changes into SalsaJ (<a href="http://www.euhou.net/" target="_blank">http://www.euhou.net/</a>), a version of ImageJ focused on Astronomy in education.<br>



<br>
Best regards,<br>
<br>
-wayne<br>
<br>
<br>
<br>
On Jan 2, 2011, at 2:44 AM, Karen Collins wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Wayne,<br>
       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&#39;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.<br>



       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?<br>



       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.<br>



<br>
Happy New Year!<br>
Karen<br>
<br>
-------- Original Message --------<br>
Subject:        ImageCanvas Rotation in ImageJ<br>
Date:   Thu, 30 Dec 2010 05:02:02 -0500<br>
From:   Karen Collins&lt;<a href="mailto:karen.collins@insightbb.com" target="_blank">karen.collins@insightbb.com</a>&gt;<br>
To:     Rasband Wayne&lt;<a href="mailto:wsr@nih.gov" target="_blank">wsr@nih.gov</a>&gt;<br>
<br>
  Hi Wayne,<br>
       In connection with the Astronomy_Tool plugin that is still under<br>
development, I have been experimenting with ways to accomplish rotating<br>
an ImageCanvas (as opposed to rotating an ImagePlus). In astronomy, we<br>
often want to display an image such that North is up and East is to the<br>
left when viewed on the screen. However, images are often not exposed in<br>
this orientation on the sky, but are rotated by 90, 180, or 270 degrees<br>
and/or flipped in X or Y. We don&#39;t want to rotate the actual image<br>
dataset so that if it is modified and saved, the saved image is<br>
maintained in the original orientation, regardless of the display<br>
orientation.<br>
      Assuming that this feature may not be needed for non-astronomy<br>
ImageJ users, I have been investigating extending ImageCanvas to<br>
accomplish the rotations/flips. I am utilizing the Graphics2d Affine<br>
Transformations which keeps all the changes within ImageCanvas (or<br>
extension thereof), and leaves the Roi code unchanged. The changes<br>
needed are the insertion of the affine transformations in<br>
ImageCanvas.paint and ImageCanvas.paintDoubleBuffered methods and the<br>
modification of the offscreenX/Y and screenX/Y methods to accommodate<br>
the flips and rotates. The zoom indicator code also needs additional<br>
functionality to handle the different orientations and to add X and Y<br>
axis indicator arrows.<br>
     I have a working version implemented as a subclass of ImageCanvas,<br>
but I had to change some of the ImageCanvas method and variable<br>
modifiers from private to protected to be able to Override the<br>
ImageCanvas paint method from the subclass. I wanted to find out if it<br>
would be possible to change some of the modifiers in the base ImageJ<br>
code, so that I could avoid a non-standard release of ImageJ?<br>
<br>
The changes that would be needed in ImageCanvas are:<br>
<br>
private Image offScreenImage;  -&gt;   protected Image offScreenImage;<br>
private int offScreenWidth = 0;   -&gt;   protected int offScreenWidth = 0;<br>
private int offScreenHeight = 0;  -&gt;   protected int offScreenHeight = 0;<br>
<br>
private void drawRoi(Roi roi, Graphics g)    -&gt;   protected void<br>
drawRoi(Roi roi, Graphics g)<br>
void drawAllROIs(Graphics g)    -&gt;   protected void drawAllROIs(Graphics g)<br>
void drawZoomIndicator(Graphics g)    -&gt;   protected void<br>
drawZoomIndicator(Graphics g)<br>
void showFrameRate(Graphics g)    -&gt;   protected void<br>
showFrameRate(Graphics g)<br>
<br>
<br>
<br>
There is one additional change that may be needed in ij.gui.Roi.<br>
ImageCanvas.paint() line 4 is:<br>
    if (roi!=null) roi.updatePaste();<br>
In Roi, roi.updatePaste() is currently unmodified, but would need to be<br>
public for me to be able access it outside the ij.gui package. I haven&#39;t<br>
been able to fully understand what this feature does, but assuming I<br>
need to keep it in the ImageCanvas.paint override code, could the<br>
Roi.updatePaste() modifier be changed to &quot;public&quot; if the above changes<br>
are also acceptable?<br>
<br>
If these changes are not appropriate for standard ImageJ releases, I<br>
will search for other solutions, although I&#39;m not sure how to accomplish<br>
this otherwise without a special release of ImageJ. I will put in my<br>
disclaimer here: I am certainly not a Java guru, so I hope my analysis<br>
is sensible.  I am very open to other ideas if I am off track.<br>
<br>
If you are interested in offering canvas rotation in the standard ImageJ<br>
release, I am happy to contribute my work to the project by providing<br>
you an updated ImageCanvas.java file when I am finished, which in turn<br>
would avoid an ImageCanvas subclass for me. I currently have X/Y canvas<br>
flipping working, and will turn next to rotation. I think this will only<br>
require one more boolean to exchange X and Y coordinates, as it seems<br>
that all combinations of 90, 180, and 270 degree rotations and X/Y flips<br>
can be accomplished with a single 90 rotation combined with appropriate<br>
X and Y flips.<br>
<br>
Thanks,<br>
     Karen<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote></div><br>