This project has moved. For the latest updates, please go here.

screen resolution

Jul 11, 2013 at 9:17 AM
Hi all
I have a few questions about screen resolution and designing experiments. The screen I am using has different standard dimensions (1680 x 1050) to the default when the experiment designer starts up (1024 x 768).
  1. Is there a way to change more permanently the experiment default to match the screen default on a particular machine, so that I don't have to keep remembering to change it when I design a new experiment?
  2. If I change the monitor's settings to match the experiment designer default (1024 x 768), then when I calbrate the eye-tracker (a Mirametrix S2) the calibration dimensions (presumably 'inherited' from the S2 software) still use the screen's default settings, and so for instance the right hand column and bottom row of the 3x3 set of calibration circles are off-screen altogether. Is this normal behaviour and can anything be done (or is that a Mirametrix issue)?
  3. If I forget to change the screen dimensions in the experiment settings to match the screen's default then I get a reminder to do so when I try to record an experiment (i.e. the experiment sensibly won't run if the screen dimensions don't match the experiment settings). However, changing the settings at that point seems to produce results in the experiment that are fine for mouse tracking but, as far as I can tell, are respecting not the changed settings but the default Ogama dimensions for eye tracking. That is, the eye-track coordinates are 'off' by a factor that seems to be a ratio of default and actual sizes, so that a gaze that might actually have been to the bottom right of the tracked screen at recording time is only some 1/2 to 2/3 down & across the screen in the replay, and similarly for other points on the screen. Is there a fix to this?
    Thanks
    Paul
Coordinator
Jul 13, 2013 at 6:11 PM
Hi Paul,
I have a few questions about screen resolution and designing experiments. The screen I am using has different standard dimensions (1680 x 1050) to the default when the experiment designer starts up (1024 x 768).
Just one general statement, such huge resolutions are scratching the power of the underlying image processing. For what I´ve seen you will get slow and stutter replay, cause the image update rate, in parallel with the fixation processing will get high CPU load, on newer machines that may is not a problem, but be aware. The most common problem is, when someone uses a screen resolution of 1024x768 with an image of 1920x1080, which has to be resized every frame...
  1. Is there a way to change more permanently the experiment default to match the screen default on a particular machine, so that I don't have to keep remembering to change it when I design a new experiment?
Sorry, this one is a "magic number" hard coded in the sources. I try to change this in future release, good point.
  1. If I change the monitor's settings to match the experiment designer default (1024 x 768), then when I calbrate the eye-tracker (a Mirametrix S2) the calibration dimensions (presumably 'inherited' from the S2 software) still use the screen's default settings, and so for instance the right hand column and bottom row of the 3x3 set of calibration circles are off-screen altogether. Is this normal behaviour and can anything be done (or is that a Mirametrix issue)?
The mirametrix interface was coded from mirametrix itself, but as far as I can see, there is no communication between ogama and mirametrix hardware talking about the screen resolution, so I think the s2 uses its latest configuration. Should be fixed, can you tell me the command for the S2 to sets the calibration plane (e.g. the command for displaying the calibration is <SET ID="CALIBRATE_SHOW" STATE="0">, than I may add it. I would prefer that you test it yourself using the sources (the code location is Ogama.Modules.Recording.MirametrixInterface class MirametrixTracker.cs.
  1. If I forget to change the screen dimensions in the experiment settings to match the screen's default then I get a reminder to do so when I try to record an experiment (i.e. the experiment sensibly won't run if the screen dimensions don't match the experiment settings). However, changing the settings at that point seems to produce results in the experiment that are fine for mouse tracking but, as far as I can tell, are respecting not the changed settings but the default Ogama dimensions for eye tracking. That is, the eye-track coordinates are 'off' by a factor that seems to be a ratio of default and actual sizes, so that a gaze that might actually have been to the bottom right of the tracked screen at recording time is only some 1/2 to 2/3 down & across the screen in the replay, and similarly for other points on the screen. Is there a fix to this?
From my point of view this is a problem that directly comes form point 2. The tracker does not know about your current screen resolution and so ogama receives wrongly calculated raw data.
Kind regards,
Adrian
Jul 14, 2013 at 6:54 AM
Thanks Adrian for the very helpful response. I'll remember in future to set up screen size as the first thing I do before calling any instance of the Mirametrix tracker or Ogama, and to keep the screen size to a lower resolution. I've done both these and everything works just fine.

You asked about the command for screen size for the Mirametrix S2. I've checked the Mirametrix API documentation. Screen size can be read (GET) or written (SET) as set out below:

6.16 SCREEN_SIZE
Description Get the size of the screen in pixels.

DATA_ID Read/Write Parameters Type Description

SCREEN_SIZE R/W WIDTH int Screen width (pixels)
SCREEN_SIZE R/W HEIGHT int Screen height (pixels)


Example Usage
SEND: <GET ID="SCREEN_SIZE" />
REPLY: <ACK ID="SCREEN_SIZE" WIDTH="1680" HEIGHT="1050" />

Paul
Coordinator
Jul 14, 2013 at 10:00 AM
Hi Paul,
thanks for your input, I updated the mirametrix interface with changeset 9cb710ad2413, so that it checks the screen resolution on initialization of the mirametrix recorder but cannot test it cause I have no device at hand. If you have the ability to run ogama from the latest sources using visual studio, I would be interested on your feedback if this update works. I also updated the timing issue with changeset bcd53890d908.
Kind regards,
Adrian
Jul 14, 2013 at 10:20 AM
I don't have visual studio, sorry. (And I suspect that even if I did I would not know what to do with a 'changeset')

Paul



Coordinator
Jul 16, 2013 at 7:51 AM
Hi Paul, I made a beta release: https://ogama.codeplex.com/releases/view/109493
I would appreciate your feedback once you have time to test it regarding the both mirametrix issues (timing and screen size) whether this works as expected.
Thanks in advance,
Adrian
Jul 16, 2013 at 7:54 AM
thanks Adrian
I'll check that out soon. I actually got a colleague to explain how to set up and use Visual Studio (which I had planned to do in the next day or so) so I hope that in future I'll be able to work with your changesets

Paul



Jul 16, 2013 at 8:26 AM
The beta release gives me the following error message when I click on Record data
Exception catched in SendMessage(...) Method; Unable to send data to server(s) !
Object reference not set to an instance of an object.
Coordinator
Jul 16, 2013 at 9:05 AM
That's why it would be great, if you can use the changesets :-)
I now moved the method into the connection method, so this might help, I also replaced the beta installer file, so it would be great if you try it again (awaiting the next error ;-) ). Need to have a mirametrix device myself... would be the faster solution ...
Adrian
Jul 16, 2013 at 10:19 AM
Thanks Adrian -
1. the screen resolution now successfully resets for the Mirametrix calibration
!
2. the samples are now much more regular. For example, on one trial of approx 14 seconds I get 853 samples, of which 694 are either 16 or 17 msec after the preceding sample, and 743 are 15-18 msec after the preceding sample. There is one extreme outlier at 122 msec which is not obviously linked to any other event (although I realise now that I did have Firefox running in the background).
Paul


Coordinator
Jul 16, 2013 at 11:24 AM
Good news. Thanks for your support!
Because the timestamps are now coming from the mirametrix api itself, its not ogama anymore which is responsible for the dispersion of the time stamps and the outlier :-)... This ranges should also appear when using the mirametrix recording application, and we can assume, that the samples timestamp is the correct time the gaze data was collected, without any side-effects from ogama.
Will be merged in the next official release 4.4.
Kind regards, don´t hesitate to ask further, currently I´m on holidays, so as you noticed I have some time for my ogama hobby :-).
Adrian