ClusterMF

[Eddymorphling]

Hello, I have been trying to use the Light sheet analysis pipeline on my datasets with the Matlab scripts I downloaded from here - https://static-content.springer.com/esm/art%3A10.1038%2Fnprot.2015.111/MediaObjects/41596_2015_BFnprot2015111_MOESM271_ESM.zip.

I am still in the learning phase and currently am trying to understand how to use the pipeline. I am keen on using the KLB image compression and for this, I have been using the ClusterMF script on my datasets. My datasets are xyzc in dimensions acquired with a single camera. I have four different fluorescent channels in my datasets.

When I run the matlab script, it only create the KLB file format output for just the first and second channels both not the remaining two channels and gives me the following error:

Index exceeds the number of array elements (1).

Error in processTimepoint (line 302)
                    referenceStacks{n} = zeros(heights(c), widths(c), depths(c), 'uint16');

Error in clusterPT (line 422)
                    processTimepoint(parameterDatabase, t, jobMemory(2));

Could you please suggest how I can fix this issue? All my files are named and structured correctly as per the original protocol. I have also created a single xml file for each channel as mentioned in the protocol.

Thank you!

[davidackerman]

The c in that part of the code is the camera index, so the error is implying that there are more cameras specified in cameras than the number of cameras implied by the dimensions of heights, widths and or depths:

From clusterPT.m:

cameras      = [0 1];               % camera indices to be processed

and

widths       = [1148 1148];         % cropping width for each camera (ImageJ-w convention)
heights      = [1468 1468];         % cropping height for each camera (ImageJ-h convention)

% use highly saturated global XZ projection to determine the following two parameters (can be left empty to enforce maximum ROI)
startsFront  = [   0    0];         % cropping front start coordinates for each camera (ImageJ-y convention)
depths       = [ 234  234];         % cropping depth for each camera (ImageJ-h convention)

Do the number of cameras (number of values in cameras) match the number of values in heights, widths and depths.

[Eddymorphling]

Hello David, Yes, I have been using just a single camera and hence set the camera value to be 0 and that seems to fix the issue. Here is what I have been using:

specimen     = 0;                   % specimen index to be processed
timepoints   = 0;               % time points to be processed
cameras      = [0];               % camera indices to be processed
channels     = [0];               % channel indices to be processed

I also set the maximize the ROI size for the camera. So I leave the widths and height to be empty.

startsLeft   = [];         % cropping left start coordinates for each camera (ImageJ-x convention)
startsTop    = [];         % cropping top start coordinates for each camera (ImageJ-y convention)
widths       = [];         % cropping width for each camera (ImageJ-w convention)
heights      = [];         % cropping height for each camera (ImageJ-h convention)

This now works fine and creates a KLB file. Now the output KLB is always a mirror image when compared to the input TIFF files. Is there anyway to fix that?

Also if I have three specimens to be processed inside the input folder, how do I mention that in the code above, so that it processes all the specimens in a single round. Currently I am processing them one by one by changing:

specimen = 0; % specimen index to be processed instead of 0, I change it to 1,2 or 3

[davidackerman]

Glad you were able to fix the first issue!

As for the KLB mirror image, I am not sure. What direction are they mirrored in? Are you specifying the dimensions yourself? If not, are they correct in the XML? Is rotation set to 0? Does this still occur if outputType is set to 2 (Tif)?

As for multiple specimens, you may just need to surround everything with a for loop. So you would have eg.

specimens = [0,1,2]
for specimen = specimens
      %REST OF CODE GOES HERE
end

[davidackerman]

Also, does the mirroring happen with the example data provided here: https://static-content.springer.com/esm/art%3A10.1038%2Fnprot.2015.111/MediaObjects/41596_2015_BFnprot2015111_MOESM271_ESM.zip ?

[Eddymorphling]

So I tried specimens = [0,1,2] and looped the rest of the code, but it still only runs for one specimen. Also, I can still work around this by doing it one by one. So its ok :)

The rotation is set to 0. Strange thing is that this only happens for KLB, when I output them in TIFF, it does not get rotated. I have only done this on my dataset so far. Here is a screen shot of what I mean. The left image is the raw TIFF stack, middle one is the KLB file of the same stack, while the one of the right is the same file has been output in the TIFF format. I have only tested the code on my datasets so far.

[davidackerman]

It seems to be swapping the x and y axes. I checked and it does appear when loading the example images in Fiji. It is possible that the data is the same, but that Fiji swaps the axes when loading. I will try to find out more.

[davidackerman]

Nice catch by the way! As per Philipp Keller:

Yes, the axes are indeed flipped when comparing the TIFFs and KLB files. This issue is not so much related to our code but rather to the uncommon axis definitions used by Matlab (which are flipped compared to e.g. the Fiji coordinate system) and the way the TIFF reader/writer is implemented (not written by us). Opening TIFF files in Matlab flips the axes and they are then flipped again when saving the files in TIFF format (such that no transformation is apparent to the user). However, when converting images from TIFF to KLB in Matlab, only one transformation takes place (the one triggered by opening the TIFF files). We did not correct for this, since this is specific to how the TIFF readers and writers are implemented – other input/output libraries do not usually include such a transformation, and we thus did not want to make such an enforced transformation a “feature” of the KLB libraries either. Ideally, one would fix the TIFF libraries, but this would then also have to be considered in the rest of the code.