|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
Hi all, we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text. In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions. Specifically (I will refer to lines in the script here to hopefully make it easier to follow): Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display. When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122). Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part. On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5. We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5. Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440). Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/
Attachments
4.jpg
(133 views,
346.00 KB)
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xHi all, we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text. In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions. Specifically (I will refer to lines in the script here to hopefully make it easier to follow): Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display. When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122). Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part. On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5. We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5. Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440). Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/ > the target word flickers in and out of visibility randomly during the zooming effect Not seeing this under Inquisit 6.4.2 on not particularly beefy systems (e.g. a ca. 2013 ThinkPad T430 with a 3rd generation Intel Core i5 and 8GB of RAM). The image has a 16:9 aspect ratio (1920 x 1080 pixels). Your display has a 16:9 aspect ratio (3840 x 2160 pixels), too, so this shakes out. Since the inherent aspect ratio of the image will not be distorted, you should expect to see artifacts on displays that are not 16:9, i.e. the image cannot cover the screen fully (e.g. 1680 x 1050 is 16:10). Here's an example when running at a 16:10 resolution:  Note the artifacts at the top and bottom due to the image-display aspect ratio mismatch. The 16:9 image cannot cover the entire 16:10 area, so previous (larger) instances of the image remain visible underneath (per /erase=false, they are not erased, which would cause flickering). By contrast, here's a shot running at a 16:9 resolution:  Since the aspect ratios match, the image can cover the entire display area. Artifacts at 2560 x 1440 would be odd, since that is 16:9. Are you sure the system was actually running at that resolution? You can get rid of those artifacts by either - setting a /canvasaspectratio of 16:9 in <defaults>, and/or - inserting a clearscreen as the first stimulus in the zoom trial, followed by the picture stimulus, then the text stimulus.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
Hmm. Thanks for the info about the aspect ratio - I knew I was missing something, but for some reason I couldn't make that simple connection.
The flickering is unfortunately reproducible on multiple systems - I'm not sure what's doing it. I'll try to get my colleagues to capture some screen footage for a better bug report.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xHmm. Thanks for the info about the aspect ratio - I knew I was missing something, but for some reason I couldn't make that simple connection. The flickering is unfortunately reproducible on multiple systems - I'm not sure what's doing it. I'll try to get my colleagues to capture some screen footage for a better bug report. Would you happen to have the specs for at least some of the affected systems? Particularly: - OS type and version (note the system requirements at: https://www.millisecond.com/products/inquisit6/requirements.aspx ; e.g. if you're seeing this under e.g. Windows 7 or 8, those operating systems are technically not supported.) - Inquisit version (please make sure everyone is using the same, latest version available, 6.4.2). - Graphics card make and model. - General specs such as RAM, processor speed, etc.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
We have some footage of the bug: https://4xdk5geps1hgl8wg.myfritz.net:47219/nas/filelink.lua?id=da2d0729aa03b7d5Specs for the PC in the video are attached. I'll try to get the specs of some of the other systems as well!
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+x What's the installed driver version for the Intel HD 520 graphics adapter? Double-click the entry in the device manager, then go to the Driver tab, and driver date and version should be listed there. Also, what's the Inquisit version installed / used, please? If you're running this in Inquisit Lab, that information is available via Help->About. If using the web version / player, open the player, and the information is at the bottom of the Home / Browse tab: 
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
+x+x What's the installed driver version for the Intel HD 520 graphics adapter? Double-click the entry in the device manager, then go to the Driver tab, and driver date and version should be listed there. Also, what's the Inquisit version installed / used, please? If you're running this in Inquisit Lab, that information is available via Help->About. If using the web version / player, open the player, and the information is at the bottom of the Home / Browse tab: Oh - sorry, it's Inquisit 6.4.2, we re-installed just before testing. I'll check out the driver version for you!
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
Driver date on the PC in the footage: October 20, 2016; version 21.20.16.4541
In contrast, I DON'T have the issue on my PC:
Inquisit 6.4.2 64bit (build 6307)
Windows 10 Pro Build 19042
Intel Core i7-5960X
32GB RAM
Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020)
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xDriver date on the PC in the footage: October 20, 2016; version 21.20.16.4541 In contrast, I DON'T have the issue on my PC: Inquisit 6.4.2 64bit (build 6307) Windows 10 Pro Build 19042 Intel Core i7-5960X 32GB RAM Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020) The driver on the affected system is fairly ancient and outdated, and a driver bug is a distinct possibility. According to Intel's website, the latest release available for the HD 520 is driver version 27.20.100.9466 (date: 05/14/2021): https://www.intel.com/content/www/us/en/support/products/88355/graphics/graphics-for-6th-generation-intel-processors/intel-hd-graphics-520.htmlPlease try updating to that driver and let me know if the issue persists after doing so. One more question for clarification: The script run on the affected system is the exact same one you provided in this thread, correct? I'd like to rule out that we're looking at slightly different bits of code, with a subtle mistake in one version, but not the other.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+x+xDriver date on the PC in the footage: October 20, 2016; version 21.20.16.4541 In contrast, I DON'T have the issue on my PC: Inquisit 6.4.2 64bit (build 6307) Windows 10 Pro Build 19042 Intel Core i7-5960X 32GB RAM Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020) The driver on the affected system is fairly ancient and outdated, and a driver bug is a distinct possibility. According to Intel's website, the latest release available for the HD 520 is driver version 27.20.100.9466 (date: 05/14/2021): https://www.intel.com/content/www/us/en/support/products/88355/graphics/graphics-for-6th-generation-intel-processors/intel-hd-graphics-520.htmlPlease try updating to that driver and let me know if the issue persists after doing so. One more question for clarification: The script run on the affected system is the exact same one you provided in this thread, correct? I'd like to rule out that we're looking at slightly different bits of code, with a subtle mistake in one version, but not the other. Adding: If you don't want to install the non-branded Intel driver, the Dell support portal for your system should also offer a more recent OEM driver version (these typically lag a little behind the Intel releases, but can contain OEM customizations integrating them with other Dell-proprietary features on the system, such as hotkey integration).
|
|
|
|