can't getRoi from ImagePlus???

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

can't getRoi from ImagePlus???

Kenneth Sloan-2
Today, I wrote two Java plugins - custom data collection tools for a specific project.

The code looks like this:

  ImagePlus iml = IJ.openImage(filename)
  IJ.setTool("line");
  ...wait for user to indicate that the line is ready...
  Roi roi = imp.getRoi();

after which I extract the two pairs of x,y points.

This works perfectly.

Then, I modified it for another custom plugin, which wants polygons.  So, the code looks like:

  ImagePlus iml = IJ.openImage(filename)
  IJ.setTool("polygon");
  ...wait for user to indicate that the polygon is ready...
  Roi roi = imp.getRoi();

This works - but the returned Roi *always* contains 4 points and these 4 points are *always* the 4 corners of the
image.

I want to use "polygon", but I also tried "freehand".  Same result.

Are the "polygon" and "freehand" tools broken?

Or, am I missing something?

I'm moderately sure that I have used similar code in the past, but that code may have been written by students.  
I'll try to find it.  In the meantime - can anyone see what I'm doing wrong?

Are there, perhaps, options that I need to add to 'setTool("polygon")'???  Does the user have to do something to "finalize"
the polygon and make it the "current selection"?  I'm very confused!

This is time critical!

If it matters, I'm extending KeyListener and responding to KeyRelease events - examining the character typed by the
user (which also signals that the line/polygon is complete).  As near as I can make out - this part works perfectly.
It feels as if setTool("line") simply does something that setTool("polygon") does not.

Or...is it possible that the polygon is being assigned to the wrong ImagePlus?  Question: are ImagePlus options born with a "current selection" that matches the image boundaries?  To my code, it appears that the current selection is *always* a rectangle matching the image bounds.


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Robert Dougherty
Kennith,

