Drag-n-drop folder with mixed layer types (e.g. image.tiff and Points.csv) or just csv fails #5460
Labels
Comments
|
Hi, could you tell us what kind of files were in the folder? Also, could you provide the full traceback? |
|
We can open files singularly, they are csvs. |
|
So just to be clear, if you manually open |
psobolewskiPhD
changed the title
|
Exactly how you described it. |
|
Ok! I have a reproducer when writing up #6846 Edit: the workaround is to open the folder in your OS file browser and select the contents and drag and drop that. Then it will work! I would expect dragging and dropping a folder to work just the same. I guess the difference is that if you have a a folder of TIFF they get merged into a single layer stack. While if you drag and drop N TIFF files, you get N layers. |
psobolewskiPhD
changed the title
|
Yeah so there's a confluence of problems here unfortunately. The first is that back in the day, we had a (mostly silent) convention that a list of paths was always to be stacked, and a single path wasn't. We started work on passing
So tbh I'm surprised to see this too, but this is a result specifically of the fact that our
You can hold I'm not sure that we always want a different reader to be used for each file in a folder, if the user drags in a folder... Readers accept the folder paths directly, so it's up to them how they deal with what's inside. For our own builtin folder reader, I can imagine maybe wanting to special case this and potentially call a different reader for each file... but it's not immediately obvious to me that we want that. |
|
Thanks for the insight.
I strongly feel that by default the output of |
I think that's a very valid feeling lol.
This feels maybe overly specific. What if we did all files same type- open with our usual reader and stack. Not all files same type? Open them file-by-file with our built in reader? |
|
The specific case probably covers majority of use cases, but also I don't think stacking csv would work -- that's not how 3d shapes/points are "made" Stacking would be only for image type extensions (maybe same shape, but that's in the eye of the beholder). Edit: in workflows I've been helping with lately, the layer list is basically any number of image layers, plus few Points, a shapes, and optionally labels. So if there is csv in the folder it's a good tell that Edit2: I'm also mentally merging behavior of Save all layers and Save all selected -- I think the logic could be identical for both? |
I think that we should stack only files that share prefix and has number suffix. So directory with It should be read as two layers. |
|
I think that's another level of sophistication/magic... |
You need some magic to load layers in proper order. |
|
I think by default what should work is that a saved folder of layers is opened as a layer list. Folders not saved by napari all bets are off in terms of the order. How can we be able to guess? |
Not sure if you mean this explicitly, but we can't currently distinguish whether napari originally saved the folder. We could absolutely change our built-in writer to do save a small piece of metadata to indicate this, but we don't currently do that. Also just to clarify, what we're talking about here doesn't really change how we do reading at an architecture level, but rather changes the behaviour of the built-in napari reader right? |
|
Right. Reading arbitrary folders and guessing intent will be hard and never perfect. Of course if we need to we can write a .file with export but I think that is overkill since dragging all the files after Select All does work correctly. |
|
@psobolewskiPhD I'd be happy to look at a PR with your desired behaviour implemented. Here is the code that lists the directory and makes a list of all the filenames, and here is the code that actually does the reading. |
|
Thanks @DragaDoncila |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
馃悰 Bug
To Reproduce
Steps to reproduce the behavior:
- Open napari
- Open folder via menu or drag and drop
303 raise err_type(err_msg)ValueError: Could not find a backend to open
_path_`` with iomoderi`. -->Expected behavior
Environment
napari: 0.4.16
Platform: Windows-10-10.0.19043-SP0
Python: 3.10.6 | packaged by conda-forge | (main, Oct 24 2022, 16:02:16) [MSC v.1916 64 bit (AMD64)]
Qt: 5.15.2
PyQt5: 5.15.7
NumPy: 1.23.4
SciPy: 1.9.3
Dask: 2022.10.0
VisPy: 0.10.0
OpenGL:
Screens:
Plugins:
The text was updated successfully, but these errors were encountered: