-
Notifications
You must be signed in to change notification settings - Fork 62
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 bltest data #11
Add bltest data #11
Conversation
These files are managed using git-lfs
Alright. |
@che85 can you please study this: https://github.com/github/git-lfs/wiki/Tutorial The question is to decide if git lfs is a suitable mechanism to handle test data, or we should use an external system. |
@fedorov To me it seems as if it doesn't work properly. Checking out your branch and fetching the objects seems to download something, but the size of the DICOM images is still a few bytes... After checking out master and then switching back to add-bltest-data, the DICOM images has appropriate sizes. I might be wrong or git lfs is unusable in it's current state. Another point which assures that is the large amount of open issues https://github.com/github/git-lfs/issues One thought how to manage that alternatively would probably be, to have another repository or branch for the test data only so that the user has better control about "if" the test data will be checked out or not. I found a nice page http://blog.deveo.com/storing-large-binary-files-in-git-repositories/ which lists git lfs like mechanism. I will take a look at it. |
Related discussion that resolved the problem I had: git-lfs/git-lfs#1339 |
Kudos to @technoweenie for suggesting this solution! See git-lfs/git-lfs#1339 With this modification, git-lfs tracked files are no longer marked as modified by git status after git lfs checkout.
@che85 @pieper @hmeine @nolden you are most welcome to test this and comment.
The problem I described to you seems to be resolved, and was due to my limited knowledge (I did not add Let me know what you think about using this approach to maintain test data. We can always switch to something else later, but from what I've seen so far, the next alternative is Midas. Distributed FSs like IPFS and DAT do not solve the hosting problem. As discussed earlier with the RT team and Marco, it is nice to have data in the same repo as the code, so I like this approach with git-lfs, if it works. |
Yes, I think git-lfs is at least as good as any of the alternatives we On Thu, Jun 30, 2016 at 1:35 PM, Andrey Fedorov notifications@github.com
|
As I reported by mail, there are problems with the CT data. I believe that MeVisLab is rather strict, but I think if we publish this as reference datasets, it might be worth looking into. Actually, the problems are even more severe with the BLTests/BLSEGTest2/Image folder than with the Brainlab-deid folder I reported on. Also, the instructions you gave above were not enough for me – I had to issue |
Yes, I did get your report. I haven't had time to look into it, as I've been quite busy with other dcmqi issues (see https://github.com/fedorov?tab=overview&from=2016-06-28&to=2016-06-30). For test data, I first want to organize BLTest data, and then work on the CT dataset you are concerned about.
I didn't know about this. Can you please describe the problem? I've just tried loading the dataset in Slicer, and it looks fine (see screenshot below). However, something is not right, since Slicer says this is a multiframe image, but the fact is it is not a multiframe image .... Also, did you notice ImageType is
Interesting. I added an FAQ entry about accessing the data: QIICR/dcmqi-faq#3 (and after doing this, realized this PR is not yet merged!) |
I may be wrong, but wasn't the idea of the BLTest dataset to illustrate That said, Andrey did you notice that the CT is actually screwed up in the On Fri, Jul 1, 2016 at 3:11 PM, Andrey Fedorov notifications@github.com
|
the idea of the dataset is to provide testing for the data collected from the platforms that produce SEG. I agree with Steve - unless the data was corrupted somewhere in transmission, it makes sense to keep it.
I did not, but now I do! I should ask the source of the data! Interesting.
There is, but it is somewhat cryptic, and the difference does not show up, unless I resize the table: |
Maybe slicer should complain more. What does MeVisLab say about this data?
|
I decided to exclude BLTest2 for various reasons, at least in its current state. I can explain later. I will explain later. I will make another PR after revising the data. |
contributes 4 image series and matching SEGs generated using Brainlab. Baseline NRRDs to be added. Note that only tests 1 and 4 can be handled by the converter, the other two cases need to be debugged ...
related to #9