You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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)
defget_image_size(self) ->Tuple[int, int, int]:
returnself._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.
The text was updated successfully, but these errors were encountered:
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.
[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
toBrukerTiffSinglePlaneImagingExtractor
. **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:roiextractors/src/roiextractors/extractors/tiffimagingextractors/brukertiffimagingextractor.py
Lines 167 to 175 in 29c3491
And this is applied to xml elements that look like this:
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 ofBrukerTiffMultiPlaneImagingExtractor
passing plane streams toBrukerTiffSinglePlaneImagingExtractor
here:roiextractors/src/roiextractors/extractors/tiffimagingextractors/brukertiffimagingextractor.py
Lines 239 to 242 in 29c3491
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.
The text was updated successfully, but these errors were encountered: