You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem with the current approach: we cannot unload the temporary files for gradio.File - therefore the disc space and RAM is allocated twice for no good reason.
Potential solutions
Gradio could recognize temp file paths and reuse them instead of creating a fresh one
Forward the upload / blob to the Image or Video component
Unload of components (not just hiding) and related temp files
A gradio.Media component
Additional context
FaceFusion stores the processed images and videos to an given path. Once done, we display this in the UI. From my observation this is causing a similar issue. A copy from the output_path is is stored within another temporary Gradio file.
The text was updated successfully, but these errors were encountered:
Hey! We've now made it possible for Gradio users to create their own custom components -- meaning that you can write some Python and JavaScript (Svelte), and publish it as a Gradio component. You can use it in your own Gradio apps, or share it so that anyone can use it in their Gradio apps. Here are some examples of custom Gradio components:
You can see the source code for those components by clicking the "Files" icon and then clicking "src". The complete source code for the backend and frontend is visible. In particular, its very fast if you want to build off an existing component. We've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help. Hopefully this will help address this issue.
Is your feature request related to a problem? Please describe.
In FaceFusion and some other roop forks, we have a target_path droparea that allows images and videos for later processing.
Bildschirmaufzeichnung.vom.05.10.2023.17.57.07.webm
At the moment this has been solved this way:
gradio.File
as an entry pointgradio.File
becomes invisiblegradio.Image
orgradio.Video
Source: https://github.com/facefusion/facefusion/blob/master/facefusion/uis/components/target.py#L16-L44
Describe the solution you'd like
The problem with the current approach: we cannot unload the temporary files for
gradio.File
- therefore the disc space and RAM is allocated twice for no good reason.Potential solutions
gradio.Media
componentAdditional context
FaceFusion stores the processed images and videos to an given path. Once done, we display this in the UI. From my observation this is causing a similar issue. A copy from the output_path is is stored within another temporary Gradio file.
The text was updated successfully, but these errors were encountered: