Add rv1126 yolov3 support to sdk

[AllentDan]

After #1203 and #1238

[AllentDan]

@lvhan028 @lzhangzz Any comments?

[lvhan028]

@lvhan028 @lzhangzz Any comments?

in test

[lvhan028]

I have to do serval modifications when converting yolov3 torch model to rknn-int8 model.

• Disable normalize in yolov3 model's config by changing std=[255.0, 255.0, 255.0] to std=[1.0, 1.0, 1.0]
• Enable do_quantization=True in rknn.py and set mean_value and std_value to [[0, 0, 0]] and [[255.0, 255.0, 255.0]] respectively
• uncomment the partition_config of yolov3&yolox in detection_rknn_static-320x320.py

I don't think users are willing to buy it.

Let's try to eliminate the manual part.

• Can we move the normalize config from torch model config to deploy config according to do_quantization?
• How about automatically choosing the proper partition config according to target_platform and torch model config?

[AllentDan]

I have to do serval modifications when converting yolov3 torch model to rknn-int8 model.

• Disable normalize in yolov3 model's config by changing std=[255.0, 255.0, 255.0] to std=[1.0, 1.0, 1.0]
• Enable do_quantization=True in rknn.py and set mean_value and std_value to [[0, 0, 0]] and [[255.0, 255.0, 255.0]] respectively
• uncomment the partition_config of yolov3&yolox in detection_rknn_static-320x320.py

I don't think users are willing to buy it.

Let's try to eliminate the manual part.

• Can we move the normalize config from torch model config to deploy config according to do_quantization?
• How about automatically choosing the proper partition config according to target_platform and torch model config?

Codes now automatically move the Normalization part for quantization to the rknn model.

Tried to make codes automatically tackle the partition part but failed. The expression was not elegant and it would destroy the rule built before.

[lvhan028]

How about deriving another task from class ObjectDetection for rknn?

[AllentDan]

How about deriving another task from class ObjectDetection for rknn?

Why? Actually, I also used other backends with partition configs, which is convenient for debugging. These codes are more related to partition settings than just the RKNN backend.

[lvhan028]

How about deriving another task from class ObjectDetection for rknn?

Why? Actually, I also used other backends with partition configs, which is convenient for debugging. These codes are more related to partition settings than just the RKNN backend.

I found the API of BaseTask.create_input is changed to the following:

    @abstractmethod
    def create_input(self,
                     imgs: Union[str, np.ndarray, Sequence],
                     input_shape: Optional[Sequence[int]] = None,
                     backend: Optional[Backend] = None,
                     **kwargs) -> Tuple[Dict, torch.Tensor]:

Make backend as an argument of create_input kinda odd.
So I propose to derive another task to reimplement create_input instead of changing the base class API.
But I realized this proposal requires a derived task in every codebase if deploying it to rknn, which is bad.

[AllentDan]

@grimoire Now, the process is moved to the base task. New arguments for create_input and process_model_cfg are avoided.