Stimulus drag and drop

David Cox's Avatar

David Cox

13 Sep, 2010 04:18 PM

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

  1. Support Staff 1 Posted by Christopher Sta... on 13 Sep, 2010 04:22 PM

    Christopher Stawarz's Avatar

    [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

  2. Support Staff 2 Posted by Christopher Sta... on 13 Sep, 2010 04:23 PM

    Christopher Stawarz's Avatar

    [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

  3. Support Staff 3 Posted by Christopher Sta... on 13 Sep, 2010 04:24 PM

    Christopher Stawarz's Avatar

    [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

  4. Support Staff 4 Posted by Christopher Sta... on 13 Sep, 2010 06:54 PM

    Christopher Stawarz's Avatar

    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

  5. 5 Posted by David Cox on 13 Sep, 2010 07:07 PM

    David Cox's Avatar

    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

  6. Support Staff 6 Posted by Christopher Sta... on 22 Sep, 2010 10:39 PM

    Christopher Stawarz's Avatar

    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

  7. 7 Posted by Dave Cox on 23 Sep, 2010 09:26 PM

    Dave Cox's Avatar

    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

  8. Support Staff 8 Posted by Christopher Sta... on 24 Sep, 2010 04:47 PM

    Christopher Stawarz's Avatar

    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

  9. 9 Posted by Dave Cox on 24 Sep, 2010 07:09 PM

    Dave Cox's Avatar

    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

  10. Support Staff 10 Posted by Christopher Sta... on 20 Oct, 2010 10:32 PM

    Christopher Stawarz's Avatar

    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

  11. Christopher Stawarz closed this discussion on 25 Oct, 2010 04:26 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac