

I'm struggling to implement the stereo calibration example in chapter
12 of the new O'Reilly Learning OpenCV book.
My results have not been good, and I'm trying to zero in on the
problem. My first concern is with some apparent confusion over the
proper ordering of the points returned form cvFindChessboardCorners.
I'm running a 10x6 calibration target, any my points from
cvFindChessboardCorners are returned in rowmajor order, i.e.:
a b c d e f g h i j
k l m n o p q r s t ...
returns as abcdefghijklmnopqrst
This is in direct contradiction to this post:
http://tech.groups.yahoo.com/group/OpenCV/message/40455Also, the figure on page 384 of the O'Reilly book shows the points
drawn bottomtotop, lefttoright.
I tried a square chessboard also, and it alternated between placing
the points in column and row order. Tilting the target changed
effected the order, and the left and right images were sometimes
opposite.
So, what't the correct order? Any idea what could effect the
behavior?
Any general guidance or experience on stereo calibration is also
appreciated. My results range from nonsense to reasonablebut
inaccurate.
Joe


Joe, I'm not that good on this but was able to get it working. One
warning about the book's implementation  if one of the images fail
the calibration won't complete. It took me a while to realize this
and the code is hard to correct so make sure all your images are
good or remove them from the list.
Single camera handles this much easier.
Ed
 In [hidden email], "JoeStam" <jstam@...> wrote:
>
> I'm struggling to implement the stereo calibration example in
chapter
> 12 of the new O'Reilly Learning OpenCV book.
>
> My results have not been good, and I'm trying to zero in on the
> problem. My first concern is with some apparent confusion over
the
> proper ordering of the points returned form
cvFindChessboardCorners.
>
> I'm running a 10x6 calibration target, any my points from
> cvFindChessboardCorners are returned in rowmajor order, i.e.:
>
> a b c d e f g h i j
> k l m n o p q r s t ...
>
> returns as abcdefghijklmnopqrst
>
> This is in direct contradiction to this post:
> http://tech.groups.yahoo.com/group/OpenCV/message/40455>
> Also, the figure on page 384 of the O'Reilly book shows the points
> drawn bottomtotop, lefttoright.
>
> I tried a square chessboard also, and it alternated between
placing
> the points in column and row order. Tilting the target changed
> effected the order, and the left and right images were sometimes
> opposite.
>
> So, what't the correct order? Any idea what could effect the
> behavior?
>
> Any general guidance or experience on stereo calibration is also
> appreciated. My results range from nonsense to reasonablebut
> inaccurate.
>
> Joe
>


Do you see the points in row or column order?
 In [hidden email], "Ed Elston" <ed.elston@...> wrote:
>
> Joe, I'm not that good on this but was able to get it working. One
> warning about the book's implementation  if one of the images fail
> the calibration won't complete. It took me a while to realize this
> and the code is hard to correct so make sure all your images are
> good or remove them from the list.
>
> Single camera handles this much easier.
>
> Ed
>
>  In [hidden email], "JoeStam" <jstam@> wrote:
> >
> > I'm struggling to implement the stereo calibration example in
> chapter
> > 12 of the new O'Reilly Learning OpenCV book.
> >
> > My results have not been good, and I'm trying to zero in on the
> > problem. My first concern is with some apparent confusion over
> the
> > proper ordering of the points returned form
> cvFindChessboardCorners.
> >
> > I'm running a 10x6 calibration target, any my points from
> > cvFindChessboardCorners are returned in rowmajor order, i.e.:
> >
> > a b c d e f g h i j
> > k l m n o p q r s t ...
> >
> > returns as abcdefghijklmnopqrst
> >
> > This is in direct contradiction to this post:
> > http://tech.groups.yahoo.com/group/OpenCV/message/40455> >
> > Also, the figure on page 384 of the O'Reilly book shows the
points
> > drawn bottomtotop, lefttoright.
> >
> > I tried a square chessboard also, and it alternated between
> placing
> > the points in column and row order. Tilting the target changed
> > effected the order, and the left and right images were sometimes
> > opposite.
> >
> > So, what't the correct order? Any idea what could effect the
> > behavior?
> >
> > Any general guidance or experience on stereo calibration is also
> > appreciated. My results range from nonsense to reasonablebut
> > inaccurate.
> >
> > Joe
> >
>


