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

[Question]: Transforms size keep growing. #363

Open
4 tasks done
naserpiltan opened this issue Jun 25, 2023 · 3 comments
Open
4 tasks done

[Question]: Transforms size keep growing. #363

naserpiltan opened this issue Jun 25, 2023 · 3 comments
Labels
BUG 🐛 Vidgear api's error, flaw or fault POSTPONED ⌛ This issue/PR is postponed for later due to some missing resources. PR WELCOMED 📬 Related Pull Requests are welcomed for this issue!

Comments

@naserpiltan
Copy link

Issue guidelines

Issue Checklist

  • I have searched open or closed issues for my problem and found nothing related or helpful.
  • I have read the Documentation and found nothing related to my problem.
  • I have gone through the Bonus Examples and FAQs and found nothing related or helpful.

Describe your Question

Hello and thank you for sharing your great work. I was testing the code provided in the video stabilization library and bumped into something weird at this line :

# save this transformation
self.__transforms.append([dx, dy, da])
# calculate path from cumulative transformations sum
I checked the size of the self.__transforms variable and noticed that it keeps increasing throughout the video. If you use a camera for live-streaming and let it run for a long time, it will consume and eventually exhaust the memory. I tried to fix it by changing it to a queue and removing the first item at the end of each frame, but it worsened the final result. I wanted to ask you if this was intentional or a bug.

Terminal log output(Optional)

No response

Python Code(Optional)

No response

VidGear Version

0.3.0

Python version

3.8.0

Operating System version

Windows

Any other Relevant Information?

No response

@naserpiltan naserpiltan added the QUESTION ❓ User asked about the working/usage of VidGear APIs. label Jun 25, 2023
@welcome
Copy link

welcome bot commented Jun 25, 2023

Thanks for opening this issue, a maintainer will get back to you shortly!

In the meantime:

  • Read our Issue Guidelines, and update your issue accordingly. Please note that your issue will be fixed much faster if you spend about half an hour preparing it, including the exact reproduction steps and a demo.
  • Go comprehensively through our dedicated FAQ & Troubleshooting section.
  • For any quick questions and typos, please refrain from opening an issue, as you can reach us on Gitter community channel.

@abhiTronix
Copy link
Owner

Hello and thank you for sharing your great work. I was testing the code provided in the video stabilization library and bumped into something weird at this line :

vidgear/vidgear/gears/stabilizer.py

Lines 283 to 286 in 3572ef3

save this transformation

self.__transforms.append([dx, dy, da])

calculate path from cumulative transformations sum

I checked the size of the self.__transforms variable and noticed that it keeps increasing throughout the video. If you use a camera for live-streaming and let it run for a long time, it will consume and eventually exhaust the memory. I tried to fix it by changing it to a queue and removing the first item at the end of each frame, but it worsened the final result. I wanted to ask you if this was intentional or a bug.

@naserpiltan Thanks for sharing this insight. Yeah, it was intentional. In stabilizer, Once we have estimated the motion(rigid (Euclidean) transformation), we decompose it into x and y translation and rotation (angle). We store these transformation values in an array so we can change them smoothly. Also, we find the trajectory of motion by cumulatively adding the differential motion estimated.

But I agree, storing all transformation throught is not necessary or logical but instead storing them w.r.t to our window size is the better way to handle them. So I'll see if it can be replaced with deque or something similar, and let you know.

@abhiTronix abhiTronix added BUG 🐛 Vidgear api's error, flaw or fault BUG CONFIRMED ✅ Bug is confirmed! WORK IN PROGRESS 🚧 currently been worked on. and removed QUESTION ❓ User asked about the working/usage of VidGear APIs. labels Jun 29, 2023
@abhiTronix abhiTronix self-assigned this Jun 29, 2023
@abhiTronix abhiTronix added this to the v0.3.1 milestone Jun 29, 2023
@abhiTronix abhiTronix moved this to In Progress in VidGear + Deffcode Jun 29, 2023
@abhiTronix abhiTronix moved this from In Progress to Todo in VidGear + Deffcode Jun 29, 2023
@abhiTronix abhiTronix removed this from the v0.3.1 milestone Jul 8, 2023
@abhiTronix abhiTronix removed the status in VidGear + Deffcode Jul 8, 2023
@abhiTronix abhiTronix added this to the v0.3.2 milestone Jul 22, 2023
@abhiTronix
Copy link
Owner

@naserpiltan There's no immediate solution for this issue as transformations cannot be simply deleted from queue, as we require cumulative sum of all transformations. I'll see this problem later.

@abhiTronix abhiTronix added POSTPONED ⌛ This issue/PR is postponed for later due to some missing resources. PR WELCOMED 📬 Related Pull Requests are welcomed for this issue! and removed BUG CONFIRMED ✅ Bug is confirmed! WORK IN PROGRESS 🚧 currently been worked on. labels Aug 28, 2023
@abhiTronix abhiTronix removed their assignment Aug 28, 2023
@abhiTronix abhiTronix removed this from the v0.3.2 milestone Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BUG 🐛 Vidgear api's error, flaw or fault POSTPONED ⌛ This issue/PR is postponed for later due to some missing resources. PR WELCOMED 📬 Related Pull Requests are welcomed for this issue!
Projects
None yet
Development

No branches or pull requests

2 participants