Introducing Kiretu - A Kinect reconstruction tutor
dawu
I want to introduce the result of my software practical to you. It is
called "Kiretu" (KInect REconstruction TUtor) and adresses people
interested in point-cloud-reconstruction using Kinect and OpenKinect.
Note that I am still a beginner at Kinect (and even at programming)
and I know that there are a lot of aspects which could be improved.
But at the beginning, it was hard for me dealing with the different
important topics (the theoretical, mathematical and programming-
related topics), that it was my intention to sum up all the
information I dealt with at the beginning.
I don't want to write a lot of information, because it is explained at
the project-website in detail:
http://pille.iwr.uni-heidelberg.de/~kinect01/
I am looking forward to any kind of feedback!
Greetings,
dawu
Antonio Ospite
dawu <dawu...@gmx.de> wrote:
> Hi,
>
> I want to introduce the result of my software practical to you. It is
> called "Kiretu" (KInect REconstruction TUtor) and adresses people
> interested in point-cloud-reconstruction using Kinect and OpenKinect.
>
Daniel[1],
thanks a lot for sharing.
> Note that I am still a beginner at Kinect (and even at programming)
> and I know that there are a lot of aspects which could be improved.
> But at the beginning, it was hard for me dealing with the different
> important topics (the theoretical, mathematical and programming-
> related topics), that it was my intention to sum up all the
> information I dealt with at the beginning.
>
This will save me a lot of time I would have spent fetching info here
and there, thanks.
> I don't want to write a lot of information, because it is explained at
> the project-website in detail:
>
> http://pille.iwr.uni-heidelberg.de/~kinect01/
>
> I am looking forward to any kind of feedback!
Would you add some info about the difference between doing calibration
with RGBDemo and using the registration data from the Kinect itself?
A pure libfreenect solution will be even grater, maybe we can even fix
examples/glpclview.c to use the registration data? I am not able to
do that yet, tho. :)
Regards,
Antonio
[1] What about showing your real name in the From: field when you send
emails too?
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
mankoff
On Jan 28, 7:45 am, dawu <dawu2...@gmx.de> wrote:
> Hi,
>
> I want to introduce the result of my software practical to you. It is
> called "Kiretu" (KInect REconstruction TUtor) and adresses people
> interested in point-cloud-reconstruction using Kinect and OpenKinect.
as follows to get it to compile on OS X. Haven't run it yet as the
Kinect isn't plugged in...
INCLUDES = -I /usr/local/include/libfreenect -I/usr/X11/include
LIBS = -lfreenect -framework OpenGL -framework glut
Daniel Wunderlich
> Daniel[1],
you are right. I am quite new to mailing-lists/Google Groups and still
accustomed to use Nicknames at the Internet. But i changed the
name. :-)
> This will save me a lot of time I would have spent fetching info here
> and there, thanks.
> Would you add some info about the difference between doing calibration
> with RGBDemo and using the registration data from the Kinect itself?
not possible to get the calibration parameters. Maybe I am wrong and
somebody could correct me!
> A pure libfreenect solution will be even grater, maybe we can even fix
> examples/glpclview.c to use the registration data? I am not able to
> do that yet, tho. :)
// Do the projection from u,v,depth to X,Y,Z directly in an opengl
matrix
// These numbers come from a combination of the ros kinect_node wiki,
and
// nicolas burrus' posts.
void LoadVertexMatrix()
{
float fx = 594.21f;
float fy = 591.04f;
float a = -0.0030711f;
float b = 3.3309495f;
float cx = 339.5f;
float cy = 242.7f;
GLfloat mat[16] = {
1/fx, 0, 0, 0,
0, -1/fy, 0, 0,
0, 0, 0, a,
-cx/fx, cy/fy, -1, b
};
glMultMatrixf(mat);
}
So it looks that this example uses default calibration-parameter and
does the same computations I did (even if the way is a bit different,
because it is solved with matrix-multiplications). Or am I wrong?
Regards,
Daniel
Daniel Wunderlich
> Neat stuff. I'll look into it some more. I had to modify the makefile
> as follows to get it to compile on OS X. Haven't run it yet as the
> Kinect isn't plugged in...
>
> INCLUDES = -I /usr/local/include/libfreenect -I/usr/X11/include
> LIBS = -lfreenect -framework OpenGL -framework glut
I will take a note of it and add it to the website in a future update.
Regards,
Daniel
Florian Echtler
>> Would you add some info about the difference between doing calibration
>> with RGBDemo and using the registration data from the Kinect itself?
> Oh, I am asking myself if this is possible?! As far as I know it is
> not possible to get the calibration parameters. Maybe I am wrong and
> somebody could correct me!
Getting the registration parameters is possible with the unstable branch
from the github repository.
>> A pure libfreenect solution will be even grater, maybe we can even fix
>> examples/glpclview.c to use the registration data? I am not able to
>> do that yet, tho. :)
You're right, that example should be updated.
> So it looks that this example uses default calibration-parameter and
> does the same computations I did (even if the way is a bit different,
> because it is solved with matrix-multiplications). Or am I wrong?
When you've switched to unstable, you can use the
FREENECT_DEPTH_REGISTERED format to get depth data which is a) rectified
and b) aligned to the RGB image using the Kinect's internal registration
parameters. ( a) might be more important for you, b) perhaps less so.)
You can then use the freenect_camera_to_world and freenect_depth_to_mm
helper functions to convert depth image x-y coordinates and a depth image
value at that position into x-y-z world coordinates.
Hope this helps,
Florian
--
"_Nothing_ brightens up my morning. Coffee simply provides a shade o
grey just above the pitch-black of the infinite depths of the _abyss_."
Daniel Wunderlich
> Getting the registration parameters is possible with the unstable
> branch from the github repository.
of the stuff I did. :o(
> When you've switched to unstable, you can use the
> FREENECT_DEPTH_REGISTERED format to get depth data which is a)
> rectified and b) aligned to the RGB image using the Kinect's internal
> registration parameters. ( a) might be more important for you, b)
> perhaps less so.)
> You can then use the freenect_camera_to_world and freenect_depth_to_mm
> helper functions to convert depth image x-y coordinates and a depth
> image value at that position into x-y-z world coordinates.
future!
Do you know where I find a explanation how the Kinect determines these
parameters (if something like this exists)?
Regards,
Daniel
Florian Echtler
>> from the github repository.
> oh, I didn't knew this. That's annoying, because it makes obsolete most of
> the stuff I did. :o(
the master branch and the 0.1.2 release, so if you use the packages from
my PPA, the new functions should be available.
>> When you've switched to unstable, you can use the
>> FREENECT_DEPTH_REGISTERED format to get depth data which is a) rectified
>> and b) aligned to the RGB image using the Kinect's internal registration
>> parameters. ( a) might be more important for you, b) perhaps less so.)
>> You can then use the freenect_camera_to_world and freenect_depth_to_mm
>> helper functions to convert depth image x-y coordinates and a depth image
>> value at that position into x-y-z world coordinates.
> Thank you very much for this information! I will deal with this in the
> future!
> Do you know where I find a explanation how the Kinect determines these
> parameters (if something like this exists)?
These parameters are likely stored in the Kinect during factory
calibration, using something like Nicolas' chessboard method.
Florian
--
"_Nothing_ brightens up my morning. Coffee simply provides a shade of
Joko Sutopo
Daniel Wunderlich
> Sorry :-)
no problem, it was my fault. :-) It's only a bit frustrating to know,
that the last weeks work was nearly for nothing. ;-)
> BTW, I've just realized that Drew has already merged this into
> the master branch and the 0.1.2 release, so if you use the packages from
> my PPA, the new functions should be available.
began working with libfreenect, there was only Maverick available.
> These parameters are likely stored in the Kinect during factory
> calibration, using something like Nicolas' chessboard method.
message.
Regards from Heidelberg to Munich,
Daniel
Jonathan Gennick
I don't want to write a lot of information, because it is explained at
the project-website in detail:
http://gennick.com/bio.html
Brighten the corner--where you are!
Alex
great job - kiretu looks great!
Three observations:
1. When scanning in IR format - the top half of the points in the PLY
file is in black and white (IR) and the bottom half is in color (RGB).
2. Are you going to put the source on github - it's simpler to do
updates for us if you modify the code
3. You write on your website "It is lightweight and does not include
features which are useless in context of point cloud reconstruction,
as the alternative OpenNI". What do you mean by that?
Best regards,
Alex
On Jan 30, 12:14 pm, Jonathan Gennick <j...@gennick.com> wrote:
> > I don't want to write a lot of information, because it is explained at
> > the project-website in detail:
>
> You did a very nice job on that website.
>
Daniel Wunderlich
> great job - kiretu looks great!
thank you, I'm glad you like it!
> Three observations:
> 1. When scanning in IR format - the top half of the points in the PLY
> file is in black and white (IR) and the bottom half is in color (RGB).
Oh, that's possible. I have to admit that I have never created a
point-cloud using the IR-format. I will check this in the future (I am
very busy at the moment) and try to fix this bug.
> 2. Are you going to put the source on github - it's simpler to do
> updates for us if you modify the code
I am very new to version control and after an evening of research in the
web I decided to use Bazaar at the beginning. Compared to git, it should
be a bit easier to learn and as a Linux Mint user, the comfortable
connection to Launchpad is also interesting for me. But at the moment,
it would be no problem to switch to git, if you give me some reasons --
I am open-minded!
> 3. You write on your website "It is lightweight and does not include
> features which are useless in context of point cloud reconstruction,
> as the alternative OpenNI". What do you mean by that?
I don't know much about OpenNI, but one of the advantages of OpenNI over
libfreenect is its built-in API for natural interaction (that's what NI
stands for), e. g. gesture recognition. In case of creating
point-clouds, these features are not necessary and would be overhead.
That's why I call libfreenect 'lightweight' and used it.
Thank you for your feedback. I hope I could help you a little bit!
Best regards,
Daniel