Joe,
It says somewhere in the book that it is best to use a grid that has
one axis with an even number of squares and the other axis with an odd
number. This gives a single line of symmetry i.e one way round the
top left square is black, rotate by 180 degrees and the top left
square is now white. Maybe the cornerfinder uses the colour gradient
to work this out and arrange the ordering?
I've had similar problems with a 6x8 grid, but I'm interfacing from
matlab so I just flipped the returned ordering on the dodgy results.
Martin.
 In [hidden email], "JoeStam" <jstam@...> wrote:
>
> I'm struggling to implement the stereo calibration example in chapter
> 12 of the new O'Reilly Learning OpenCV book.
>
> My results have not been good, and I'm trying to zero in on the
> problem. My first concern is with some apparent confusion over the
> proper ordering of the points returned form cvFindChessboardCorners.
>
> I'm running a 10x6 calibration target, any my points from
> cvFindChessboardCorners are returned in rowmajor order, i.e.:
>
> a b c d e f g h i j
> k l m n o p q r s t ...
>
> returns as abcdefghijklmnopqrst
>
> This is in direct contradiction to this post:
> http://tech.groups.yahoo.com/group/OpenCV/message/40455>
> Also, the figure on page 384 of the O'Reilly book shows the points
> drawn bottomtotop, lefttoright.
>
> I tried a square chessboard also, and it alternated between placing
> the points in column and row order. Tilting the target changed
> effected the order, and the left and right images were sometimes
> opposite.
>
> So, what't the correct order? Any idea what could effect the
> behavior?
>
> Any general guidance or experience on stereo calibration is also
> appreciated. My results range from nonsense to reasonablebut
> inaccurate.
>
> Joe
>


I just tried 7x5, identical to the chart on page 384, and also 6x5.
Both identified points lefttoright, then top to bottom  opposite
of how it's drawn in the picture.
I'm not sure if this is the source of my problems or not. Does the
calbiration routine expect or require the points in column major
order as suggested here:
http://tech.groups.yahoo.com/group/OpenCV/message/40455Any other ideas why my points are being detected in row major?
 In [hidden email], "mdale9_opencv" <martin.dale.1@...>
wrote:
>
> Joe,
>
> It says somewhere in the book that it is best to use a grid that has
> one axis with an even number of squares and the other axis with an
odd
> number. This gives a single line of symmetry i.e one way round the
> top left square is black, rotate by 180 degrees and the top left
> square is now white. Maybe the cornerfinder uses the colour
gradient
> to work this out and arrange the ordering?
> I've had similar problems with a 6x8 grid, but I'm interfacing from
> matlab so I just flipped the returned ordering on the dodgy
results.
>
> Martin.
>
>  In [hidden email], "JoeStam" <jstam@> wrote:
> >
> > I'm struggling to implement the stereo calibration example in
chapter
> > 12 of the new O'Reilly Learning OpenCV book.
> >
> > My results have not been good, and I'm trying to zero in on the
> > problem. My first concern is with some apparent confusion over
the
> > proper ordering of the points returned form
cvFindChessboardCorners.
> >
> > I'm running a 10x6 calibration target, any my points from
> > cvFindChessboardCorners are returned in rowmajor order, i.e.:
> >
> > a b c d e f g h i j
> > k l m n o p q r s t ...
> >
> > returns as abcdefghijklmnopqrst
> >
> > This is in direct contradiction to this post:
> > http://tech.groups.yahoo.com/group/OpenCV/message/40455> >
> > Also, the figure on page 384 of the O'Reilly book shows the
points
> > drawn bottomtotop, lefttoright.
> >
> > I tried a square chessboard also, and it alternated between
placing
> > the points in column and row order. Tilting the target changed
> > effected the order, and the left and right images were sometimes
> > opposite.
> >
> > So, what't the correct order? Any idea what could effect the
> > behavior?
> >
> > Any general guidance or experience on stereo calibration is also
> > appreciated. My results range from nonsense to reasonablebut
> > inaccurate.
> >
> > Joe
> >
>


