populse / mri_conv

3 stars 0 forks source link

How mri_conv find data and Philips format readable by nmri_conv #7

Closed servoz closed 4 years ago

servoz commented 4 years ago

Let's say that we have 4 directories with data and the format of the data (Philips PAR/REC) as below:

1/ briclot: V4 format DBIEX_3_1.PAR DBIEX_3_1.REC DBIEX_4_1.PAR DBIEX_4_1.REC DBIEX_5_1.PAR DBIEX_5_1.REC DBIEX_6_1.PAR DBIEX_6_1.REC DBIEX_7_1.PAR DBIEX_7_1.REC

3/ coued_200225: V4.2 format coued_200225_3D_pCASL_6mm_8_1.PAR coued_200225_3D_pCASL_6mm_8_1.REC coued_200225_FE_EPI_32chSHC_6_1.PAR coued_200225_FE_EPI_32chSHC_6_1.REC coued_200225_CS_T1_3D_EG_5_1.PAR coued_200225_CS_T1_3D_EG_5_1.REC coued_200225_PERFUSION_11_1.PAR coued_200225_PERFUSION_11_1.REC

4/ alej170316: V4.2 format alej170316_testMIA24052018_anat.PAR alej170316_testMIA24052018_anat.REC alej170316_testMIA24052018_hypc12.PAR alej170316_testMIA24052018_hypc12.REC

5/ alej170316: V4.2 format alej170316_testMIA24052018_anat.par alej170316_testMIA24052018_anat.rec alej170316_testMIA24052018_hypc12.par alej170316_testMIA24052018_hypc12.rec

To illustrate this ticket, here are 3 tests I did with the directories above:

- test_I: 3/ and 4/ in the same directory : foo/alej170316 and foo/coued_200225

_-> Click on Philips Achieva button > select coued200225 > click on Select this directory:

=> Result: we get all the data in mri_conv by going up one level from the chosen directory (i.e. ../coued_200225 so foo) and by exploring all the directories present at this level, so the data in foo/alej170316 and foo/coued_200225. In fact we get exactly the same result as if we had selected foo. So why not. However this is not exactly what the user asked for and it could have serious consequences if at a level above the selection there is data not compatible with mri_conv (see after).

A/ Would it be possible to work only in the selected directory? if there is data in this directory I recover these data and I look if there are directories in this directory and if yes I recover the data in these (but I don't go up a notch as at present).

test_II: 3/ and 5/ in the same directory : foo/alej170316 and foo/coued_200225 _-> Click on Philips Achieva button > select coued200225 > click on Select this directory:

=> Result: We get all the data from coued_200225 and none from alej170316 since the data in alej170316 are in .par/.rec format rather than .PAR/.REC (already opened #6 issue). Since the user has selected coued_200225 this is not shocking. However, given the way the mri_conv selection described in test_I works, if the user selects alej170316 he will have the data of coued_200225, but not from alej170316 ... which may be surprising to the user not knowing this strange operation. No error is raised in this case.

test_III: 1/ and 3/ in the same directory: foo/briclot and foo/coued_200225 -> Click on Philips Achieva button > select coued_200225 > click on Select this directory:

=> Result: no data is retrieved. Exceptions are:

$ java -jar MRIManager.jar
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    at MRIFileManager.ActionSelectionData.mouseReleased(ActionSelectionData.java:57)
    at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:298)
    at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
    at java.desktop/java.awt.Component.processMouseEvent(Component.java:6636)
    at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
    at java.desktop/java.awt.Component.processEvent(Component.java:6401)
    at java.desktop/java.awt.Container.processEvent(Container.java:2263)
    at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5012)
    at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
    at java.desktop/java.awt.Component.dispatchEvent(Component.java:4844)
    at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4919)
    at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4548)
    at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4489)
    at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
    at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2764)
    at java.desktop/java.awt.Component.dispatchEvent(Component.java:4844)
    at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
    at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
    at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
    at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
    at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

I think the problem comes from briclot directory where the data are in V4 format and not V4.2.

B/ Would it be possible to upgrade mri_conv to make the V4.x formats readable?

The fact that mri_conv only supports the V4.2 format (and not V4 for example) while mri_conv is looking in the directory above the one selected during data selection is a very big problem for mia_populse. Indeed the clinical data are all stored in the same place at the CHU. So, given the way it works, it's not possible to use populse_mia for the moment because of this ...

Proposal:

This problem is a priority for populse because as we have chosen mri_conv as the entry door of populse_mia, we are for the moment stuck for a clinical use at the Grenoble CHU!

montigno commented 4 years ago

see with the last version of mri_conv and observe the behavior. Thanks !

servoz commented 4 years ago

Last tests with devpt branch: test_I: Exactly the same result (not only the data from coued_200225 but all the data from coued_200225 AND alej170316) test_II: We get now all the data from coued_200225 AND alej170316. This is simply due to the fix in #6 ticket but we keep the problem explained in test_I test_III: Exactly the same result !

Proposal:

Please, use the links to download the data to make tests.

montigno commented 4 years ago

I'm starting to understand the problems better. I will make the software compatible with v4.X, it will take a little time (but not too much i hope). And for point /A, I'll see what I can do. To be continued !

servoz commented 4 years ago

Thanks a lot !!! We are looking forward to your fix, because at the moment we are a bit stuck for the use of mia with real data coming from CHU !

montigno commented 4 years ago

a new version of mri_conv (20.2.0a) is available on the 'devt' branch. It is now compatible with V4 and V4.1 (and V4.2 of course). For point /A, see if it fits.

(I will be absent tomorrow and Friday) Thanks!

servoz commented 4 years ago

Thank you very much for this big work. I'll run some tests as soon as possible!

servoz commented 4 years ago

Ohhh Yeahhh very good job @montigno !!!

- test_I: it works very well now. Just a little detail : It will be perfect if in the field just below all the Bruker, DICOM etc... buttons it was exactly what we chose : Ex. If we choose coued_200225 as described in test_1, I can still see the directory name above in this field. To be clear: Let's say that in my station, I have: /home/econdami/Desktop/tests/coued_200225 and /home/econdami/Desktop/tests/alej170316. If I select /home/econdami/Desktop/tests/alej170316, I only have the data from /home/econdami/Desktop/tests/alej170316 (which is a very good improvement!). If I select /home/econdami/Desktop/tests, I now have all the data from alej170316 and alej170316. This is exactly what is expected! But in the field under the button, it is in both cases home/econdami/Desktop/tests. I guess it will be fine if it was /home/econdami/Desktop/tests/alej170316 in the first case and /home/econdami/Desktop/tests in the second!

- test_II : works very well too (same small detail as test_1)

-test_III: works very well.

Very good job , thanks again.

montigno commented 4 years ago

Thank you !

For the field just below the buttons, I did not think of testing it ! I'll see that next week.

To be continued !

servoz commented 4 years ago

for me the devpt branch can be merged with master (i don't see other issue with the devpt branch when using with mia). Please do not forget the field just below the buttons.

montigno commented 4 years ago

ok, as soon as I solve this field problem, i will merge master with dev. The field problem was more complicated than I thought, but it will come.

montigno commented 4 years ago

A new version (20.2.1a) is available in the 'dev' branch. It corrects the problem of the 'history' field (i hope so). If it's ok, i am merging master with dev.

servoz commented 4 years ago

All tests passed fine with mia. I guess you can merge to master branch!

montigno commented 4 years ago

the software has just been merged in the 'master' branch !

servoz commented 4 years ago

Very nice ! Thanks a lot for this hard work !