New ICY Version slower and ROS protocol readings differs to manual readings

Usage & Issues
,
#1

We had an issue where if the newer version of ICY (version 2 and higher) was used, the videos we wanted to analyse took extremely long and required more memory when passing through the intensity projection tool compared to the older version (version 1.8.0) which didn’t require as much memory and handled the videos (that were 4-8 seconds long) very quickly with the intensity projection tool. To give an example, we would allow a protocol to run for 14 hours and only 13 videos would have been completed. Could this be an issue with the newer ICY versions? Protocol is pasted below:

Final work_protocol_ICY_Exflagellation.protocol_screenshot
Final work_protocol_ICY_Exflagellation.protocol_screenshot1349×881 195 KB

We also have a problem in that our protocol gives ROS numbers that differs from the ROS numbers obtained from manually reading the videos with ROS Statistics, even though the exact same parameters are being used. Example, for our drug controls we would identify 15 ROS centres but manually reading the video would show 0 centres. I saw this problem was already posted on the old ICY forum and had been solved however, the solution to the problem is somewhat unclear to me. Could you please elaborate on how to adjust our protocol so we could obtain the same results as manually reading the videos? Thank you in advance for your help in this matter. :smiley:

#2

Dear Ashley,

Thank you for reporting this issue about the Intensity Projection block being slower with version 2.0 and higher compared to version 1.8.0. Another user from our institute recently reported internally the exact same issue. The more bug report we get on the same issue, the easier it is for us to troubleshoot it. We will investigate, but this kind of issue could take some time to solve.

I see two ways to quickly go around:

  1. either use version 1.8.0 instead of 2.0
  2. or replace the block Intensity Projection by the block CLIj2_standard deviation Z projection from Clicy:
    CLIJ2_block_standard_deviation_block
    I would do something like that in between the Extract channel block and the Wavelet Spot Detector block:
    protocol_with_standard_deviation_projection_Clicy.protocol_screenshot
    protocol_with_standard_deviation_projection_Clicy.protocol_screenshot1134×578 88 KB

    Link to upload this piece of protocol: protocol_with_standard_deviation_projection_Clicy.protocol (6.0 KB)
    I call in the developer of Clicy @haesleinhuepf regarding this second solution.

Regarding the differences between the number of ROIs found manually and with the protocol, could you provide the link to the post on the old forum that was addressing this issue?

Best regards,
Marion

1 Like
#3

Hey @MarionLouveaux

what a great idea :slight_smile:

Just a minor addendum: Call release_buffer on all images in the GPU (input image, the one projected and the one blurred):

protocol_with_standard_deviation_projection_Clicy2.protocol_screenshot
protocol_with_standard_deviation_projection_Clicy2.protocol_screenshot1127×621 91.7 KB

protocol_with_standard_deviation_projection_Clicy2.protocol (7.0 KB)

I hope in a future release we can get rid of these blocks, but for now we need to stick them everywhere where an image is no longer forwarded to another block :wink:

Cheers,
Robert

2 Likes
#4

Thank you so much. I will try that out! I forgot to mention with the older versions (v 18.) although it manually read the videos faster when we tried to make a protocol with the older version we got an error (screenshot is attached below).

image (6)
image (6)1366×768 89 KB

Below is a link to a query from the old forum that had a similar problem regarding ROI differences between manual and protocol output obtained from ROI statistics. It seems to have been solved but I am unsure how they did this.
Link: http://icy.bioimageanalysis.org/support/topic/inconsistencies-in-roi-statistics-outputs/

#5

Dear Ashley, Dear Robert,

Thank you @haesleinhuepf for the tip about Clicy!!

@Ashley_VH, as there is also a bug with Icy version 1.8, I would recommend to try Clicy.
Thank you for the link to the old post. In that case, it seems that there was a difference of pixel size between the original image and the binary image. I am not entirely sure you have the same issue here. I would need to try the protocol myself to figure it out.
However, I would already try the following and see if the values are still different:
I would remove the block ROI to detection and directly link the list of ROI output from the Connected Component block to the Region of Interest input from the ROI Statistics block and connect the output sequence from the Connected Component block to the Sequence input from the ROI Statistics block.
Note that, if you want to compute fluorescence intensities, the Sequence input should be connected to the original image, not to the binary image. Maybe this could also explain the discrepancy between the values found manually and with the protocol.
I still call in @Stephane, who answered this post on the Icy forum, in case he has other ideas.

Best regards,
Marion

1 Like
#6

@Ashley_VH Just to notify you that we fixed the Intensity Projection plugin and should now perform much faster ! Sorry for the long delay but we had time to tackle that just recently !

Best

– Stephane

1 Like