This post has NOT been accepted by the mailing list yet.
Hi Joe,
I'm having the same problem and was wondering if you found a solution? Right now I'm just tilting my checkerboard so that the image is always in rowmajor order.
Thanks,
Brian
JoeStam wrote
I just tried 7x5, identical to the chart on page 384, and also 6x5.
Both identified points lefttoright, then top to bottom  opposite
of how it's drawn in the picture.
I'm not sure if this is the source of my problems or not. Does the
calbiration routine expect or require the points in column major
order as suggested here:
http://tech.groups.yahoo.com/group/OpenCV/message/40455Any other ideas why my points are being detected in row major?
 In OpenCV@yahoogroups.com, "mdale9_opencv" <martin.dale.1@...>
wrote:
>
> Joe,
>
> It says somewhere in the book that it is best to use a grid that has
> one axis with an even number of squares and the other axis with an
odd
> number. This gives a single line of symmetry i.e one way round the
> top left square is black, rotate by 180 degrees and the top left
> square is now white. Maybe the cornerfinder uses the colour
gradient
> to work this out and arrange the ordering?
> I've had similar problems with a 6x8 grid, but I'm interfacing from
> matlab so I just flipped the returned ordering on the dodgy
results.
>
> Martin.
>
>  In OpenCV@yahoogroups.com, "JoeStam" <jstam@> wrote:
> >
> > I'm struggling to implement the stereo calibration example in
chapter
> > 12 of the new O'Reilly Learning OpenCV book.
> >
> > My results have not been good, and I'm trying to zero in on the
> > problem. My first concern is with some apparent confusion over
the
> > proper ordering of the points returned form
cvFindChessboardCorners.
> >
> > I'm running a 10x6 calibration target, any my points from
> > cvFindChessboardCorners are returned in rowmajor order, i.e.:
> >
> > a b c d e f g h i j
> > k l m n o p q r s t ...
> >
> > returns as abcdefghijklmnopqrst
> >
> > This is in direct contradiction to this post:
> > http://tech.groups.yahoo.com/group/OpenCV/message/40455> >
> > Also, the figure on page 384 of the O'Reilly book shows the
points
> > drawn bottomtotop, lefttoright.
> >
> > I tried a square chessboard also, and it alternated between
placing
> > the points in column and row order. Tilting the target changed
> > effected the order, and the left and right images were sometimes
> > opposite.
> >
> > So, what't the correct order? Any idea what could effect the
> > behavior?
> >
> > Any general guidance or experience on stereo calibration is also
> > appreciated. My results range from nonsense to reasonablebut
> > inaccurate.
> >
> > Joe
> >
>


I am also having an ambiguity issue with FindChessboardCorners. I am using a Python interface.
If I use an asymmetric chessboard such as 4x5, such a choice removes rowmajor verses columnmajor ordering. This conclusion is probably obvious, but I wanted to state it for clarity.
However, using the same 4x5 chessboard, I have a second ambiguity of a 180degree flip. Sometimes, the FindChessboardCorners returns the following ordering:
a b c d e
f g h i j
k l m n o
p q r s t
Other runs, the algorithm returns the following ordering:
t s r q p
o n m l k
j i h g f
e d c b a
I logically understand why the ambiguity happens as the chessboard is symmetric and a 180degree rotation in the plan of the chessboard is not resolvable.
However, what I don't understand is that FindChessboardCorners seems to behave randomly as to which ordering it returns. I am trying to find deterministically how FindChessboardCorners behaves.
Any thoughts or insights?


Hi,
I'm using a chessboard with 10 x 15 squares (9 x 14 internal corners) and because it has an even x odd design then it is not 180 degree rotationally symmetric.
If you draw this out on a piece of paper you will see that one side/edge of the chessboard has black squares on its corners while the opposite edge has white squares. The direction from the "black side" to the "white side" is the primary direction (X). The Z axis is into the plane of the chessboard so using Flemings Right Hand Rule we can determine the Y direction.
Hope this makes sense.
Martin
 In [hidden email], "page3d@..." <davidpage@...> wrote:
>
>
> I am also having an ambiguity issue with FindChessboardCorners. I am using a Python interface.
>
> If I use an asymmetric chessboard such as 4x5, such a choice removes rowmajor verses columnmajor ordering. This conclusion is probably obvious, but I wanted to state it for clarity.
>
> However, using the same 4x5 chessboard, I have a second ambiguity of a 180degree flip. Sometimes, the FindChessboardCorners returns the following ordering:
>
> a b c d e
> f g h i j
> k l m n o
> p q r s t
>
> Other runs, the algorithm returns the following ordering:
>
> t s r q p
> o n m l k
> j i h g f
> e d c b a
>
> I logically understand why the ambiguity happens as the chessboard is symmetric and a 180degree rotation in the plan of the chessboard is not resolvable.
>
> However, what I don't understand is that FindChessboardCorners seems to behave randomly as to which ordering it returns. I am trying to find deterministically how FindChessboardCorners behaves.
>
> Any thoughts or insights?
>


I follow you. I think I need to correct my post and I see that the ambiguity is gone.
I am actually using a 4x5 (inner corner) grid. I do get rowmajor ordering but from right to left and bottom to top.
If I use a 5x4 (inner corner) grid. I also get rowmajor ordering but from left to right and top to bottom.
The 4x5 and 5x4 grids are different only by definition and not by geometry. The definition difference is in whether the rows are even or odd.
The mistake that I made is to use a 4x5 grid in one instance and then I used a 5x6 grid later. With the 4x5 grid, I had rowmajor rightleft, bottomtop ordering. With the 5x6 grid, I had the flip ordering with leftright, topbottom. I assumed (wrongly) that this difference was "random."
I know understand that it is important that you clearly specify two components of your grid's inner corners.
(A) Make sure you have a mixture of even rows and odd columns or visa versa odd rows and even columns. This inner corner choice leads to orientation uniqueness.
(B) Further, if you have odd rows, then you will also have rowmajor ordering with leftright and topbottom sequencing for a normal orientation of the grid. Conversely, if you have even rows, you withll have rightleft, bottomtop ordering.
Summary:
(A) 4x5 (even x odd) inner corner yields rowmajor from right to left and bottom to top.
(B) 5x4 (odd x even) inner corner yields rowmajor from left to right and top to bottom.
Maybe this information is documented somewhere, but I haven't found it yet. So, I wanted to post it for clarity. If I've made an error, please correct me.
Thanks!
Dave
 In [hidden email], "mdale9_opencv" <martin.dale.1@...> wrote:
>
> Hi,
>
> I'm using a chessboard with 10 x 15 squares (9 x 14 internal corners) and because it has an even x odd design then it is not 180 degree rotationally symmetric.
>
> If you draw this out on a piece of paper you will see that one side/edge of the chessboard has black squares on its corners while the opposite edge has white squares. The direction from the "black side" to the "white side" is the primary direction (X). The Z axis is into the plane of the chessboard so using Flemings Right Hand Rule we can determine the Y direction.
>
> Hope this makes sense.
> Martin
>
>  In [hidden email], "page3d@" <davidpage@> wrote:
> >
> >
> > I am also having an ambiguity issue with FindChessboardCorners. I am using a Python interface.
> >
> > If I use an asymmetric chessboard such as 4x5, such a choice removes rowmajor verses columnmajor ordering. This conclusion is probably obvious, but I wanted to state it for clarity.
> >
> > However, using the same 4x5 chessboard, I have a second ambiguity of a 180degree flip. Sometimes, the FindChessboardCorners returns the following ordering:
> >
> > a b c d e
> > f g h i j
> > k l m n o
> > p q r s t
> >
> > Other runs, the algorithm returns the following ordering:
> >
> > t s r q p
> > o n m l k
> > j i h g f
> > e d c b a
> >
> > I logically understand why the ambiguity happens as the chessboard is symmetric and a 180degree rotation in the plan of the chessboard is not resolvable.
> >
> > However, what I don't understand is that FindChessboardCorners seems to behave randomly as to which ordering it returns. I am trying to find deterministically how FindChessboardCorners behaves.
> >
> > Any thoughts or insights?
> >
>


Hmmm. I'm seeing another correction here.
Looks like the key is to have an oddeven rowcolumn relationship and then to know where the "key" square is.
I am defining the "key" square as the upper leftmost black square. So for a 3x4 (inner corner) chessboard, we would have rowmajor ordering with leftright, topbottom inner corner squencing from FindChessboardCorners with the following orientation:
b00 w01 b02 w03 b04
w10 b11 w12 b13 w14
b20 w21 b22 w23 b24
w30 b31 w32 b33 w34
where 'b' denotes black square and 'w' denotes white. The numbering 'bxy' (or 'wxy') denotes a black (or white) square in row 'x' and column 'y'.
So for the above 'b00' is what I'm defining as the "key" square.
If we begin with a white square in the upper left such as with a 4x3 inner corner configuration, we have:
w00 b01 w02 b03
b10 w11 b12 w13
w20 b21 w22 b23
b30 w31 b32 w33
w40 b41 w42 b43
In this case, 'b43' is the "key" square and ordering would be still be rowmajor but with rightleft, bottomtop sequencing.
In reality, the above 4x3 configuration is just a 180 rotation in the plane of the chessboard of the following configuration:
b43 w42 b41 w40
w33 b32 w31 b30
b23 w22 b21 w20
w13 b12 w11 b10
b03 w02 b01 w00
Now, the key "b43" is in the upperleft corner and we again have rowmajor ordering with leftright, topbottom sequencing.
Summary, it seems to me that if the "key" square is defined to be in the upper leftmost corner of the normal orientation of an oddeven inner corner grid, then you will always have rowmajor ordering with leftright, topbottom sequencing.
Do I have this correct?
Dave
 In [hidden email], "page3d@..." <davidpage@...> wrote:
>
>
> I follow you. I think I need to correct my post and I see that the ambiguity is gone.
>
> I am actually using a 4x5 (inner corner) grid. I do get rowmajor ordering but from right to left and bottom to top.
>
> If I use a 5x4 (inner corner) grid. I also get rowmajor ordering but from left to right and top to bottom.
>
> The 4x5 and 5x4 grids are different only by definition and not by geometry. The definition difference is in whether the rows are even or odd.
>
> The mistake that I made is to use a 4x5 grid in one instance and then I used a 5x6 grid later. With the 4x5 grid, I had rowmajor rightleft, bottomtop ordering. With the 5x6 grid, I had the flip ordering with leftright, topbottom. I assumed (wrongly) that this difference was "random."
>
> I know understand that it is important that you clearly specify two components of your grid's inner corners.
>
> (A) Make sure you have a mixture of even rows and odd columns or visa versa odd rows and even columns. This inner corner choice leads to orientation uniqueness.
>
> (B) Further, if you have odd rows, then you will also have rowmajor ordering with leftright and topbottom sequencing for a normal orientation of the grid. Conversely, if you have even rows, you withll have rightleft, bottomtop ordering.
>
> Summary:
>
> (A) 4x5 (even x odd) inner corner yields rowmajor from right to left and bottom to top.
>
> (B) 5x4 (odd x even) inner corner yields rowmajor from left to right and top to bottom.
>
>
> Maybe this information is documented somewhere, but I haven't found it yet. So, I wanted to post it for clarity. If I've made an error, please correct me.
>
> Thanks!
>
> Dave
>
>
>
>
>  In [hidden email], "mdale9_opencv" <martin.dale.1@> wrote:
> >
> > Hi,
> >
> > I'm using a chessboard with 10 x 15 squares (9 x 14 internal corners) and because it has an even x odd design then it is not 180 degree rotationally symmetric.
> >
> > If you draw this out on a piece of paper you will see that one side/edge of the chessboard has black squares on its corners while the opposite edge has white squares. The direction from the "black side" to the "white side" is the primary direction (X). The Z axis is into the plane of the chessboard so using Flemings Right Hand Rule we can determine the Y direction.
> >
> > Hope this makes sense.
> > Martin
> >
> >  In [hidden email], "page3d@" <davidpage@> wrote:
> > >
> > >
> > > I am also having an ambiguity issue with FindChessboardCorners. I am using a Python interface.
> > >
> > > If I use an asymmetric chessboard such as 4x5, such a choice removes rowmajor verses columnmajor ordering. This conclusion is probably obvious, but I wanted to state it for clarity.
> > >
> > > However, using the same 4x5 chessboard, I have a second ambiguity of a 180degree flip. Sometimes, the FindChessboardCorners returns the following ordering:
> > >
> > > a b c d e
> > > f g h i j
> > > k l m n o
> > > p q r s t
> > >
> > > Other runs, the algorithm returns the following ordering:
> > >
> > > t s r q p
> > > o n m l k
> > > j i h g f
> > > e d c b a
> > >
> > > I logically understand why the ambiguity happens as the chessboard is symmetric and a 180degree rotation in the plan of the chessboard is not resolvable.
> > >
> > > However, what I don't understand is that FindChessboardCorners seems to behave randomly as to which ordering it returns. I am trying to find deterministically how FindChessboardCorners behaves.
> > >
> > > Any thoughts or insights?
> > >
> >
>

