💻 software-dev


user-1369b4 05 May, 2026, 16:20:06

Hello, I've noticed that many outdoor scenes fail to render successfully when using reference images, even after recording a two-minute scan video. What else should I pay attention to in order to render successfully?

user-1369b4 05 May, 2026, 16:20:47

it shows error after few minutes processing.

rob 05 May, 2026, 16:48:03

Hi @user-1369b4 , Reference Image Mapper was specifically designed to also handle complex outdoor scenes and has been used successfully in such situations many times, as shown in the Documentation.. If you are open to inviting us as Collaborators to your Workspace [email removed] then we can take a closer look and provide better feedback.

user-1369b4 05 May, 2026, 19:56:28

Thanks, I send the link to you. Could you take look on my enrichments in gaze_vlm project? I deleted some old videos but the serval newest video are still showing error

rob 05 May, 2026, 20:49:11

Hi @user-1369b4 , I have taken a look. Some feedback:

  • It seems you are trying to take Scanning Recordings that stay narrowly focused on the Reference Image. You should move more forward, back, left, right, and up and down, but maintain the speed you are currently using. Try to scan from the side, too.
  • The Scanning Recording can be up to 3 minutes long. You currently scan for 1.5 minutes. In this case, you may want to take advantage of the full 3 minutes.
  • There is something covering the top of the scene camera that is occluding part of the image in some recordings. Is it potentially a hat? You may want to remove that to improve mapping success.
  • If that does not resolve it, then try using a Reference Image taken from the Neon recording, via a screenshot in the browser for example. The current Reference Image has slightly different colors than the Neon recording. This would be the last thing to try.

Basically, the goal is to scan a 3D model of the scene. If the above recommendations do not improve it, please let us know.

user-1369b4 05 May, 2026, 21:01:18

Okay, I will try to take longer scanning video. But new issues

rob 05 May, 2026, 21:02:07

Can you please open a Support Ticket about this in 🛟 troubleshooting ? I will report it to the Pupil Cloud team in the morning. Thanks!

user-3aecaf 24 May, 2026, 12:46:14

Hi Guys, Again with the pupil cloud -- I'm having a new problem. Now, all the .zip files I download contain "double" files (i.e. two files named the same thing). This causes problems when extracting. Files I downloaded 2 months ago worked fine.

The doubled files are almost always the ".raw" files (gaze ps1.raw) and some of the other .raw files.

They are different sizes, and one is not a subset of the other (the heads and tails are NOT the same, seemingly).

For example, I download a native format recording from the cloud collected from pupil neon or pupil invisible, and I get a .zip file. Inside the archive, I see two files named the same name! When I extract of course they clash.

user-3aecaf 24 May, 2026, 12:58:50

An example of the problematic recording is 2026-03-11_14-24-05-794259f1.

I just confirmed that the "first" file in each (the smaller sized file) is the correct one -- its MD5SUM hash matches the one I downloaded 2 months ago.

Howver, if it was bugged 2 months ago, I should compare it against the file copied manually from my phone I guess?

user-d407c1 25 May, 2026, 07:02:34

Hi @user-3aecaf 👋 ! Pupil Cloud recomputes gaze and other metrics when they were not originally recorded at the full sampling rate (200 Hz). These are what we call densified files, you would typically find these files suffixed by _200hz. In those instances, the full processing pipeline has rerun on Cloud and you would find data on every frame, that's why heads and tails don't match as they would contain more data.

There was a small bug last week affecting some of those 200 Hz densified exports, where the files were misplaced during download and named it wrongly. This issue has now been fixed, so if you redownload the recordings, the files should now appear in the correct location and with proper naming.

End of May archive