Question/Issue: I am training FOMO models and converting them to .Onnx file format with the help of this repo. However I run into this error:
ERROR: The name 'serving_default_x:0:0' looks a like a Tensor name, but is not a valid one. Tensor names must be of the form "<op_name>:<output_index>".
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 3983, in _as_graph_element_locked
op_name, out_n = name.split(":")
ValueError: too many values to unpack (expected 2)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/tflite2tensorflow", line 5976, in main
inputs= {re.sub(':0*', '', t): graph.get_tensor_by_name(t) for t in input_node_names},
File "/usr/local/bin/tflite2tensorflow", line 5976, in <dictcomp>
inputs= {re.sub(':0*', '', t): graph.get_tensor_by_name(t) for t in input_node_names},
File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 4128, in get_tensor_by_name
return self.as_graph_element(name, allow_tensor=True, allow_operation=False)
File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 3952, in as_graph_element
return self._as_graph_element_locked(obj, allow_tensor, allow_operation)
File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 3986, in _as_graph_element_locked
raise ValueError("The name %s looks a like a Tensor name, but is "
ValueError: The name 'serving_default_x:0:0' looks a like a Tensor name, but is not a valid one. Tensor names must be of the form "<op_name>:<output_index>".
However, when converting a Mobilenet model, the conversion completes successfully, but the model is extremely inaccurate. Any idea why this might be happening?
These are the exact instructions we’ve followed while converting Mobilenet to Onnx, however after conversion there are erroneous detections which are completely random on the frame. I suspect there’s some conversion loss going on but not sure what. We want to deploy this on a device which only accepts models in the form of (.blob) which can easily be converted from an .onnx format but converting to .onnx from .tflite leads to conversion loss. Is there any way we can natively obtain onnx from the dashboard or if onnx conversion could be enabled on the projects given above?
import argparse
import tensorflow as tf
import sys, subprocess
#import tf2onnx
parser = argparse.ArgumentParser(description='TFLite to ONNX')
parser.add_argument('--tflite-file', type=str, required=True)
parser.add_argument('--out-file', type=str, required=True)
args = parser.parse_args()
### TF Lite
# Load TFLite model and get input/output details
interpreter = tf.lite.Interpreter(model_path=args.tflite_file)
interpreter.allocate_tensors()
input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()
# Get input and output names
input_name = input_details[0]['name']
output_name = output_details[0]['name']
# Note: the inputs (and outputs) formats of the TFLite model are preserved in ONNX model.
# For example TFlite is NHWC and ONNX will also be in NHWC.
# If you want the ONNX input (and/or output) to be in NCHW
# pass the `--inputs-as-nchw`, `--outputs-as-nchw` parameters, respectively.
# e.g. --inputs-as-nchw input_name
# convert to ONNX
print ('Creating ONNX model...')
CMD = "python3 -u -m tf2onnx.convert --verbose --tflite {0} --opset {1} --inputs {2} --outputs {3} --output {4}".format(args.tflite_file, 12, input_name, output_name, args.out_file)
subprocess.run(CMD, shell=True, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
Hi @rjames, thanks for the reply! My teammate @dhruvsheth tried out your solution and it works well! However we want to deploy the model on an Oak-D and therefore we have to convert it to a .blob file format. We are achieving it through this service: http://blobconverter.luxonis.com.
However, when we test the model on the Oak-D, we get a lot of false positives. Any idea what might be happening?
Additionally, the false positives isn’t because of the dataset since FOMO or for that matter, Mobilenet works fine before conversion. After conversion, it starts to generate random false positives with bounding box height and width close to 0.
Try removing the --inputs-as-nchw parameter. This adds a transpose to the input layer and may be cause an issue if your input image is fed to the NN in NHWC format.