-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add type to model nodes #12
Comments
Would you just add this to give a hint about the type of the tensor, or would you actually use this to check for the correctness of the type, e.g. when building some application and only allowing models that output Also, would you link the dimension of the tensor and the type? We could add |
Adding a type would make things much easier! At the moment, in HPA ShuffleNetV2, the What about those networks which have tables and images as outputs, as MaskRCNN? |
This is still unresolved, right? I agree with @esgomezm, specifying the type would avoid guessing games on the consumer side. |
I wouldn't mind having type as an optional field in the tensor specification. |
I think we should have a type hint key, however, the name For the input tensors UI types:
For the output tensors UI types:
How about name the key as - name: input-1
data_type: float32
data_range: [-inf, inf]
meta:
type: image
axes: bcyx
label: Widefield Image
- name: input-2
data_type: float32
data_range: [-inf, inf]
meta:
type: choice
label: Mode
options:
- microtubule
- nuclear pore
- action filament
encoding: one-hot |
@oeway I agree that type is a bit to ambiguous. Maybe I am not so sure about the ui field. I think this is the responsibility of the consumer and we shouldn't start to encode this in the yaml, because we will need to enumerate a lot of different options. |
How to render is the responsibility of the consumer, these are just some additional information that are required to render them on UI. When you work with models that take image as input and output an image, you don't need to care much about the UI, however, for a classification model for example, there is no way to figure it out the class labels from the consumer side without additional hint. The information has come from the yaml. The ui key might not be the best choice, but, a simple string won't be enough. Also, tensor_type feels very much similar to dtype (example). We should discuss this tomorrow. |
It would be great to specify a type for each model node (outputs for sure, maybe also inputs) - it could be something like
image
,table
,scalar
.The text was updated successfully, but these errors were encountered: