OpenVINO Model Server的服务化部署——step2(天空分割模型)
基于OpenVINO的“semantic-segmentation-adas”模型,能够较为精确的分割出天空;使用OpenCV的seamlessClone等函数,实现天空的无缝替换;基于Django实现网络化部署。三者结合,实现并部署“天空替换”模型。
目前服务已经上线:打开地址:http://81.68.242.86:8000/upload 就可以体验,手机端和PC端都可以。虽然界面比较简陋,速度也比较慢,但是基本可用。总的来说,openvino自带的这个模型本来是用于道路分割的,不是专用的,能够出一定效果,但是有些时候不精确;再加上后期处理,还有粗糙的地方。但本文最为重要的是证明工具链的可行,探索一条道路,这个是有价值的。
OpenVINO Model Server的服务化部署——step1(OpenVINO™ Model Server Quickstart)
https://www.cnblogs.com/jsxyhelu/p/13796161.html
OpenVINO Model Server的服务化部署——step2(天空分割模型)
https://www.cnblogs.com/jsxyhelu/p/13829051.html
OpenVINO Model Server的服务化部署——step3(django服务构建)
https://www.cnblogs.com/jsxyhelu/p/13878335.html
OpenVINO Model Server的服务化部署——step4(实现天空替换)
https://www.cnblogs.com/jsxyhelu/p/13894565.html
==========================================================================
本系列中关于OpenVINO Model Server的服务化研究,就是为了能够寻找到一种可行的天空分割的方法。由于使用传统方法,已经无法很好地解决这个复杂问题,所以转而研究AI的方法。而服务化部署就是为了最终能够被更方便地调用这里的AI技术。
![](https://img-blog.csdnimg.cn/img_convert/48132bd64b6ad010e7791456134485fd.png)
我们下载了bin+xml,需要 按照以下模式存放
models /
├── model1
│ ├── 1
│ │ ├── ir_model.bin
│ │ └── ir_model.xml
│ └── 2
│ ├── ir_model.bin
│ └── ir_model.xml
└── model2
└── 1
├── ir_model.bin
├── ir_model.xml
└── mapping_config.json
这里的models以及下面的级联文件夹,都是在本机创建好的。
![](https://img-blog.csdnimg.cn/img_convert/e93f4fa14a2c2192e1f6f34246818021.png)
openvino /model_server :latest 启动的docker镜像 --model_path 和前面的 -v要保持一致 --model_name openvino调用的model的名称
其它几个不是太重要, 也不容易写错。
sudo docker exec -it 775c7c9ee1e1 /bin /bash
wget https : / /download. 01.org /opencv / 2021 /openvinotoolkit / 2021. 1 /open_model_zoo /models_bin / 2 /semantic -segmentation -adas - 0001 /FP32 /semantic -segmentation -adas - 0001.xml
[root@VM - 0 - 13 -centos 1] # cd /models
[root@VM - 0 - 13 -centos models] # tree
.
├── model1
│ └── 1
│ ├── face -detection -retail - 0004.bin
│ └── face -detection -retail - 0004.xml
└── model2
└── 1
├── semantic -segmentation -adas - 0001.bin
└── semantic -segmentation -adas - 0001.xml 4 directories, 4 files
[root@VM - 0 - 13 -centos models] # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 27907ca99807 openvino /model_server :latest "/ovms/bin/ovms --mo…" 5 seconds ago Up 3 seconds 0. 0. 0. 0 : 9000 - > 9000 /tcp flamboyant_mahavira
Inputs
The blob with BGR image in format : [B, C = 3, H = 1024, W = 2048], where :
B - batch size,
C - number of channels
H - image height
W - image width
……
( 1, 3, 1024, 2048)
Traceback (most recent call last) :
File "sky_detection.py", line 79, in <module >
result = stub.Predict(request, 10. 0)
File "/usr/local/lib64/python3.6/site-packages/grpc/_channel.py", line 690, in __call__ return _end_unary_response_blocking(state, call, False, None)
File "/usr/local/lib64/python3.6/site-packages/grpc/_channel.py", line 592, in _end_unary_response_blocking
raise _Rendezvous(state, None, None, deadline)
grpc._channel._Rendezvous : <_Rendezvous of RPC that terminated with :
status = StatusCode.RESOURCE_EXHAUSTED
details = "Received message larger than max (8388653 vs. 4194304)"
debug_error_string = "{"created ":"@ 1602672141. 715481155 ","description " :"Received message larger than max (8388653 vs. 4194304) ","file ":"src /core /ext /filters /message_size /message_size_filter.cc ","file_line ":190,"grpc_status ":8}"
@jsxyhelu The limit on the server side is actually 1GB. Your logs indicate 4MB.
It seems to be client side restriction.
Could you try the following settings :
options = [('grpc.max_receive_message_length', 100 * 1024 * 1024),('grpc.max_send_message_length', 100 * 1024 * 1024)]
channel = grpc.insecure_channel(server_url, options = options)
[ 'sky9.jpg']
Start processing 1 iterations with batch size 1
Request shape ( 1, 3, 1024, 2048)
image in batch item 0 , output shape ( 1, 1024, 2048)
saving result to results / 1_0.jpg 1024 2048