By René Kopietz - 11/19/2014
Hi there,
the attached experiment runs just fine on the Mac I programmed it on. When using any of our Lab PCs we encounter error messages. The initial error message is:
WIC error: 0xffffffffff80070057. Wrong parameter. Line 762, File win\Direct2DGraphics.cpp
followed by
Unable to load the picture PATH. Verify the file is of a supported image format.
I've read elsewhere in the forum that we should get rid of spaces in file names. However, removing spaces in the file names and path do not help.
|
By René Kopietz - 11/19/2014
Sorry, forgot the attachment.
|
By Dave - 11/19/2014
The error message indicates a codec issue, specifically
WINCODEC_ERR_INVALIDPARAMETER
(cf. http://msdn.microsoft.com/en-us/library/windows/desktop/ee719669%28v=vs.85%29.aspx )
In other words, the Windows Imaging Component (which Inquisit uses; cf. https://en.wikipedia.org/wiki/Windows_Imaging_Component ) on those systems is unable to render your particular JPEGs. This may be due to a number of reasons:
(1) WIC differs between Windows versions. Under Vista and particularly XP it is picky and has some bugs. It imposes certain limits on the images in terms of chroma / subsampling / etc. information and won't work if those limits are exceeded (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/dn302094%28v=vs.85%29.aspx ; see the "Remarks" section). The information at that link applies to the latest WIC (under Windows 8.1), older versions are more restrictive. (FWIW, my Windows 7 test system does not have any problem with the your images and displays them just fine.)
(2) Invalid metadata in image files can cause weird problems. Photoshop in particular is prone to producing such issues (cf. https://stackoverflow.com/questions/878768/error-reading-iptc-fields-from-jpegs-in-net ).
Re-saving the files on a Windows system using any of the supplied image editors (MS Paint will do) should make sure the files end up being usable on those systems.
|
By Dave - 11/19/2014
P.S.: A minor different problem. There is a mistake in your <defaults> element's /fontstyle attribute:
<defaults>
...
/fontstyle = ("ARIAL, 22, false, false, false, false, 5, 0")
</defaults>
ought to be
<defaults>
...
/fontstyle = ("ARIAL", 22, false, false, false, false, 5, 0)
</defaults>
(note the position of the double-quotes)
|
By René Kopietz - 11/19/2014
Thanks Dave, by re-saving the pictures as bmp via MS Paint the experiment runs now.
Now we have a different problem: Any idea why blocks might be presented in a different order than specified in the expt element?
<expt controlcond>
/blocks = [1=beginn; 2= stimmung; 3=manipulationcontrol; 4=mancheck1; 5=demo; 6=lernen; 7=abruf; 8=mancheck2; 9=ende]
/subjects = (3 of 3)
</expt>
For some strange reason blocks 6 and 7 are reversed... this is replicable, on different PCs in our lab.
|
By Dave - 11/19/2014
I'm pretty sure you have a mistake (specifying the wrong block order) in the script you've deployed on the lab machines.
FWIW, the <expt> element you included in your last post does not match the one in the script you attached in your 2nd post (that one is missing the "stimmung" block):
<expt controlcond>
/blocks = [1=beginn; 2=manipulationcontrol; 3=mancheck1; 4=demo; 5=lernen; 6=abruf; 7= mancheck2; 8=ende]
/subjects = (3 of 3)
</expt>
I.e., there must have been various edits between the two. The script I have at hand runs the blocks in exactly the order specified.
|
By René Kopietz - 11/20/2014
The script was edited, true, but the error occurred nevertheless. We needed to exclude the stimmung (mood) items that were put into a surveypage from the begin block because it led to a crash of Inquest on some machines. Thus, we put them into a separate survey element.
However, after deleting all files, rebooting the PCs, and putting the files back on the experiment now seems to run as it should.
|
By Dave - 11/20/2014
Pretty sure the surveypage crash you've observed is due to the syntax error in your /fontstyle I outlined here:
https://www.millisecond.com/forums/FindPost15041.aspx
|
|