• I'm doing some testing for a new project and would like to record what the viewer looks at both during a 'normal' web session, i.e. PC, tablet, mobile and also if they are using VR (google cardboard, monoscopic).

    My Idea would be to somehow record current vlookat and hlookat values (say once per second) and save them in a file.

    Any ideas?

    Thanks

    Tim


    ps: I seem to remember seeing a demo that had 'readouts' of current parameters on the screen???

  • That should not be much of a problem.

    I would probably handle the data acquisition in javascript in the html file where the pano is implemented. It is easy to get data from the krpano environment from this level.

    A javascript function that reads out the h and v.

    Code
    h = krpano().get('view.hlookat'); 
    v = krpano().get('view.vlookat');

    Then you could simply use the setinterval function to read out the data every x milliseconds. How accurate you want the motion to be captured determines how often you would poll the data.


    Code
    setInterval(function(){ getPanoData(); }, 1000); // get pano data once a second

    Storing the data is also subject mostly to personal preference. I'd probably dump it in a freakishly large array and periodically send it off to some PHP module that stores it either in a database or a flat file.

    I think that is the Q&D way of doing it, but you could make some enhancements like storing duration. It all depends what you want to do with the data. Once a second is quite slow. Head movements can be very fast. I'd poll at least 10 times a second, but that is just a gut feeling. Faster polling gets you more data which could be a bother, but there is a way around this.

    With a VR headset, a user typically looks at something for an amount of time and then looks to something else. You could have the function check the new read out with the last read out and set a threshold. If the conditions are the same, you count 1 interval. If the conditions are different (detect movement), you store the new values plus the interval counter times the interval delay time. This could dramatically decrease the data you need to save. for staring at something for 5 second, you'd have 2 entries instead of an entry * 5 seconds/interval.

    Edited 5 times, last by Timescale (April 30, 2016 at 12:54 PM).

  • I've been dicking around with it because thinking about it, this could be something that could be used to build automated tours.
    I think it's entirely possible to "playback" these recorded motions, which would be cool!
    This is what I came up with.

    If you set :

    Code
    setInterval(function(){ recordMovement(); }, 1000);

    On the body where the pano is implemented, you get a readout once every second.

    You can play with the interval or the amount of deviation required to count as movement to see what suits your needs best.
    You could also let the function neatly return the 3 values to another function if needs be.

    Edited once, last by Timescale (April 30, 2016 at 1:34 PM).

  • Hi

    Thanks for this, I'm not a javascript programmer, but get the 'gist' of what this does.

    What I'm trying to do for a given pano is build up a picture of what the popular areas of the pano are.

    So for example I could then create a heat map which could be superimposed on the 360x180 image showing which areas get looked at the most.

    I played around with trace and error log:

    <eventsonkeydown="showlog(true);
    trace('hlookat=',view.hlookat);
    trace('vlookat=',view.vlookat);
    trace('fov=',view.fov);"

    So everytime I hit a key I get a snapshot of the current orientation, for example:

    INFO: hlookat=46.2821350492115
    INFO: vlookat=-2.5397327282438455
    INFO: fov=85
    INFO: hlookat=55.24328575509891
    INFO: vlookat=-2.13933945152334
    INFO: fov=85

    Keeping it simple for now, how hard would it be to just write out the three values above once a second (I agree with your point that in reality you would probably do this more often) to a local file that could then be processed by counting up the number of occurances of each hlookat from 0 to 360 and v lookat from -90 to 90. i.e. if I spend 10 secs in the tour and look at 90 for 5 sec, then I spent 50% of my visit looking to my right

  • Just outputting the data per second would be easier. Just take out the code that does the compare and your have a data point every second the interval triggers. Then all you need to do is decide how to collect and store it. If you are developing on a platform that has PHP, then you could simply use a quick and dirty form that dumps all the data to a database or a file.

    You could implement the interval in KRpano directly and build an action for it, perhaps with openURL you could send the data to a storage mechanism which would mean you don't need javascript at that end, but you'd have to build up the string that is the url with the arguments, and that is easier anyway in JS. Bottom line is, that if you need to store this data server-side, eventually you'll have to get the data to a point where it can quickly and safely be stored. I think PHP and a MySQL/MariaDB solution would be quickest.


    (JS function without the compare)

    Code
    function recordHVF(){
    	
    		// called every second
    		var h = krpano().get('view.hlookat'); // get view data
    		var v = krpano().get('view.vlookat');
    		var fov = krpano().get('view.fov');
    	
    		writeToXYZ(h,v,fov);	// the thing that writes data to somewhere.
    	}

    Now what and how writeToXYZ actually works depends on how you want to process the data and what is available to you. Generate XML? or just dump all of it to a database? Are you running an *amp stack as a platform?

    I like the idea of the heat map. That also would be a nice application for this type of data. Figuring out what people find interesting or worthwhile is something that has not been done a lot regarding panoramic tours I think, well at least not for the application I use it for.

    Of course, if you are to process a heat map, you'll need to do some type of data analysis as well. With your per-second approach, incorporating FOV into the equation would be simpler, but after I added FOV to my implementation, I thought how FOV would be a useful metric for actually measuring interest, but I came to the conclusion that it doesn't really, or at least not all the time. (So I do not trigger of off FOV, but I do record it)

    I further chose to generate XML data from the pseudo-mocap function and I have an example at the bottom. My assumption is that evey motion is done within a second, meaning that a record with 6 seconds is in fact 5 seconds of motionlessness. This means that every record with 1 second is in fact pure motion. If I'd want to tally interest, I'd gather all records with time > 1 and assign interest = time -1 to the previous coordinate set, because that was the spot what was looked at without motion.

    Edited once, last by Timescale (May 1, 2016 at 11:44 PM).

  • Perhaps something like this could work for you?

    It basically is a method to get data server-side, but now in a action script. I haven't yet checked if it actually works as a KRpano action, but I suspect it would. I tend to use as little JS in KRpano as possible for debugging reasons, but in effect with using the setinterval() function of KRpano, you can set this to 1 second and you would receive the data on the server-side every second.

    "eyeTrackIO.php" would then get the variables $_GET["ath"],$_GET["atv"],$_GET["fov"] and you can store them any which way you want.

    It's not the prettiest of solutions, nor the best, but with a limited set of options, this perhaps is a way to go. If you need help on the PHP side, just ask.

    (You could have the PHP script return valid XML, but in this case it is not necessary, it is more of a hack.)

  • The following scripts will fill a table with view data every second.

    1. set the interval in the KRpano XML file (example with 1 second timer

    Code
    setinterval(time, 1.0, eyeTrack(get('view.vlookat'),get('view.hlookat'),get('view.fov')));

    2. The action script that calls the PHP function

    3. the PHP script that takes the data ans stores it into a DB

    This is about the quickest way I can think of getting the data you need into a workable stored format. The only thing needed is a *AMP stack with a table with the proper fields. I made the datafields of the type Double.

    Edited once, last by Timescale (May 2, 2016 at 4:04 PM).

  • Thanks for all your work on this, I will try it out tomorrow.

    Cheers
    Tim


    No Problemo!, Though it is not a completely unselfish act on my part, mind! I now have a vested interest in this concept which your first comment initiated.. Thanks for that as well!.

    Let me know how it goes..

    Greetz,
    Peter From Timescale.

  • Very interesting idea! And really nice work on the JS-part, Timescale *thumbup*

    The krpano-script could be a little more exciting though. Right now every 1 sec. the ath, atv and fov are getting saved, but that´s maybe not really where the user was looking at, but just the actual ath/atv/fov while panning. There should be some kind of detection when the user is pausing panning or holding the view at a specific field of view (+-2 or 3 degrees ie). This would create a table of the point of interests...

  • Thanks!

    I agree and in post number 3 ( eye tracking ) I posted a script that would actually record time spend in a given H * V degrees area. I use a variant of that implementation with the only difference that it also stores FOV and it now stores the last known coordinates + time instead of the time + current coordinates.

    Trek wanted a Q&D implementation, so the once per second setup will probably work for basic data processing. And a lot of the information still exists in the data-set, it just has to be pulled out at a later stage.

    It is also true that the center of the screen is not necessarily the point at which the user has looked, but assuming that most people using a desktop PANO viewer as well as a mobile/VR one tend to center on the objects of interest, I'm not really bothered by that. Imagine that X percentage of humans preferred to gaze past objects of interest slightly. Then on average, I imagine, the mean center of those points would again be the point where the other % of people would stare directly!

    We'll just have to analyze the data!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!