dnn: missed fusion opportunities by using case-sensitive string comparisions to identify layer types

[YashasSamaga]

System information (version)

• OpenCV => master (760e9e0)

Detailed description

[FORWARD] Convolution 557
[SKIPPED] BatchNorm 558
[FORWARD] Relu 559
[FORWARD] Convolution 560
[FORWARD] Convolution 561
[SKIPPED] BatchNorm 562
[FORWARD] Relu 563

code to obtain the above skipped/forward summary

`std::cout << (ld.skip ? "[SKIPPED]" : "[FORWARD]") << ' ' << ld.type << ' ' << ld.name << std::endl;`

in forwardLayer

Relu layers are not fused with convolution. It's because Relu is not the same as ReLU for a case-sensitive string comparison which is what fuseLayers uses to identify layers for fusion.

Steps to reproduce

ONNX model (taken from #16869)

Issue submission checklist

• I report the issue, it's not a question
• I checked the problem with documentation, FAQ, open issues,
  answers.opencv.org, Stack Overflow, etc and have not found solution
• I updated to latest OpenCV version and the issue is still there
• There is reproducer code and related data files: videos, images, onnx, etc

[dkurt]

That's interesting. But how layer "Relu" is initialized while only "ReLU" is supported? I though it should throw something like

opencv/modules/dnn/src/dnn.cpp

Line 539 in 78c5e41

CV_Error(Error::StsError, "Can't create layer \"" + name + "\" of type \"" + type + "\"");

source:

opencv/modules/dnn/src/init.cpp

Line 100 in 78c5e41

CV_DNN_REGISTER_LAYER_CLASS(ReLU, ReLULayer);

In example, for TensorFlow there is even remap for origin types:

opencv/modules/dnn/src/tensorflow/tf_importer.cpp

Lines 2166 to 2171 in ca23c0e

	std::string dnnType = type;
	if (type == "Abs") dnnType = "AbsVal";
	else if (type == "Tanh") dnnType = "TanH";
	else if (type == "Relu") dnnType = "ReLU";
	else if (type == "Relu6") dnnType = "ReLU6";
	else if (type == "Elu") dnnType = "ELU";

Can reproduce that layer types are weird:

[FORWARD] Convolution 553
[FORWARD] MVN 554/MVN
[SKIPPED] BatchNorm 554
[FORWARD] Relu 555
[FORWARD] Pooling 556
[FORWARD] Convolution 557
[SKIPPED] BatchNorm 558
[SKIPPED] Relu 559

(tested on CPU but it matches by dynamic_cast however for OpenCL/CUDA backends it's a problem. Thanks @YashasSamaga!).

[YashasSamaga]

I couldn't find ONNX importer code using ReLU anywhere (it uses ReLU6 and what not but just ReLU isn't there anywhere). This bug might be specific to the ONNX importer.

Here is my guess on how this bug might have happened.

You can find Relu when you open the ONNX model in a hex editor. So Relu as a string (probably as an op type) is present in the ONNX model binary.

The ONNX importer uses the type name from node_proto (which is probably directly read off the ONNX file which can be Relu):

opencv/modules/dnn/src/onnx/onnx_importer.cpp

Lines 323 to 324 in 760e9e0

	std::string layer_type = node_proto.op_type();
	layerParams.type = layer_type;

Layer factory uses toLowerCase on the type to find layers.

opencv/modules/dnn/src/dnn.cpp

Lines 4985 to 5003 in 760e9e0

	Ptr<Layer> LayerFactory::createLayerInstance(const String &type, LayerParams& params)
	{
	CV_TRACE_FUNCTION();
	CV_TRACE_ARG_VALUE(type, "type", type.c_str());
	cv::AutoLock lock(getLayerFactoryMutex());
	String type_ = toLowerCase(type);
	LayerFactory_Impl::const_iterator it = getLayerFactoryImpl().find(type_);
	if (it != getLayerFactoryImpl().end())
	{
	CV_Assert(!it->second.empty());
	return it->second.back()(params);
	}
	else
	{
	return Ptr<Layer>(); //NULL
	}
	}

So even irrespective of whether the type is ReLU or Relu or relu, a ReLU layer will be successfully created.

[dkurt]

Please take a look at #16878.