midjji

HRT does not help with scarring or issues caused by scarring. Lots of other things sure, but not scarring, which is what the article claims is the problem.

Its mostly a question of pr I think. More highly trained troops are less likely to die or mess up, and that is bad pr. So we train them more, but if that training also causes deaths, which becomes bad pr, we will train them less. Younger less trained soldiers are cheaper too, so I think the tradeoff will favor less training as soon as this becomes common knowledge anyways.

The only usable EMPs we have are nuclear weapons. So if you are willing to use one, then just detonate it a bit closer to the surface and it will work just as well against everything we have.

You say that suicide hotlines are more for the friends of people at risk, than the people at risk, as if it is a bad thing. We as a society generally dont know how to help people who consider suicide for its myriad of causes. We do know how to help their friends though, and pretending that there is help to be had is a big part of it.

A .45 gunshot feels like a sound, and with hearing protections at a few meters you hear it but cant feel it in the slightest. You feel it in your hand but not further. Artillery is more similar to how it feels standing next to gigantic speakers at a concert, even with hearing protections you feel it throughout your entire body, except sharper.

My bet is on a high threshold. There is no evidence for this at all in small arms enthusiasts.

If this is accurate there is likely very little to be done, and the solution will likely be to have less training and retire a decade sooner.

If I understood it right, its firing artillery, not rifles. Even then I doubt cavitation, but not shock echos at density borders tearing he tissues at the border.

The bash code which creates the c file which gets the list of null terminated files in a directory and compiles it, and runs it, is easier to write and understand. Bash is a lousy language to do anything in, python is almost always available, and if not, then CC is.

Yes. The higher derivates are useful in many cases, both as sought properties and observations. The invariances implied by relativity,(the trivial notion that the universe behaves the same regardless of where you select the center), mean that most laws are defined on the second derivative. Taylor approximations are useful to approximate something locally, but properties of the system over wider regions generally need to account for the higher derivatives. You can see this in e.g. simulating a system over time requires that the derivatives at the borders of the valid taylor approximation region to be included as diracs.

Or in other words, you can approximate exp(x) as a set of first order taylor approximations that each covers a small window to arbitrary precision, but the combination of them is still has well defined higher derivatives that are not 0.

Why bother with giving words for something which is longer than their mathemathical definition? The word can be unknown, but if the function is unknown the word is useless?

But all of them are based on courses that define nth derivative, and the notion of continuous vs non continuous functions. What is the value of giving them names instead of just using nth derivative?

What value is gained from using these terms over just saying nth derivative?

Will do

It would be amazing. Willing test subjects and the competitions to actually tell if we are making improvements.

Its just for fun.

This is correct. They were calibrated in advance.

Very few know the old methods. Few were trained, and deep learning started working just 5 years after classics got good and easy enough that a few people could use it for a product. So there was never the needed wave of non deep learning based computer vision students, they all went to deep learning.

Many of the libraries are not well maintained. I needed a basic homography estimation recently and asked a minion to try opencv for it before anything more advanced. He got it working, but the best inlier ratio for every feature he tried with default parameters was 3%. The images were offset by 30 pixels left right, and less than a pixel in warp and taken with different exposure time. So he used sift...

He argued he got it working and that was as good as keypoint matching got... If I hadnt happened to be the guy who needed it one step up, it could have just propagated, someone adding a shitty ekf to make it smooth, then buried in layers of heuristics and api.

Fair enough, it is very hard to be worse than opencv in terms of user friendlyness, so even if it did nothing more than improve that, its better.

If you have say a 1Mpixel image which has been rectified, then a human will generally say that it looks correct if the calibration errors are less than 10 pixels. Perhaps as little as 5 if they know what they should look for and are careful. Most camera calibrations are this bad and no one notices. If showing a person the image rectified is the goal thats good enough. But, if you want to do post processing of any kind...

Sfm tests the calibration to the extreme and even single pixel calibration error will be highlighted as correlated reprojection error vector in most images. And that is assuming the bad calibration does not cause the system to fail outright. There is also the inbetween case where the system is only able to use small parts of the image.

The distortion field often visibly tells you if the estimation failed. It should be smooth, and monotonic, and you can draw it not just for where there are pixels but further and in higher resolution, and for regular lenses almost always highly symmetric. Looking at the distortion field you can see alot of problems that you could not otherwise. The most common problem is the monotonicity, since that constraint is very difficult to add to general optimizers. Since this means the distortion goes backwards, they are visible as sharp edges in the distortion field.

Well, its good that it works, but its intended for correcting for hardware defects, not hardware engineer defects.

Or you know, vignetting

I do not think there is an off the shelf solution aside from e.g. arkit.

In general a good starting point for such a problem would be to implement https://grail.cs.washington.edu/rome/ on your own.

Its not particularily hard, and there is no difference between reconstructing from uncalibrated cameras and reconstructing from many images from one camera with unknown calibration. Then you can check if the calibration is unchanged over time, and if it is, add that as a constraint. So far it will still take half an hour to run, but now you can add in tracking exploiting motion prediction and imu, which in turn will give you the real time speed.

Looking through the comments People are confusing the lens models, with the nl estimator used, with the framework for calibrating cameras. There is no such thing as the OPENCV lens model. There is such a thing as the brown lense model as implemented in opencv.

The lense model is the parametrized approximation of the lense function. Picking the right one matters for ideal accuracy.

The estimator takes observations which constrain the parameters of the lens function, and find the parameters.

The framework helps you create those observations.

Nonsense. Opencv has been used widely for outdoor localisation too, in particular since it is much easier to do outdoor than indoor.

Such algorithms always create a graph over the images, but if you mean the graphslam graph filter methods, those are substantially subpar compared to classic feature based methods as well as the more modern, dense and semidense methods.

For you to say that you would have needed the image res 2MPixel, but ignoring that, it should have been a paper I knew about if true. So I checked. mrcal is providing the same lens models as opencv, and it looks like its using opencv to do the estimate. For higher perf calibration checkout https://arxiv.org/abs/1912.02908

Also always do calibration in good light conditions.

The corner detection is bad. Not sure why. I also think its gotten worse since 3.5. I know the corner detection refinement is worse than the raw detections, so turn that shit off.

Yeah thats a common problem if the calibration failed. It could also be that you are not cropping to what is in front of the camera, but if its really weird, its most likely the former.

So the default, and probably most of the camera models in opencv requires a monotonic change lenses and bijective imaging. The former is common unless the lense has defects on the surface, and the latter is practically a physical constraint. The problem is that these constraints are difficult to add to the estimator, so they didnt. Meaning it will find a solution where they are not satisfied. If say the bijectiveness is not satisfied a bit outside the image, but stil valid accounting for infront and float accuracy, then that would absolutely account for the problem you describe. Is pretty obvious if you consider the function what the problem is, just hard to add the constraint in opencvs estimator.

The solution is 1, verify the result is satisfied after estimation, 2 make sure you make the parameters are as observable as possible during calibration. This means spread out in the image, evenly distributed, and all the way to the edges. Also make verify it has not rotated one or more of the detected chessboards upside down, or 90 deg sideways. Finally, because it becomes harder and harder to avoid this problem with more parameters, always start with 1, then try 2, then the two variations of 3, and so on. More parameters always fit better, so use an appropriate test.

Sounds like a paper, link?

Camera calibration is almost always underestimated and a source of both failure and algorithm degradation. Shit in, shit out. Keep the model simple, but actually understand it. Make sure its observable. Visualize and verify.