Process Virtual Stack...

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

Process Virtual Stack...

Jeffrey B. Woodward
ImageJ'ers,

I have recently been doing a fair amount of work with Virtual Stacks
(both writing new plugins that consume and produce Virtual Stacks and
consuming Virtual Stacks from existing plugins such as
Import->Sequence), and I have come across the following complaint from
one of my users. Operations under the "Process" menu (such as Find
Edges, Smooth, etc) go through all of motions of processing a virtual
stack; however, the outcome of the processing is never realized. I
assume that this is because of the getProcessor() nature of
VirtualStacks makes them effectively readonly and the various plugins
under the Process menu attempt to process the stack in place rather than
returning a new stack for the results. Not sure if this behavior is
considered a bug or not, but it is somewhat frustrating for the end user
(whom may or may not know or understand what it means to be processing a
Virtual stack). Ideally, it would be nice if the plugin were to return a
new stack when attempting to operate in place on a virtual stack;
however, that would probably mean that each such plugin would have to be
modified accordingly. Is there anything that the ImageJ platform can do
to help this situation?

Many thanks,

-Woody
Reply | Threaded
Open this post in threaded view
|

Re: Process Virtual Stack...

Wayne Rasband
On Sep 17, 2008, at 1:24 PM, Jeffrey B. Woodward wrote:

> ImageJ'ers,
>
> I have recently been doing a fair amount of work with Virtual Stacks
> (both writing new plugins that consume and produce Virtual Stacks and
> consuming Virtual Stacks from existing plugins such as
> Import->Sequence), and I have come across the following complaint from
> one of my users. Operations under the "Process" menu (such as Find
> Edges, Smooth, etc) go through all of motions of processing a virtual
> stack; however, the outcome of the processing is never realized. I
> assume that this is because of the getProcessor() nature of
> VirtualStacks makes them effectively readonly and the various plugins
> under the Process menu attempt to process the stack in place rather
> than returning a new stack for the results. Not sure if this behavior
> is considered a bug or not, but it is somewhat frustrating for the end
> user (whom may or may not know or understand what it means to be
> processing a Virtual stack). Ideally, it would be nice if the plugin
> were to return a new stack when attempting to operate in place on a
> virtual stack; however, that would probably mean that each such plugin
> would have to be modified accordingly. Is there anything that the
> ImageJ platform can do to help this situation?

Recent versions of ImageJ display this message when the user attempts
to process a virtual stack using a Process menu command:

       Custom code required to process virtual stacks.

ImageJ 1.41l and later displays this message:

       Custom code required to process this virtual stack
       (e.g., "Process Virtual Stack" macro) or it must be
       converted to a normal stack using Image>Duplicate,
       which will require xxx MB of additional memory.

-wayne
Reply | Threaded
Open this post in threaded view
|

Re: Process Virtual Stack...

Bill Mohler
Wayne-

Are there jar files available for versions after 1.41e?  I can't find
them on the download page.

Thanks,
Bill

>On Sep 17, 2008, at 1:24 PM, Jeffrey B. Woodward wrote:
>
>>ImageJ'ers,
>>
>>I have recently been doing a fair amount of work with Virtual
>>Stacks (both writing new plugins that consume and produce Virtual
>>Stacks and consuming Virtual Stacks from existing plugins such as
>>Import->Sequence), and I have come across the following complaint
>>from one of my users. Operations under the "Process" menu (such as
>>Find Edges, Smooth, etc) go through all of motions of processing a
>>virtual stack; however, the outcome of the processing is never
>>realized. I assume that this is because of the getProcessor()
>>nature of VirtualStacks makes them effectively readonly and the
>>various plugins under the Process menu attempt to process the stack
>>in place rather than returning a new stack for the results. Not
>>sure if this behavior is considered a bug or not, but it is
>>somewhat frustrating for the end user (whom may or may not know or
>>understand what it means to be processing a Virtual stack).
>>Ideally, it would be nice if the plugin were to return a new stack
>>when attempting to operate in place on a virtual stack; however,
>>that would probably mean that each such plugin would have to be
>>modified accordingly. Is there anything that the ImageJ platform
>>can do to help this situation?
>
>Recent versions of ImageJ display this message when the user
>attempts to process a virtual stack using a Process menu command:
>
>       Custom code required to process virtual stacks.
>
>ImageJ 1.41l and later displays this message:
>
>       Custom code required to process this virtual stack
>       (e.g., "Process Virtual Stack" macro) or it must be
>       converted to a normal stack using Image>Duplicate,
>       which will require xxx MB of additional memory.
>
>-wayne