The File
input of the Import Image component has as a context menu (right-click) option “Select a directory”. Trying to use this, the component always just throws the error “Image file does not exist”. I would assume that in using the “Select a directory” option, all .bmp, .png or .jpg files of a folder would be imported. Is this not how this option works? For now I have the Elefront component List Files as work-a-round, but I don’t want to use it if I don’t have to.
don’t know if there’s a dedicated component for that, this is a basic Python script to get the list of files:
I think you could then do something like this? (I’m assuming you don’t want to read multiple files at once)
Py_List_Files_in_Directory.gh (14.8 KB)
@kike Is this a bug of Import Image?
Thank you, Inno!
import.gh (10.0 KB)
Hi @Volker_Rakow,
‘Import Image’ uses a Path input parameter. This Path parameter is able to contain file paths as well as directory paths, this is why it allows you to pick a directory or even a new file.
I agree with you that this versatility may be confusing on some cases like this one, where the component is asking for a file path and not a directory path. But is not considered a bug.
On Rhino 8 you can use Query Directory
component to enumerate all files on a directory.
@kike Ei ei ei ei ei…
So what you are telling me is, that there is a data type “Path” as is stored in the File Path container component. This datatype describes either full filepaths or directory paths. But then there are components that have inputs that advertise themselves as accepting “Path” values but only accept filepaths or directory paths?
That’s not versatility, Kike, that’s an incongruity. The entire point of data types is to provide users with an oversight of what kind of values inputs accept and outputs deliver. They shouldn’t be moving targets contextually dependent on the components they are being used with.
Grasshopper has, for instance, different data types for numbers alone: (rational) numbers, integers, complex numbers… booleans too, suppose. If one type of number is expected and another type is given, there is a standard (even if inconsistently implemented) way the number gets translated.
There is no reason this couldn’t be done with paths as well; have file paths and directory paths defined as separate data types and then have clearly established how one translates to the other. This would allow for actual versatility. You could then, for example, provide Import Image with a directory path and have the component take all filepaths of that directory. Or provide Query Directory with a filepath and have it interpret you mean the directory of that filepath.
Either way, this:
should not be a thing. I shouldn’t be able to internally set a directory or new file location to an input that is expecting file path! And I expect the same thing is true of Query Directory only in reverse if all Path parameters have been blindly given the same context menus.
love you, and appreciate all you do!
-Volker
Thanks for the suggestion, but as I stated in the OP I was hoping for a native Grasshopper solution. I was using List Files already, but wasn’t aware of the item selector. I am not fully aquainted with the Andrew Heumann suite of plug-ins yet.
What I was trying to say is the Path parameter is versatile in the sense that it can contain either a directory or a file path, and because of this confusing, I agree.
The component advertises itself as taking an image file not a directory.
Following your example with the numbers the type here is a path to anything on the hard drive.
Same way numbers may be positive or negative, paths may point to files or directories.
But we don’t have two type of number parameters for negative or for positive inputs so we don’t for directories or files.
When a component does not work with negatives values just throw an error and turn red, same do the components that do not accept a directory.
The issue with the casting-magic you suggest is that in Grasshopper you can not define a casting that is one thing to many things, in your case one directory to many files. Unfortunately this simply can’t be implemented right now without a really big change.
To me is not incongruent but confusing and I agree could be better if the casting from directory to files was possible.