pblab / rpysight Goto Github PK

Brightness levels of pixels are currently handled in a pretty simple way. We should either move these parameters to the configuration file, in hopes that one day we could modify configs and see the changes in real-time (#4) or do something smarter inside the code itself, which is probably the better solution in the long term.

The rendering status is in a type of a local maximum - it works fine and looks OKish, but in the long term it will simply not be sufficient.

The underlying library (kiss3d) is unmaintained, and some of the functionality it provides is broken. Moreover, it can only display a single window at any given moment, which means that we currently only render the merged channel.

It seems that the best way forward is to switch the underlying library, but the options are quite limited - there are currently no other high-level GPU-based rendering libs in Rust. Bevy and rg3d might go there one day, but currently they're not trying to. The only option is to go down the stack and re-implement a subset of kiss3d's functionality using the dependencies of kiss3d.

When having a config issue, like entering a wrong value for the line shift, the only solution is to restart rPySight. That's unfortunate and can perhaps be handled more elegantly.

Since this is a Rust project we're kinda neglecting the Python side of things, and specifically the import of the TimeTagger library, which is obviously crucial. Even if we release the crate in a binary form, the call_timetagger.py file will remain excluded. Its first import part might have to be modified on a per-user basis due to the PATH modification done in it, so it's still unclear how to distribute it.

Perhaps we can embed its code in the Rust source code and ask users to have the TimeTagger library in their path beforehand.

While the API reference is OKish, the library isn't published to crates.io so it's kind of inaccessible. Moreover there's currently no user guide, how-to articles and the basic tutorial only exists in the article form.

rPySight is definitely resource heavy, and it would be nice to know exactly which parts of it are causing the most issues for the computer.

It's also worth looking at changing a few Cargo.toml settings and see if it helps, and even try to use the TimeTagger's C++ API instead of the Pythonic one.

Currently rPySight doesn't know when to end reading from the data stream. During online acquisition it's less of a problem, but during replay the rendering window simply hangs instead of gracefully exiting.