-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Improve example ssd #4225
Comments
Just to confirm: do you mean it converges on the nnvm branch? Glad to know that you find mx.image useful. I'm planing to write some tutorials on that. Are you interested in jumping in? |
Yes, I mean nnvm branch. And I'm absolutely very interested in the tutorial, @piiswrong. |
more suggestions:
|
@howard0su Looks good, I will consider them carefully, especially 4 is the one I'm thinking about. Detection problems should reuse the same basics, and it could possibly benefit all existing/future projects. |
@zhreshold Can u propose a design? I can afford some time to help as well. |
I think mx.image.ImageIter could be a very good starting point to unify the interface of DataIter for object detection problem.
Just wondering if you guys ever had plans or ideas like this? @piiswrong @sxjscience @precedenceguo |
|
Data augmentations, are u proposing current spatial transform iterators supporting both "label" data as a vector of bounding box? another possible solution is exposing transform information through another output variable. and build iterator to consume those variables to transform bounding box. |
The results we have now:
The problem:
From weiliu-ssd we can learn:
|
Adding a deconvolutional augmentation to the current SSD would help as well: Achieves 80.1 mAP on VOC 2007 test and 33.2 mAP on COCO without sacrificing too much in terms of speed. Simple modification of existing feature extractor and additions of deconvolutional network operations at the end of the architecture should improve the SSD. |
I'm testing a new iterator to allow extensive data augmentation with better speed/api, after that I will try to write multiple symbols to match many variations, including this one. |
Can we try to unify the data pipeline for faster rnn and ssd?
…On Thu, Feb 2, 2017 at 8:13 AM, Joshua Z. Zhang ***@***.***> wrote:
I'm testing a new iterator to allow extensive data augmentation with
better speed/api, after that I will try to write multiple symbols to match
many variations, including this one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4225 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAiudObtWlQ90_Gj6_psTbdJagCfabrCks5rYgC-gaJpZM4LMDE1>
.
|
@piiswrong Can you have a look at this: https://github.com/zhreshold/mxnet/blob/ssd2/python/mxnet/image.py, though it's not fully finished. |
If I read this correctly, line 518 adds support for variable-length label list. That's awesome! |
@piiswrong
So, brightness+contrast+saturation+pca_noise augmenter could impact the performance a lot, even greater than random cropping and padding(for detection), which is a surprise to me. |
did you try increasing num cpu workers?
Joshua Z. Zhang <notifications@github.com>于2017年2月6日 周一下午1:45写道:
… @piiswrong <https://github.com/piiswrong>
I now still have concerns about the performance of augmenters in python
end. Here's some tests with ssd example on single gpu(titan x) with a
relatively weak cpu(e5 4c4t 2.8g):
cast mean bright contrast saturation pca_noise mirror rand_crop rand_pad
sample/s
✓ x x x x x x x x 31.6
✓ ✓ x x x x x x x 31.2
✓ ✓ ✓ x x x x x x 30.34
✓ ✓ x ✓ x x x x x 28.3
✓ ✓ x x ✓ x x x x 29.02
✓ ✓ x x x ✓ x x x 29.93
✓ ✓ ✓ ✓ ✓ ✓ x x x 20.65
✓ ✓ x x x x ✓ x x 30.6
✓ ✓ x x x x x ✓ x 30.56
✓ ✓ x x x x x x ✓ 30.54
✓ ✓ x x x x ✓ ✓ ✓ 26.41
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 16.9
So, brightness+contrast+saturation+pca_noise augmenter could impact the
performance a lot, even greater than random cropping and padding(for
detection), which is a surprise to me.
I also tried threading and it provides no gain, possibly due to GIL.
Any suggestion?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4225 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAiudEufKaotC9cbQJi1NjPQflPx2JS7ks5rZ5SGgaJpZM4LMDE1>
.
|
Well, forgot to do so 😓. Instant climb from 16 sample/s to 29.8 sample/s. Thanks |
Might take some work, but I'd also look into using multiprocessing. I have found GIL to be a big pain in the past. |
@andreaolgiati I was think about multiprocessing as well. However, if pushing time consuming work into mxnet engine works well, there's no reason to do so. |
Up to now, there are several issues with example ssd, I'm posting here to track the progress in improving this example in nnvm branch.
Make sure the current example does converge. This is confirmed @piiswrong
Add test_score.py to allow automatic check for future commits
Write a new lr_scheduler because initial gradients are not stable, since the current model vgg16 has no batchNorm layer
Replace data loading/augmentation functions with mx.image, after some experiments, I found this is more important than packing images into sequential file, this will make training faster with many gpus
Support rec files as input
Make caffemodel converter available
Any suggestion is very welcome. I will keep this updated.
The text was updated successfully, but these errors were encountered: