Applying the same data description with one click when loading multiple files

Hi,
when loading multiple files, is there a way to load them all as, say "FiberBundle"s with a single click, i.e. without needing to chose “FiberBundle” for every individual file? If yes, what is the way to do this?

Thanks.

If you mean in the Add Data dialog, yes, you can hold down Shift while changing the type of one file and it will change the other corresponding ones in the list.

If you mean in the Add Data dialog, yes, you can hold down Shift while changing the type of one file and it will change the other corresponding ones in the list.

Had tried with Shift before posting and it does not work: it only selects the last row I click on. Ubuntu 22.04; Slicer 5.2.2.

I can confirm with Slicer 5.2.2 and latest Slicer preview on Windows, that holding shift and changing the type combobox selection in the “Description” column of the Add Data Dialog does propagate the change to other rows in the table.

In the video below I change the type without pressing shift and it changes only the individual row. Then I press and hold shift and change the type and it changes the type to the other row as well.

Maybe the issue is unique to Ubuntu.

We could use the new file introspection feature to recognize fiber bundle files and by default load them as “FiberBundle”.

OK, that works; my bad then, not the way I expected for it to work: I would have expected to be able to

  • Select all files first holding the shift button; release the shift button (and have all files selected)
  • Change the Description
  • The Description to propagate across all files.

As shown in here:

Instead of needing to hold shift when I change the Description. But thanks @jamesobutler; I appreciate a lot having explained it clearly. It saves me time

I also realize that regardless of the files that I select (following the procedure you explained, and regardless of the state of checkboxes), it will change the Description for all files in the list. Is this expected? See the recording:

In both cases, the blue overlay adds to the confusion, as usually one expected it to be the span of the data the action will apply. Maybe the same reasoning applies to the checkboxes.

Thanks.

For my use case, this would be ideal, but not sure if this conflicts with other uses of those files within the Slicer community. Thanks Andras.

@pieper Is there a quick and robust way of determining that a vtk/vtp file contains fiber bundles? Even something like searching for some text in the first few hundred bytes of the file could work.

I wondered that too and took a quick look but didn’t see anything. I haven’t looked at the vtk readers in a long time to know if there’s something that reads just the metadata of a .vtk file the way you could on, say, a nrrd header. Does anyone know if that’s possible?

If would be trivial of course if we had thought ahead to use something like a .fiber.vtk file extension but we didn’t. Maybe it’s not too late to start a convention like that to better support the whitematteranalysis usecase. Also though since all the cases use the same naming conventions it’s possible to set up .mrml files that you can just copy into a new directory to load cases the way you want.

We could start using this naming convention now. It is easy to rename existing files to make loading more convenient.

If having hundreds of bundles has become common then it would make sense to develop the same kind of infrastructure as we have for dealing with many segments: multi-select, filter&search, right-click menu for bulk operations, standard terminology (and use it for default naming and coloring).

I agree, at some level the fiber bundles are segments (subdivisions of anatomy). Maybe they could be proxied to appear in the Segmentations module to avoid duplication of code and user interface concepts. They are subclasses of Model nodes now, but have multiple display nodes for glyphs, lines, and tubes so there may be some complexities. Stepping back, dealing with hundreds of anything is Slicer is hard, so maybe we can think of more generic interface tools that work for any kind of nodes.

@jhlegarreta if it would save you a lot of time, there are a few small (pure python) changes to implement the .fiber.vtk naming idea. First would be to add it to the whitematteranalysis code as the default output filename. Second would be to add a custom scripted IO class that detects the file extension and sets a high confidence so it becomes the default for that file extension.

There is already a FIberBundle reader plugin, so probably all we would need to do is to add .fiber.vtk to the list of extensions.

Automatic detection (not 100% but probably very close) would be to search for <PointData Tensors="Tensors_">" in the first 1000 bytes of the file - it should appear at around position 500, as fiber vtp files start like this:

<?xml version="1.0"?>
<VTKFile type="PolyData" version="0.1" byte_order="LittleEndian" header_type="UInt32" compressor="vtkZLibDataCompressor">
  <PolyData>
    <Piece NumberOfPoints="1079"                 NumberOfVerts="0"                    NumberOfLines="8"                    NumberOfStrips="0"                    NumberOfPolys="0"                   >
      <PointData Tensors="Tensors_">
        <DataArray type="Float32" Name="Tensors_" NumberOfComponents="9" format="appended" RangeMin="0.00084

Automatic detection in .vtk files would be hard, as there is nothing very specific at the beginning of the file (the tensor data starts around the middle of the file, so a lot would need to be read, which might slow down the loading).

Thanks for checking @lassoan - yes, adding .fiber.vtk and .fiber.vtp to the existing plugin and using those extensions consistently would be the cleanest.

@jhlegarreta if it would save you a lot of time, there are a few small (pure python) changes to implement the .fiber.vtk naming idea. First would be to add it to the whitematteranalysis code as the default output filename. Second would be to add a custom scripted IO class that detects the file extension and sets a high confidence so it becomes the default for that file extension.

For dMRI/tractography users, having to change the Description every time they load VTP/VTK streamline data into Slicer is not practical, but I understand that there is no (easy) way to tell these files apart from other non-streamline data files. I’m fine even if changes are to be done in C++.

search for <PointData Tensors="Tensors_">" in the first 1000 bytes of the file - it should appear at around position 500

I would not rely on the existence of tensor data in the file: even if some tools (e.g. UKF) may add such data to the file, such data is not strictly required to define a streamline.

As time permits, we can discuss about this to implement some strategy. My bandwidth is very limited now, but I could consider talking offline with Steve so that he can provide with some pointers about the Slicer environment.

Thanks for the thoughts.