-
Notifications
You must be signed in to change notification settings - Fork 74
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
WIP: Huggingface Integration #228
Conversation
@ejolly: I sent this to you on slack as well, but thought I would put everything in the same place for you to play with. I finished the first version of the new FastDetector version of py-feat. It's pretty fast! even with the au outputs not being in pytorch. I've now run into a new problem that it would be helpful to have help reasoning through. The new FastDetector, cannot really accommodate batches unfortunately. Due to the way img2pose is written, it processes data as lists of tensors. This is most likely because each image can contain varying numbers of faces. To output a combined tensor of (batch, channel, height, width, n_faces), we would have to pad the n_faces dimension based on the image that has the maximum number of faces and then store a mask to work with the whole thing. That seems to be not a very good idea, which is why I'm guessing the authors opted for the list of tensors. This isn't really a big deal as I can modify everything to work on lists now, but there will be some overhead and I have no idea what the torch/gpu speedup will be once I'm done. Just wanted to get your thoughts on this problem. Essentially, there is a reason why TK/Jin went with list of lists approach. As each frame can potentially contain varying number of faces, it is easiest to just operate on a single image. However, they also then proceeded to loop over faces within an image, which i've addressed in the new version to operate on tensors. If I go with the currently easier option of just looping over each image within the detector class I have no idea if batching will ultimately speed up our computations. I think it helped even with the list of lists representation, but I can't remember by how much. I've just pushed my whole WIP in repository in case you want to play with it. I made you a I've updated a bunch of other functions in the repository for various things. One thing that I haven't fully solved is the MPS problem. I started working on it last night, but got stuck. I think it should be fixable, but I'm struggling to figure out precisely where the problem is. Haven't tried it on NVIDIA yet. Thought you might want to play with it and possible see if it runs as is in pyfeatlive. |
@ljchang Cloned this branch and downloaded the requirements but I can't get your new model class to initialize. Not sure if there's some additional setup steps you did that we need to add to code-base. I wrote a quick test file to try (pushed my changes so you should be able to):
Here's the error I get:
|
ok, this turned out to be a pretty annoying issue that has to do with security with skops persistence. Basically, they are trying to prevent any malicious file from being loaded and they changed how serialized files are loaded due to a reported security isse However, this makes it difficult to load model weights in other environments from how the original weights were created see this issue. I make a kludgy solution for now where I manually populate |
@ejolly: the landmark issue was just the result of the tensors reordering the coordinates. [x0,y0,x1,y1,...] -> [x0,x1,...,y0,y1,...]. I've also been looking into finding easy ways to speed things up. Tiny effects from using Would be good to talk over batching. I think I have an idea how to do it more quickly, but it's ugly. Want to see if this update fixes the landmarks for pyfeat-live now? |
@ljchang Almost done with this here are the change so far:
Here's what I have left:
Then the new release should be good to go and I'll hook it up to py-feat, and the experimental module can be used at any time by |
great! that all sounds good to me. I think we are also going to need to update our documentation for the very small api changes. I think it will be easy to port the new detector tests to MPDetector when we're ready, but for now it's probably not quite ready for that yet. Especially the gaze and head pose estimators. |
Hey guys. I have been working on running the new version of PyFeat, using the most up-to-date version of Detector on the huggingface branch. I'm facing the issue where, on longer videos, I seem to run out of RAM at the last step when the results are being stored to a pandas dataframe. I am running on a list of image paths generated from a long video (30 mins at 60fps 1080p). The process seems to run completely up until this point at which the kernel dies and the only logging info I get is The other issue I had to change was line 126 of the In the meantime I'm going to address the kernel death issue by saving to disk every so many frames, rather than at the end. This has worked for me in the past. Thanks for all the great work! |
Thanks @LandryBulls! I just added a new arg you can pass to We haven't stress tested a super huge job with that much parallelization, so it sounds like your system ran out of RAM right when it needed a lot of it: to combine all batches into a single dataframe and compute identities over it after it finished processing. Once I finish up some bug fixes and other stuff this will be in the new release! |
Status: Just gotta finish clean up docs and finalize renaming bug-fixes after going through them (2,3, and 4) |
This PR modifies all models to be compatible with weights stored in huggingface_hub.
pytorch models all use huggingface_hub tools
sklearn and xgboost models all use skops tools
Tasks