Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenCV tracking example needs a frame limit #1930

Closed
teh-cmc opened this issue Apr 19, 2023 · 3 comments · Fixed by #3835
Closed

OpenCV tracking example needs a frame limit #1930

teh-cmc opened this issue Apr 19, 2023 · 3 comments · Fixed by #3835
Labels
🧑‍💻 dev experience developer experience (excluding CI) examples Issues relating to the Rerun examples

Comments

@teh-cmc
Copy link
Member

teh-cmc commented Apr 19, 2023

It runs for like two minutes otherwise, making end-to-end tests extremely painful.

Similar to opencv_canny, this should have an optional frame limit.

@teh-cmc teh-cmc added 🧑‍💻 dev experience developer experience (excluding CI) examples Issues relating to the Rerun examples labels Apr 19, 2023
This was referenced Apr 19, 2023
@javierttgg
Copy link

Hi, is there a way to only store the last frame?

Similar to what is achieved with OpenCV by calling cv2.imshow('name', image) multiple times.
This way memory requirements would be reduced since only the most recently processed image needs to be kept in memory.

I think this usage could be very common when visualizing a sequence of images where only the current image is important. However I understand this may not be a use case of the library since we would not be able to rerun the sequence.

I have a similar question for 3D scenes too. Since one of rerun's objectives is #1630, the previous behavior would not only fit imshow and plot but also draw_geometries from Open3D (its viewer only visualizes the current actors with their current transformations).

I feel that this question may fit this issue, but please let me know if that's not the case.

P.S. This is an amazing library, thanks a lot for open-sourcing it!

@Wumpf
Copy link
Member

Wumpf commented Apr 22, 2023

@javierttgg As you inferred correctly, one of the central ideas of Rerun is to store data as you go and don't throw away earlier results. But that said we have a mechanism to reduce the memory used and throw away previous images/logs/etc, see https://www.rerun.io/docs/howto/limit-ram
What we're missing so far there is good defaults, exposition in the api and an easy way to discard "anything older than x".
In my experience the problem isn't as bad for 3d scenes - meshes are relatively lightweight in textures rarely change. Ofc, a large difference is that with Rerun you wouldn't continously call a draw method, but instead re-actively log data if there's something new & interesting.

I feel that this question may fit this issue, but please let me know if that's not the case.

It's very related, but not entirely 😄. The issue is more that we (miss-)use our examples right now a lot for testing and then when running all examples at once and doing so is a bit too lengthy for some, so it would be nice to a have a parameter there to not run through the whole video stream.
But still thank you for posting, any feedback no matter where is very welcome. This confirms that we still need to improve this area quite a bit and to so soon!

This is an amazing library, thanks a lot for open-sourcing it!

Thank you <3

@javierttgg
Copy link

@Wumpf thanks a lot for the thorough response. It is great to know that you have those features in mind!
I see now that my question doesn't fit well here, my apologies for adding noise 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🧑‍💻 dev experience developer experience (excluding CI) examples Issues relating to the Rerun examples
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants