So, you look for any real input layer and check if we created internal layer *Int8? I mean, someone could rename the layer or add a new one that doesn't follow that convention. Maybe we're better off with layerParams.set("depth", CV_8S) in each layer, or we could create a set of all integer layers. I think this should be discussed further with the rest of the team.

Thanks for your code review. OpenCV DNN needs to allocate output blob according to depth type (for example the depth of CV_8S will be allocated as int8 Mat.)

someone could rename the layer or add a new one that doesn't follow that convention.

It is possible. I agree with create a set of all integer layers. I think a better way is for us to have both Int8 name endings and keep sets. The set only stores some special layers that do not follow the rules like Quantize. For other layer type ending with Int8, we can keep the current implementation.

I'm not sure relying on internal names is a good idea. Let's discuss this on Friday, maybe someone will come up with a better solution.

Hi @rogday, please take a look. I have refactored the code.

So if we insert unsupported at the moment layer(Gather, for example) after integer node, it will set the depth to CV_8S and corrupt the memory at runtime? (reading int8 as float in this case).

What if we have a set of ONNX layers instead? e.g. in this set we would put QuantizeLinear, DequantizeLinear, QLinearConv, Transpose, Reshape, MaxPool, etc.
And check that if we have integer inputs, current layer should be in this set, otherwise we throw an error, what do you think?

So if we insert unsupported at the moment layer(Gather, for example) after integer node, it will set the depth to CV_8S and corrupt the memory at runtime? (reading int8 as float in this case).

Yes, if we do this, it will corrupt. But this should not happen, Gather-like layer should output the same format as the input. So, if a Gather layer gets int8 input, it should be GatherInt8. And if the type of GatherInt8 layer is Gather, we can add the Gather to the list.

What if we have a set of ONNX layers instead? e.g. in this set we would put QuantizeLinear, DequantizeLinear, QLinearConv, Transpose, Reshape, MaxPool, etc.
And check that if we have integer inputs, the current layer should be in this set, otherwise we throw an error, what do you think?

I also considered a list of ONNX operators. Functionally, there is no difference between the two lists in essence, one is the original version of ONNX and the other is the mapped version of OpenCV.
Considering the future maintainability, indeed using the original version of ONNX operator names is better.