By zajac - 6/3/2014
Hi Dave
I'm having a bit of a problem getting a .gif to loop, but only when I present it as part of a trial with other image stimuli. Consider following
<picture stillpic> / items = ("still.jpg") / size = (250px,250px) / position = (values.horizcentrepos, values.vertcentrepos) </picture>
<video animatedpic> / items = ("animated.gif") / size = (250px,250px) / position = (values.horizcentrepos, values.vertcentrepos) </video>
<trial test> / stimulustimes = [0=stillpic;3000=animatedpic]/ timeout = 5000 </trial>
This trial crashes as soon as Inquisit tries to present the animatedpic .gif file. I get the "Inquist has stopped working, Windows is looking for a solution" error. The interesting thing is that the trial runs fine when the animated pic is not presented. It also runs fine when ONLY the animated pic is presented. It's seems to only be a problem when I try to present BOTH of the images.
|
By zajac - 6/3/2014
I've messed around with this a bit more. I've edited the .gif files and deleted the transparent background layer. Everything seems to work fine now. Strange hey?
|
By Dave - 6/3/2014
Yes, it is a bit strange. Can you share both versions of one such .GIF (with / without transparency)? Could you attach them here?
|
By zajac - 6/4/2014
Hi Dave
I realise at the same time as editing the image, that I updated Inquisit to the latest version. This morning, having tested on a touch-screen machine, I also had to update Inquisit to resolve the error (I was running 4.04 something before). However, it isn't completely resolved. Despite the upgrade, I have had the same error sporadically when Inquisit tries to run a trial. It is unpredictable. Previously, on the older version, it happened every time.
One of the machines I use is WIN 7 Enterprise. The other is WIN 8.1 Ent...
The images are attached.
|
By Dave - 6/4/2014
Thanks for the files. We'll take a look at this ASAP. If you come across any additional details or insights in the meantime, please don't hesitate to add them to this thread.
Thanks!
|
By zajac - 6/4/2014
Do you know of a way I can recover the Inquisit/Windows error logs that were occurring for me from my machine? Would these be useful for you?
|
By Dave - 6/4/2014
For the Windows logs right-click the Computer icon -> Manage -> Event Viewer -> Windows Logs -> Application. From there you can filter the log (i.e. display only the relevant entries / entry types) and save them to file.
Inquisit also keeps its own technical log, which is accessible via Tools -> View Log File...
Meanwhile I have been running a couple of test using the files you kindly provided and a bit of simple code:
<block myblock>
/ trials = [1-100=test]
</block>
<picture stillpic>
/ items = ("static.jpg")
/ size = (250px,250px)
/ position = (50%, 50%)
</picture>
<video animatedpic>
/ items = ("solid.gif", "transparent.gif")
/ loop = true
/ size = (250px,250px)
/ position = (50%, 50%)
</video>
<trial test>
/ stimulustimes = [0=stillpic;3000=animatedpic]
/ timeout = 5000
</trial>
Unfortunately I have so far been unable to observe the crash you described. This is true for version 4.0.5.0 as well as a current 4.0.6.0 pre-release build. It also doesn't make any difference whether the transparent- or solid-background GIF is used.
When you say the crash happens randomly, how frequently does it occur (i.e. approx. 1 out of N trials)? Is the crash tied to any specific files (i.e. only happens for certain GIFs)?
To rule out some other additional factor necessary to cause the crash, are you able to reproduce it using the above code?
Thanks!
|
By zajac - 6/9/2014
I'm going to run your test script later today and see if I can get the error to occur. It has happened barely a handful of times on the new install. I have gone over the windows error log and found the relevant entry. This is the info I can extract from it.
GENERAL: Faulting application name: Inquisit.exe, version: 4.0.3.0, time stamp: 0x51d05b53 Faulting module name: d2d1.dll, version: 6.2.9200.16765, time stamp: 0x528bf6b2 Exception code: 0xc0000420 Fault offset: 0x002466e8 Faulting process id: 0x27bc Faulting application start time: 0x01cf7fed2688f8db Faulting application path: C:\Program Files\Millisecond Software\Inquisit 4\Inquisit.exe Faulting module path: C:\Windows\system32\d2d1.dll Report Id: b31e29dd-ebe0-11e3-b373-2016d891ba21
I can't really find anything in there that looks like it will help narrow things down.
|
By Dave - 6/9/2014
Thanks. Let me know what you find. Just for clarification, the error message you posted
> Faulting application name: Inquisit.exe, version: 4.0.3.0, time stamp: 0x51d05b53
refers to a (very) outdated Inquisit version (4.0.3.0). So, either that crash message stems from before updating the respective machine or the system is still running an old build. |
By Eric del Rio - 3/17/2017
I have been having a similar issue with using .gif in <video> as stimuli in my test (Inquisit 5). On windows machines, the program will crash after one or two instances of a .gif.
On an iMac, the program will run, but .gif files get pretty choppy from time to time (start jumping and shaking on the screen). I've tried reducing the resolution of the images going into the .gif files but it doesn't seem to make a difference. When I use static images as stimuli, the program runs fine.
|
By Dave - 3/17/2017
+xI have been having a similar issue with using .gif in <video> as stimuli in my test (Inquisit 5). On windows machines, the program will crash after one or two instances of a .gif. On an iMac, the program will run, but .gif files get pretty choppy from time to time (start jumping and shaking on the screen). I've tried reducing the resolution of the images going into the .gif files but it doesn't seem to make a difference. When I use static images as stimuli, the program runs fine.
As far as I can determine the problem ultimately comes from two sources:
(1) The way Inquisit handles GIFs -- it essentially expands them into stimulusframes.
(2) The fact that in your case GIFs are drawn on top of each other, i.e. introducing two sets of potentially conflicting stimulusframes in a given instance of a <trial>.
Due to platform differences, this leads to a crash under Windows and "choppiness" under OSX.
The best "quick fix" I can see is to either (a) switch to a different (non-GIF) video format or (b) split things into separate <trial>s, i.e. instead of inserting the GIFs at values.stiminterval
<trial TargBP>
/ stimulusframes = [1 = NonBP, NonFace]
/ontrialbegin = [
values.rt = 0;
values.stiminterval = list.stimulusinterval.nextvalue;
trial.TargBP.insertstimulustime(video.NonFace, values.stiminterval);
trial.TargBP.insertstimulustime(video.TargetBP, values.stiminterval);
]
...
</trial>
have the trial only display NonBP and NonFace and set it to /timeout = values.stiminterval; if no response occurs prior to timeout, /branch to a 2nd <trial> that displays NonFace and TargetBP.
Hope this helps.
|
By Eric del Rio - 3/17/2017
+x+xI have been having a similar issue with using .gif in <video> as stimuli in my test (Inquisit 5). On windows machines, the program will crash after one or two instances of a .gif. On an iMac, the program will run, but .gif files get pretty choppy from time to time (start jumping and shaking on the screen). I've tried reducing the resolution of the images going into the .gif files but it doesn't seem to make a difference. When I use static images as stimuli, the program runs fine. As far as I can determine the problem ultimately comes from two sources: (1) The way Inquisit handles GIFs -- it essentially expands them into stimulusframes. (2) The fact that in your case GIFs are drawn on top of each other, i.e. introducing two sets of potentially conflicting stimulusframes in a given instance of a <trial>. Due to platform differences, this leads to a crash under Windows and "choppiness" under OSX. The best "quick fix" I can see is to either (a) switch to a different (non-GIF) video format or (b) split things into separate <trial>s, i.e. instead of inserting the GIFs at values.stiminterval <trial TargBP> / stimulusframes = [1 = NonBP, NonFace] /ontrialbegin = [ values.rt = 0; values.stiminterval = list.stimulusinterval.nextvalue; trial.TargBP.insertstimulustime(video.NonFace, values.stiminterval);
trial.TargBP.insertstimulustime(video.TargetBP, values.stiminterval);] ... </trial> have the trial only display NonBP and NonFace and set it to /timeout = values.stiminterval; if no response occurs prior to timeout, /branch to a 2nd <trial> that displays NonFace and TargetBP. Hope this helps.
Thanks Dave,
I shortened up the .gif files and optimized them so they are not such big file sizes. With the new .gif they won't overlap unless I loop them, I've tried to make the changes in the .gifs happen at a rate so that the delay during the change between non-target and target .gif files isn't so obvious.
Thanks again for all of your help
Eric
|
|