[Hm, somehow the formatting and link of my last mail where spoiled. So, here again for better readability...]
Hello everyone, I want to inform about an internal discussion concerning the handling of DICOM tags as BaseData properties and the changes we are planning to do in the context of finally switching to the DICOM reading infrastructure of the Module DICOMReader. Please feel free to comment on that topic, if you have thoughts about it. This would give us the possibility to make the refactorization as beneficial as possible for everyone. Background/motivation: ---------------------- - At the moment we store extracted DICOM tags as properties. => Good :) - At the moment the properties naming style for DICOM tags is very heterogeneous/individualized [1]. And that's putting it nicely. => Bad! :( - At the moment you have no standardized possibility to access DICOM tag values stored in properties. Especially if a value is slice or time point specific. Planned changes: ---------------- 1. DICOM tags (or generally spoken, information that should be stored in properties semantically encoded with DICOM tags as names) will be stored with the following property naming convention: "DICOM.<Group Number>.<Element Number>". E.g.: the values of the DICOM tag "Modality" would be stored with the property name "DICOM.0008.0060". The storing location of the information will be the (Base)Data instance (not the node!). 2. To support human readability the following strategies will be used. 2a. Dedicated Plugin and/or overlay information. See "Bug 19476 - Create a way to show selected DICOM tags of a node" (http://bugs.mitk.org/show_bug.cgi?id=19476). 2b. The PropertyDescriptions service will be used to add the human readable DICOM tag names as description for the respective properties. (Therefore it will also automatically displayed in the PropertyView) 3. We will introduce non-member functions that allow to query the value of a DICOM tag from the properties of a BaseData instance. They will also allow querying for certain slices or time points. Additionally there will be some helper function for name management. The draft for the function signatures is something like [2]. 4. The content of the property will be stored as a JSON string. The function introduced in bullet point 3 can be used as a convenient access to the values. The hide implementation details and allow easier refactorization later one (e.g. if we move to microservice for more configurability of the encoding/decoding/storing of the information. Planned implementation process: ------------------------------- 1. The above mentioned points will be implemented and the default. 2. The old property naming becomes deprecated. This will additionally indicated by adding a PropertyDescription to all old names, saying "DEPRECATED!!!" (or something like this ;). 3. The mitk code base will be checked and usage of old names will be corrected 4. Removal of the old style from the code (e.g. DICOMSeriesReader, DICOMReaderModule...) after one release cycle. If you have any comments or thoughts on this topic, please let us know. Thanks. Best regards, Ralf ---------------------------------------- [1] Currrent naming style zoo: - Some have the root "dicom", some "dicomSeriesReader - Some are stored by name - Some are stored by numbers - Different upper and lower case styles [2] Draft of the non member function signatures /** Convenience function to get the value of a certain DICOM tag from an data object. @param data BaseData instance that may contain the DICOM tag as property @param tag DICOM tag of the wanted value. @param value The retrieved value as string (only valid if return is true) @param timePoint Value for the given time point. (If undefined for the time point (e.g. only one value at all), the last suitable value will be used) @param z Slice index/ z indicating the slice the value should correspond to. (If undefined for the time point (e.g. only one value at all), the last suitable value will be used) @param strict If strict equals "true", the query will only be successful, when there is really a value stored for the given time point and slice. If strict equals "false" it will return the value that matches best. If no perfect match is possible, it will be the "default" value for the time point (1st order) and slice index (2nd order), if defined. @return Indicates if the tag was found and the out parameter value is valid. Only use "value" if return value is true.**/ bool mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const mitk::DICOMTag& tag, std::string& value, int timePoint = 0, int z = 0 , bool strict = false) /**Overloaded convenience function that returns the value as double. If the value was found, but cannot be returned as double, the return value will be false and the content of "value" is invalid.*/ bool mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const mitk::DICOMTag& tag, double& value, int timePoint = 0, int z = 0 , bool strict = false) /**Overloaded convenience function that returns the value as int. If the value was found, but cannot be returned as int, the return value will be false and the content of "value" is invalid.*/ bool mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const mitk::DICOMTag& tag, double& int, int timePoint = 0, int z = 0 , bool strict = false) /** Returns the property for a given DICOM tag. If no property is found a NULL pointer is returned. */ mitk::BaseProperty::Pointer mitk::GetDICOMDataProperty ( const mitk::BaseData* data, const mitk::DICOMTag& tag) /** Checks if the value of a certain DICOM tag is stored for the passed data instance. @param data BaseData instance that may contain the DICOM tag as property @param tag DICOM tag of the wanted value. @param timePoint Value for the given time point. (If undefined for the time point (e.g. only one value at all), the last suitable value will be used) @param z Slice index/ z indicating the slice the value should correspond to. (If undefined for the time point (e.g. only one value at all), the last suitable value will be used) @param strict If strict equals "true", the query will only be successful, when there is really a value stored for the given time point and slice. If strict equals "false" it will return the value that matches best. If no perfect match is possible, it will be the "default" value for the time point (1st order) and slice index (2nd order), if defined. @return Indicates if the tag was found and the out parameter value is valid. Only use "value" if return value is true.**/ bool mitk::isExistingDICOMValueInDataProperty ( const mitk::BaseData* data, const mitk::DICOMTag& tag, int timePoint = 0, int z = 0 , bool strict = false) /** returns the correct property name for a given DICOMTag instance. */ std::string mitk::GeneratPropertyNameForDICOMTag(const mitk::DICOMTag& tag); ------------------------------------------------------------------------------------------------------ Dr. Ralf Floca Software development for Integrated Diagnostic and Therapy (SIDT) Group leader German Cancer Research Center (DKFZ) Foundation under Public Law Im Neuenheimer Feld 280 69120 Heidelberg Germany phone: +49 6221 42-2560 r.fl...@dkfz.de www.dkfz.de Management Board: Prof. Dr. Michael Boutros (interim), Prof. Dr. Josef Puchta VAT-ID No.: DE143293537 Confidentiality Note: This message is intended only for the use of the named recipient(s) and may obtain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited. > Message: 1 > Date: Thu, 10 Mar 2016 14:43:20 +0100 > From: "Floca, Ralf Omar" <r.fl...@dkfz-heidelberg.de> > Subject: [mitk-users] Handling of DICOM tags as BaseData properties > To: "mitk-users@lists.sourceforge.net" > <mitk-users@lists.sourceforge.net> > Message-ID: > <f9cbef185bb9b140a1a9edcb8d888540016a3b6e7...@dkfzex01.ad.dkfz- > heidelberg.de> > > Content-Type: text/plain; charset="us-ascii" > > Hello everyone, > > I want to inform about an internal discussion concerning the handling of > DICOM tags as BaseData properties and the changes we are planning to do > in the context of finally switching to the DICOM reading infrastructure > of the Module DICOMReader. Please feel free to comment on that topic, if > you have thoughts about it. This would give us the possibility to make > the refactorization as beneficial as possible for everyone. > > Background/motivation: > > * At the moment we store extracted DICOM tags as properties. => > Good :) > > * At the moment the properties naming style for DICOM tags is > very heterogeneous/individualized [1]. And that's putting it nicely. => > Bad! :( > > * At the moment you have no standardized possibility to access > DICOM tag values stored in properties. Especially if a value is slice or > time point specific. > > Planned changes: > > 1. DICOM tags (or generally spoken, information that should be > stored in properties semantically encoded with DICOM tags as names) will > be stored with the following property naming convention: "DICOM.<Group > Number>.<Element Number>". E.g.: the values of the DICOM tag "Modality" > would be stored with the property name "DICOM.0008.0060". The storing > location of the information will be the (Base)Data instance (not the > node!). > > > > 2. To support human readability the following strategies will be > used. > > a. Dedicated Plugin and/or overlay information. See Bug > 19476<https://dkfzowa0.dkfz- > heidelberg.de/owa/redir.aspx?SURL=DLGc3uSBeZwIhFBYJIHiNh9VlNxinevOFo1VP8 > 7MwkV_- > NFru0jTCGgAdAB0AHAAOgAvAC8AYgB1AGcAcwAuAG0AaQB0AGsALgBvAHIAZwAvAHMAaABvA > HcAXwBiAHUAZwAuAGMAZwBpAD8AaQBkAD0AMQA5ADQANwA2AA..&URL=http%3a%2f%2fbug > s.mitk.org%2fshow_bug.cgi%3fid%3d19476> - Create a way to show selected > DICOM tags of a node. > > b. The PropertyDescriptions service will be used to add the human > readable DICOM tag names as description for the respective properties. > (Therefore it will also automatically displayed in the PropertyView) > > > > 3. We will introduce non-member functions that allow to query the > value of a DICOM tag from the properties of a BaseData instance. They > will also allow querying for certain slices or time points. Additionally > there will be some helper function for name management. The draft for > the function signatures is something like [2]. > > > 4. The content of the property will be stored as a JSON string. The > function introduced in bullet point 3 can be used as a convenient access > to the values. The hide implementation details and allow easier > refactorization later one (e.g. if we move to microservice for more > configurability of the encoding/decoding/storing of the information. > > Planned implementation process: > > 1. The above mentioned points will be implemented and the default. > > 2. The old property naming becomes deprecated. This will > additionally indicated by adding a PropertyDescription to all old names, > saying "DEPRECATED!!!" (or something like this ;). > > 3. The mitk code base will be checked and usage of old names will > be corrected > > 4. Removal of the old style from the code (e.g. DICOMSeriesReader, > DICOMReaderModule...) after one release cycle. > > If you have any comments or thoughts on this topic, please let us know. > Thanks. > > Best regards, > Ralf > > > [1] Currrent naming style zoo: > > * Some have the root "dicom", some "dicomSeriesReader > > * Some are stored by name > > * Some are stored by numbers > > * Different upper and lower case styles > > [2] Draft of the non member function signatures > /** Convenience function to get the value of a certain DICOM tag from an > data object. > @param data BaseData instance that may contain the DICOM tag as property > @param tag DICOM tag of the wanted value. > @param value The retrieved value as string (only valid if return is > true) @param timePoint Value for the given time point. (If undefined for > the time point (e.g. only one value at all), the last suitable value > will be used) @param z Slice index/ z indicating the slice the value > should correspond to. (If undefined for the time point (e.g. only one > value at all), the last suitable value will be used) @param strict If > strict equals "true", the query will only be successful, when there is > really a value stored for the given time point and slice. If strict > equals "false" it will return the value that matches best. If no perfect > match is possible, it will be the "default" value for the time point > (1st order) and slice index (2nd order), if defined. > @return Indicates if the tag was found and the out parameter value is > valid. Only use "value" if return value is true.**/ bool > mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const > mitk::DICOMTag& tag, std::string& value, int timePoint = 0, int z = 0 , > bool strict = false) > > /**Overloaded convenience function that returns the value as double. If > the value was found, but cannot be returned as double, the return value > will be false and the content of "value" is invalid.*/ bool > mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const > mitk::DICOMTag& tag, double& value, int timePoint = 0, int z = 0 , bool > strict = false) > > /**Overloaded convenience function that returns the value as int. If the > value was found, but cannot be returned as int, the return value will be > false and the content of "value" is invalid.*/ bool > mitk::GetDICOMValueFromDataProperty ( const mitk::BaseData* data, const > mitk::DICOMTag& tag, double& int, int timePoint = 0, int z = 0 , bool > strict = false) > > /** Returns the property for a given DICOM tag. If no property is found > a NULL pointer is returned. */ mitk::BaseProperty::Pointer > mitk::GetDICOMDataProperty ( const mitk::BaseData* data, const > mitk::DICOMTag& tag) > > /** Checks if the value of a certain DICOM tag is stored for the passed > data instance. > @param data BaseData instance that may contain the DICOM tag as property > @param tag DICOM tag of the wanted value. > @param timePoint Value for the given time point. (If undefined for the > time point (e.g. only one value at all), the last suitable value will be > used) @param z Slice index/ z indicating the slice the value should > correspond to. (If undefined for the time point (e.g. only one value at > all), the last suitable value will be used) @param strict If strict > equals "true", the query will only be successful, when there is really a > value stored for the given time point and slice. If strict equals > "false" it will return the value that matches best. If no perfect match > is possible, it will be the "default" value for the time point (1st > order) and slice index (2nd order), if defined. > @return Indicates if the tag was found and the out parameter value is > valid. Only use "value" if return value is true.**/ bool > mitk::isExistingDICOMValueInDataProperty ( const mitk::BaseData* data, > const mitk::DICOMTag& tag, int timePoint = 0, int z = 0 , bool strict = > false) > > /** returns the correct property name for a given DICOMTag instance. */ > std::string mitk::GeneratPropertyNameForDICOMTag(const mitk::DICOMTag& > tag); > > > ------------------------------------------------------------------------ > ------------------------------ > Dr. Ralf Floca > Software development for Integrated Diagnostic and Therapy (SIDT) Group > leader > > German Cancer Research Center (DKFZ) > Foundation under Public Law > Im Neuenheimer Feld 280 > 69120 Heidelberg > Germany > phone: +49 6221 42-2560 > > r.fl...@dkfz.de > www.dkfz.de<http://www.dkfz.de/> > > [cid:image001.png@01D17ADB.30EFE670] > > Management Board: Prof. Dr. Michael Boutros (interim), Prof. Dr. Josef > Puchta VAT-ID No.: DE143293537 > > > Confidentiality Note: > This message is intended only for the use of the named recipient(s) and > may obtain confidential and/or privileged information. If you are not > the intended recipient, please contact the sender and delete the > message. Any unauthorized use of the information contained in this > message is prohibited. > > -------------- next part -------------- > An HTML attachment was scrubbed... > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 13120 bytes > Desc: image001.png > > ------------------------------ > > ------------------------------------------------------------------------ > ------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with Intel Data Analytics > Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > > ------------------------------ > > _______________________________________________ > mitk-users mailing list > mitk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mitk-users > > > End of mitk-users Digest, Vol 118, Issue 7 > ****************************************** ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
