Multi-D Acquisition saved image stacks are fault and refuse to open in Icy

Home › Forums › Bug Reports › Multi-D Acquisition saved image stacks are fault and refuse to open in Icy

Tagged: ,

  • MasoudR June 18, 2019 at 10:21 pm

    Hey Icy crew,

    my post was automatically marked as spam so I’m trying again without the embedded images…

    I’m having some trouble with my Icy-MicroManager saved Image stacks of multiple positions. I’m having several issues so I’ll cut this post into parts:

    1. Opening a file through drag and drop or the Recent Files menu gives an error:

    This is making the only way for me to open image stacks through the ‘Open…’ file browser.

    java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
at java.util.ArrayList.get(ArrayList.java:433)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:688)
at loci.formats.FormatReader.setId(FormatReader.java:1397)
at plugins.kernel.importer.LociImporterPlugin.openReader(LociImporterPlugin.java:939)
at plugins.kernel.importer.LociImporterPlugin.open(LociImporterPlugin.java:853)
at icy.file.Loader.internalLoadSingle(Loader.java:3764)
at icy.file.Loader.loadSequences(Loader.java:3237)
at icy.file.Loader$9.run(Loader.java:2663)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

           2. Saved image stack from multiple-positions acquisition is a mess of what seems to be a mapping of the other positions.

    I’m using multiple positions, using default position names (Pos0, Pos1, etc.). When I open the first file (Pos0) I get this odd mess of miniature versions of what seems to be the first image of all the other image stack files jumbled into small squares.

    I remember that in an older version of Icy, when I dragged and dropped such a file into icy it would open a window where I could select which files from that acquisition I wanted to open (e.g. just Pos 0, Pos3 and Pos4 if I wanted). Perhaps this is an error caused by something going wrong with that function?

    These files open properly in ImageJ, so there doesn’t seem to be anything wrong with the image stack itself. I’m not sure if this only happens with the first file (Pos0) or if the others are a similar mess, the reason I can’t determine this is my final point.

           3. Opening a file from such an acquisition (lets say Pos2), will automatically open Pos0 instead.

    No matter which one you select you will automatically get Pos0. Again, this does not happen in ImageJ so the files can still be accessed there.

    Looking at the sequence properties we find that the path points to the correct file, Pos2, yet the name and the contents of the file are Pos0:

     

    Any idea if this could be my mistake somehow, or if it is something that has been wrong with the Icy program or MM plugin?

    Let me know if you need my files. I’ll provide a MEGA link since the smallest acquisition data set is 200MB.

     

    Stephane Dallongeville June 19, 2019 at 1:15 pm

    Hi Masoud,

    We will try to replicate your different problems using Micro-Manager with Multi-D acquisition and multi position and get back to you after our discovers. About the automatic stitching problem : you can disable it, just select “separate files” for grouping mode :

    So it will allow you to open independent image, otherwise grouping will automatically try to stitch all the position acquired to build a big image out of it.

    Best,

    – Stephane
    MasoudR July 4, 2019 at 11:09 am

    Hello Stephane,

    Did you have any luck replicating the problems?

    I’ve tried opening my tif files with the “Seperate files” option now and it gives me another error:
    Java.lang.IndexOutOfBoundsException: Index 1 out-of-bounds for length 1
    at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
    at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Unknown Source)
    at java.base/jdk.internal.util.Preconditions.checkIndex(Unknown Source)
    at java.base/java.util.Objects.checkIndex(Unknown Source)
    at java.base/java.util.ArrayList.get(Unknown Source)
    at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:688)
    at loci.formats.FormatReader.setId(FormatReader.java:1397)
    at plugins.kernel.importer.LociImporterPlugin.openReader(LociImporterPlugin.java:939)
    at plugins.kernel.importer.LociImporterPlugin.open(LociImporterPlugin.java:853)
    at icy.file.Loader.internalLoadSingle(Loader.java:3764)
    at icy.file.Loader.loadSequences(Loader.java:3237)
    at icy.file.Loader$5.run(Loader.java:2303)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)
    They do open without error in imageJ

    One of my image stacks: https://ufile.io/lmgbqdvi

    • This reply was modified 4 years, 9 months ago by
      MasoudR      .
    MasoudR July 4, 2019 at 11:11 am

    Hello Stephane,

    Did you have any luck replicating the problems?

    I’ve tried opening my tif files with the “Seperate files” option now and it gives me another error:

    Java.lang.IndexOutOfBoundsException: Index 1 out-of-bounds for length 1
