By thv - 5/19/2016
Hello,
I am programming an experiment that presents several .gif images, however the times of the gifs seem to be varying unexpectedly (even when they should be the same length).
When I changed it to present the same gif for 4 trials in a row, the first trial is often about twice as long as the rest of them, but occasionally other trials are much longer than the others. (It does not have this issue for static images.)
Has anyone encountered this issue, or know how to solve it? Any help would be much appreciated.
Here's a bit more information:
I tried recording the time each image was displayed for (as suggested in this post http://www.millisecond.com/forums/Topic16654.aspx?Keywords=time-spent-on-page). According to that post, because its being recorded starting from ontrialbegin (rather than the stimulus onset) it will record the times with some additional variability (up to 100ms), which is not actual variability in the presentation times. I see this when I time some static images, but the variability in my gifs is definitely more that that (several hundred ms) and is noticeable to the naked eye.
Here's how I'm recording the times, and below is some of the times I recorded
<trial fastfractaltrial>
/ ontrialbegin = [values.t_start=script.elapsedtime;]
/ stimulusframes = [1 = fastfractals]
/ response = timeout(1)
/ recorddata = false
/ ontrialend = [values.t_end=script.elapsedtime;]
</trial>
<values>
/ t_start = 0
/ t_end = 0
</values>
<expressions>
/ imagedisplaytime = (values.t_end-values.t_start)
</expressions>
Here is an example where I took 2 different gifs (one shorter and one longer), and presented them in blocks of 4.
The largest delay seem to be the first time each gif is used, though e.g. the 3rd trial here is also much longer.
| trialtype | imagedisplaytime | | short | 734 | | short | 295 | | short | 796 | | short | 312 | | long | 793 | | long | 547 | | long | 463 | | long | 461 | | short | 276 | | short | 308 | | short | 295 | | short | 295 | | long | 477 | | long | 445 | | long | 467 | | long | 494 |
|
By Dave - 5/19/2016
I seem to be unable to reproduce this. Here's the code I'm using, which mimics yours:
<expt>
/ blocks = [1-4 = myblock]
</expt>
<block myblock>
/ trials = [1-4 = mytrial]
</block>
<trial mytrial>
/ ontrialbegin = [values.t_start=script.elapsedtime;]
/ stimulusframes = [1 = mygif]
/ response = timeout(1)
/ ontrialend = [values.t_end=script.elapsedtime;]
</trial>
<video mygif>
/ items = ("short.gif", "long.gif")
/ playthrough = true
/ select = sequence
/ selectionrate = block
/ resetinterval = 0
</video>
<values>
/ t_start = 0
/ t_end = 0
</values>
<expressions>
/ imagedisplaytime = (values.t_end-values.t_start)
</expressions>
<data>
/ columns = [blocknum trialnum stimulusitem values.t_start values.t_end expressions.imagedisplaytime]
/ separatefiles = true
</data>
The "short" GIF has 10 frames and an expected duration of approx. 700ms given the GIFs settings and the test system's refresh rate. The "long" GIF has 20 frames and an expected duration of a little more than twice that of the "short" GIF. Both files are attached. The tests were conducted using the latest Inquisit 4 release (if you are using some older version, please update). The data I'm getting corresponds well with what would be anticipated under those circumstances:
blocknum trialnum stimulusitem1 values.t_start values.t_end expressions.imagedisplaytime
1 1 short.gif 64 754 690
1 2 short.gif 904 1625 721
1 3 short.gif 1642 2345 703
1 4 short.gif 2362 3066 704
2 1 long.gif 3150 4591 1441
2 2 long.gif 4608 6049 1441
2 3 long.gif 6065 7507 1442
2 4 long.gif 7523 8964 1441
3 1 short.gif 9050 9752 702
3 2 short.gif 9769 10473 704
3 3 short.gif 10489 11193 704
3 4 short.gif 11210 11914 704
4 1 long.gif 11999 13439 1440
4 2 long.gif 13455 14896 1441
4 3 long.gif 14913 16354 1441
4 4 long.gif 16371 17812 1441
I suppose there must be some additional factors at play here, although I am not sure what they may be. Perhaps it's something about the specific GIFs you are using. Perhaps there is some deeper issue with the system you have observed this on (this could be ruled out by replicating it on other systems). If you can think of anything, please add it to this thread. It would also be interesting to know the results of running the attached test script on your system(s).
|
|