Drawing roi is slow

memory
fiji
roi
Tags: #<Tag:0x00007fd548488f58> #<Tag:0x00007fd548488af8> #<Tag:0x00007fd548488738>

#1

I am trying to draw ROIs over a 16 bit image. It is very slow indeed. I searched google and increased the memory (it was at 5000 but increased to 8000 mb, well enough!). The threads is 4.

I additionally tried the infinity divide by zero don’t command at start up (suggested on another thread for MacOS).

Is it just slow for 16bit images or am I missing something?

Thanks!


#2

I should mention that I am using Fiji (latest version) ImageJ 1.51K, Java 1.8.0_66 (64 bit)
It says using <1% 8000 of memory.


#3

Good day!

May I ask how you “draw” the ROIs?

I’ve just drawn a selection (ROI) with the freehand tool onto a 2048x2048 16bit canvas and everything works as expected.

Please be more specific with respect to how the drawing is slow and how big your images are.

Regards

Herbie


#5

Hi Herbie,
I just use the polygon tool to make multiple clicks.
I just tried to freehand and it, too, is slow. Makes me think it’s a setting or something, unless there is something else within the picture meta-data that can be useful…

Sorry, picture is quite large 3115.91x2039.32 microns(units) (9632x6304); 16bit; 232 MB

When I say the drawing is slow, I mean each point takes a few seconds to be placed and then a couple of other seconds for the “line” to connect to dots.


#6

:smiley: It took me a little while to find out that you mean this post, right?

Did you verify that the Don’t set Mac menu bar setting is actually checked in Edit > Options > Misc…?


#7

Dear,

thanks for specifying the behavior!

With your data specified, I must admit that I have no idea what goes wrong on your side.

I just tried a polygon selection in a 16bit image of exactly the size you’ve specified and I can’t see a significant slow down in drawing compared to the 2048x2048 16bit image used before. However, I’m on the fastest current iMac.

What appears strange to me is that you report an image size of 232Mb while mine is 116MB (as indicated in the subtitle).

Sorry, no help …

Herbie


#8

Hi Herbie,
It may have to do that these images are extracted from a VSI file using the BIOP VSI reader plugin. However, I draw a rectangle and extract that ROI, so essentially the rectangle is its own picture.

Well, it bother me that I specify so much memory but it doesn’t seem to use that alotted amount ? Maybe I am doing something in correct

Imagejan:
I am actually running Windows 10, 64x, 8GB RAM


#9

Dear,

if what you wrote earlier

It says using <1% 8000 of memory

is true and your computer has 8GB of RAM installed, then this is by far a suboptimum situation, because the maximum memory set for ImageJ is recommended to be 75% of the installed RAM.

Besides this, you should try to find out what makes the image larger in memory than one generated in ImageJ. Since it is just has double size, I guess it is either a 32 bit image or it is a stack with two slices.

Clueless

Herbie


#10

Oh, yes, Herbie. I forgot about the second channel. It is indeed two slices!
Yes, I was concerned, as well, about the <1%. Do you know how to fix this? I also changed it to run it at high priority, to see if that would force anything.

Any help?


#11

Well,

for changing the memory setting of ImageJ go to

Edit > Options > Memory & Threads…

set the Maximum memory to 6000 MB.

• Don’t check “Keep Multiple undo buffers”.

• Check “Run garbage collector on status bar click”.

Now, after you’ve extracted the rectangular excerpt from the original stack, click onto the ImageJ status bar (under the tool icons). You may click several times until the reported memory consumption does no longer change.

Finally, start the ROI-selection and please report the result.

Regards

Herbie


#12

I extracted the rectangle from the image.

I then hit the status bar until the memory stablised at 449 MB. The extracted rectangle is still 2 channels. Do you think it would be better to split the channels at this stage?

The drawing of roi is still very slow.

I should mention that 1 micron here = 3.01… pixels
and size is 3167x2008 microns, or 9792x6298 pixels


#13

Dear,

you could just try splitting the channels, save and close them and reopen only one.

You may also create a test stack of the same size in ImageJ by

File > New > Image…

Set the parameters as shown here:

If the drawing is still slow it may either be due to your CPU or it is caused by

Java 1.8.0_66 (64 bit)

I still use Java 1.6.0_65 (64 bit).

If your CPU has several cores you may enter the according number of “Parallel threads” in

Edit > Options > Memory & Threads…

Good luck

Herbie


#14

Hm yes, It is fine if I create a new file with same dimensions and slices.

I have 4 entered in parallel threads.

It leads me to believe it is something within the image itself.

I then split the original file by Image>stacks>Stack to Image. Saved the one channel and reopened it. It works good.

So, it is something with having 2 channels of that big of size with the pixel density ?


#15

You wrote:

Hm yes, It is fine if I create a new file with same dimensions and slices.

Does this mean that drawing a selection to this test stack isn’t slow?

If this is the case, then something is wrong with your excerpt image. Did you save it as a TIFF-stack?

If this is not the case, then I think it is the CPU or do you have the images on a server and not in local memory. If the former is the case, then you are limited by the LAN-speed. And finally it may also be a problem with Java 1.8.0.

No other ideas yet …

Best

Herbie


#16

"Does this mean that drawing a selection to this test stack isn’t slow?"
Yes, on the test stack, it is fast

“Did you save it as a TIFF-stack?” - went to Save As-> Tiff. So I am assuming this is a Tiff Stack

Yes, the extracted rectangle is saved as a tiff with 2 channels

see this: I then split the original file/extracted rectangle stack by Image>stacks>Stack to Image. If I try to draw ROI on one of the split images, it is still slow; however, if I SAVE the split images, close the split images, the reopen the 1 split image, it is fast!

So, I am wondering if it is setting some settings that aren’t modified even when image is split… They only change when it is “refreshed” (ie, split images closed and reopened)


#17

From my point of view you’ve now tried a lot already …

What puzzles me most is that making a ROI selection in the test stack is normal.

What happens if you don’t split channels of the excerpt stack, save it iin TIFF-format, close it and finally reopen it for ROI generation.

Make sure that no other images are open in ImageJ before reopening the excerpt stack.

Also click onto the ImageJ status bar to free memory before reopening the excerpt stack.

Best

Herbie


#18

Hi Herbie,
I have saved my file again and cleared excess memory and then reopened. Still slow.
I noticed that my files were saved in *tif and not *tiff, so I explicitly save it as *tiff (for some reason who knows if that would help!). No dice. Still slow.

It must be something inherent in the image? Would it help if I pasted the image details?

I will try to fool around with some other file extensions to see if anything help, as well.
Also trying to compare the test image with 2 slices that we made earlier with one of my images. Would it help/be faster if I gave you one of my images ?

EDIT: I noticed that the file info is very different for the two. For one thing, my images come from a microscope and as such has all the metadata attached to it. But I guess that doesn’t explain why ROI drawing becomes faster when split the channels and save separately. Hm

Thanks for all your time and advise!


#19

Dear,

no need to play with suffixes, “.tif” is perfectly ok.

It must be something inherent in the image?

Evidently yes, but what?

It would be interesting how you open the original and evidently very big stacks in ImageJ.
Do you use BioFormats?
Are there any Metadata with the stacks?

As far as I understand the forum regulations, TIF-stacks cannot be uploaded (I may be wrong though and you may simply try it). It could help to see a smaller excerpt. In case it is not possible to upload it here you may try to upload it to a server and communicate a link to it here.

Best

Herbie


#20

https://drive.google.com/file/d/0Bx_6ImrbCu4lT25pZG0wRDhMQ2M/view?usp= sharing

Please see attached link for download. Please delete the space between the “=” and “sharing” at the end of the link. It was trying to automatically upload the file when I pasted the link normally.

Hopefully we can eliminate the possibility of ImageJ/Fiji and Java version difference being the culprit!
Also, I imagine the metadata tags along with the image you download – if not, let me know!

I do not know what you mean by BioFormats, I guess. I see it is a plugin (googled it). What I do is I open a very large microscope image with VSI Reader (http://biop.epfl.ch/TOOL_VSI_Reader.html) plugin, because it has a *vsi extension and it part of a very large group of images (2 channels each image), I open a single image from a list of the images included in the *vsi file. I then draw a rectangle ROI and save that small extracted rectangle as tiff. I then open the extracted rectangle simply by dragging the tiff into the imagej bar. I do not explicitly use a special program to open that extracted rectangle.

I would say opening the very large, multiple images is the problem but even when I extract the rectangle from one image and completely close everything (including restarting Fiji) and only open the extracted rectangle, it is still slow.

Anyway, hopefully the attached link works! Let me know if not


#21

Thanks for the upload.

The stack arrived savely. Hippocampus I guess …

Now please try the following:

Image > Color > Channels Tool…

In the Dialog window set the drop-down menu to “Grayscale”.
This appears possible because the two slices in fact don’t contain color information, they are in fact monochrom (slice 1: red, slice 2 green).

With this choice, drawing ROIs should be as expected.

You can always go back to color if you like.

Why this drawing problem exists, is unclear to me and I don’t have the time to analyze the source code. Perhaps Wayne may have a look at this problem. I’m sure the behavior is unintended and may be remedied.

So for the time being, I hope you can continue with your work.

Regards

Herbie