-
Notifications
You must be signed in to change notification settings - Fork 1.3k
MONAI Archive Specification #3834
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
Changes from 7 commits
f25631f
f0ea2f8
3e2c78d
0a65480
ebbb801
c974092
08225a6
f2a6fef
d7660ef
e788f84
83277a5
a3787a7
4e92174
55c944c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,137 @@ | ||||||
|
|
||||||
| =========================== | ||||||
| MONAI Archive Specification | ||||||
| =========================== | ||||||
|
|
||||||
| Overview | ||||||
| ======== | ||||||
|
|
||||||
| This is the specification for the MONAI Archive (MAR) format of portable described deep learning models. The objective of a MAR is to define a packaged network or model which includes the critical information necessary to allow users and other programs to understand how the model is used and for what purpose. A MAR includes the stored weights of a model as a state dictionary and/or a Torchscript object. Additional JSON files are included to store metadata about the model, information for constructing training, inference, and post-processing transform sequences, plain-text description, legal information, and other data the model creator wishes to include. | ||||||
|
|
||||||
| This specification defines the directory structure a MAR must have and the necessary files it must contain. Additional files may be included and the directory packaged into a zip file or included as extra files directly in a Torchscript file. | ||||||
|
|
||||||
| Directory Structure | ||||||
| =================== | ||||||
|
|
||||||
| A MAR package is defined primarily as a directory with a set of specifically named subdirectories containing the model and metadata files. The root directory should be named for the model, given as "ModelName", and should contain the following structure: | ||||||
| :: | ||||||
| ModelName | ||||||
| ┣━ configs | ||||||
| ┃ ┗━ metadata.json | ||||||
| ┣━ models | ||||||
| ┃ ┣━ model.pt | ||||||
| ┃ ┗━ model.ts | ||||||
| ┗━ docs | ||||||
| ┣━ README.md | ||||||
| ┗━ license.txt | ||||||
|
|
||||||
|
|
||||||
| These files mostly are required to be present with the given names for the directory to define a valid MAR: | ||||||
|
|
||||||
| * **metadata.json**: netadata information in JSON format relating to the type of model, definition of input and output tensors, versions of the model and used software, and other information described below. | ||||||
|
||||||
| * **metadata.json**: netadata information in JSON format relating to the type of model, definition of input and output tensors, versions of the model and used software, and other information described below. | |
| * **metadata.json**: metadata information in JSON format relating to the type of model, definition of input and output tensors, versions of the model and used software, and other information described below. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * **optional_packages_version**: dictionary relating optional package names to their versions, these packages are not needed but are recommended to be isntalled with this stated minimum version. | |
| * **optional_packages_version**: dictionary relating optional package names to their versions, these packages are not needed but are recommended to be installed with this stated minimum version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also what about required dependencies (apart from torch, monai, numpy)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those would go into optional_packages_version so maybe call this other_package_versions instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ericspod , I would suggest optional_packages_version or optional_dependencies_version, to be consistent with our installation guide doc:
https://docs.monai.io/en/latest/installation.html#installing-the-recommended-dependencies
Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is mulitclass? I'm guessing this is a array of integers where each integer represents a class index. In this case, I would personally refer to this as a "label map"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea with that was to allow multiple categories for each voxel, so multi-labeling is assigning a label to each voxel as a number, to have multi-class requires keeping N channels for N classes to handle voxels that would be referenced in multiple channels.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am concerned that in some cases this will be too restrictive. I have a few models that do not have a fixed input shape, but may have restrictions on the input shape, e.g. [32n, 32n, 2n] for something that must be as multiple 32 down the first two axes and a multiple of 2 down the last.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this was something we in one meeting or another discussed earlier and I didn't include details here. There's a range of specification we can define, so using "*" for any size on one dimension, using "n" like multiplier here or as a power, so we'd need to specify shape probably as a string. For example, permitting any number of channels (somehow) and a spatial shape that's the same power of 2 would be "[*, 2n, 2n]". We would need a parser to recognize these formats and validate they are correct, and then generate code that validates the network itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about allowing "any size". That might be the case while dealing with Digital Pathology Slides...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @GreySeaWolf , may I know what's the any size you mean? Can we use "*" to represent it as @ericspod described?
Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ericspod ,
I got a question here: What's the expected data type of spatial_shape in the metadata? Seems you are using str in this example. We need to finalize the data type then check it with the schema. Otherwise, it's hard to check network input / output shape with scripts.
What do you think?
Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shapes are going to have to be defined as lists of either strings to accommodate "2n" or "*" as specifiers or integers for exact know sizes. For example, a 2D image that's 256x256 in the spatial dimension with any number of channels would be ["*", 256, 256] by if the spatial dimensions had to be multiples n of a power p of 2 we would have ["*", "2**p*n", "2**p*n"]. The expression syntax we would allow here may get a bit complicated and requires validation in separate steps.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we call out the version of the model? I have seen use cases requiring multiple versions of the same model, and the Triton inference supports multiple versions of the same named model. The version info is embedded in the metadata, it is accessible, I guess the consumer will just need to parse the metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MMelQin ,
I think we already included the
versionandchangelogof the model package:https://github.com/Project-MONAI/MONAI/pull/3834/files#diff-139c21b7be482dc057c2b0b9d131f86500621c01b7132cb15060c54b2fb22775R84
@ericspod Maybe you can update the description to make it more clear?
Thanks in advance.