Posted by
Michael Schmid on
Nov 27, 2019; 7:49pm
URL: http://imagej.273.s1.nabble.com/confusing-overlay-behavior-tp5022716p5022717.html
Hi Kenneth,
for troubleshooting, if you know how many objects to expect in the
overlay, you can try this simple Javascript:
imp=IJ.getImage();
IJ.log(imp.getTitle());
ovly=imp.getOverlay();
IJ.log("overlay="+ovly);
It will show something like this:
blobs.gif
overlay=Overlay[size=1 none]
Here, the 'blobs.gif' image has one object in the overlay.
It might show whether there are maybe more objects in the overlay that
you are aware of; maybe the old ones did not disappear but are invisible
for some reason.
Alternatively, use Image>Overlay>To ROi Manager to see what you have in
the overlay.
Please beware that not everything that looks like an overlay is
necessary in the Overlay class (the basis for the Image>Overlay
commands). The Overlay class was added to ImageJ around version 1.30.
Prior to that, other mechanisms have been used to draw overlays (e.g.,
replacing the ImageCanvas with a custom one that draws the overlay). If
you happen to have an overlay drawn by such a legacy method, it won't be
saved with the image.
If you have such legacy code, it might also hide the contents of the
Overlay class ("modern-type overlay") without actually removing the overlay.
---
"Stack to Images" indeed checks that there is currently more than one
stack slice; for single images it produces an error message. See
ij.plugin.StackEditor, method convertStackToImages (line 253).
If there is only one stack slice, what else should it do? Leave the
image as it is? Then the (interactive) user (who might erroneaouly
believe that he/she has a stack with several slices) will be astonished
that the command does nothing; maybe wait a few seconds whether the
computer is slow, retry, and it still does not work. This could lead to
frustration...
When running it non-interactively, it is easy to check for a stack size > 1.
Michael
________________________________________________________________
On 27.11.19 19:14, Kenneth Sloan wrote:
> I'm just starting to debug this, and I apologize for the complexity - but I'm hoping this might ring a bell with someone.
> As I proceed to investigate, I'll try to produce a minimum implementation that duplicates the problem.
>
> Java Plugin
> *creates two windows
> *a StackWindow (which for this processing contains only 1 image - 32-bit)
> *a second StackWindow (containing multiple images - not used further)
> *these are both specialized Classes that extend StackWindow and contain objects which
> extend ImagePlus. It may be relevant that these windows talk to each other, and
> redraw their overlays based on cursor movement.
> *under user control, one of many different Overlays may be drawn on the first StackWindow.
> This overlay completely replaces the old Overlay. It is displayed perfectly.
>
> Now...I want to save the resulting image, including the new Overlay.
>
> Problem 1 - given that there *might* be several images in the stack, I tried Image->Stacks->Stack to Images
>
> This FAILS when there is only 1 image in the stack. Why? is an ImageStack with only 1 image NOT considered to be
> a Stack?
>
> Pushing through, I then try File->Save As->TIFF (I also tried JPG).
>
> This writes a file just fine - but when I look at it - I see the OLD Overlay. Note that this old Overlay is NOT visible on the screen when I do the Save. And, the new Overlay is *still* displayed after the Save.
>
> So...does Save As use some hidden version of the Stack which may not be in sync with what is displayed on the screen???
>
> I also tried Image->Duplicate. I get a second copy of the image, but with the OLD Overlay. The original version remains displayed with the NEW Overlay.
>
> I'm stumped.
>
> I would be happy to send the actual plugin, and test data, to anyone with the energy to deal with it - but it's really much too much to ask. In the next day or two, I will try to write the smallest possible plugin that replicates this behavior.
>
> In the meantime - any ideas???
>
>
> As it turns out, our actual need for this can be satisfied by taking a ScreenShot. So, it's not critical. But, I'm astounded that Image->Save As and Image->Duplicate do not reproduce the image as displayed on the screen. This seems to be a very basic requirement!
>
> One theory - does Image->Save As and Image->Duplicate somehow duplicate the underlying ImagePlus - and then manipulate it without display? Note that my images are using an EXTENSION of ImagePlus that re-draws the original Overlay - usually based on cursor movement. If the ImagePlus is somehow duplicated...and then manipulated off-screen...it's possible that the original Overlay is re-drawn on the off-screen version.
>
> Which leads to: is there a convenient way to ask ImageJ to save the *displayed image* (in any format). Something like "PrintWindowContents" or some such? What I want is an image file (an RGB PNG would be perfect).
>
> note: I just tried changing the TYPE of the image to RGB and then saving as TIFF. No joy. The conversion worked fine, but the resulting image had the OLD Overlay.
>
> So...I'm back to: how can I save an RGB version of an ImageJ window *as currently displayed on the screen*. I prefer an image without the framing, but I don't want to rely on the standard ScreenShot mechanism which (I think) requires me to precisely pick the corners of the window.
>
> That would be a "workaround". I'm (eventually) interested in knowing WHY Image->Save does NOT write an image file representing what is actually displayed on the screen.
>
>
> --
> 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