Community
cancel
Showing results for 
Search instead for 
Did you mean: 
jsmit119
Beginner
105 Views

yolov3-tiny model vs IR

I use yolov3-tiny model(https://pjreddie.com/media/files/yolov3-tiny.weights) to  detect video。Then convert the official model to IR and use the IR model to detect video(ncs2)。

The detection effect of the two is different。

Yolov3-tiny has a good detection effect。

Can someone tell me why?

0 Kudos
6 Replies
Shubha_R_Intel
Employee
105 Views

Dear smith, joe,

Which two are you comparing ? OpenVino's sample which runs Yolov3-tiny and some other thing ? I'm not clear about which produces good results and which produces bad.

Thanks,

Shubha

 

jsmit119
Beginner
105 Views

Shubha R. (Intel) wrote:

Dear smith, joe,

Which two are you comparing ? OpenVino's sample which runs Yolov3-tiny and some other thing ? I'm not clear about which produces good results and which produces bad.

Thanks,

Shubha

 

I use the [object_detection_demo_yolov3_async] in the OpenVino example to detect the video (ncs2)

I use the official darknet program to detect the same video.

The two results are different.

Is there a loss of precision when I convert yolov3-tiny(.weights) to IR?

Shubha_R_Intel
Employee
105 Views

Dearest smith, joe

 Keep in mind that NCS2 supports FP16 so when you followed these instructions to convert a yolov3-tiny model for use on NCS2, you likely added  a --data_type FP16 parameter to the mo_tf.py command. That said, yolov3-tiny works well on NCS2. You're likely running the official darknet program on GPU (probably Nvidia) or CPU correct ? So of course, they will be different in some ways. But the OpenVino NCS2 version should give good results. Does it not ? 

I see this line  inputs = tf.placeholder(tf.float32, [None, FLAGS.size, FLAGS.size, 3], "inputs") in the 'convert_weights_pb.py' file which comes from the darknet github. This script has to do with NCHW/NHWC back and forth conversion, so it's unrelated to precision.

So the difference you are seeing is likely related to the fact that the model went from FP32 to FP16 for use on NCS2 - but that said, the results should still be accurate. If the OpenVino results are inferior, please do report back on this forum and let us know.

Thanks,

Shubha

jsmit119
Beginner
105 Views

Shubha R. (Intel) wrote:

Dearest smith, joe

 Keep in mind that NCS2 supports FP16 so when you followed these instructions to convert a yolov3-tiny model for use on NCS2, you likely added  a --data_type FP16 parameter to the mo_tf.py command. That said, yolov3-tiny works well on NCS2. You're likely running the official darknet program on GPU (probably Nvidia) or CPU correct ? So of course, they will be different in some ways. But the OpenVino NCS2 version should give good results. Does it not ? 

I see this line  inputs = tf.placeholder(tf.float32, [None, FLAGS.size, FLAGS.size, 3], "inputs") in the 'convert_weights_pb.py' file which comes from the darknet github. This script has to do with NCHW/NHWC back and forth conversion, so it's unrelated to precision.

So the difference you are seeing is likely related to the fact that the model went from FP32 to FP16 for use on NCS2 - but that said, the results should still be accurate. If the OpenVino results are inferior, please do report back on this forum and let us know.

Thanks,

Shubha

Regarding the problems with FP32 and FP16, I tried to convert the model to FP32 and then use cpu (intel) for detection. But the result is still not as good as the result of using darknet directly.

jsmit119
Beginner
105 Views

Shubha R. (Intel) wrote:

Dearest smith, joe

 Keep in mind that NCS2 supports FP16 so when you followed these instructions to convert a yolov3-tiny model for use on NCS2, you likely added  a --data_type FP16 parameter to the mo_tf.py command. That said, yolov3-tiny works well on NCS2. You're likely running the official darknet program on GPU (probably Nvidia) or CPU correct ? So of course, they will be different in some ways. But the OpenVino NCS2 version should give good results. Does it not ? 

I see this line  inputs = tf.placeholder(tf.float32, [None, FLAGS.size, FLAGS.size, 3], "inputs") in the 'convert_weights_pb.py' file which comes from the darknet github. This script has to do with NCHW/NHWC back and forth conversion, so it's unrelated to precision.

So the difference you are seeing is likely related to the fact that the model went from FP32 to FP16 for use on NCS2 - but that said, the results should still be accurate. If the OpenVino results are inferior, please do report back on this forum and let us know.

Thanks,

Shubha

In the process of darknet(.weights) -> tensorflow(.pb) -> IR(.xml), the accuracy of darknet(.weights) -> tensorflow(.pb) is now different.

Is there any documentation or explanation explaining the loss of precision between the two frameworks?(darknet(.weights) -> tensorflow(.pb))

Shubha_R_Intel
Employee
105 Views

Dear smith, joe,

We don't have any documentation on the conversion process from FP32->FP16. But perhaps this previous forum post will help you. Of course there may be a loss of accuracy from FP32->FP16, but you should not notice the difference visually. That forum post discusses potential for overflow in FP16 and the salient answer in that post is this one below:

When MO (Model Optimizer) converts weights of a model from FP32 to FP16 it checks for maximum value overflow (in fact MO uses numpy function astype which performs the values conversion).

If the value overflow occurs then the following error is printed (however the IR is generated):

[ ERROR ]  83 elements of 189 were clipped to infinity while converting a blob for node [['conv2d_transpose']] to <class 'numpy.float16'>.

But the MO cannot guarantee that the overflow will not occur during inference. For example, you can create a network that will sum 2 values. Even though both of them are below float16 max value the sum of them will be more than the limit.

It is not possible to normalize weights values before converting because it will significantly decrease prediction results (or most probably completely break the topology) so there is no such feature in MO.

The recommendation to the customer would be to re-train the model with scaled input values to, for example, [0, 1] or [-1, 1] segment.

Hope this answers your question. Thanks for using OpenVino !

Shubha

 

Reply