Comments (14)
I suggest we test the current build a bit, as I noted here
https://www.nitrc.org/forum/message.php?msg_id=19507
the latest version includes a kludge to handle images that include icons where the icon does not match the transfer syntax of the main image. By handling a clear (but potentially common) violation of the DICOM standard, it is possible we may have unintended consequences for legitimate DICOM images. I think we want developers to test this a bit before we deploy this to the wild.
from dcm2niix.
FYI, I am currently using v1.0.20161101
.
from dcm2niix.
It was recently brought to my attention by @yarikoptic that the versioning scheme of dcm2niix
had changed a few times (#28). This leads us to an uncomfortable situation whereby the NeuroDebian packages (which follow the old YYYYMMDD scheme) and Debian packages (currently following the 1.0.YYYYMMDD scheme) have incompatible upgrade paths, since upgrades are triggered by version number sorting.
Your last post in #28 reads like a more complicated versioning scheme than YYYYMMDD would not be required, which was followed by an ack from @yarikoptic. I just wanted to know what made you change from YYYYMMDD to the current versioning scheme and whether you would see an inconvenience in returning to using the former from future releases thereon.
My personal opinion is that if dcm2niix
were a library, there would be plenty of room for discussion regarding which version scheme is best. For a single application however, a simple chronological versioning scheme such as YYYYMMDD is probably enough. Again, just my opinion.
from dcm2niix.
I had originally used the YYYYMMDD scheme, but was encouraged to move to a semver scheme, as noted earlier. I think this is a mature release, and do not see many changes other than keeping up to date with the vendor's reinterpretation of DICOM. I am agnostic about this, but think we should be consistent, so to be consistent with the last release I suggest 1.0.YYYYMMDD going forward.
from dcm2niix.
Quoting the last post of the thread you linked:
As long as MRIcroGL has a stable (ascending) versioning scheme as part of the filename over time it's ok. Otherwise package managers have a hard time distinguising new versions over old ones.
That's exactly the situation we are in now.
from dcm2niix.
Hi Chris,
FYI, the deadline for updating a package to a new release for the next stable version of Debian is on January 25th (tomorrow). Shall I take the current snapshot of master
as of today, or are you happy keeping the old v1.0.20161101
?
Cheers,
Ghis
from dcm2niix.
from dcm2niix.
Apologies for the late reply.
The JSON sidecar can be amended with any custom key/value pair as long as the key is not previously specified in the spec. This means that addition of the "dcm2niixVersion": “v1.0.20170101”
key/value is perfectly fine.
However, because the key name is so specific to dcm2niix it's unlikely this would be included in the new revision of BIDS as part of the standard. Your previous suggestion: “DicomConversion": [“dcm2niix", "v1.0.20170101"]
is more software agnostic. To keep it more in line with other key/values derived from DICOM ontology and make it more agnostic to the original format of the data (after all dcm2niix also works with other types than DICOM) I would propose splitting this into two explicit keys:
"ConversionSoftwareName": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20170101"
One more clarification on commas. The fact that the last element in a list cannot have a trailing comma is part of the JSON specification. Changing this would break a lot of existing code relying on the plethora of JSON libraries available for many languages.
from dcm2niix.
I have generated a new release of dcm2niix. I would greatly appreciate if people could try out the latest version in the MRIcroGL release - as MRIcroGL includes not only dcm2niix but a GUI for using dcm2niix (the 'Import' menu). Unless there are any issues reported I will release the compiled code on NITRC next week.
from dcm2niix.
I've done a quick test with a few of my datasets (on macOS), and the conversion seems to work fine through MRIcroGL.
from dcm2niix.
@neurolabusc 1cent: as previously suggested (https://github.com/rordenlab/dcm2niix/search?q=annotated&type=Issues&utf8=%E2%9C%93) better to use annotated tags for the releases, which wasn't the case
$> git describe v1.0.20170130
20160606-174-gcf4a5e1
$> git show v1.0.20170130
commit cf4a5e1236bbf39540bc110cb819ceeec001b661
Author: Chris Rorden <[email protected]>
Date: Mon Jan 30 08:51:09 2017 -0500
new release
diff --git a/README.md b/README.md
index 70653cf..e996ef4 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@ This software is open source. The bulk of the code is covered by the BSD license
## Versions
-1-Jan-2017
+30-Jan-2017
- Handle 3D Philips DICOM files where images are not stored in a spatially contiguous order.
- Handle DICOM violations where icon is uncompressed but image data is compressed.
- Best guess matrix for 2D slices (similar to dcm2nii, SPM and MRIconvert).
from dcm2niix.
@yarikoptic - my fault entirely. I am not sure how to do that, I built the release using the web-based github interface, and did not see any options for this. Is there a concise github documentation or can you provide a few lines regarding how to do this. I do like how the online GUI editor allows me to attach precompiled exectuables.
from dcm2niix.
from dcm2niix.
@neurolabusc I haven't realized that github web ui doesn't create those release tags annotated (I guess for the purpose of being able to change/edit release description later on). I guess the only way then would be as @ghisvail pointed out to do it in the command line, and generate github release from the pushed tag (as I usually do)
from dcm2niix.
Related Issues (20)
- Estimated Gantry Tilt -nan(ind), but Gantry Tilt field is 0 HOT 5
- Please provide instructions HOT 1
- Unable to find any DICOM images if the absolute path of input folder too long HOT 3
- Extract kVp into the json file from DICOM header HOT 1
- Series split into multiple NIfTI volumes unexpectedly HOT 7
- setBidsGE fails to recognize Gradient Echo EPI HOT 4
- Slice timing missing in the json file HOT 2
- Q about where json gets written HOT 6
- Filename oddity in 20240202 for Philips DWI HOT 10
- GE UHP/7T Diffusion SliceTiming HOT 5
- Possible incorrect SliceTiming HOT 16
- Siemens conversion problems (Magnetom Altea) HOT 2
- error dcm2niix using dcm2bids HOT 1
- PET json information HOT 12
- Inquiry on DICOM to NIfTi HOT 4
- Siemens 2D epi TR is incorrect HOT 2
- dcm2niix is incorrectly attempting to use a JPEG:Lossless transfer syntax that was set inside an Original Attributes Sequence HOT 1
- GE AcquisitionDuration HOT 6
- Incorrect Slice/Vol Order After Site Updated Philips Software (Ingenia version 11.1) HOT 11
- Return status bug (incorrectly reported error) v1.0.20240202 HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dcm2niix.