at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Unknown Source)
at java.base/jdk.internal.util.Preconditions.checkIndex(Unknown Source)
at java.base/java.util.Objects.checkIndex(Unknown Source)
at java.base/java.util.ArrayList.get(Unknown Source)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:688)
at loci.formats.FormatReader.setId(FormatReader.java:1397)
at plugins.kernel.importer.LociImporterPlugin.openReader(LociImporterPlugin.java:939)
at plugins.kernel.importer.LociImporterPlugin.open(LociImporterPlugin.java:853)
at icy.file.Loader.internalLoadSingle(Loader.java:3764)
at icy.file.Loader.loadSequences(Loader.java:3237)
at icy.file.Loader$5.run(Loader.java:2303)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

    They do open without error in imageJ

    One of my image stacks: https://ufile.io/lmgbqdvi
    MasoudR July 4, 2019 at 11:11 am

    Hello Stephane,

    Did you have any luck replicating the problems?

    I’ve tried opening my tif files with the “Seperate files” option now and it gives me another error:

    Java.lang.IndexOutOfBoundsException: Index 1 out-of-bounds for length 1
at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Unknown Source)
at java.base/jdk.internal.util.Preconditions.checkIndex(Unknown Source)
at java.base/java.util.Objects.checkIndex(Unknown Source)
at java.base/java.util.ArrayList.get(Unknown Source)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:688)
at loci.formats.FormatReader.setId(FormatReader.java:1397)
at plugins.kernel.importer.LociImporterPlugin.openReader(LociImporterPlugin.java:939)
at plugins.kernel.importer.LociImporterPlugin.open(LociImporterPlugin.java:853)
at icy.file.Loader.internalLoadSingle(Loader.java:3764)
at icy.file.Loader.loadSequences(Loader.java:3237)
at icy.file.Loader$5.run(Loader.java:2303)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

    They do open without error in imageJ
    MasoudR July 4, 2019 at 11:24 am

    I just tried it with an older version of Icy: Icy 1.9.7.0

    With this, I can open my files. Using Seperate Files it gives me the series selection window, allowing me to open all files in a group.
    When using Group Files it gives me the tiled image again.

    With this, I can atleast analyse my data now using an older version. But it would be nice if this was fixed soon.

    Stephane Dallongeville July 4, 2019 at 4:44 pm

    Hi Masoud,

    After having investigating several hours about this problem, i can confirm you this is definitely a bug with Bio-Formats :-/ Icy is using version 5.9.2 of Bio-Formats but it looks like the bug is also present on the last version anyway.

    The problem comes from when we force un-grouping files (which Icy does when you select Separate files and when using drag & drop operation for a single file, ImageJ is always using grouping), in this case Bio-Formats has a bug parsing metadata of this multi series OME TIFF files.

    The bug happen at line 688 from loci.formats.in.OMETiffReader class in initFile(..) function :

    
Pixels pix = img.getPixels();
List<Plane> planes = pix.copyPlaneList();
for (int p=0; p<planes.size(); p++) {
  Plane plane = planes.get(p);
  if (plane.getTheZ().getValue() >= core.get(i).sizeZ ||
    plane.getTheC().getValue() >= core.get(i).sizeC ||
    plane.getTheT().getValue() >= core.get(i).sizeT)
  {
    pix.removePlane(planes.get(p));
  }
}

    I guess they should used pix.getSizeZ() instead of core.get(i).sizeZ as at this point as core isn’t yet fully filled.

    Still hopefully there a way to display a single dataset, just try to open the associated metadata.txt file instead of the .tif file, in my case that is enough to get the proper dataset to open (unfortunately we cannot just disable un-grouping as other things would break).

    Hope that helps.

    – Stephane

    Stephane Dallongeville July 4, 2019 at 4:51 pm

    I realized you can exhibit the same bug in ImageJ by forcing un-grouping :
    MasoudR July 5, 2019 at 3:31 pm

    Dear Stephane,

    Thank you for all the support.

    Sadly some of the people in my lab have not turned on the option to create the metadata files, is there any other way to open them?

    Does OME know about the issue with bio-formats? Could Icy use a previous version where the bug is not present until they fix it?

     

    Cheers,

    Masoud

    Stephane Dallongeville July 10, 2019 at 2:33 pm

    Dear Masoud,

    I tried to find a way so you can open them in Icy, but the fastest solution i found is to drag the image on ImageJ app (into Icy) so it will open the image through ImageJ then convert it back to Icy format.

    We cannot revert on older version of Bio-Formats as there is others issues with them (it may fix this one, but bring others issues). What we can do is to patch the code ourself, that might be possible and probably the fastest way to go.

    Best,

    – Stephane

Viewing 10 posts - 1 through 10 (of 10 total)

The forum ‘Bug Reports’ is closed to new topics and replies.