Dnn deploy.prototxt incompatible with external protobuf lib

System information (version)
  • OpenCV => 4.3.0
  • Operating System / Platform => Windows 64 Bit
  • Compiler => Visual Studio 2019, Static
Detailed description

We built OpenCV 4.3.0 to add the static lib to our own externals. After some conflicts between the built in Protobuf version of openCV and our own official protobuf build we wanted to use the given option to build OpenCV lib using our own external protobuf lib.

Everything builds and links great but an error happens upon usage of the dnn caffe config file deploy.prototxt given in the openCV samples.

After a bit of inquiry we found out that the protobuf version included with openCV has been “hacked” to allow specific caffe config behaviour.

  • Why let the option to use a custom protobuf library if the one needed requires a custom modification ? What are we doing wrong here ?
  • Is there a specific version of deploy.prototxt that we should use in case of using the official protobuf library and still have dnn faceDetector work ?

We would like to keep running with our official protobuf library AND be able to use openCV dnn at the same time if possible.

Thanks for your help


please try with recent master (4.5.1-pre currently), so we’re all on the same stage

which is ?

again for which model, exactly (they’re all called like “deploy. prototxt”, so this alone isn’t all too helpful) ?

can you explain, why you need this ? if their “hacked” one works better for the opencv devs, why go against the stream ?

Will do right now [EDIT] As expected the problem is still here with 4.5.0 version

[libprotobuf ERROR [localpath]\google\protobuf\text_format.cc:288] Error parsing text-format opencv_caffe.NetParameter: 1788:9: Message type "opencv_caffe.DetectionOutputParameter" has no field named "clip".

As said in the post it is for the face_detector sample that comes with openCV

I need to have a more recent and official version of protobuf and since I use static libraries I get linking errors if openCV imports a different version. Their hacked version may let errors go through since it allows for unknown keywords in proto files. I find it quite odd of a practice to modify 3rd party libraries inside a library tbh…

Thanks for your answer, I’ll check with the latest version but I don’t expect much since I saw that protobuf 3rd party is still modified in the latest version.