Compilation error in Visual Studio when using cubic interpolation

63 views
Skip to first unread message

Zi Wang

unread,
Jul 26, 2017, 10:29:07 PM7/26/17
to Ceres Solver
Hi,

I am using the bicubic interpolation object in ceres for optimization with respect to image coordinates. Yet it runs into compilation error in Visual studio 2013, at the function "CubicHermiteSpline" from the file "cubic_interpolation.h". The error message is as follows.

"error C1001: An internal error has occurred in the compiler" 

Yet, the same program can successfully run on Linux system. As I am restricted to develop on Windows platform, I would appreciate any pointers on this issue. Thanks!

Best,
Zi

Sameer Agarwal

unread,
Jul 26, 2017, 11:35:01 PM7/26/17
to Ceres Solver
Zi,
This looks like a bug in Visual Studio. 
Sameer


--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/468f0f11-8005-4874-adf7-74e2de806c40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Zi

unread,
Aug 7, 2017, 5:38:03 PM8/7/17
to Ceres Solver
Hi Sameer,

Thanks a lot for your reply. It is indeed an issue of Visual studio. I have updated Visual studio and the code compiles now. 

However, I encounter another problem. I want to use rgb values to optimize the vertex positions of a 3D model. The current optimization gives weird output, as shown in the attached image. From iteration 3 to 7, the cost function value remains constant, then the program hangs at iteration 12. 

I wonder if this is some problem from cost function. Any pointers would be appreciated. Thanks!

Best,
Zi
summary report.png

Sameer Agarwal

unread,
Aug 7, 2017, 5:50:30 PM8/7/17
to Ceres Solver
Zi,
What do you mean it hangs?
Sameer


Zi

unread,
Aug 7, 2017, 5:53:27 PM8/7/17
to Ceres Solver
Sorry, I mean the program cannot proceed to the next iteration and stays there for a very long time...

Zi

Sameer Agarwal

unread,
Aug 7, 2017, 5:54:29 PM8/7/17
to Ceres Solver
Hard to debug this from here Zi. Would be good to see in a debugger where it is spending time.

Zi

unread,
Aug 11, 2017, 6:40:02 PM8/11/17
to Ceres Solver
Hi Sameer,

Thanks for your reply. After tuning the regularization parameter in the objective function, I found that the computation time is largely reduced. So I think that previously the large computation time is probably due to that the initial cost function value is far from the final converging value.


However, I encounter another problem, where the computation time is quite different when I apply two different implementations using Ceres solver. 

The problem is that given a template mesh (whose deformation can be controlled through around 70 pose parameters) and a point cloud, I want to solve for the optimal pose parameters, such that the deformed mesh match well with the point cloud.  I tried two implementations:

1) each data point in the point cloud is represented as one residual block
2) all the data points in the point cloud are represented as a single residual block

while in both cases, the pose parameters are represented as one parameter block. I found that the first case (representing each data point as one residual block) takes much longer to converge compared to the second case. The detailed summary report for the two cases are attached ('posefitting_multipleresidualblocks.png', 'posefitting_singleresidualblock.png'). I wonder what might be the cause for the differences in computation time? 


In addition, I further added upper & lower bound for pose optimization, please find the summary report attached ('posefitting_singleresidualblock_withconstraint.png'). From iteration 2 to 5, the cost function value does not change. I wonder if this is normal after adding the upper & lower bound. Thanks a lot!

Best,
posefitting_multipleresidualblocks.png
posefitting_singleresidualblock.png
posefitting_singleresidualblock_withconstraint.png

Sameer Agarwal

unread,
Aug 12, 2017, 1:37:03 AM8/12/17
to Ceres Solver
Zi,
Are you using a loss function on your residuals? 

If you have a single residual block and apply a loss function to it, it is very different than having separate residual blocks for each row and applying a loss function to it.

The reason is that the loss function applies to the squared norm of the residual of an entire residual block. 

so \rho(\sum_i r_i^2) is very different from \sum \rho(r_i^2)

Sameer


Zi

unread,
Aug 12, 2017, 8:43:39 PM8/12/17
to Ceres Solver
Hi Sameer,

Thanks for your reply. For loss function, I am using the default squared 2-norm.  For example, for multiple residual blocks, in each block, the residuals are computed as

residuals[0] = vx - sx;
residuals[1] = vy - sy;
residuals[2] = vz - sz;

where (vx, vy, vz), (sx, sy, sz) are the 3D coordinates of the mesh vertex and corresponding point in the point cloud.

For single block implementation, the residuals are computed as 

for(int i = 0; i < numpoints; i ++){
     residuals[3*i] = VX[i] - SX[i];
     residuals[3*i+1] = VY[i] - SY[i];
     residuals[3*i+2] = VZ[i] - SZ[i];
}

I wonder if the implementations look Ok, the optimization results seem plausible in both cases.. Thanks.


Best,
Zi

Sameer Agarwal

unread,
Aug 13, 2017, 12:16:57 AM8/13/17
to Ceres Solver
Zi,
If you are not using a loss function then there is likely some sort of difference in the two implementations.
Sameer

Zi

unread,
Aug 13, 2017, 12:50:02 AM8/13/17
to Ceres Solver
Hi Sameer,

Thanks for your reply. Can I also ask about the effect of adding lower/upper bounds for pose fitting? Attached are the summary reports of pose fitting without/with low & upper bounds. When the lower/upper bounds are applied, the optimization results in three unsuccessfully steps (iteration 3 - 5). I wonder if this is normal or does it mean the lower & upper bounds need to be relaxed. Thanks!

Best,
Zi
posefitting_singleresidualblock.png
posefitting_singleresidualblock_withconstraint.png

Sameer Agarwal

unread,
Aug 13, 2017, 1:06:35 AM8/13/17
to Ceres Solver
Zi,
This can totally happen, the step search algorithm now uses a trust region step followed by a line search, so no reason to expect that both constrained and unconstrained algorithms will behave the same.
Sameer


Reply all
Reply to author
Forward
0 new messages