http://imagej.273.s1.nabble.com/Overlays-from-Java-2nd-try-tp5021416p5021421.html
Thanks for the reply. I'll look at the code and see what makes sense.
editing of the overlay is NOT a good reason to extend it further.
Question: given that the Paintbrush Tool draws on an RGB ImageRoi - is it feasible to *find* that Roi
attached to an image (or stack)? The only distinguishing feature I would need is the information that
it is an *Image* ROI. My *guess* is that there would be two ImageRoi's associated with the image - one
But...at least *reading* the BrushTool.java code will probably answer all of my questions.
I have resisted creating customized versions of tools that already exist - but this may be the time to revisit that
practice.
Again - thank you for the rapid reply.
Vision is the art of seeing what is invisible to others.
> On 6 Nov 2018, at 11:59 , Wayne Rasband <
[hidden email]> wrote:
>
>> On Nov 6, 2018, at 8:44 AM, Kenneth Sloan <
[hidden email] <mailto:
[hidden email]>> wrote:
>>
>> I'm trying to control Overlays from Java. What I *think* I need is:
>>
>> a) initialize Overlay from an image (that's easy enough)
>> b) EDIT the Overlay (preferably using one of the two Brush tools)
>> c) extract the edited Overlay as an Image
>
>
> You could create a custom version of the PlugInTool that implements the Paintbrush Tool.
>
>
https://github.com/imagej/imagej1/blob/master/ij/plugin/tool/BrushTool.java <
https://github.com/imagej/imagej1/blob/master/ij/plugin/tool/BrushTool.java>
>
> The Paintbrush Tool draws on an RGB ImageRoi in an Overlay when “Paint on overlay” is checked in the options dialog. I do not see a need to extend StackWindow.
>
> -wayne
>
>
>> All of this over an (extended) ImageStackWindow.
>>
>> I *think* I see a way forward - but I can't find documentation. I'll start experimenting
>> today. Any clues that will speed that up will be welcome.
>>
>> My other option is to select a single (grey) image from the Stack, form a Composite with the
>> (binary) overlay) and use the Brush Tool to draw in RED (to draw) and GREEN (to "erase"). The major
>> issue here is that the drawing is destructive. I would fix that by iterating on the editing process,
>> periodically refreshing the binary overlay and re-constructing the composite image. This has worked
>> for me in the past, but feels clunky.
>>
>> Most likely, my problem has to do with ignorance of ROI processing, and the details of how to get at the
>> results of the Overlay created/modified by the two brush tools.
>>
>> While I'm at it - is my best bet the Overlay Brush tool, or the normal Brush tool with the "draw in overlay" box checked?
>> What are the practical differences?
>>
>> My current plan is to assume that the Brush Tools leave behind a record of what they do in *some* ROI attached to the image (or the ImageStackWindow). I already have a few purely graphic overlays in use - but presumably I can go through all the overlays
>> associated with the StackWindow and pay attention to the "image" overlays. I'm confused about whether to expect many of these, or just one. I can find out by doing experiments, but I hate to base an application on empirically derived information - I'd prefer authoritative documentation.
>>
>> What should I read?
>>
>> Does anyone have sample (Java) code for the three basic operations above?
>>
>> I am always impressed by the speed and usefullness of replies - the silence greeting my first plea for help is a but puzzling.
>> Perhaps my message did not go through; perhaps it's just hard?
>>
>> Hoping against hope - does anyone have an "Edit Mask" plugin (in Java, preferably). This task feels fairly generic - given a maxk, allow the user to edit it. I can live with editing while referencing a SINGLE image - or modify two work with a Stack.
>>
>> My last resort is to further extend the StackWindow to include mask editing. I really prefer to use the standard tools whenever possible.
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html <
http://imagej.nih.gov/ij/list.html>