Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Bruker plane specification implementation through file_paths #345

Open
h-mayorquin opened this issue Jun 11, 2024 · 2 comments
Open

Comments

@h-mayorquin
Copy link
Collaborator

h-mayorquin commented Jun 11, 2024

[Draft]

I discussed this today with @weiglszonja and we converged to this solution. I am writing the context here for provenance and as a to-do list.

The main problem is a clash between the plane specification and the channel specification that are both passed as stream_name to BrukerTiffSinglePlaneImagingExtractor. **For the test examples we have got this works because the channel names are always part of the file name ** (and therefore of the string implementation) see here:

folder_path: PathType,
stream_name: Optional[str] = None,
):
"""Create a BrukerTiffMultiPlaneImagingExtractor instance from a folder path that contains the image files.
Parameters
----------
folder_path : PathType
The path to the folder that contains the Bruker TIF image files (.ome.tif) and configuration files (.xml, .env).

And this is applied to xml elements that look like this:

      <File channel="2" channelName="Ch2" filename="NCCR32_2022_11_03_IntoTheVoid_t_series-005_Cycle00001_Ch2_000001.ome.tif" />

See that the channelName is part of the file_paths. However, this assumption does not hold for data from the Clandinin lab and the data from this other issue #341 here so we need to decouple.

A first attempt was done here:
#343

This works for the BrukerTiffSinglePlaneImagingExtractor because we can look for the file_paths that correspond to a channel name and have very specific list of file and that works. Unfortunately, this breaks the use case of BrukerTiffMultiPlaneImagingExtractor passing plane streams to BrukerTiffSinglePlaneImagingExtractor here:

# TODO: fix this method so that it is consistent with base multiimagingextractor method (i.e. num_rows, num_columns)
def get_image_size(self) -> Tuple[int, int, int]:
return self._image_size

Because that also relied on the assumption that the plane specification we have is contained in the file name.

So what gives?

The thing that we can do programatically is find all the file_paths that correspond to a channel.
The thing that we can do programatically is find a simple and friendly user specifation to get a single plane. Yet.

@weiglszonja
Copy link
Contributor

weiglszonja commented Jun 11, 2024

Yeah we need the number of planes as well, if we have the list of file_paths maybe we can do something similar as in:

plane_stream_names = [matches["stream_name"] for matches in regular_expression_matches if matches]

I think in that example we have two planes: "..._Ch2_000002.ome.tif" and "..._Ch2_000001.ome.tif"
maybe from the list of file paths we could find the part until the last '_' to determine how many unique files we have and that should be the number of planes?
But again this assumption would only hold true when we have volumetric data, as in this example there is a simple plane.

@h-mayorquin
Copy link
Collaborator Author

Yes, to get the number of planes, I think we can count Sequence elements in the xml. What do you think?

For choosing a single plane though we still need to use some sort of regular expression as you were doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants