## RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration

 RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Andrew Fitzgibbon - 2002-11-14 11:13:40 ```> > Can you make a flag so the old behaviour is toggleable? > > Of course. But why would that be needed? > A PMatrix P and the matrix -P represent the same projection, > so they should essentially return the same decomposition. Peter, The difference between theory and practice is the reason code breaks. For example, a few months ago many changes were made to netlib which should in theory have made no difference, but in practice meant that Cholesky and other routines were silently broken for several weeks. I submitted a paper for review with results generated by broken Cholesky. In general, I think we all need to take more care with changes which "essentially" return the same results. A. ```

 [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Yu Lianqing - 2002-10-28 01:06:08 ```PMatrixDecompCR(oxl/mvl) decomposes a projection matrix P into the form P = K [R t] where K is upper triangular and R is a rotation. However, it only guarantees that K(0,0)>0 and K(2,2)=1 and not K(1,1)>0, which should be the focal length in y coordinate axis. For example, for a projection matrix: -12.80 -0.70 0.87 0.45 0.67 -12.82 -0.49 0.89 -0.00 0.00 -0.04 0.00 we get: calibration: 299.998282844 -0.000019245 -0.000050939 0.000000000 -300.001236810 0.003046630 0.000000000 0.000000000 1.000000000 rotation: -0.996196941 -0.054735483 0.067791459 -0.052208744 0.997893760 0.038500522 -0.069756019 0.034814795 -0.996956382 translation: 0.034816940 -0.069632838 0.034816739 if we set t=[1 0 0; 0 -1 0; 0 0 1], right multiply C with t and left multiply R with inv(t), the correct result can be obtained calibration: 299.998282844 0.000019245 -0.000050939 0.000000000 300.001236810 0.003046630 0.000000000 0.000000000 1.000000000 rotation: -0.996196941 -0.054735483 0.067791459 0.052208744 -0.997893760 -0.038500522 -0.069756019 0.034814795 -0.996956382 translation: 0.034816940 0.069632838 0.034816739 Are there anyone notice this issue, what is your opinions? help and discussion appreciated! -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@...! http://shopnow.netscape.com/ ```
 Re: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Peter Vanroose - 2002-11-14 08:56:38 ```> PMatrixDecompCR(oxl/mvl) decomposes a projection matrix P into the form > P = K [R t] where K is upper triangular and R is a rotation. > However, it only guarantees that K(0,0)>0 and K(2,2)=1 and not K(1,1)>0, > which should be the focal length in y coordinate axis. If nobody objects, I will change the source code to guarantee K(1,1) >= 0, which as you point out is easily done by just changing the sign of a few output values. Peter. ```
 RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Andrew Fitzgibbon - 2002-11-14 10:45:35 ```Can you make a flag so the old behaviour is toggleable? > -----Original Message----- > From: vxl-users-admin@... > [mailto:vxl-users-admin@...] On Behalf Of > Peter Vanroose > Sent: 14 November 2002 08:56 > To: Yu Lianqing > Cc: vxl-users@... > Subject: Re: [Vxl-users] PMatrixDecompCR does not guarantee a > reasonable calibration > > > > PMatrixDecompCR(oxl/mvl) decomposes a projection matrix P > into the form > > P = K [R t] where K is upper triangular and R is a rotation. > > However, it only guarantees that K(0,0)>0 and K(2,2)=1 and > not K(1,1)>0, > > which should be the focal length in y coordinate axis. > > If nobody objects, I will change the source code to guarantee > K(1,1) >= 0, which as you point out is easily done by just changing > the sign of a few output values. > > > Peter. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Vxl-users mailing list > Vxl-users@... > https://lists.sourceforge.net/lists/listinfo/vxl-users > ```
 RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Peter Vanroose - 2002-11-14 10:59:46 ```> Can you make a flag so the old behaviour is toggleable? Of course. But why would that be needed? A PMatrix P and the matrix -P represent the same projection, so they should essentially return the same decomposition. Peter. ```
 RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Andrew Fitzgibbon - 2002-11-14 11:13:40 ```> > Can you make a flag so the old behaviour is toggleable? > > Of course. But why would that be needed? > A PMatrix P and the matrix -P represent the same projection, > so they should essentially return the same decomposition. Peter, The difference between theory and practice is the reason code breaks. For example, a few months ago many changes were made to netlib which should in theory have made no difference, but in practice meant that Cholesky and other routines were silently broken for several weeks. I submitted a paper for review with results generated by broken Cholesky. In general, I think we all need to take more care with changes which "essentially" return the same results. A. ```
 RE: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Peter Vanroose - 2002-11-14 11:19:31 ```> In general, I think we all need to take more care with changes > which "essentially" return the same results. The same argument holds also in the other direction: when an implementation of an algorithm does not return what the user expects, it's better to change the implementation to match the expectations. Peter. P.S. This does of course not preclude the addition of a flag in PMatrixDecompCR, as you were suggesting. ```
 Re: [Vxl-users] PMatrixDecompCR does not guarantee a reasonable calibration From: Yu Lianqing - 2002-11-21 13:56:17 Attachments: Message as HTML ```I am sorry for the delay to reply this mail as I am very busy with the application. I favour to change the code because one will get the wrong calibration and motion if she uses the original code. This has been verified in my research. Since sourceforge.net has been blocked in China(I can't access it and download the source code any longer), so Peter, Can you synchronize vxl mirror site at Kuleuven please? Peter Vanroose wrote: >>PMatrixDecompCR(oxl/mvl) decomposes a projection matrix P into the form >>P = K [R t] where K is upper triangular and R is a rotation. >>However, it only guarantees that K(0,0)>0 and K(2,2)=1 and not K(1,1)>0, >>which should be the focal length in y coordinate axis. >> >> > >If nobody objects, I will change the source code to guarantee >K(1,1) >= 0, which as you point out is easily done by just changing >the sign of a few output values. > > > Peter. > > > -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@...! http://shopnow.netscape.com/ ```