Z coord of Timepoint seen as Z steps

[open-science-tools]

Z coord of Timepoint seen as Z steps

[bioimage-analysis]

Hi Ruben,

Thank you for the quick fix, I tried it with multiple files and it seems to work well.

[ggirelli]

Hi all, sorry for the late reply. The fix works perfectly also with my files, thank you! :)

[bioimage-analysis]

Just a little comment on the _parse_z_levels function I wrote previously, I took it from Github but the if 0 != len(z_levels): didn't make a lot of sense, in the PIP version it is actually if 0 == len(z_levels):. In any case, I just wonder why putting that exception?

[rbnvrw]

Thank you very much for submitting the issue. That is indeed not the intended behavior. I quickly checked one of my files (x, y, and time series) and did not reproduce the same behavior:

Specifically, z_levels is empty and z_coordinates is populated. I think this makes sense: the position of the stage is saved for every timestep and can be retrieved via z_coordinates, which might be useful for some applications.

For this specific file, I get this:
TextInfoItem_5 => Metadata: Dimensions: T(6810)

So there is no additional color channel like you're getting, but otherwise it seems fine.
I think the GitHub function is actually correct.

z_levels = self._parse_dimension(r""".*?Z\((\d+)\).*?""")

Parses the amount of Z levels from the Dimensions metadata field. If there are no Z levels, this is empty.

if 0 != len(z_levels):

Ensures that we only add the Z levels when the Dimension field contains them.

However, the following block seems strange:

z_levels = parse_if_not_none(self.z_data, self._parse_z_coordinates)
if z_levels is None:
    z_levels = []
else:
    z_levels = range(len(z_levels))
    warnings.warn("Z-levels details missing in metadata. Using Z-coordinates instead.")

What I think should happen, is that we just return z_levels = range(len(z_levels)) here. However, the problem is that I don't have any ND2 files with different Z levels available to test at the moment.

If you have some, could you maybe send them to me?

[rbnvrw]

Actually, I now found that this functionality was added in PR #28 to fix issue #27. Maybe it depends on how NISElements saved the file exactly.

[ggirelli]

Hi @rbnvrw !

I think the issue could actually be this line: if 0 != len(z_levels):

The idea of PR #28 was to use the 'z_coordinates' metadata field instead of 'z_levels' when the latter is missing but the former is present (as I have encountered this in some nd2 images).

If the condition above is !=, then this becomes the default behavior while it should happen only when the former is absent.

Not sure how this behaves in timecourse images, especially if the stage Z position fluctuates a bit and this is recorded in the metadata...

[bioimage-analysis]

Hi Gabriele and Ruben,

First @ggirelli, actually if you look at my second post, the version of nd2reader in PyPi is actually if 0 == len(z_levels): and behave as expected.

@rbnvrw I think the expected behavior for the function is if no Z is found in the dimension part of the metadata, it looks into z_coordinates.

If you look at the following file:
Seq0000.nd2.zip
you will see how it behave.

I have other similar files, the idea is Elements acquire a z coordinates for each time point for a lot of the files, but not all, unfortunately I can't access the microscope at the moment to check why and in which condition. Also in @ggirelli PR #28 file, it seems that there was no dimensions part in the metadata, not sure why. It might be a little heavy but maybe before if 0 == len(z_levels):, it might be worth checking if there is a dimensions part in the metadata as such, Metadata: Dimensions as an extra precaution?

[rbnvrw]

Hi both, thank you for your help!

It seems that there are three cases:

Case 1: the 'Dimensions: ' textinfo item contains a part with 'Z'. Then we can just return a list of the z levels.

Case 2: the 'Dimensions: ' textinfo item is there, but it does not contain any information on 'Z'. In that case, we should not use the z coordinates as a fallback for the z_levels, but just return an empty list. (this fixes the issue that @bioimage-analysis was having).

Case 3: Strangely, sometimes there is no 'Dimensions: ' textinfo item at all. Then we have no idea whether or not there are z_levels. I think that in this case, we can indeed fallback to the z_coordinates, it might be spurious but it is something at least for the time being, until we understand the file format better. This was the case for the file of @ggirelli for which they made PR #28 .

I have committed a fix. Could you both test if it is working as intended for your files? I have tested it with your file @bioimage-analysis , it seems to work. @ggirelli it would be great if you could test it with your files as well.

[rbnvrw]

Thank you both again, I'll close this issue now. And hope to do a release soon.