WFinfo VS Warframe-OCR

If you just want the Prime parts/relics management features, use WFInfo.

https://github.com/WFCD/WFinfo, but any third party software is at your own risk. WFinfo doesn't touch the game (which would be an instant permanent ban), it just takes a screenshot and then runs OCR on it.

I've been using WFInfo for years: https://wfinfo.warframestat.us/

I started to use https://github.com/WFCD/WFInfo , can mark items with a tick which is for built, will also show the reough value in plat and ducats of the item.

You can also use the WFInfo overlay to check plat prices easier while opening relics

Most of that functionality is already on the wiki for info on which parts come from which relics and in the WFInfo utility to tell you the plat prices on warframe.market, whether or not it's vaulted and how many ducats it's worth in real time as an overlay when you crack the relics.

Yes, you can link them statically. Here's a Python script I wrote to install and build a Python module in Rust. It will install the required development libraries on Linux and build a static build of tesseract on Windows (it also downloads the LLVM based clang compiler, I forgot why). Then it set up two environment variables VCPKG_ROOT to discover the tesseract library and RUSTFLAGS -Ctarget-feature=+crt-static (this forces the vpkg crate to link tesseract:x64-windows-static and not the dynamic version).

Tesseract is slow but not too slow. I wrote a multi-threaded wrapper around the Rust bindings und a Python wrapper around that. Granted it is not very polished and I apparently forgot to make the Rust repository public but it works. The previous version of the project for which I made this wrote the image to disk and called the tesseract binary which took half a minute for a few of images. Definitely not usable for real-time processing. Now it takes around 200-300 ms with 12 worker threads. I'm not sure if there is further potential to make it faster though.

I don't like maturin workflow either because it installs directly to the python environment. This is not very useful during development. I wrote a module import file which loads the python module from the shared library. You could easily invoke cargo before importing the module (remember to delete the previous shared library file) to have a fully automated development processes.