Rows 7-10 store the global transformation matrix that applies to the points (and I would assume to the sensor as well). At least that's what I could see in samples files such as some files found on http://www.libe57.org/data.html or Paul Bourke's site.
So in your case, I would expect row 3 to equal the 3 first values of row 10, and rows 4 to 6 equal the 3 first values of rows 7 to 9 (or something totally different depending on how the cloud was registered). Otherwise, this means that the points have been registered, but there's no 'sensor' associated.
Statistics: Posted by daniel — Fri May 29, 2026 2:04 pm
]]>
]]>
]]>
Pretty sure this is a bug. When importing a PTX file that has been registered (eg. exported from Leica Register360), the Sensor coordinates come through at 0,0,0. This is incorrect. The sensor coordinates should be translated by the values in row 10. See here: https://wiki.photoneo.com/index.php?tit ... ile_format
Furthermore, lines 7-10 define the transformation matrix for the sensor. See screenshot below, which shows the transformation matrix in a registered PTX next to the correct sensor location in CC (from an E57 file of the same cloud)
Statistics: Posted by framed — Tue May 26, 2026 8:04 am
]]>
]]>
OK it is confirmed it is a dumb question:
i didn't noticed that "Coord.Z" is the name of the scalar field that indeed i created and THEN applied some transforms.
Maybe its good to have a suffix to that label. "SF Coord.Z =" to have a nice "first glance" comprehension of that value.
Refreshing it is causing values to match again.
For the global shift: yes i know i lose some accuracy, but since the values are millimeters, i can afford to have a whole 1mm error
As a little suggestion:
it would be nice (for me..) to have:
less transparency in the beam
to be able to copy/paste from tree a 2d label to have full data, not only the name.
copy/paste now results in a: "2D label: Point #6225085"
the last suggestion in "eye-candy"
to have a border and a footer banner to match the picked point's RGB color:
Statistics: Posted by c3kkos — Mon Apr 20, 2026 5:58 am
]]>
The way the red X, green Y and blue Z appear on the left side of the label is weird. And also, how and when was the 'coord Z' scalar field generated? Does it really match the coordinates in the current cloud position?
Last, even if I agree it's a different problem - not using a Global shift is risky here (as you will probably lose some accuracy, at least along the X dimension).
Statistics: Posted by daniel — Sat Apr 18, 2026 9:17 am
]]>
there is something i can't get even after some time spent tweaking and checking my setup.
For i have a world-coordinates-referenced point cloud,
a -yellow- plane (set wireframe) which is set to be on Z=1000
here the screenshots:
so... why if i shift-pick a point which is correctly shown as Z0 = -91.231567, then the same widget reports a "Coord. Z = -1035.231567" ?
here's a second screenshot, i added a second -green- plane which is set on Z=0
They are not different values, an offset is applied (note the decimals, they are the same)
This seems strange at least, but it must be either wrong or wrong is my take on it (and my two cents are bet on the latter)
I do not have any kind of global shifts, or somehow voluntary altered the coordinate system.
By the way, i used shift-picking but the other methods return the same data
Statistics: Posted by c3kkos — Fri Apr 17, 2026 5:56 am
]]>
]]>
Is there a way to log this start to help you investigate ?
It's not an important issue but it irritates a bit and it could be the premise of another issue.
Statistics: Posted by BenoitD — Mon Apr 13, 2026 10:17 am
]]>
]]>
]]>
Statistics: Posted by daniel — Fri Mar 06, 2026 2:49 pm
]]>
]]>
(sadly it's not signed with a certificate, so you may have to convince Windows that it's safe to run)
Statistics: Posted by daniel — Sat Feb 21, 2026 11:01 pm
]]>