Hey,
I saw Jim today, and he mentioned that there was a complaint that it was not possible to drag image files into the MWEditor. Just wanted to give you a heads-up that this has in fact been feature for several years now (did you try it?). See the linked screencast for details:
http://dl.dropbox.com/u/275083/stimulus_drag_and_drop.mov
– Dave
[From Najib]
Hi David,
Firstly, there was no complaint. There was a conversation about what you can and can’t do in MW editor/server/client.
And honestly speaking that conversation so far has been quite good, it has revealed many things that needed fixing, and has expanded the capabilities of mworks quite a bit.
The conversation started because as part of our array project, we have been running more and more images in our RSVP task.
One of our image sets is quite large ~3000 images.
Initially we stumbled on the memory limit of how many images can we load at once.
Once we pushed that to the limit, it still wasn’t enough.
Next came the load unload solution.
I believe that has been a great improvement as well, except for the fact that we stumbled on the randomization problem.
The randomization problem lead to a discussion of image index, image names, image filenames.
Jim was under the impression that images retained their original filenames.
I told him that the way we load large chunks of images was through a replicator, and that the replicator forces you to name images in a particular way.
Some thing like “Image_index” where index can vary across the replicator.
Jim thought that we just dragged and dropped images in, and didn’t understand why we did it the way we did.
Now to answer your question, I never tried to drag images into an image folder. I never knew that it could be done. I have asked people around the lab, and it is a feature that no one is aware of. If it was ever publicized, we completely missed it. I am guessing that this was something that was added with the switch from the old editor to the new editor. But it might have been in the old editor and I simply was unaware of it.
Now to the important part of this email. I have tried this feature this morning. It works great with a few images (about 10). I am still uncertain whether it works for large image sets. I dragged 640 images files to a folder in the MWeditor 30 mins ago. All i see is the beach ball spinning, THe MWEditor is red in the Activity monitor at 144 %CPU. And it is still going. (btw, i will probably stop this job soon and try 100 images next)
I am glad that the feature exists, because that means that it needs to be fixed not created from scratch.
It still doesn’t solve our problem, and that is completely fine.
When I signed up to use MW, I know that it was a work in progress, that involves me talk to you and Jim and Chris about features.
I apologize, if these conversations seem as complaints, they really are not.
In the heat of battle when you are trying to get something done, and you can’t, signs of frustration come out.
Best
Najib
[From Jim]
Thanks Najib and Dave.
Dave, thanks for bringing this feature to our attention.
We will have Chris look at this feature when he is back (Monday).
In the lab, we are also talking about ways that MWorks might help us better keep track of what images were actually presented in each experiment.
One thing we think is a good idea is to have MWorks include an (e.g.) MD5 hash (based on the image content) as part of the stimulus announce.
No work to do on your part on this, just wanted to keep you in the loop.
I am sure Chris will be in touch early next week to talk more.
Best,
JIm
[From Dave]
Hey,
One thing we think is a good idea is to have MWorks include an (e.g.) MD5 hash (based on the image content) as part of the stimulus announce.
Yeah, this is a fine idea. We do this already in my lab for some of our dynamically-generated random stimuli, but it would make sense for static images too if you were worried that they might somehow change out from under you.
However, it sounds like your core issue might be that you’re being forced to artificially rename a bunch of stimuli, making it easier run into naming confusion/trouble. Irrespective of md5 hashes, etc., we should address this issue directly in one way or another. I can imagine a variety of solutions for this: we could have stimulus groups that explicitly link to folders, we could have “folder replicators”, we could have list semantics for the list replicator that reference folders, etc.
As for the drag-and-drop performance scaling problems, these turn out to have to do with the efficiency of inserting nodes into an experiment from any source (so if you dragged or pasted 100 nodes from elsewhere in the experiment, you’d see comparable slow downs). On the bright side, this means that fixing this will make the application more snappy all around. On the down side, I’m not sure that the fix will be quick or easy.
– Dave
Even if we improve the efficiency of node insertion, the drag-and-drop feature probably won’t help Najib very much. Dragging in 100 images creates 100 individual image stimuli, each with the default parameters. Unless Najib is happy with the default position, size, transparency, and loading style, he’ll have to modify the parameters on all 100 stimuli, which is neither fun nor practical.
As for alternatives, I like the “folder replicator” idea: You give it a directory path, and it iterates over the (non-hidden, regular) files in the directory, assigning the name of each to a local variable in turn. It could be used in an experiment like so:
<folder_replicator tag="New Folder Replicator" path="/folder/with/images" variable="filename">
<stimulus type="image_file" tag="${filename}" path="/folder/with/images/${filename}" ...></stimulus>
</folder_replicator>
This seems like a convenient solution that has the advantage of not being tied explicitly to images or stimulus groups. Any thoughts?
Chris
Yes, that’s an excellent point about editing the multiple stimuli. While I agree that the “folder replicator” is probably the best way to go for this problem, for convenience sake, we probably also want to enable multiple selection editing of stimulus parameters (e.g. select all and change their parameters to a common thing). I just checked and it currently doesn’t work (only the first selected item is edited).
Your folder replicator syntax is basically what I was imagining, and I think this would be a useful add.
– Dave
As for alternatives, I like the “folder replicator” idea: You give it a directory path, and it iterates over the (non-hidden, regular) files in the directory, assigning the name of each to a local variable in turn.
After considering this some more, I think I’d prefer to add this functionality to list_replicator rather than create a separate folder_replicator. Here’s an example:
<list_replicator tag="New List Replicator" values="DIR(images)" variable="filename">
<stimulus type="image_file" tag="${filename}" path="images/${filename}" ...></stimulus>
</list_replicator>
If “images” is a directory that contains the files a.png, b.png, and c.png, then values="DIR(images)" is equivalent to values="a.png,b.png,c.png". More generally, DIR(some_dir) expands into a list of the names of all regular, non-hidden files in directory some_dir. The “DIR” part is case-insensitive (so “dir” or “Dir” would also work).
You can mix “DIR” expressions with other items, including other “DIR” expressions, e.g.
values="DIR(foo),bar/x.png,bar/y.png,DIR(blah),z.png"
I already have this mostly implemented (although I need to write some more tests). Unless Dave or someone else thinks it’s a bad idea, I’ll finish it and merge it in.
Chris
I wonder of this wouldn’t be cleaner as a “filenames” directive using a path wildcard string (e.g. filenames(“images/*.png”) ). That way the occasional readme.txt wouldn’t break things.
Dave
Sent from my iPhone
I wonder of this wouldn’t be cleaner as a “filenames” directive using a path wildcard string (e.g. filenames(“images/*.png”) ). That way the occasional readme.txt wouldn’t break things.
Yeah, that’s a good point. I suppose the directive could work similar to ls, with the argument being a globbable string that expands to one or more directory or file names. That would make it very similar to MATLAB’s dir command. Presumably we’d still want it to match only regular files?
Chris
Yeah, probably best to have it match regular files only, though a recursive option would be nice too. Also a pony.
Dave
Sent from my iPhone
I finished implementing the “filenames” directive and merged it into master. It will be in nightly builds starting tonight.
The syntax is filenames(glob_expr), where glob_expr is a shell-style file name pattern that must match one or more regular files. Both absolute and relative paths are acceptable. Matches against non-regular files (e.g. directories) are ignored. If glob_expr matches no regular files, the parser raises an error.
The pattern matching is performed by the system glob function, so all the default wildcards recognized by glob are acceptable in glob_expr.
I also added an FAQ about using replicators to load a folder of images.
Chris