It seems like it is necessary to cast an Roi as a PolygonRoi in order to get its polygon correctly, e.g.,

  Roi roi = imp.getRoi();
        if(roi instanceof PolygonRoi){
                PolygonRoi pr = (PolygonRoi)roi;
                java.awt.Polygon poly = pr.getPolygon();
                ...

If you call roi.getPolygon() then, as I understand it, you will be calling the method of the parent class, Roi, and this always returns a polygon with 4 points.

Bob


> On Jan 23, 2019, at 7:56 PM, Kenneth Sloan <[hidden email]> wrote:
>
> Today, I wrote two Java plugins - custom data collection tools for a specific project.
>
> The code looks like this:
>
>  ImagePlus iml = IJ.openImage(filename)
>  IJ.setTool("line");
>  ...wait for user to indicate that the line is ready...
>  Roi roi = imp.getRoi();
>
> after which I extract the two pairs of x,y points.
>
> This works perfectly.
>
> Then, I modified it for another custom plugin, which wants polygons.  So, the code looks like:
>
>  ImagePlus iml = IJ.openImage(filename)
>  IJ.setTool("polygon");
>  ...wait for user to indicate that the polygon is ready...
>  Roi roi = imp.getRoi();
>
> This works - but the returned Roi *always* contains 4 points and these 4 points are *always* the 4 corners of the
> image.
>
> I want to use "polygon", but I also tried "freehand".  Same result.
>
> Are the "polygon" and "freehand" tools broken?
>
> Or, am I missing something?
>
> I'm moderately sure that I have used similar code in the past, but that code may have been written by students.  
> I'll try to find it.  In the meantime - can anyone see what I'm doing wrong?
>
> Are there, perhaps, options that I need to add to 'setTool("polygon")'???  Does the user have to do something to "finalize"
> the polygon and make it the "current selection"?  I'm very confused!
>
> This is time critical!
>
> If it matters, I'm extending KeyListener and responding to KeyRelease events - examining the character typed by the
> user (which also signals that the line/polygon is complete).  As near as I can make out - this part works perfectly.
> It feels as if setTool("line") simply does something that setTool("polygon") does not.
>
> Or...is it possible that the polygon is being assigned to the wrong ImagePlus?  Question: are ImagePlus options born with a "current selection" that matches the image boundaries?  To my code, it appears that the current selection is *always* a rectangle matching the image bounds.
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Robert P. Dougherty
President
OptiNav, Inc.
1414 127th Pl NE #106
Bellevue, WA 98005
(425) 891-4883
FAX (425) 467-1119
[hidden email]
www.optinav. com


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Michael Schmid
In reply to this post by Kenneth Sloan-2
Hi Kenneth,

the Polygon and Freehand selections are *area* selections (closed shapes
with an interior), whereas a the Line, Polyline and Freeline are line
selections (no interior area defined).
Apart from Line, all of these are members of the PolygonRoi class.

So what do you need?

If it is the area covered by the line, Edit>Selection>Line to Area would
be required.
You can find the Java code here
 
https://github.com/imagej/imagej1/blob/master/ij/plugin/Selection.java#L629

If you only need a polyline (line selection that can have more than one
point), you would have to modify it like this (JavaScript version):

   imp=IJ.getImage();
   roi=imp.getRoi();
   p = roi.getFloatPolygon();
   roi2 = new PolygonRoi(p, Roi.POLYLINE);
   imp.setRoi(roi2);


Michael
________________________________________________________________
On 24.01.19 04:56, Kenneth Sloan wrote:

> Today, I wrote two Java plugins - custom data collection tools for a specific project.
>
> The code looks like this:
>
>    ImagePlus iml = IJ.openImage(filename)
>    IJ.setTool("line");
>    ...wait for user to indicate that the line is ready...
>    Roi roi = imp.getRoi();
>
> after which I extract the two pairs of x,y points.
>
> This works perfectly.
>
> Then, I modified it for another custom plugin, which wants polygons.  So, the code looks like:
>
>    ImagePlus iml = IJ.openImage(filename)
>    IJ.setTool("polygon");
>    ...wait for user to indicate that the polygon is ready...
>    Roi roi = imp.getRoi();
>
> This works - but the returned Roi *always* contains 4 points and these 4 points are *always* the 4 corners of the
> image.
>
> I want to use "polygon", but I also tried "freehand".  Same result.
>
> Are the "polygon" and "freehand" tools broken?
>
> Or, am I missing something?
>
> I'm moderately sure that I have used similar code in the past, but that code may have been written by students.
> I'll try to find it.  In the meantime - can anyone see what I'm doing wrong?
>
> Are there, perhaps, options that I need to add to 'setTool("polygon")'???  Does the user have to do something to "finalize"
> the polygon and make it the "current selection"?  I'm very confused!
>
> This is time critical!
>
> If it matters, I'm extending KeyListener and responding to KeyRelease events - examining the character typed by the
> user (which also signals that the line/polygon is complete).  As near as I can make out - this part works perfectly.
> It feels as if setTool("line") simply does something that setTool("polygon") does not.
>
> Or...is it possible that the polygon is being assigned to the wrong ImagePlus?  Question: are ImagePlus options born with a "current selection" that matches the image boundaries?  To my code, it appears that the current selection is *always* a rectangle matching the image bounds.
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Kenneth Sloan-2
In reply to this post by Robert Dougherty
AHA!  This was the most useful reply - but I still have a problem, which has NOTHING to do with what I thought was going on.
I discovered the real issue by implementing Robert's changes - and putting in sufficient debugging statements to track what's going on.

My problem is that I am using a KeyListener to specify the TYPE of Polygon.  I have three types: 'a', 'v', and 'c'.  What I failed to consider was that ImageJ was *also* listening, and applying shortcuts.  

So, when I type 'a' - my KeyListener is, indeed called, but only after the shortcut "'a' - Select All" has been run.  So, having done a "Select All" - the current Roi for the image does indeed include the entire image.  ('c' works just fine! 'v' brings up the Clipboard, trying to do a 'paste'

Now my problem is: how do I disable shortcuts?  

One option is to list all the current shortcuts and avoid them.  This does not seem to generalize well.

Perhaps a second option is to use compound keystrokes (CNTL-a, CNTL-c, CNTL-v) which might avoid shortcuts?

Another option is to disable all existing shortcuts while my KeyListener is active - which seems OK (but I don't know how to do that).

Any other ideas?  I'd really like to use mnemonic 1-character keypresses to classify polygon classes - so that the user doesn't have to move the cursor from the image to (for example) a dialog box.

In the simpler LINE case, there were no classes and I used SPACE to accept a polygon.  This did not run afoul of any existing shortcuts.  Question: is it possible to define SPACE as a shortcut (that is, am I safe using SPACE without further precautions)?

I hope I have explained the situation so that someone can properly educate me on how to proceed.  My ultimate goal is to allow the user to draw polygons one at a time, and classify each one as we go without moving the cursor away from the part of the image being analyzed.  I *do* want to allow the user to do things like panning and zooming on the image - so I don't want to disable *everything*.  Perhaps single keystrokes are too ambitious?  Please feel free to make other suggestions.  

If someone thinks it will help, I will be happy to provide full source code for both plugins.  They are stand-alone and fairly simple (if a bit verose).  Feel free to point and giggle at my peculiar coding style.  I prefer NOT to post publically, so "serious inquires only, please".

Thank you very much for your help.  Trying to implement the first round of suggestions was most useful in zeroing in on the problem.

Just for completeness, the goal of the current plugin is:

a) open an image (I prefer this over starting with an existing open image)
b) draw polygons, one at a time, on the image
c) extract the x,y coordinates (first raw, then converted using a Calibration)
d) write the x,y coordinates (and the polygon type) as a single line in a .csv file

I do not need to "measure" anything, and I don't need to use any other ImageJ ROI-analysis tools.  The program sets the Tool to "polygon" at the start of the interaction and to "hand" when done.

Perhaps there is a simple way to do that in a macro.  I would be happy to see such a macro, if only to learn a bit more about the macro language.  My training and experience leads me to write almost exclusively in Java.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On Jan 24, 2019, at 12:34 AM, Robert Dougherty <[hidden email]> wrote:
>
> Kennith,
>
> It seems like it is necessary to cast an Roi as a PolygonRoi in order to get its polygon correctly, e.g.,
>
> Roi roi = imp.getRoi();
> if(roi instanceof PolygonRoi){
> PolygonRoi pr = (PolygonRoi)roi;
> java.awt.Polygon poly = pr.getPolygon();
> ...
>
> If you call roi.getPolygon() then, as I understand it, you will be calling the method of the parent class, Roi, and this always returns a polygon with 4 points.
>
> Bob
>
>
>> On Jan 23, 2019, at 7:56 PM, Kenneth Sloan <[hidden email]> wrote:
>>
>> Today, I wrote two Java plugins - custom data collection tools for a specific project.
>>
>> The code looks like this:
>>
>> ImagePlus iml = IJ.openImage(filename)
>> IJ.setTool("line");
>> ...wait for user to indicate that the line is ready...
>> Roi roi = imp.getRoi();
>>
>> after which I extract the two pairs of x,y points.
>>
>> This works perfectly.
>>
>> Then, I modified it for another custom plugin, which wants polygons.  So, the code looks like:
>>
>> ImagePlus iml = IJ.openImage(filename)
>> IJ.setTool("polygon");
>> ...wait for user to indicate that the polygon is ready...
>> Roi roi = imp.getRoi();
>>
>> This works - but the returned Roi *always* contains 4 points and these 4 points are *always* the 4 corners of the
>> image.
>>
>> I want to use "polygon", but I also tried "freehand".  Same result.
>>
>> Are the "polygon" and "freehand" tools broken?
>>
>> Or, am I missing something?
>>
>> I'm moderately sure that I have used similar code in the past, but that code may have been written by students.  
>> I'll try to find it.  In the meantime - can anyone see what I'm doing wrong?
>>
>> Are there, perhaps, options that I need to add to 'setTool("polygon")'???  Does the user have to do something to "finalize"
>> the polygon and make it the "current selection"?  I'm very confused!
>>
>> This is time critical!
>>
>> If it matters, I'm extending KeyListener and responding to KeyRelease events - examining the character typed by the
>> user (which also signals that the line/polygon is complete).  As near as I can make out - this part works perfectly.
>> It feels as if setTool("line") simply does something that setTool("polygon") does not.
>>
>> Or...is it possible that the polygon is being assigned to the wrong ImagePlus?  Question: are ImagePlus options born with a "current selection" that matches the image boundaries?  To my code, it appears that the current selection is *always* a rectangle matching the image bounds.
>>
>>
>> --
>> Kenneth Sloan
>> [hidden email]
>> Vision is the art of seeing what is invisible to others.
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> Robert P. Dougherty
> President
> OptiNav, Inc.
> 1414 127th Pl NE #106
> Bellevue, WA 98005
> (425) 891-4883
> FAX (425) 467-1119
> [hidden email]
> www.optinav. com
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Michael Schmid
Hi Kenneth,

what is in the foreground and accepting KeyEvents?

Is it the image, i.e., the ImageCanvas?
Then it is fairly easy to intercept the KeyEvents:

The ImageCanvas has previously done

   addKeyListener(IJ.getInstance())

so you can remove this by

   ic.removeKeyListener(IJ.getInstance())
where ic is the ImageCanvas.

In your own KeyPressed, keyReleased, keyTyped methods, forward events
with keys that you don't use to ij = IJ.getInstance(), e.g.

public void keyPressed(KeyEvent e) {
    if (e.getKeyChar() == 'a')      {  // it is one of my keys
        #do whatever you like
    else if (e.getKeyChar() == 'v') {  // also this is one of my keys
        #do whatever you like
    } else
        ij.keyPressed(e);              // ImageJ will handle the rest
}

Alternatively, selectively forward events for commands that may be used,
e.g. keyCodes VK_PLUS, VK_ADD, VK_MINUS, VK_SUBTRACT, VK_4, VK_5 for
zooming, VK_SPACE for panning, and all the modifiers VK_SHIFT, VK_ALT,
VK_CONTROL, as well as VK_ESCAPE.

Best have one function that decides which keys may be forwarded to
ImageJ, and use it in all three listener methods.

When your plugin is done, and the image remains open, don't forget to
get ImageJ listen to it again:

   ic.addKeyListener(ij)


Michael
________________________________________________________________
On 24.01.19 18:23, Kenneth Sloan wrote:

> AHA!  This was the most useful reply - but I still have a problem, which has NOTHING to do with what I thought was going on.
> I discovered the real issue by implementing Robert's changes - and putting in sufficient debugging statements to track what's going on.
>
> My problem is that I am using a KeyListener to specify the TYPE of Polygon.  I have three types: 'a', 'v', and 'c'.  What I failed to consider was that ImageJ was *also* listening, and applying shortcuts.
>
> So, when I type 'a' - my KeyListener is, indeed called, but only after the shortcut "'a' - Select All" has been run.  So, having done a "Select All" - the current Roi for the image does indeed include the entire image.  ('c' works just fine! 'v' brings up the Clipboard, trying to do a 'paste'
>
> Now my problem is: how do I disable shortcuts?
>
> One option is to list all the current shortcuts and avoid them.  This does not seem to generalize well.
>
> Perhaps a second option is to use compound keystrokes (CNTL-a, CNTL-c, CNTL-v) which might avoid shortcuts?
>
> Another option is to disable all existing shortcuts while my KeyListener is active - which seems OK (but I don't know how to do that).
>
> Any other ideas?  I'd really like to use mnemonic 1-character keypresses to classify polygon classes - so that the user doesn't have to move the cursor from the image to (for example) a dialog box.
>
> In the simpler LINE case, there were no classes and I used SPACE to accept a polygon.  This did not run afoul of any existing shortcuts.  Question: is it possible to define SPACE as a shortcut (that is, am I safe using SPACE without further precautions)?
>
> I hope I have explained the situation so that someone can properly educate me on how to proceed.  My ultimate goal is to allow the user to draw polygons one at a time, and classify each one as we go without moving the cursor away from the part of the image being analyzed.  I *do* want to allow the user to do things like panning and zooming on the image - so I don't want to disable *everything*.  Perhaps single keystrokes are too ambitious?  Please feel free to make other suggestions.
>
> If someone thinks it will help, I will be happy to provide full source code for both plugins.  They are stand-alone and fairly simple (if a bit verose).  Feel free to point and giggle at my peculiar coding style.  I prefer NOT to post publically, so "serious inquires only, please".
>
> Thank you very much for your help.  Trying to implement the first round of suggestions was most useful in zeroing in on the problem.
>
> Just for completeness, the goal of the current plugin is:
>
> a) open an image (I prefer this over starting with an existing open image)
> b) draw polygons, one at a time, on the image
> c) extract the x,y coordinates (first raw, then converted using a Calibration)
> d) write the x,y coordinates (and the polygon type) as a single line in a .csv file
>
> I do not need to "measure" anything, and I don't need to use any other ImageJ ROI-analysis tools.  The program sets the Tool to "polygon" at the start of the interaction and to "hand" when done.
>
> Perhaps there is a simple way to do that in a macro.  I would be happy to see such a macro, if only to learn a bit more about the macro language.  My training and experience leads me to write almost exclusively in Java.
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On Jan 24, 2019, at 12:34 AM, Robert Dougherty <[hidden email]> wrote:
>>
>> Kennith,
>>
>> It seems like it is necessary to cast an Roi as a PolygonRoi in order to get its polygon correctly, e.g.,
>>
>> Roi roi = imp.getRoi();
>> if(roi instanceof PolygonRoi){
>> PolygonRoi pr = (PolygonRoi)roi;
>> java.awt.Polygon poly = pr.getPolygon();
>> ...
>>
>> If you call roi.getPolygon() then, as I understand it, you will be calling the method of the parent class, Roi, and this always returns a polygon with 4 points.
>>
>> Bob
>>
>>
>>> On Jan 23, 2019, at 7:56 PM, Kenneth Sloan <[hidden email]> wrote:
>>>
>>> Today, I wrote two Java plugins - custom data collection tools for a specific project.
>>>
>>> The code looks like this:
>>>
>>> ImagePlus iml = IJ.openImage(filename)
>>> IJ.setTool("line");
>>> ...wait for user to indicate that the line is ready...
>>> Roi roi = imp.getRoi();
>>>
>>> after which I extract the two pairs of x,y points.
>>>
>>> This works perfectly.
>>>
>>> Then, I modified it for another custom plugin, which wants polygons.  So, the code looks like:
>>>
>>> ImagePlus iml = IJ.openImage(filename)
>>> IJ.setTool("polygon");
>>> ...wait for user to indicate that the polygon is ready...
>>> Roi roi = imp.getRoi();
>>>
>>> This works - but the returned Roi *always* contains 4 points and these 4 points are *always* the 4 corners of the
>>> image.
>>>
>>> I want to use "polygon", but I also tried "freehand".  Same result.
>>>
>>> Are the "polygon" and "freehand" tools broken?
>>>
>>> Or, am I missing something?
>>>
>>> I'm moderately sure that I have used similar code in the past, but that code may have been written by students.
>>> I'll try to find it.  In the meantime - can anyone see what I'm doing wrong?
>>>
>>> Are there, perhaps, options that I need to add to 'setTool("polygon")'???  Does the user have to do something to "finalize"
>>> the polygon and make it the "current selection"?  I'm very confused!
>>>
>>> This is time critical!
>>>
>>> If it matters, I'm extending KeyListener and responding to KeyRelease events - examining the character typed by the
>>> user (which also signals that the line/polygon is complete).  As near as I can make out - this part works perfectly.
>>> It feels as if setTool("line") simply does something that setTool("polygon") does not.
>>>
>>> Or...is it possible that the polygon is being assigned to the wrong ImagePlus?  Question: are ImagePlus options born with a "current selection" that matches the image boundaries?  To my code, it appears that the current selection is *always* a rectangle matching the image bounds.
>>>
>>>
>>> --
>>> Kenneth Sloan
>>> [hidden email]
>>> Vision is the art of seeing what is invisible to others.
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>> Robert P. Dougherty
>> President
>> OptiNav, Inc.
>> 1414 127th Pl NE #106
>> Bellevue, WA 98005
>> (425) 891-4883
>> FAX (425) 467-1119
>> [hidden email]
>> www.optinav. com
>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Kenneth Sloan-2
Thank you for this very useful reply. I had just about given up on a hot
key approach and was inventing reasons why a NonblockingGenericDialog would
be OK. (Briefly, the polygons take longer to draw than the lines, do it’s
not such a big deal to avoid navigating back to a dialog box - and I even
thought it might be useful in this application to allow for text
annotations)

I apologize for leaving out the crucial information (KeyEvents) from my
very first query - of course, had I known it was crucial I might have known
what the problem is.

Your solution of removing the original KeyListener, restoring it on exit,
and forwarding unused keystrokes looks perfect. I’ll implement it tonight.

I should also cleanup the other plugin, which uses only SPACE. But, that
will have to wait awhile. I think it’s safe as is.
On Thu, Jan 24, 2019 at 12:06 Michael Schmid <[hidden email]>
wrote:

> Hi Kenneth,
>
> what is in the foreground and accepting KeyEvents?
>
> Is it the image, i.e., the ImageCanvas?
> Then it is fairly easy to intercept the KeyEvents:
>
> The ImageCanvas has previously done
>
>    addKeyListener(IJ.getInstance())
>
> so you can remove this by
>
>    ic.removeKeyListener(IJ.getInstance())
> where ic is the ImageCanvas.
>
> In your own KeyPressed, keyReleased, keyTyped methods, forward events
> with keys that you don't use to ij = IJ.getInstance(), e.g.
>
> public void keyPressed(KeyEvent e) {
>     if (e.getKeyChar() == 'a')      {  // it is one of my keys
>         #do whatever you like
>     else if (e.getKeyChar() == 'v') {  // also this is one of my keys
>         #do whatever you like
>     } else
>         ij.keyPressed(e);              // ImageJ will handle the rest
> }
>
> Alternatively, selectively forward events for commands that may be used,
> e.g. keyCodes VK_PLUS, VK_ADD, VK_MINUS, VK_SUBTRACT, VK_4, VK_5 for
> zooming, VK_SPACE for panning, and all the modifiers VK_SHIFT, VK_ALT,
> VK_CONTROL, as well as VK_ESCAPE.
>
> Best have one function that decides which keys may be forwarded to
> ImageJ, and use it in all three listener methods.
>
> When your plugin is done, and the image remains open, don't forget to
> get ImageJ listen to it again:
>
>    ic.addKeyListener(ij)
>
>
> Michael
> ________________________________________________________________
> On 24.01.19 18:23, Kenneth Sloan wrote:
> > AHA!  This was the most useful reply - but I still have a problem, which
> has NOTHING to do with what I thought was going on.
> > I discovered the real issue by implementing Robert's changes - and
> putting in sufficient debugging statements to track what's going on.
> >
> > My problem is that I am using a KeyListener to specify the TYPE of
> Polygon.  I have three types: 'a', 'v', and 'c'.  What I failed to consider
> was that ImageJ was *also* listening, and applying shortcuts.
> >
> > So, when I type 'a' - my KeyListener is, indeed called, but only after
> the shortcut "'a' - Select All" has been run.  So, having done a "Select
> All" - the current Roi for the image does indeed include the entire image.
> ('c' works just fine! 'v' brings up the Clipboard, trying to do a 'paste'
> >
> > Now my problem is: how do I disable shortcuts?
> >
> > One option is to list all the current shortcuts and avoid them.  This
> does not seem to generalize well.
> >
> > Perhaps a second option is to use compound keystrokes (CNTL-a, CNTL-c,
> CNTL-v) which might avoid shortcuts?
> >
> > Another option is to disable all existing shortcuts while my KeyListener
> is active - which seems OK (but I don't know how to do that).
> >
> > Any other ideas?  I'd really like to use mnemonic 1-character keypresses
> to classify polygon classes - so that the user doesn't have to move the
> cursor from the image to (for example) a dialog box.
> >
> > In the simpler LINE case, there were no classes and I used SPACE to
> accept a polygon.  This did not run afoul of any existing shortcuts.
> Question: is it possible to define SPACE as a shortcut (that is, am I safe
> using SPACE without further precautions)?
> >
> > I hope I have explained the situation so that someone can properly
> educate me on how to proceed.  My ultimate goal is to allow the user to
> draw polygons one at a time, and classify each one as we go without moving
> the cursor away from the part of the image being analyzed.  I *do* want to
> allow the user to do things like panning and zooming on the image - so I
> don't want to disable *everything*.  Perhaps single keystrokes are too
> ambitious?  Please feel free to make other suggestions.
> >
> > If someone thinks it will help, I will be happy to provide full source
> code for both plugins.  They are stand-alone and fairly simple (if a bit
> verose).  Feel free to point and giggle at my peculiar coding style.  I
> prefer NOT to post publically, so "serious inquires only, please".
> >
> > Thank you very much for your help.  Trying to implement the first round
> of suggestions was most useful in zeroing in on the problem.
> >
> > Just for completeness, the goal of the current plugin is:
> >
> > a) open an image (I prefer this over starting with an existing open
> image)
> > b) draw polygons, one at a time, on the image
> > c) extract the x,y coordinates (first raw, then converted using a
> Calibration)
> > d) write the x,y coordinates (and the polygon type) as a single line in
> a .csv file
> >
> > I do not need to "measure" anything, and I don't need to use any other
> ImageJ ROI-analysis tools.  The program sets the Tool to "polygon" at the
> start of the interaction and to "hand" when done.
> >
> > Perhaps there is a simple way to do that in a macro.  I would be happy
> to see such a macro, if only to learn a bit more about the macro language.
> My training and experience leads me to write almost exclusively in Java.
> >
> > --
> > Kenneth Sloan
> > [hidden email]
> > Vision is the art of seeing what is invisible to others.
> >
> >
> >
> >
> >
> >> On Jan 24, 2019, at 12:34 AM, Robert Dougherty <[hidden email]> wrote:
> >>
> >> Kennith,
> >>
> >> It seems like it is necessary to cast an Roi as a PolygonRoi in order
> to get its polygon correctly, e.g.,
> >>
> >>      Roi roi = imp.getRoi();
> >>      if(roi instanceof PolygonRoi){
> >>              PolygonRoi pr = (PolygonRoi)roi;
> >>              java.awt.Polygon poly = pr.getPolygon();
> >>              ...
> >>
> >> If you call roi.getPolygon() then, as I understand it, you will be
> calling the method of the parent class, Roi, and this always returns a
> polygon with 4 points.
> >>
> >> Bob
> >>
> >>
> >>> On Jan 23, 2019, at 7:56 PM, Kenneth Sloan <[hidden email]>
> wrote:
> >>>
> >>> Today, I wrote two Java plugins - custom data collection tools for a
> specific project.
> >>>
> >>> The code looks like this:
> >>>
> >>> ImagePlus iml = IJ.openImage(filename)
> >>> IJ.setTool("line");
> >>> ...wait for user to indicate that the line is ready...
> >>> Roi roi = imp.getRoi();
> >>>
> >>> after which I extract the two pairs of x,y points.
> >>>
> >>> This works perfectly.
> >>>
> >>> Then, I modified it for another custom plugin, which wants polygons.
> So, the code looks like:
> >>>
> >>> ImagePlus iml = IJ.openImage(filename)
> >>> IJ.setTool("polygon");
> >>> ...wait for user to indicate that the polygon is ready...
> >>> Roi roi = imp.getRoi();
> >>>
> >>> This works - but the returned Roi *always* contains 4 points and these
> 4 points are *always* the 4 corners of the
> >>> image.
> >>>
> >>> I want to use "polygon", but I also tried "freehand".  Same result.
> >>>
> >>> Are the "polygon" and "freehand" tools broken?
> >>>
> >>> Or, am I missing something?
> >>>
> >>> I'm moderately sure that I have used similar code in the past, but
> that code may have been written by students.
> >>> I'll try to find it.  In the meantime - can anyone see what I'm doing
> wrong?
> >>>
> >>> Are there, perhaps, options that I need to add to
> 'setTool("polygon")'???  Does the user have to do something to "finalize"
> >>> the polygon and make it the "current selection"?  I'm very confused!
> >>>
> >>> This is time critical!
> >>>
> >>> If it matters, I'm extending KeyListener and responding to KeyRelease
> events - examining the character typed by the
> >>> user (which also signals that the line/polygon is complete).  As near
> as I can make out - this part works perfectly.
> >>> It feels as if setTool("line") simply does something that
> setTool("polygon") does not.
> >>>
> >>> Or...is it possible that the polygon is being assigned to the wrong
> ImagePlus?  Question: are ImagePlus options born with a "current selection"
> that matches the image boundaries?  To my code, it appears that the current
> selection is *always* a rectangle matching the image bounds.
> >>>
> >>>
> >>> --
> >>> Kenneth Sloan
> >>> [hidden email]
> >>> Vision is the art of seeing what is invisible to others.
> >>>
> >>> --
> >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
> >> Robert P. Dougherty
> >> President
> >> OptiNav, Inc.
> >> 1414 127th Pl NE #106
> >> Bellevue, WA 98005
> >> (425) 891-4883
> >> FAX (425) 467-1119
> >> [hidden email]
> >> www.optinav. com
> >>
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Kenneth Sloan-2
In reply to this post by Michael Schmid
Michael -

Again - thanks for your helpful replies.  After sorting out a few type issues and filling in some fuzzy parts, my
new plugin works perfectly!

One fine point, for which I just need verification.  When my user draws a polygon, and types a key to classify it, I add the Roi to an Overlay (colorized appropriately).  If I do nothing, the Roi remains selected (which makes the outline appear different - probably a feature, not a bug).  But, I want to be completely finished with it.

What I did was:

        ipl.setRoi((Roi)null);

Which seems to do what I expect (the boundary disappears and the next mouse click starts a new polygon)

Is this correct?  Is there some "cleaner" way?

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On Jan 24, 2019, at 12:05 PM, Michael Schmid <[hidden email]> wrote:
>
> Hi Kenneth,
>
> what is in the foreground and accepting KeyEvents?
>
> Is it the image, i.e., the ImageCanvas?
> Then it is fairly easy to intercept the KeyEvents:
>
> The ImageCanvas has previously done
>
>  addKeyListener(IJ.getInstance())
>
> so you can remove this by
>
>  ic.removeKeyListener(IJ.getInstance())
> where ic is the ImageCanvas.
>
> In your own KeyPressed, keyReleased, keyTyped methods, forward events with keys that you don't use to ij = IJ.getInstance(), e.g.
>
> public void keyPressed(KeyEvent e) {
>   if (e.getKeyChar() == 'a')      {  // it is one of my keys
>       #do whatever you like
>   else if (e.getKeyChar() == 'v') {  // also this is one of my keys
>       #do whatever you like
>   } else
>       ij.keyPressed(e);              // ImageJ will handle the rest
> }
>
> Alternatively, selectively forward events for commands that may be used, e.g. keyCodes VK_PLUS, VK_ADD, VK_MINUS, VK_SUBTRACT, VK_4, VK_5 for zooming, VK_SPACE for panning, and all the modifiers VK_SHIFT, VK_ALT, VK_CONTROL, as well as VK_ESCAPE.
>
> Best have one function that decides which keys may be forwarded to ImageJ, and use it in all three listener methods.
>
> When your plugin is done, and the image remains open, don't forget to get ImageJ listen to it again:
>
>  ic.addKeyListener(ij)
>
>
> Michael

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Michael Schmid
Hi Kenneth,

ImagePlus also has a killRoi() = deleteRoi() method.
imagePlus.setRoi((Roi)null) does exactly the same.


Michael
________________________________________________________________
On 25.01.19 02:14, Kenneth Sloan wrote:

> Michael -
>
> Again - thanks for your helpful replies.  After sorting out a few type issues and filling in some fuzzy parts, my
> new plugin works perfectly!
>
> One fine point, for which I just need verification.  When my user draws a polygon, and types a key to classify it, I add the Roi to an Overlay (colorized appropriately).  If I do nothing, the Roi remains selected (which makes the outline appear different - probably a feature, not a bug).  But, I want to be completely finished with it.
>
> What I did was:
>
> ipl.setRoi((Roi)null);
>
> Which seems to do what I expect (the boundary disappears and the next mouse click starts a new polygon)
>
> Is this correct?  Is there some "cleaner" way?
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On Jan 24, 2019, at 12:05 PM, Michael Schmid <[hidden email]> wrote:
>>
>> Hi Kenneth,
>>
>> what is in the foreground and accepting KeyEvents?
>>
>> Is it the image, i.e., the ImageCanvas?
>> Then it is fairly easy to intercept the KeyEvents:
>>
>> The ImageCanvas has previously done
>>
>>   addKeyListener(IJ.getInstance())
>>
>> so you can remove this by
>>
>>   ic.removeKeyListener(IJ.getInstance())
>> where ic is the ImageCanvas.
>>
>> In your own KeyPressed, keyReleased, keyTyped methods, forward events with keys that you don't use to ij = IJ.getInstance(), e.g.
>>
>> public void keyPressed(KeyEvent e) {
>>    if (e.getKeyChar() == 'a')      {  // it is one of my keys
>>        #do whatever you like
>>    else if (e.getKeyChar() == 'v') {  // also this is one of my keys
>>        #do whatever you like
>>    } else
>>        ij.keyPressed(e);              // ImageJ will handle the rest
>> }
>>
>> Alternatively, selectively forward events for commands that may be used, e.g. keyCodes VK_PLUS, VK_ADD, VK_MINUS, VK_SUBTRACT, VK_4, VK_5 for zooming, VK_SPACE for panning, and all the modifiers VK_SHIFT, VK_ALT, VK_CONTROL, as well as VK_ESCAPE.
>>
>> Best have one function that decides which keys may be forwarded to ImageJ, and use it in all three listener methods.
>>
>> When your plugin is done, and the image remains open, don't forget to get ImageJ listen to it again:
>>
>>   ic.addKeyListener(ij)
>>
>>
>> Michael
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: can't getRoi from ImagePlus???

Kenneth Sloan-2
Thanks - I missed killRoi() when reading the documentation. I will change
my code, even if my version “does exactly the same”. You never know when
some future release might add features that require more detailed cleanup.
On Fri, Jan 25, 2019 at 03:03 Michael Schmid <[hidden email]>
wrote:

> Hi Kenneth,
>
> ImagePlus also has a killRoi() = deleteRoi() method.
> imagePlus.setRoi((Roi)null) does exactly the same.
>
>
> Michael
> ________________________________________________________________
> On 25.01.19 02:14, Kenneth Sloan wrote:
> > Michael -
> >
> > Again - thanks for your helpful replies.  After sorting out a few type
> issues and filling in some fuzzy parts, my
> > new plugin works perfectly!
> >
> > One fine point, for which I just need verification.  When my user draws
> a polygon, and types a key to classify it, I add the Roi to an Overlay
> (colorized appropriately).  If I do nothing, the Roi remains selected
> (which makes the outline appear different - probably a feature, not a
> bug).  But, I want to be completely finished with it.
> >
> > What I did was:
> >
> >       ipl.setRoi((Roi)null);
> >
> > Which seems to do what I expect (the boundary disappears and the next
> mouse click starts a new polygon)
> >
> > Is this correct?  Is there some "cleaner" way?
> >
> > --
> > Kenneth Sloan
> > [hidden email]
> > Vision is the art of seeing what is invisible to others.
> >
> >
> >
> >
> >
> >> On Jan 24, 2019, at 12:05 PM, Michael Schmid <[hidden email]>
> wrote:
> >>
> >> Hi Kenneth,
> >>
> >> what is in the foreground and accepting KeyEvents?
> >>
> >> Is it the image, i.e., the ImageCanvas?
> >> Then it is fairly easy to intercept the KeyEvents:
> >>
> >> The ImageCanvas has previously done
> >>
> >>   addKeyListener(IJ.getInstance())
> >>
> >> so you can remove this by
> >>
> >>   ic.removeKeyListener(IJ.getInstance())
> >> where ic is the ImageCanvas.
> >>
> >> In your own KeyPressed, keyReleased, keyTyped methods, forward events
> with keys that you don't use to ij = IJ.getInstance(), e.g.
> >>
> >> public void keyPressed(KeyEvent e) {
> >>    if (e.getKeyChar() == 'a')      {  // it is one of my keys
> >>        #do whatever you like
> >>    else if (e.getKeyChar() == 'v') {  // also this is one of my keys
> >>        #do whatever you like
> >>    } else
> >>        ij.keyPressed(e);              // ImageJ will handle the rest
> >> }
> >>
> >> Alternatively, selectively forward events for commands that may be
> used, e.g. keyCodes VK_PLUS, VK_ADD, VK_MINUS, VK_SUBTRACT, VK_4, VK_5 for
> zooming, VK_SPACE for panning, and all the modifiers VK_SHIFT, VK_ALT,
> VK_CONTROL, as well as VK_ESCAPE.
> >>
> >> Best have one function that decides which keys may be forwarded to
> ImageJ, and use it in all three listener methods.
> >>
> >> When your plugin is done, and the image remains open, don't forget to
> get ImageJ listen to it again:
> >>
> >>   ic.addKeyListener(ij)
> >>
> >>
> >> Michael
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html