Mask_RCNN VS onnx

The most widely used algorithms for classical feature detection today are "whatever opencv implements"

In terms of tech that's advancing at the moment? https://co-tracker.github.io/ if you want to track individual points, https://github.com/matterport/Mask_RCNN and its descendents if you want to detect, say, the cover of a book.

Mask R-CNN

Click to Learn more...

- Mask RCNN https://github.com/matterport/Mask_RCNN (open source, so also not Palantir's)

pip install git+https://github.com/matterport/Mask_RCNN

It is important to realize that to do its masking procedures, Hent-AI uses the Mask RCNN (MRCNN) package from Matterport. The problem with this version of MRCNN is that it is not compatible with Tensorflow 2.X versions, essentially limiting Hent-AI compatibility to strict Tensorflow 1.X versions. Since Tensorflow 1.15 is the last of the Tensorflow 1.X versions and uses CUDA 10.0, which supports a maximum compute capability of 7.5, this means that the last NVIDIA GPU series that is compatible with the original Hent-AI implementation is the RTX 2000 series. This is, of course, not optimal since it means that RTX 3000 series and later GPUs cannot be used despite their significant computing power and high VRAM.

I read that it could bethe problem with scipy version (https://github.com/matterport/Mask_RCNN/issues/2122) so I downgraded it, I also tried to modify shift = np.array([0, 0, 1., 1.]) in utils.py but nothing helped.

I am assuming you did a pip install of this github repository, or did you run pip install mrcnn. The mrcnn package on pypi is just an example package and doesn't have any useful functionality. In addition, where did you get the code from that you are trying to run, from someone else or did you write it yourself? Reason I am asking is because the import error is to be expected since there indeed is no InferenceConfig class defined in mrcnn.visualize.

Hello AI learners, check out my own development of Mask-RCNN supporting Tensorflow2.7.0 and Keras2.8.0. This is an edit of MRCNN which supports Tensoflow1.0, only.

Once your model has been trained and validated using Anomalib, the next step is to prepare it for real-time implementation. This is where ONNX (Open Neural Network Exchange) or OpenVINO (Open Visual Inference and Neural network Optimization) comes into play.

ONNX is an open format from the Linux Foundation to represent machine learning models. It is becoming extensively adopted by the Machine Learning community and is compatible with most of the machine learning frameworks like PyTorch, TensorFlow, etc. Converting a model between any of those formats and ONNX is really simple and can be done in most cases with a single command.

ONNX[0], model-as-protosbufs, continuing to gain adoption will hopefully solve this issue.

[0] https://github.com/onnx/onnx

Running inference for large models on CPU is not a new problem and fortunately there has been great development in many different optimization frameworks for speeding up matrix and tensor computations on CPU. We explored multiple optimization frameworks and methods to improve latency, namely TorchScript, BetterTransformer and ONNX.

ONNX is a format for representing machine learning models in a portable way. Additionally, ONNX models can be easily optimized and thus become smaller and faster.

I would say onnx.ai [0] provides more information about ONNX for those who aren’t working with ML/DL.

[0] https://onnx.ai

It's not clear why you thing this sub is appropriate for some third party system with a Python interface. Why don't you try their discussion group: https://github.com/onnx/onnx/discussions

This kind of indirection through standardisation is pretty common to make compatibility between different kinds of software components easier. Some other good examples are the LSP project from Microsoft and ONNX to represent machine learning models. The first provides a standard so that IDEs don't have to re-invent the weel for every programming language. The latter decouples training frameworks from inference frameworks. Going back to WSGI, you can find a pretty extensive rationale for the WSGI standard here if interested.