[Insight-developers] MetaIO - versioning

Williams, Norman K norman-k-williams at uiowa.edu
Mon Jan 24 11:13:15 EST 2011


If there's no version present in the file when you read it, the version is
1. Version 1 would indicate that whatever extensions defined for versions
> 1 are absent.

For versions > 1, each version would indicate the presence of one or more
new attributes or changes in definition, which would be handled by the new
code associated with that version.

So long as no new behavior/attributes is introduced without a new revision
number, it should be completely backwards compatible.

I'm not sure there'd be any problems, given the Meta file format, with
older readers accomodating the new versioned format, just as long as the
versioned file didn't change the meaning or organization of the data
common between the old format and the new format.  The fact that there's a
version tag will be ignored by the old reader. Any new data present will
be in an unrecognized tagged data field in the file, and likewise be
ignored.

It will require that someone adding a new version not bugger up the data
read by all versions of the reader.

In terms of testing, perhaps adding a version of '0' and instrumenting the
reader such that it will behave exactly like the pre-version-numbers
reader would allow tests to simulate the old reader with the new reader.

Do I have that about right, Stephen?

On 1/23/11 1:25 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:

>Hello Stephen,
>
>It sounds quite a reasonable way to move the file format forward.
>
>My one concern would be testing. All the different versions greatly
>increase this burden. How to ensure that you can still read the old
>formats correctly and the newly written old formats are still compatible?
>Do you have a proposed strategy for testing the different combinations of
>file formats? 
>
>Brad
>
>On Jan 23, 2011, at 11:59 AM, Stephen Aylward wrote:
>
>> Hi ITK'ers.
>> 
>> Proposal
>> =======
>> I am writing to propose adding version information to metaObject
>> files, including meta images.
>> 
>> Problem addressed
>> ===============
>> Meta was created 14+ years ago and needs updating.   This will allow
>> us to better support images of vectors of vectors, spacing per slice,
>> ...
>> 
>> Method
>> ======
>> We could add a Met_ReadVersion function for meta object developers
>> that returns a version number for a file's format.   The version
>> number can be read from a file without reading the other contents of a
>> file.   MetaObject readers would be able to adjust the fields they
>> read from a file based on that version.  MetaObject writers should be
>> able to write to older version formats as well as the current version
>> format.
>> 
>> The version tag will be set to 1.0 for all object formats at this
>> time.   Thus, if a version number hasn't been specified in the file,
>> the MET_ReadVersion function returns 1 (corresponding to the current
>> version of meta).   Moving forward, each object can increase its
>> version - that is, there will not be a global version number, it will
>> be object specific.
>> 
>> Justification for design: Currently, there is a function
>> "Met_ReadForm" that allows a developer to query the type of object in
>> a meta file (e.g., image, matrix, arrow, tube,...).    The proposed
>> MET_ReadVersion function follows that pattern.
>> 
>> The file tag will be "ObjectVersion".
>> The value of ObjectVersion with be an unsigned int.  (no concept of
>> minor/major versioning will be provided).
>> -- The tag is ObjectVersion and not FileVersion because the content of
>> the file/object will change, not just its organization in the file.
>> 
>> Comments / suggestions / concerns?
>> 
>> s
>> 
>> -- 
>> 
>> ==============================
>> Stephen R. Aylward, Ph.D.
>> Director of Medical Imaging Research
>> Kitware, Inc. - North Carolina Office
>> http://www.kitware.com
>> stephen.aylward (Skype)
>> (919) 969-6990 x300
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.html
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.itk.org/mailman/listinfo/insight-developers



More information about the Insight-developers mailing list