Closed ThomasRochefortB closed 6 months ago
đ Hello there! We wanted to give you a friendly reminder that this issue has not had any recent activity and may be closed soon, but don't worry - you can always reopen it if needed. If you still have any questions or concerns, please feel free to let us know how we can help.
For additional resources and information, please see the links below:
Feel free to inform us of any other issues you discover or feature requests that come to mind in the future. Pull Requests (PRs) are also always welcomed!
Thank you for your contributions to YOLO đ and Vision AI â
@ThomasRochefortB hello! It's great to see you're diving deep into modifying the YOLOv8 architecture for your custom dataset that includes regression targets along with the traditional detection and segmentation tasks.
From what you've described, it seems like you have appropriately modified the dataloader and the ExtendedSegment head to accommodate your additional regression outputs. As for implementing the custom regression loss function alongside the existing loss components, this process can indeed be nuanced.
The approach you've chosen for computing the mean squared error (MSE) loss on the regression predictions is conceptually in line with the typical process. Masking with fg_mask
to account for only the foreground objects is a valid way to restrict the regression loss to the relevant predictions.
However, there are a few things to consider that might affect your performance:
Masking Strategy: Your masking and computation of loss seem correct, but it's essential to cross-verify the outputs after masking and before loss computation to ensure only foreground bounding boxes contribute to the loss.
Balancing Losses: When introducing a new loss component to a multi-task network like YOLOv8, it might require tuning the relative weighting of this new regression loss compared to the existing loss components. Too much weight on the regression loss could distort the learning of other tasks.
Normalization: Your normalization choice of dividing by the number of positive samples is reasonable, but again this may need tuning. You could consider other normalization strategies based on batch size or the sum of weights for the loss.
Hyperparameters: Since you're adding a new head, you may need to adjust learning rates or other hyperparameters, as the new task could affect the convergence balance with other tasks.
Post-processing: Ensure that the regression targets are correctly post-processed after prediction to match the ground truth format. Sometimes a mismatch here can lead to poor performance even if the network is predicting accurately.
Quality of Regression Targets: Check the quality and distribution of your regression targets. Make sure they are being scaled or normalized in a way that is conducive to learning and that they indeed correlate well with the object instances.
Debugging Strategy: During debugging, consider simplifying the problem. For example, train only the regression head with a fixed detection model to make sure the head learns correctly, then integrate back into the full model.
As always, it's also recommended to carefully inspect the shapes and values of the tensors at different points in your pipeline to confirm that your additions work as intended during both the forward and backward passes.
Since ultimately each task's complexity can affect learning, a blend of model inspection, empirical testing, and, if needed, loss adjustment will be crucial to attaining good performance. Patience and iteration over these steps will be your ally here.
Please continue exploring and refining your approach, and if you have further questions or updates, we're here to assist. Keep up the excellent work, and we're looking forward to seeing your custom regression head fully integrated and performing well!
@glenn-jocher , thank you for the comprehensive answer, would the project be interested in a regression head PR ? I got everything working for my use case, was wondering if it could be useful for the overall project. Not sure if there is a general benchmark in computer vision that would require an additional regression head.
@ThomasRochefortB, I'm delighted to hear that you've got everything to work for your use case! đ
Regarding your question about contributing a regression head PR to the project, it's always a pleasure to see contributions that extend the functionality of YOLOv8. Such features could indeed be beneficial for a range of applications where predictions beyond bounding boxes and classes are required, like predicting additional attributes or continuous variables associated with detected objects.
Regarding benchmarks, while there isn't a universal computer vision benchmark requiring a regression head, there are various domain-specific tasks where this would be valuable. For example, in autonomous vehicle perception, predicting the distance or speed of detected vehicles could be useful, or in agricultural applications, predicting the ripeness or size of detected fruits.
Before preparing a PR, there are a few considerations to keep in mind:
Generic Implementation: Ensure that the regression head is implemented in a generic way that can be easily adopted or modified for various use cases.
Documentation: Providing thorough documentation and usage examples would be essential for ensuring clarity on how to apply the regression head for various tasks.
Modifications: It's crucial to ensure that the additional code integrates seamlessly with the current architecture without affecting the primary functionalities when the regression head is not used.
Testing: Adequate testing is necessary to confirm that your extension operates as intended and does not introduce any issues.
If you've considered these points and have a regression head that you believe could be broadly useful and well-integrated within YOLOv8, we would indeed consider reviewing a pull request.
Please make sure any contribution aligns with the project's design principles and coding standards. You can start by opening an issue or discussion on the repo to describe your proposed feature and its potential applications. That's the best place to begin a conversation on whether and how to integrate such a feature.
We appreciate your enthusiasm and willingness to contribute. It's the community's collective effort that keeps pushing the boundaries of what's possible in this fast-moving field of computer vision! đ
@glenn-jocher Cool! Would love to do this. There seems to be some CV benchmark that we could use to validate the implementation. See here the 2012 Object Detection and Orientation Estimation on the KITTI Dataset: https://www.cvlibs.net/datasets/kitti/eval_object.php?obj_benchmark=2d. I will be closing this issue and opening a new one with the label "enhancement".
@ThomasRochefortB, that sounds like a wonderful plan! The KITTI benchmark is a well-regarded dataset and challenge in the field of computer vision, particularly for tasks that involve object detection with additional parameters like orientation, which is a good fit for your regression head capabilities. Applying and validating new features on such widely recognized benchmarks is a strong way to demonstrate the utility and robustness of the enhancement.
Creating an "enhancement" issue to discuss this further with the community and maintainers is the appropriate next step. It allows for a more focused discussion on the feature, provides an opportunity for feedback, and helps set expectations for the contribution process.
Thank you for proactively identifying a valuable extension to YOLOv8 and for preparing to share it with the community. Your initiative reflects the spirit of open-source collaboration, and we are looking forward to seeing your proposal in detail. Feel free to reference any pilot results, design decisions, and potential integration approaches you have in mind when opening the new issue. This will greatly help others understand your vision and provide constructive feedback.
If you have any questions or need guidance as you prepare your contribution, the community is here to support you. Good luck with your enhancement proposal, and once again, we appreciate your engagement and efforts! đđ¤
Very interested in this as well. @ThomasRochefortB could you point to your branch where you got this working? I'm very interested to take a look!
@rob-rapid-robotics will do in the next week!
@ThomasRochefortB Was curious if you had a chance to get to this, WIP is fine just curious what you found worked! :)
@rob-rapid-robotics here is my current very coarse WIP branch in my forked repo: https://github.com/ThomasRochefortB/ultralytics-custom/tree/reghead
I am working on a real pull-request for the official ultralytics repo. I just need to find a good benchmark dataset combining segmentation, detection and "per-instance regression" to validate the implementation. I find the usecase to be very niche and have not found good decent benchmarks as of yet.
@ThomasRochefortB-robotics, I appreciate your interest! You can take a look at the work-in-progress on my forked repository's reghead
branch. Keep in mind it's still quite rough around the edges.
I'm in the process of preparing a more polished pull request for the official Ultralytics repository. The challenge right now is identifying a suitable benchmark dataset that encompasses segmentation, detection, and per-instance regression to thoroughly validate the implementation. It's indeed a niche use case, and finding robust benchmarks has been tricky. If you have any suggestions or know of datasets that could serve this purpose, your input would be very welcome! đ ď¸đ
@ThomasRochefortB I'm interested in adding regression heads to YOLOv8, what you're doing seems cool. Looking at your fork I don't see documentation on the changes but could you just roughly point me towards the code sections to look at in order to test your repo? I'm guessing somewhere you modified the code that reads in labels since those now need regression values as well, so I'd need to find that in order to re-format the input data correctly.
đ Hello there! We wanted to give you a friendly reminder that this issue has not had any recent activity and may be closed soon, but don't worry - you can always reopen it if needed. If you still have any questions or concerns, please feel free to let us know how we can help.
For additional resources and information, please see the links below:
Feel free to inform us of any other issues you discover or feature requests that come to mind in the future. Pull Requests (PRs) are also always welcomed!
Thank you for your contributions to YOLO đ and Vision AI â
Search before asking
Question
Hello! I am working on implementing an additional "regression head" to the YOLOv8 segmentation model because I am dealing with a custom dataset which has 6 variables I want to predict in addition to the bbox, class and masks.
I have managed to modify the dataloader and the model head successfully. Here is my ExtendedSegment head:
I now have an extra prediction tensors which is of shape (BS, 6, 8400). My question is about the implementation of the loss function for this extra prediction output. I want to use MSE but I find it tricky to know if my implementation is correct. So here is what I did:
Then, in loss.py, I can also use the fg_mask to mask out the predicted regression variables:
The code runs allright and the loss decreases but I get horrible regression performance and was wondering if my loss calculation process might be the issue. Am I doing this correctly with dealing with all the 8400 predicted object instances?
Thanks for your time!
Additional
No response