converting to correct point data

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

converting to correct point data

ikillbombs
This post has NOT been accepted by the mailing list yet.
Hi everyone,

I'm new here. I'm using kinfu right now and I had recorded a pointcloud in the past. It is a recording that I saved to PLY files using Openframeworks:
https://github.com/openframeworks/openFrameworks/blob/master/examples/addons/kinectExample/src/ofApp.cpp#L161

I've converted the data to Obj to make it readable:

v 674.695 -601.755 1750
v 684.274 -604.85 1759
v 690.384 -604.85 1759
v 696.494 -604.85 1759
v 702.603 -604.85 1759

When I load this into Kinfu, I get this:
ERROR: In /tmp/vtk5-UywL/VTK5.10.1/Filtering/vtkStreamingDemandDrivenPipeline.cxx, line 1009
vtkStreamingDemandDrivenPipeline (0x7f9379260990): The update extent specified in the information for output port 0 on algorithm vtkImageFlip(0x7f937925f490) is 0 50741 0 0 0 0, which is outside the whole extent 0 50740 0 0 0 0.


I've noticed that the Openni recording data looks like this:

vn 0.000000 0.000000 0.000000
v -1.540903 -1.155074 2.532000 0.243137 0.168627 0.149020
vn 0.000000 0.000000 0.000000
v -1.536080 -1.155074 2.532000 0.243137 0.164706 0.149020
vn 0.000000 0.000000 0.000000
v -1.554238 -1.172410 2.570000 0.243137 0.160784 0.172549
vn 0.000000 0.000000 0.000000


How can I convert this data to the correct range?




Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

ikillbombs
Im writing a small conversion app in Processing. I've searched the forum and only could find one that may be suitable. The input array looks like this:

[0] "718.261" // x
[1] "-640.611" // y
[2] "1863" // z
[3] "65" // r
[4] "42" // g
[5] "1" // b
[6] "255" // a

and outputs this.
[0] "2.5488005"
[1] "-2.273254"
[2] "1.863"
[3] "65"
[4] "42"
[5] "1"
[6] "255"

using this formula:

  float z = float(lSplit[2])* 0.001f;
  float constant = 1.0f / 525;
  lSplit[0] = str(float(lSplit[0])* z * constant);
  lSplit[1] = str(float(lSplit[1])* z * constant);
  lSplit[2] = str(z);

Is this correct?
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

kwaegel
Administrator
Your formula looks about right. The formula used by the convertTo..PointCloud() functions for each pixel (u, v) is:

pt.z = depth_value_mm * 0.001f; // Convert to meters
pt.x = (u - Cx) * pt.z * (1/Fx);
pt.y = (v - Cy) * pt.z * (1/Fy);

where Fx/Fy is the camera focal length is pixels. They are usually the same. 525 is a reasonable default for the Kinect, but you would need to do lens calibration to get an exact value.

Cx/Cy is the center, or principle point, of the input image, and is usually defined as Cx=(width-1)/2 and Cy=(height-1)/2.
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

ikillbombs
This post was updated on .
Thanks for the reply!

I'm comparing an recorded pcd file that is converted to PLY. What i've noticed is that it starts with the following values:
ply
format ascii 1.0
comment PCL generated
element vertex 307200
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
property uchar alpha
element camera 1
property float view_px
property float view_py
property float view_pz
property float x_axisx
property float x_axisy
property float x_axisz
property float y_axisx
property float y_axisy
property float y_axisz
property float z_axisx
property float z_axisy
property float z_axisz
property float focal
property float scalex
property float scaley
property float centerx
property float centery
property int viewportx
property int viewporty
property float k1
property float k2
end_header

And the values look like this:
-1.5299487 -1.1468629 2.5140002 62 43 48 0
The alpha channel is allways zero.

and sometimes this:
nan nan nan 12 4 3 0 
and at the end of the file:
0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 640 480 0 0

I tried to copy the same behaviour and add it to my PLY file and then converted it to PCD. But then I get a "Bus error: 10"  

My directly converted PLY Looks like this:

ply
format ascii 1.0
element vertex 60889
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
property uchar alpha
end_header
2.5488005 -2.273254 1.863 65 42 1 0

Then I calculated the min and max values of the x and y axis:
min of x axis :  -1526.32
max of x axis : 1104.99
min of y axis  : -726.92
min of y axis  : 1184.76
I've mentioned that the vertex count is allot smaller than the vertex count of the recorded.And it skips 1 vertex. So the surface is 320*240 .  is this a big problem?
and what about the min and max of the xy? Must it be within 640 * 480?
And the camera data? Is that needed?
Is the way the points are sorted shall I have a look at that?
I allways check in Meshlab to check if Meshlab accepts it.





Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

nizar sallem
Can you send the PLY file so we can test to figure out what is happening
in there ?

--
Nizar

On 04/03/2014 22:06, ikillbombs wrote:

> Thanks for the reply!
>
> I'm comparing an recorded pcd file that is converted to PLY. What i've
> noticed is that it starts with the following values:
>
>
> And the values look like this:
>
> The alpha channel is allways zero.
>
> and sometimes this:
>
> and at the end of the file:
>
>
> I tried to copy the same behaviour and add it to my PLY file and then
> converted it to PCD. But then I get a "Bus error: 10"
>
> My directly converted PLY Looks like this:
>
> ply
> format ascii 1.0
> element vertex 60889
> property float x
> property float y
> property float z
> property uchar red
> property uchar green
> property uchar blue
> property uchar alpha
> end_header
> 2.5488005 -2.273254 1.863 65 42 1 0
>
> Then I calculated the min and max values of the x and y axis:
>
> min of x axis :  -1526.32
> max of x axis : 1104.99
> min of y axis  : -726.92
> min of y axis  : 1184.76
>
> I've mentioned that the vertex count is allot smaller than the vertex count
> of the recorded. is this a big problem?
>
> and what about the min and max of the xy? Must it be within 640 * 480?
> And the camera data? Is that needed?
> Is the way the points are sorted shall I have a look at that?
> I allways check in Meshlab to check if Meshlab accepts it.
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://www.pcl-users.org/converting-to-correct-point-data-tp4032600p4032707.html
> Sent from the Point Cloud Library (PCL) Users mailing list mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users
>
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

ikillbombs
I made a recording of my girlfriends dog, who died. I want to 3D print the dog using the Kinfu algorithm.

 ingimo-422.ply
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

nizar sallem
I will look into it and let you know by tomorrow morning.

--
Nizar

On 04/03/2014 23:15, ikillbombs wrote:

> I made a recording of my girlfriends dog, who died. I want to 3D print the
> dog using the Kinfu algorithm.
>
>    ingimo-422.ply <http://www.pcl-users.org/file/n4032711/ingimo-422.ply>
>
>
>
> --
> View this message in context: http://www.pcl-users.org/converting-to-correct-point-data-tp4032600p4032711.html
> Sent from the Point Cloud Library (PCL) Users mailing list mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users
>
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

nizar sallem
Please find attached the PCD file.
I am not sure why it doesn't work for you (probably an old PCL ?)

--
Nizar

On 04/03/2014 23:16, Nizar Sallem wrote:

> I will look into it and let you know by tomorrow morning.
>
> --
> Nizar
>
> On 04/03/2014 23:15, ikillbombs wrote:
>> I made a recording of my girlfriends dog, who died. I want to 3D print
>> the
>> dog using the Kinfu algorithm.
>>
>>    ingimo-422.ply <http://www.pcl-users.org/file/n4032711/ingimo-422.ply>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.pcl-users.org/converting-to-correct-point-data-tp4032600p4032711.html
>>
>> Sent from the Point Cloud Library (PCL) Users mailing list mailing
>> list archive at Nabble.com.
>> _______________________________________________
>> [hidden email] / http://pointclouds.org
>> http://pointclouds.org/mailman/listinfo/pcl-users
>>
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

ingimo.pcd (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

ikillbombs
This post was updated on .
I don't think it's an old version. I used https://wiki.ccs.neu.edu/display/GPC/pcl-trunk+on+OS+X+10.8.4+with+homebrew. I see the github rapidly changes. An update would do no harm.

The converting is easy. First I used pcl_ply2ply to convert to ascii and then pcl_ply2pcd. playing recorded data from PCL doesn't give a problem.
But the playing the PLY files in Kinfu shows problems. That's why i thought that there's something wrong with the data.

The problem is the vtkImageFlip error described above and Kinfu doesn't show any result. Just some artifects on the kinfu view. It looks like a not correctly allocated openGL frame buffer. Even when adding the -pcd-fps 0 to the command.
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

nizar sallem-3
Well at least now you are sure the data is fine.

As per the FlipImage it is kind of mandatory because of OpenGL.
To make sure visualization is fine try pcl_viewer with your PCD file.

--
Nizar


On Tue, Mar 4, 2014 at 11:41 PM, ikillbombs <[hidden email]> wrote:
I don't think it's an old version. I used
https://wiki.ccs.neu.edu/display/GPC/pcl-trunk+on+OS+X+10.8.4+with+homebrew.
I see the github rapidly changes. An update would do no harm.

The converting is easy. First I used pcl_ply2ply to convert to ascii and
then pcl_ply2pcd.
But the playing in Kinfu shows problems. That's why i thought that there's
something wrong with the data.

The problem is the vtkImageFlip error described above and Kinfu doesn't show
any result. Just some artifects on the kinfu view. Even when adding the
-pcd-fps 0 to the command.




--
View this message in context: http://www.pcl-users.org/converting-to-correct-point-data-tp4032600p4032714.html
Sent from the Point Cloud Library (PCL) Users mailing list mailing list archive at Nabble.com.
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: converting to correct point data

ikillbombs
This post has NOT been accepted by the mailing list yet.
I've updated the PCL library, but the problem still consists. Could you run a set of my data in your build of PCL-kinfu? https://www.wetransfer.com/downloads/281613630ce57cc60325ea027cef857b20140307201041/559faf4e0584327a9699668a5d0d160f20140307201041/bf5b8b