Jump to content
 

imarin18

Verified Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

2 Neutral

1 Follower

About imarin18

  • Rank
    Explorer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dear @Tony PH Lin Thank you very much for your check and the information. It is really helpful. Best regards, imarin18
  2. Dear HTC team, I'm writing to ask you about the specification of HTC VIVE Pro Eye. The field of view is 110 degrees according to your information. Is 110 degrees for both vertical and horizontal or diagonal? Thank you very much for the information you could provide. Best regards, imarin18
  3. Dear @Asish and @shomik As @Corvus mentioned, we need to see Unity FPS and eye sampling seprately. These two parameters: frame rate and sampling frequency of eye tracker are indepedent from each other. For example, while the Unity FPS changes depending on the VR design and the computer specification (e.g. sometimes it is 50FPS and it changes to 100FPS at another time), the sampling frequency of eye tracker is basically consistent at a specific value. If you use the callback fucntion, the sampling frequency should be more or less at around 120Hz, whereas the Unity FPS may fluctuate. Specifically, while Unity Update() is running on one thread, Eye call back funciton is running on another thread. However, as I wrote in another thread ( ), it seems that the current SRanipal SDK does not properly output the time stamp data. Thus, it may be difficult to evaluate the sampling interval or frequency of eye tracker correctly, using the time stamp data. I instead used DateTime.Now.Ticks property on C# and observed that the sampling frequency was more or less at around 120Hz. I hope this helps. Best regards, imarin18
  4. Dear @Daniel_Y Thank you very much for your reply and the explanation. I understood. Best regards, imarin18
  5. Dear @Daniel_Y Thank you very much for your reply and the explanation. I understood. Is my understanding correct for the calculation of angle in degrees from the data of gaze vector, following the trigonometric functions? Best regards, imarin18
  6. Dear @Daniel_Y I think I figured out the calculation of angle in degrees. We simply need to follow the concept of trigonometric functions, don't we? For example, if we want to calculate the angle of our eye movements in X direction, we just need to get the arc tangent from the data in X and Z directions. Could you please explain what 0 and 1 mean in the normalised pupil position in terms of angle in degrees? Best regards, imarin18
  7. Dear @Daniel_Y Thank you very much for your reply and the information. First of all, I made a wrong description in my previous post. I was supposed to write "Data in degrees assuming that the normalised data are between -pi and pi.", not "Data in degrees assuming that the normalised data are between -pi/2 and pi/2." Could you please explain how the device normalises the gaze direction data? For example, what is the situation when the gaze direction on x-axis is 1? According to the technical specification, the trackable field of view of this headset is 110 degrees. I reckon that -1 of the gaze direction data means -55 degrees and 1 means 55 degrees. Is my understanding correct? I check the pupil position as well. Could you please explain the configuration of pupil position as well? Does 0 mean -55 degrees and 1 mean 55 degrees? Thank you very much for the information you could provide. Best regards, imarin18
  8. Dear @Daniel_Y Thank you very much for your reply and the information. According to the data from my measurement, the gaze direction data are not in the range between 0 and 1 as shown in the figure below. The data even have negative values. In my measurement, I intentionally moved my eyes at +/-8 degrees from the central point. Assuming that the data were normalised between -pi/2 and pi/2, I calculated the degrees and found the subsequent figure, showing that my eyes moved to +/-8 degrees as expected. I'm sorry to ask you again and I may be still wrong, but could you please double confirm the configuration? Normalised data in my measurement. Data in degrees assuming that the normalised data are between -pi/2 and pi/2. As for the normalised pupil position, do you mean the position from the direction of the VR headset? Thank you very much for your support and the information you could provide. Best regards, imarin18
  9. Dear @alwyuyang Just to clarify again, I am not sure if my understanding is correct. According to your result, it looks that the validity value outputs 8 despite that you don't have any values for the measurement parameters. Have you tried to get the data while you are closeing your eyes completely and look at the validity data? My personal opinion is that it would be better to use only the data with 31 on the validity data. Best regards, imarin18
  10. Dear @alwyuyang I suppose that the technical support team meant that the huge gap from 62613 to 4205382 in timestamp data would be also a part of improvement. I'm not sure exactly about what you meant by "when it failed to measure", but when you get 8 in your validity data, I reckon that you have the valid data only for eye openness (SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY) having the value of 8 and the other four parameters have the value of 0, meaning that the four are not valid. Best regards, imarin18
  11. Dear @alwyuyang As explained in the following post, the timestamp cannot be correctly measured with the current SDK version according to the technical support team. If I understand correctly, I reckon that the value of validity follows the table below. If you sum all the decimal digits (1+2+4+8+16), you get 31. Though again I am not sure if my understanding is correct. Enumerator Binary digit if valid Decimal digit if valid SINGLE_EYE_DATA_GAZE_ORIGIN_VALIDITY 00001 1 SINGLE_EYE_DATA_GAZE_DIRECTION_VALIDITY 00010 2 SINGLE_EYE_DATA_PUPIL_DIAMETER_VALIDITY 00100 4 SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY 01000 8 SINGLE_EYE_DATA_PUPIL_POSITION_IN_SENSOR_AREA_VALIDITY 10000 16 Best regards, imarin18
  12. Dear HTC support team, According to my investigation, it does not seem that the gaze direction data are normalised between 0 and 1 as described in the manual. I reckon the data are in the range of [-pi/2 pi/2], though I am not sure if my understanding is correct. Could you please confirm the data configuration? Best regards, imarin18 @Daniel_Y @Corvus
  13. Dear @alwyuyang As in the following thread, the combined data are not supported at this point. Best regards, imarin18
  14. Dear @alwyuyang I suppose you can get the validity data from "eye_data_validata_bit_mask" in your code. The type of the output is UInt64, not bool. Best regards, imarin18
  15. Dear @kbombeke I observed the similar situation previously. I recommend using the information of eye validity first. If I understand correctly, the following shows how it works, though I am not sure if this is correct. Enumerator Binary digit if valid Decimal digit if valid SINGLE_EYE_DATA_GAZE_ORIGIN_VALIDITY 00001 1 SINGLE_EYE_DATA_GAZE_DIRECTION_VALIDITY 00010 2 SINGLE_EYE_DATA_PUPIL_DIAMETER_VALIDITY 00100 4 SINGLE_EYE_DATA_EYE_OPENNESS_VALIDITY 01000 8 SINGLE_EYE_DATA_PUPIL_POSITION_IN_SENSOR_AREA_VALIDITY 10000 16 I hope this helps. Best regards, imarin18
×
×
  • Create New...