{ "id": 400103, "title": "pytorch to tf to tflite conversion tf.Range issue", "url": "/competitions/asl-signs/discussion/400103", "author_name": "", "post_date": "2023-04-06T21:22:42.731342400Z", "votes": 3, "comment_count": 4, "views": 0, "content": "

Error Message:

\n
Some ops are  supported by the native TFLite runtime, you can enable TF kernels fallback using TF Select. See instructions: https://www.tensorflow.org/lite/guide/ops_select \nTF Select ops: Range\nDetails:\n    tf.Range(tensor<i64>, tensor<i64>, tensor<i64>) -> (tensor<?xi64>) : {device = }\n
\n

'Normally' tflite conversion looks like supporting tf.range but this tf.Range with a capital 'R' is a questionmark.

\n

I have read the related thread. Seen solutions like: The onnx graph could be amended, or maybe explicitly stating the arguments of the functions in pytorch code could solve…not too easy, because this tf.Range could have been triggered by methods/functions wrapped in higher level methods/functions so might not be directly visible in pytorch code.
\nUsing select ops causes issues during submission, although it does the conversion..

\n

So I am stuck,
\nAny advice would be very welcome.

", "messages": [ { "id": "2212551", "postDate": "04/06/2023 21:22:42", "content": "

Error Message:

\n
Some ops are  supported by the native TFLite runtime, you can enable TF kernels fallback using TF Select. See instructions: https://www.tensorflow.org/lite/guide/ops_select \nTF Select ops: Range\nDetails:\n    tf.Range(tensor<i64>, tensor<i64>, tensor<i64>) -> (tensor<?xi64>) : {device = }\n
\n

'Normally' tflite conversion looks like supporting tf.range but this tf.Range with a capital 'R' is a questionmark.

\n

I have read the related thread. Seen solutions like: The onnx graph could be amended, or maybe explicitly stating the arguments of the functions in pytorch code could solve…not too easy, because this tf.Range could have been triggered by methods/functions wrapped in higher level methods/functions so might not be directly visible in pytorch code.
\nUsing select ops causes issues during submission, although it does the conversion..

\n

So I am stuck,
\nAny advice would be very welcome.

", "rawMarkdown": "Error Message:\n\n```python\nSome ops are not supported by the native TFLite runtime, you can enable TF kernels fallback using TF Select. See instructions: https://www.tensorflow.org/lite/guide/ops_select \nTF Select ops: Range\nDetails:\n\ttf.Range(tensor, tensor, tensor) -> (tensor) : {device = \"\"}\n```\n\n'Normally' tflite conversion looks like supporting tf.range but this tf.Range with a capital 'R' is a questionmark. \n\nI have read the related thread. Seen solutions like: The onnx graph could be amended, or maybe explicitly stating the arguments of the functions in pytorch code could solve...not too easy, because this tf.Range could have been triggered by methods/functions wrapped in higher level methods/functions so might not be directly visible in pytorch code.\nUsing select ops causes issues during submission, although it does the conversion..\n\nSo I am stuck, \nAny advice would be very welcome.", "votes": null }, { "id": "2213947", "postDate": "04/08/2023 01:43:30", "content": "

Had this issue at one point, here are a few torch functions that I had to get rid of :

\n
    \n
  • torch.arange
    • \n
  • torch.linspace
    • \n
  • torch.gather
    • \n
\n

(I'm assuming you're doing torch -> onnx -> tf -> tflite)

", "rawMarkdown": "Had this issue at one point, here are a few torch functions that I had to get rid of :\n- `torch.arange`\n- `torch.linspace`\n- `torch.gather`\n\n(I'm assuming you're doing torch -> onnx -> tf -> tflite)", "votes": null }, { "id": "2213970", "postDate": "04/08/2023 02:43:23", "content": "

Thank You.
\nYes currently I am doing torch onnx tf tflite pipeline. It is the final conversion to tflite that is hard to guess. I mean, I was using torch.arange and conversion was successful, than I connected another torch.arange to the graph, suddenly I got those tf.Range issues. So I guess it is not only about what you use, but also about how you use it, which affects how onnx decides to make the graph.
\nI have seen solutions which go into modifying the onnx graph, probably not very convenient at this point:-)

", "rawMarkdown": "Thank You.\nYes currently I am doing torch onnx tf tflite pipeline. It is the final conversion to tflite that is hard to guess. I mean, I was using torch.arange and conversion was successful, than I connected another torch.arange to the graph, suddenly I got those tf.Range issues. So I guess it is not only about what you use, but also about how you use it, which affects how onnx decides to make the graph.\nI have seen solutions which go into modifying the onnx graph, probably not very convenient at this point:-)", "votes": null }, { "id": "2217795", "postDate": "04/11/2023 07:06:28", "content": "

I think I was able to fix it by replacing torch.arange with torch.from_numpy(np.arange)

", "rawMarkdown": "I think I was able to fix it by replacing ```torch.arange``` with ```torch.from_numpy(np.arange)```", "votes": null }, { "id": "2218500", "postDate": "04/11/2023 18:44:12", "content": "

I tried many different things. It turns out doing a complex preprocessing in pytorch layers and then converting it to tf to tflite, can become very unstable. For my code, I solved it without replacing 'torch.arange'. I had to deal with the arguments on how they evolved until the torch.arange line and made some changes here and there and finally it worked. Now I have other problems but I am progressing :-)

", "rawMarkdown": "I tried many different things. It turns out doing a complex preprocessing in pytorch layers and then converting it to tf to tflite, can become very unstable. For my code, I solved it without replacing 'torch.arange'. I had to deal with the arguments on how they evolved until the torch.arange line and made some changes here and there and finally it worked. Now I have other problems but I am progressing :-)", "votes": null } ], "comments": [ { "id": 2213947, "author_name": "theoviel", "author_url": "", "post_date": "04/08/2023 01:43:30", "content": "

Had this issue at one point, here are a few torch functions that I had to get rid of :

\n
    \n
  • torch.arange
    • \n
  • torch.linspace
    • \n
  • torch.gather
    • \n
\n

(I'm assuming you're doing torch -> onnx -> tf -> tflite)

", "votes": null, "replies": [ { "id": 2213970, "author_name": "abdulkadirguner", "author_url": "", "post_date": "04/08/2023 02:43:23", "content": "

Thank You.
\nYes currently I am doing torch onnx tf tflite pipeline. It is the final conversion to tflite that is hard to guess. I mean, I was using torch.arange and conversion was successful, than I connected another torch.arange to the graph, suddenly I got those tf.Range issues. So I guess it is not only about what you use, but also about how you use it, which affects how onnx decides to make the graph.
\nI have seen solutions which go into modifying the onnx graph, probably not very convenient at this point:-)

", "votes": null, "replies": [] } ] }, { "id": 2217795, "author_name": "martynoveduard", "author_url": "", "post_date": "04/11/2023 07:06:28", "content": "

I think I was able to fix it by replacing torch.arange with torch.from_numpy(np.arange)

", "votes": null, "replies": [ { "id": 2218500, "author_name": "abdulkadirguner", "author_url": "", "post_date": "04/11/2023 18:44:12", "content": "

I tried many different things. It turns out doing a complex preprocessing in pytorch layers and then converting it to tf to tflite, can become very unstable. For my code, I solved it without replacing 'torch.arange'. I had to deal with the arguments on how they evolved until the torch.arange line and made some changes here and there and finally it worked. Now I have other problems but I am progressing :-)

", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "2212551": "Error Message:\n\n```python\nSome ops are not supported by the native TFLite runtime, you can enable TF kernels fallback using TF Select. See instructions: https://www.tensorflow.org/lite/guide/ops_select \nTF Select ops: Range\nDetails:\n\ttf.Range(tensor, tensor, tensor) -> (tensor) : {device = \"\"}\n```\n\n'Normally' tflite conversion looks like supporting tf.range but this tf.Range with a capital 'R' is a questionmark. \n\nI have read the related thread. Seen solutions like: The onnx graph could be amended, or maybe explicitly stating the arguments of the functions in pytorch code could solve...not too easy, because this tf.Range could have been triggered by methods/functions wrapped in higher level methods/functions so might not be directly visible in pytorch code.\nUsing select ops causes issues during submission, although it does the conversion..\n\nSo I am stuck, \nAny advice would be very welcome.", "2213947": "Had this issue at one point, here are a few torch functions that I had to get rid of :\n- `torch.arange`\n- `torch.linspace`\n- `torch.gather`\n\n(I'm assuming you're doing torch -> onnx -> tf -> tflite)", "2213970": "Thank You.\nYes currently I am doing torch onnx tf tflite pipeline. It is the final conversion to tflite that is hard to guess. I mean, I was using torch.arange and conversion was successful, than I connected another torch.arange to the graph, suddenly I got those tf.Range issues. So I guess it is not only about what you use, but also about how you use it, which affects how onnx decides to make the graph.\nI have seen solutions which go into modifying the onnx graph, probably not very convenient at this point:-)", "2217795": "I think I was able to fix it by replacing ```torch.arange``` with ```torch.from_numpy(np.arange)```", "2218500": "I tried many different things. It turns out doing a complex preprocessing in pytorch layers and then converting it to tf to tflite, can become very unstable. For my code, I solved it without replacing 'torch.arange'. I had to deal with the arguments on how they evolved until the torch.arange line and made some changes here and there and finally it worked. Now I have other problems but I am progressing :-)" }, "source": "meta" }