Is the parameter lamada_t in your implementation different from the one in the paper?

[LeeVinteuil]

I find that in your implementation parameter lamada_t is fixed.But in the papaer MeshFlow: Minimum Latency Online Video Stabilization, lamada_t is an adaptive parameter. Why?

[LeeVinteuil]

I have fixed it. Thank you for your implementation.

[Debiprasad-1]

x_paths = np.zeros((old_frame.shape[0]/PIXELS, old_frame.shape[1]/PIXELS, 1))

TypeError: 'float' object cannot be interpreted as an integer

i got error while running the code

[LeeVinteuil]

I change it to:
x_paths = np.zeros((int(old_frame.shape[0]/PIXELS), int(old_frame.shape[1]/PIXELS), 1))

[bob-blob]

I have fixed it. Thank you for your implementation.

Hello, @LeeVinteuil! Could you give me a hint, please, of how did you handle the lambda_t adaptive parameter?

I re-implemented this version of MeshFlow in C++ and tried to add adaptive parameter (it was stated in the paper that it could help with cropping and artifacts), but it is just not working, because translational element T is almost always negative, thus the lambda_t is equal to zero which cancels the stabilization.

The crude implementation of this looks like this:
During the motion propagation lambdas are calculated and stored in vector

Mat H = cv::findHomography(oldPoints, newPoints, cv::RANSAC);

// Find information for offline adaptive lambda
double translationalElement = sqrt(pow(H.at<double>(0, 2), 2) + pow(H.at<double>(1, 2), 2));
double l1 = -1.93 * translationalElement + 0.95;

Mat affinePart = H(cv::Range(0, 2), cv::Range(0, 2));
Mat eigenvalues;
cv::eigen(affinePart, eigenvalues);
double affineComponent = eigenvalues.at<double>(0) / eigenvalues.at<double>(1);
double l2 = 5.83 * affineComponent + 4.88;
lambdas.push_back(std::make_pair(l1, l2));

Then during optimization step they are used to compute adaptive weight

for (int i = 0; i < lambdas.size(); ++i) {
    lambda_t.at<double>(i) = (std::max(std::min(lambdas[i].first, lambdas[i].second), 0.)); 
}

I would be grateful if you could hint where I've made a possible mistake.

---

OR did you mean that you left the lambda_t parameter unchanged? (fixed) 😅

[LeeVinteuil]

I have fixed it. Thank you for your implementation.

Hello, @LeeVinteuil! Could you give me a hint, please, of how did you handle the lambda_t adaptive parameter?

I re-implemented this version of MeshFlow in C++ and tried to add adaptive parameter (it was stated in the paper that it could help with cropping and artifacts), but it is just not working, because translational element T is almost always negative, thus the lambda_t is equal to zero which cancels the stabilization.

The crude implementation of this looks like this:
During the motion propagation lambdas are calculated and stored in vector

Mat H = cv::findHomography(oldPoints, newPoints, cv::RANSAC);

// Find information for offline adaptive lambda
double translationalElement = sqrt(pow(H.at<double>(0, 2), 2) + pow(H.at<double>(1, 2), 2));
double l1 = -1.93 * translationalElement + 0.95;

Mat affinePart = H(cv::Range(0, 2), cv::Range(0, 2));
Mat eigenvalues;
cv::eigen(affinePart, eigenvalues);
double affineComponent = eigenvalues.at<double>(0) / eigenvalues.at<double>(1);
double l2 = 5.83 * affineComponent + 4.88;
lambdas.push_back(std::make_pair(l1, l2));

Then during optimization step they are used to compute adaptive weight

for (int i = 0; i < lambdas.size(); ++i) {
    lambda_t.at<double>(i) = (std::max(std::min(lambdas[i].first, lambdas[i].second), 0.)); 
}

I would be grateful if you could hint where I've made a possible mistake.

OR did you mean that you left the lambda_t parameter unchanged? (fixed)

borisqa00， it is said in the paper "Note that Ft is normalized by the image widthand height."
You can try
double translationalElement = sqrt(pow(H.at(0, 2)/img_width, 2) + pow(H.at(1, 2)/img_height, 2));

Besides,there seems to be a misprint in the paper:
double l2 = 5.83 * affineComponent - 4.88;