dicom / ruby-dicom Goto Github PK

The speeds of reads can be speed up by 10x by making the dictionary a hash and searching it that way. I have a version that I have hacked together with a new dictionary file that works. I have seen speed increases of 10 times.

Hi all!,

I'm working on a Rails 2.3.10 app and recently (today) I ran 'bundle update', after that I've started to get errors like this:

=> Booting Mongrel
=> Rails 2.3.10 application starting on http://0.0.0.0:3000
/Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:469:in load_missing_constant': uninitialized constant FlashSessionCookieMiddleware (NameError) from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:106:inconst_missing_not_from_s3_library'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/aws-s3-0.6.2/lib/aws/s3/extensions.rb:206:in rake_original_const_missing' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rake-0.9.0/lib/rake/ext/module.rb:36:inconst_missing'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:118:in const_missing' from /Users/goyox86/Code/CareShare/config/initializers/session_store.rb:16 from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:171:inload_without_new_constant_marking'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:171:in load' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:547:innew_constants_in'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:171:in load' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:622:inload_application_initializers'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:621:in each' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:621:inload_application_initializers'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:176:in process' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:113:insend'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/initializer.rb:113:in run' from /Users/goyox86/Code/CareShare/config/environment.rb:11 from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:182:inrequire'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:182:in require' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:547:innew_constants_in'
from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/activesupport-2.3.10/lib/active_support/dependencies.rb:182:in require' from /Users/goyox86/.rvm/gems/ruby-1.8.7-p334@care/gems/rails-2.3.10/lib/commands/server.rb:85 from script/server:3:inrequire'
from script/server:3

Nothing special with FlashSessionCookieMiddleware because I commented it out and the app started complaining about other constants.

This is my uname -a output: Darwin Goyox86s-MacBook.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

With 0.8 everything is fine, so something happened in 0.9. I've downgraded to 0.8 and everything is fine.

I'm using this example:

require 'dicom'
include DICOM
require 'RMagick'
include Magick
obj = DICOM::DObject.new("1478392")
image = obj.image(:level=>[100, 500]).normalize
text = Draw.new
text.fill = 'White'
text.pointsize = 12
text.annotate(image, 0, 0, 12, 30, "Guardiao")
t = Time.now
text.pointsize = 10
text.annotate(image, 0, 0, 8, 45, t.strftime("Processado em %d/%m/%Y"))
image.write("dicom.jpg")

But when I run this script from a Rails app, it crashes /Users/rodrigo/.rvm/gems/ruby-1.9.2-p180@guardiao/gems/dicom-0.9.2/lib/dicom/image_processor_r_magick.rb:65: [BUG] Segmentation fault

How can I use mini_magick and test it if it works?

We have here quite large test data (Breast TOMO IOD) objects that have an uncompressed size of about 600MB. When I try open such an object and send it to an association the library crashes with the following stack trace:

I, [2011-10-26T16:04:39.803531 #4760] INFO -- DICOM: The DICOM file has been successfully parsed.
I, [2011-10-26T16:04:39.894351 #4760] INFO -- DICOM: Association successfully negotiated with host DEFAULT (127.0.0.1).
I, [2011-10-26T16:04:39.896304 #4760] INFO -- DICOM: All 2 presentation contexts were accepted by host DEFAULT (127.0.0.1).
C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:137:in slice!': failed to allocate memory (NoMemoryError) from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:137:inblock in add'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:137:in times' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:137:inadd'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:311:in write_value' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:223:inwrite_data_element'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:205:in block in write_data_elements' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:180:ineach'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:180:in write_data_elements' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_write.rb:104:inencode_segments'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_object.rb:235:in encode_segments' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_client.rb:692:inblock in perform_send'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:in each' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:ineach_with_index'
from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:in perform_send' from C:/JENKINS_HOME/workspace/CukeTest/ThirdParty/OEM/Ruby/lib/ruby/gems/1.9.1/gems/dicom-0.9.2/lib/dicom/d_client.rb:385:insend'

The machine is a Windows 7 64 bit workstation.

On request I could make such an object available.

I've been trying to read a jpg image with RMagick and use this image as the pixel data for a blank DICOM image. I'm running into an issue where a method valid_image_objects returns an array of acceptable classes, one of which is MiniMagick::Image. This causes an exception to be thrown, saying that there is an uninitialized constant DICOM::ImageProcessor::MiniMagick. This is how I'm writing the code:

require 'dicom'
include DICOM
require 'RMagick'

DICOM.image_processor = :rmagick
img = Magick::Image.read("test_image.jpg").first
img.class # Magick::Image

dcm = DObject.new
dcm.image = img

#<Class:0x356cc30>: uninitialized constant DICOM::ImageProcessor::MiniMagick
             from C:/Ruby193/lib/ruby/gems/1.9.1/gems/dicom-0.9.4/lib/dicom/image_processor.rb:53:in 'valid_image_objects'
             from C:/Ruby193/lib/ruby/gems/1.9.1/gems/dicom-0.9.4/lib/dicom/image_item.rb:268:in 'image='

If I also add require 'mini_magick' to this, the error no longer occurs.

I understand why the error is occuring, but why do I need to also include MiniMagick if I'm using RMagick as a processor? Would it be possible to refactor the method that returns the valid image objects so that it returns a string representation as opposed to the actual class?

Something like this, perhaps (in image_processor.rb):

def valid_image_objects
  return %w[Magick::Image, MiniMagick::Image]
end

In image_item.rb

def image=(image)
  raise ArgumentError, "Expected one of the supported image objects {#{valid_image_objects}), got #{image.class}." unless valid_image_objects.include?(image.class.to_s)
  ...
end

When I run:

pacsCENTRO = DClient.new("192.168.4.32", 11112, {host_ae: "PACSCENTRO", timeout: 2}).test

with an offline server, I expected the result to be false after two seconds if there is no response from the server. Instead, the process hangs indefinitely.

Am I doing this wrong?

Currently, the ruby-dicom library supports the following two color modes: RGB and PALETTE COLOR. However, it would be nice to support the other variants of Photometric Interpretation (0028,0004) as well, such as:

• YBR_FULL
• YBR_FULL_422
• YCbCr

plz close issue

Hi in my irb I'm doing:

dcm = DICOM::DObject.read(dicom_path)

and object is ok initiated. But when I try dcm.image I get false. Please help

I've tried doing a dicom echo from an ultrasound machine but with ruby dicom it fails.

Ruby dicom DServer says:

Connection established with: ::ffff:10.110.192.123 (IP: ::ffff:10.110.192.123)
Accepted all 10 proposed contexts in the association request.
No answer was received within the specified timeout period. Aborting.

what is the alternative method of get_image_pos() in new DICOM

Currently, when dealing with compressed pixel data, these methods for extracting pure pixel values in Array/NArray, only supports extracting data from the first pixel frame. Ideally, these methods should return pixel values from any and all frames.

These methods are located in the ImageItem class.

DServer quietly cancels transmission and never proceeds past line 1490 of link.rb.

https://github.com/dicom/ruby-dicom/blob/master/lib/dicom/link.rb#L1490

message is passed into Stream.new when message is undefined. Changing it to an empty string allowed me to get through those lines and receive files, though I'm seeing some issues that may or may not be related to that change.

Hi, there-

We've run into a bug with using ruby-dicom to parse a DICOM-RT RTSTRUCT file. It seems like SuperParent#value works fine, as long as none of the child elements it's trying to retrieve are themselves parent elements. Take a look at line 473 of SuperParent.rb- it calls .value assuming that the tag it's calling it on is a regular Element. If, however, the contents of @tags[tag] is another SuperParent, it will error out with an ArgumentError:

ArgumentError: wrong number of arguments (0 for 1)
from /Library/Ruby/Gems/1.8/gems/ruby-dicom-0.7.7b/lib/dicom/SuperParent.rb:473:in value' from /Library/Ruby/Gems/1.8/gems/ruby-dicom-0.7.7b/lib/dicom/SuperParent.rb:473:invalue'
from (irb):5

An example of where this fails is on an RTStruct "Referenced Frame of Reference Sequence" (tag id 3006,0010), which contains a whole ton of Items, which in turn contain other sequences, yadda yadda yadda. I could try submitting a patch, but I'm worried that I don't understand the ruby-dicom source well enough and would be afraid of breaking something...

Are there any existing known issues with the DClient 'send' functionality?

I wrote a little script to use send to send the contents of a directory, but I keep getting this result:

INFO -- DICOM: Association successfully negotiated with host PACS
INFO -- DICOM: All 2 presentation contexts were accepted by host PACS
/Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/link.rb:1092:in `send': Broken pipe - send(2) (Errno::EPIPE)
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/link.rb:1092:in `transmit'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:699:in `perform_send'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:697:in `each'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:697:in `perform_send'
        from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:36:in `each_with_index'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:in `each'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:in `each_with_index'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:673:in `perform_send'
        from /Library/Ruby/Gems/1.8/gems/dicom-0.9.2/lib/dicom/d_client.rb:385:in `send'
        from ./dicom_push.rb:31
        from ./dicom_push.rb:28:in `foreach'
        from ./dicom_push.rb:28

A lot of documentation link (also the gem one) refers to rubyforge.org, which has been shut down some months ago.

After some research I've been able to find a copy of all the pages at archive.org.

Was wondering if you can put the documentation somewhere and update the link. Thanks for your work!

I seem to be having some difficulty querying a dcm4chee archive. I am able to associate OK, but when I try something like:

result = node.find_patients("0010,0010" => "PEREZ*")

I get

Your request was accepted by host TRCUSA1 (10.1.0.1).
Error! Something was NOT successful regarding the desired operation. (SCP responded with error code: 49152) (tag: 0000,0900)

I'm not sure why the archive is rejecting my query. Do you have any experience with the dcm4chee archive? Perhaps you could provide with a working example?

Thanks for a great and promising library!

Simon

Currently, in ruby-dicom, when creating a new DICOM object, no matter in which way, we use the #new method. When looking at the code for handling all this cases, I can't help but feel that it is somewhat overloaded, and the code isnt as clean as it could be. I would like to address this by making new class methods to offload the #new method when it comes to creating a new DICOM object in various ways. I will make some suggestions here, but I am definitely open to suggestions so please respond if you have some alterantive suggestions.

Currently, using #new with either string or nil, we can create new (empty) object, read from file, parse a pre-loaded string or even load from html string (experimental).

What I would like in a new implementation is something like the following:

Create new (empty) DICOM object:

obj = DObject.new

Create a new DICOM object which is read from a file:

obj = DObject.read('file.dcm')

Create a new DICOM object which is parsed from a pre-loaded DICOM binary string:

obj = DObject.parse(string)

Create a new DICOM object by retrieving a html link (should we even support this in ruby-dicom?)

obj = DObject.get(hyperlink)

What do you think? Please let me know.
Obviously, if carried out, we will do deprecation warnings for a period to ease the transition. I know I havent been too good with deprecation warnings in the past, but this is such a critical change that it obviously needs to be done.

Regards,
Chris

I am finding that images with this transfer syntax cannot be loaded:

WARN: DICOM: Decompressing pixel values has failed (unsupported transfer syntax: '1.2.840.10008.1.2.4.90' - JPEG 2000 Image Compression (Lossless Only))

Any tips on how to handle this situation?

It is a valid transfer syntax acocrding to: http://www.dicomlibrary.com/dicom/transfer-syntax/

Hi Chris,

First, thanks again for such a handy gem.

My question pertains to the use of :level, :remap, and "presentation state."

I am able to extract the pixel data from a .dcm file, manipulate the image data with Rmagick, and save a file.

I can see you have gone to some effort to provide methods to window and level dicom images. Thanks! ...but, I can't figure out how to get it to work well.

With code like this:

        @dcm=DObject.read(load_path+@sop_uid+".dcm")  <<< A single slice from a CT scan
        [email protected]
        [email protected](:level => [40,350])
        @image_file_name=@sop_uid+".img"
        @dcm.image_to_file(@save_path+@image_file_name)

        z=65535/2
        z=z+1024-128+32
        b=z-(40*1)
        w = z+(310*1)
        image.level(b,w,1).write(@save_path+@sop_uid+".png")  <<< This is close to what I'd like to see
        other_image.write(@save_path+@sop_uid+"_used_level.png")  <<< This yields a black & white image

'image' yields a modality CT image with a window/level that is close to what I would like.
'other_image' yields a modality CT image that is black and white with a majority of pixels clipped from the image as either black or white.

I cloned your repository and tried to look into the use of :remap, but this did not help me get to a place where W/L works. I also tried to see what the implication of "presentation state" was, but this too left me with questions. Sorry. There's definitely a lot of good code there, but I can't see how to best take advantage of it.

Can I use ruby dicom to W/L CT images? Trying something like your example:

images = dcm.images(:level => [-200,1000], :narray => true)

... on the same CT slice gives me a similar black&white result

It is important to me to have W/L functionality that works pretty close to expected. When dealing with CT images, I think about hounsfield units and typically expect zero to equal water. I'd like to make use of typical w/l settings used by radiologist, for instance w=350, l=40 for CT of the abdomen to show soft tissues. It looks like you have anticipated this to some extent with ruby dicom, but I can't figure out how to make good use of your work. I suppose the CR and DR modalities are another matter, but I imagine just normalizing those images will work well for most of my needs. Having specific and semi-accurate ranges for W/L with CT, though, is more important.

Can you clarify/assist?

Many thanks again -

Perry

It will be nice if you can please add the tags after v0.9.3 so we can inspect the code by navigating between versions easier. Thanks

I got this warning when I upgraded to the latest official version of ruby.

/Users/codehugger/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/dicom-0.9.7/lib/dicom/stream.rb:64: warning: constant ::Fixnum is deprecated

I have an rtstruct here created using the vtk/GDCM struct creator.

here are the tags dumped by gdcmdump:
...
(0018,1210) ?? (SH) [B ] # 2,1-n Convolution Kernel
(0020,000d) ?? (UI) [1.2.840.113704.1.111.3004.1275394732.3] # 38,1 Study Instance UID
(0020,000e) ?? (UI) [1.2.826.0.1.3680043.2.1143.5394333734055242796133715399006083446] # 64,1 Series Instance UID
(0020,0010) ?? (SH) [12604 ] # 6,1 Study ID

however, when I run ruby dicom (version 0.9.1, from building ruby 1.9.2 p290 from source, and then sudo ruby gem install dicom), when I run from the command line, i get:

irb(main):024:0> obj = DObject.new("/home/mvs/processing/tmp/13159598488848/RTStructFinished.dcm");0
irb(main):021:0> obj.exists?("0018,1210")
=> true
irb(main):022:0> obj.exists?("0020,000d")
=> false
irb(main):023:0> obj.exists?("0020,000e")
=> false

Being able to read the series and study UIDs used to be working. Should I be doing something special for those tags?

65 files inspected, 7774 offenses detected

at a glance all of them appear to just be cosmetic.

Did you thought about adding Logger from ruby's std library?
I see there are add_error and add_notice with the same implementation in DServer, DClient and Link.

Maybe we can change it to more customizable version using Logger?

Hi Chris,

I've come across some dicom files that appear to be structured reports, "which are used for transmission and storage of clinical documents" inside dicom files. It looks like the latest version of Ruby-Dicom is not happy with them. Is there any support planned for this? Should we fork it and try to add some? I'm especially interested in using the anonymizer with them.

Thanks for all your work on this already,

Jen

The SR is included in Supplement 23 of the dicom standard: (ftp://medical.nema.org/medical/dicom/2009/final/supp23_ft.pdf)

Found this problem while trying to deploy within an app via Heroku:

installing dicom (0.9.3)
       Gem::InstallError: dicom requires RubyGems version >= 1.8.6. Try 'gem update --system' to update RubyGems itself.
       An error occurred while installing dicom (0.9.3), and Bundler cannot continue.
       Make sure that `gem install dicom -v '0.9.3'` succeeds before bundling.
 !
 !     Failed to install gems via Bundler.
 !
 !     Heroku push rejected, failed to compile Ruby/rails app

Seems like an issue with the Heroku configuration (I've opened a ticket with them), but thought I'd raise it here, too, in case anybody has encountered it before and knows a quick fix.

I'm trying to make a dicom out of a png file (png file is the image of an ECG reading).
I'm not having much luck, is there somekind of a tutorial / example for creating new dicoms from existing images ?

here's my code :

    include DICOM
    include Magick

    dcm = DObject.new
    dcm.photometric_interpretation = "MONOCHROME2"
    dcm.bits_allocated = 8
    dcm.pixel_representation = 0
    dcm.patients_name = "My Name"
    dcm.patient_id = "some_id"
    dcm.study_id = "some_id"
    dcm.study_date =  Time.now.strftime "%Y%m%d"
    dcm.study_instance_uid ="some_id"
    dcm.series_instance_uid = "some_id"
    dcm.sop_class_uid = "some_id"
    dcm.media_storage_sop_class_uid = "some_id"
    dcm.image =  ImageList.new("db/samples/ecg/19.ecg.png").first

    dcm.write "sample.dcm"

The resulting file is a dicom file with all the information I provided, with a size of 2 MBs. (orginal png is like 84 KBs)

=> db/samples/ecg/19.ecg.png PNG 1651x1275 1651x1275+0+0 DirectClass 8-bit 83kb

is there any obvious mistakes I am doing ?

There is an issue with the way the ruby-dicom 0.8 transmits DICOM files which has a compressed transfer syntax. If the server prefers an uncompressed transfer syntax, ruby dicom's DClient will transfer an invalid DICOM file. This should hopefully be fixed in time for the next planned gem release.

Workaround:
Either use ruby dicom version 0.7 for transmitting such files, or set the transfer_syntax accessor of your DClient instance to an array containing only the transfer syntax of the particular dicom file you are transmitting.

DICOM files which has a 'normal' (uncompressed) transfer syntax should not be affected by this bug.

Im probably going to embark on a rewrite of the DObject class where I will significantly change the way Data Elements are handled.

There are two motivations for this change. One is that the DObject class feels somewhat messy, I believe it could be cleaner than it is today. The most important factor though is speed. Lately I've tried manipulating a type of DICOM file that holds a huge amount of Data Elements (~30.000!), and Ruby DICOM unfortunately performs quite slow when manipulating these files. The cause is that the array based approach used by Ruby DICOM doesnt scale very well with increasing number of Data Elements because array indexing gets expensive.

This may result in pretty significant changes, meaning different syntax for the way we interact with Data Elements in the DICOM object. In that regard, I would like to get feedback from anyone who has any thoughts on how you would really like to interact with the DICOM object. What would be an ideal syntax in your view? What would be a more Ruby-like way of handling things than are done today?

As for the back-end stuff: Basically what I would like to do is move from an array collections to hash collections to get faster indexing. Im also thinking about implementing a new Data Element class which hopefully can help clean up the code.

As this will be a pretty significant rewrite and seriously break stuff while it's ongoing, I will do this in a separate branch. The DObject class is the main target of the rewrite, but the DRead and DWrite classes will be affected too, and perhaps to some lesser degree DLibrary. The networking code should remain unaffected.

Any input will be appreciated. If this project succeeds then this will probably be the major change for the next version (0.8) of Ruby DICOM.

Hey Christoffer,

with the latest release (0.9.7) of ruby-dicom under Ruby 2.4 I get this warning:

warning: constant ::Fixnum is deprecated

I found out that the issue is already fixed in master branch.
Could you please release an update (RubyGem)?

Thanks,
Björn

Currently, the ruby-dicom library is only able to handle a small subset of the compressed transfer syntaxes allowed in the DICOM standard. For Run Length Encoding, we have a straight ruby implementation, and for jpg encoded image data, we try to use RMagick to decode the images. This works fine for some of the 'simpler' jpg variants, however, surprisingly enough, it seems that RMagick (in reality ImageMagick) is not able to handle all of the JPG variants. For example the following 3 variants have been shown to fail:

• 1.2.840.10008.1.2.4.57 - JPEG Lossless, Non-Hierarchical (Process 14)
• 1.2.840.10008.1.2.4.70 - JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression
• 1.2.840.10008.1.2.4.90 - JPEG 2000 Image Compression (Lossless Only)

It would be awesome if ruby-dicom were able to decompress the pixel data in all DICOM files, no matter the compression algorithm used. What would be a good way to achieve this?

Look at how other open source libraries, e.g. GDCM, dcmtk, etc do it?

Use an alternative JPEG library? Some time ago I briefly checked out the PVRG-JPEG library, which seems to handle everything that is jpeg. It exists in the Ubuntu repositories, where it can be installed and run through terminal. For source code, and some additional information, check out this link:
http://www.panix.com/~eli/jpeg/

Any suggestions, or even better yet, code contributions, are welcome!

We should look into the possibility of using EventMachine as the architecture for DServer. We will write less code, and this will be faster and more stable.

Trying to get the RLE images from a dicom export. Here is a sample .dcm that was sent through and saved via DServer.
image_2814918156667436.dcm.zip

Can't figure out how to get anything but the thumbnail image (3x3 image grid).

Maybe this method needs to do something different?

Here is my dcm.summary
System Properties:
Ruby DICOM version: 0.9.8
Byte Order (CPU): Little Endian

DICOM Object Properties:
Source: File (successfully read): tmp/image_2814918156667436.dcm
Modality: Ultrasound Image Storage
Meta Header: Yes
Value Representation: Explicit
Byte Order (File): Little Endian
Pixel Data: Yes
Image Size: 1024768
Number of frames: 1
Photometry: RGB
Compression: RLE Lossless
Bits per Pixel: 8
=> ["Source: File (successfully read): tmp/image_2814918156667436.dcm", "Modality: Ultrasound Image Storage", "Meta Header: Yes", "Value Representation: Explicit", "Byte Order (File): Little Endian", "Pixel Data: Yes", "Image Size: 1024768", "Number of frames: 1", "Photometry: RGB", "Compression: RLE Lossless", "Bits per Pixel: 8"]

I am having a problem when retrieving the Study Instance UID (0020,000D) even though print_all shows it is present. This doesn't happen on all DICOM images, only some. I haven't been able to pinpoint what difference there is in the images, but all images have the Study Instance UID.

This works correctly in 0.4.

This can be reproduced using the following Dockerfile (Ruby version is 2.2.6 as it is the latest current 2.2.x version):

FROM ruby:2.2.6
RUN git clone https://github.com/dicom/ruby-dicom.git /usr/dicom/ruby-dicom
WORKDIR /usr/dicom/ruby-dicom
RUN bundle install
RUN bundle exec rake spec
CMD ["/bin/bash"]

I notice that there is some "DICOM" printouts during the specs. Perhaps these are from the logger leaking through to stdout and causing some of the failures? To reproduce the failures, from the directory this Dockerfile is run the following:

➜  ruby-dicom git:(master) ✗ docker build -t ruby_dicom_test .
Sending build context to Docker daemon  9.95 MB
Step 1/6 : FROM ruby:2.2.6
 ---> 7cb10de60b6b
Step 2/6 : RUN git clone https://github.com/dicom/ruby-dicom.git /usr/dicom/ruby-dicom
 ---> Using cache
 ---> 83a938ca8131
Step 3/6 : WORKDIR /usr/dicom/ruby-dicom
 ---> Using cache
 ---> c32b8f486924
Step 4/6 : RUN bundle install
 ---> Using cache
 ---> 9c85e18ebd1e
Step 5/6 : RUN bundle exec rake spec
 ---> Running in 0debad06185e
/usr/local/bin/ruby -I/usr/local/bundle/gems/rspec-core-3.5.4/lib:/usr/local/bundle/gems/rspec-support-3.5.0/lib /usr/local/bundle/gems/rspec-core-3.5.4/exe/rspec --pattern spec/\*\*/\*_spec.rb -c -f progress -r ./spec/spec_helper.rb
........................................................................................................................................................DICOM
DICOM
DICOM
F....................................................................................................................................F.............................................................................DICOM
DICOM
DICOM
DICOM
F.........................................................................................................................................................................................................................................................................F......F...............F............................................................................................................FFF.................FFF.....................................................................................................................................

Failures:

  1) DICOM::DObject::parse should register one or more errors/warnings/debugs in the log when failing to successfully parse a DICOM string
     Failure/Error: DICOM.logger.expects(:warn).at_least_once

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected at least once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x3b97870>.warn(any_parameters)
       satisfied expectations:
       - expected at least once, invoked once: #<DICOM::Logging::ClassMethods::ProxyLogger:0x3b97870>.error(any_parameters)
       - expected at least once, invoked once: #<DICOM::Logging::ClassMethods::ProxyLogger:0x3b97870>.debug(any_parameters)
     # ./spec/dicom/d_object_spec.rb:87:in `block (3 levels) in <module:DICOM>'

  2) DICOM::load should return an array containing the expected DObject instances when given a directory (with sub-directories) which contains multiple DICOM files
     Failure/Error: expect(ary).to eql [DObject.read(DCM_ISO8859_1), DObject.read(DCM_AT_NO_VALUE)]

       expected: [{"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP..., "Bits Stored"=>16, "High Bit"=>15, "Pixel Representation"=>0, "Grid Frame Offset Vector"=>"0.00"}]
            got: [{"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP...me"=>"TEST", "Manufacturer's Model Name"=>"\u00D5nc\u00EAntr\u00E5 M\u00E6st\u00F8rPl\u00E0\u00F1"}]

       (compared using eql?)

       Diff:
       @@ -1,3 +1,3 @@
       -[{"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "Media Storage SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Transfer Syntax UID"=>"1.2.840.10008.1.2.1", "Implementation Class UID"=>"1.2.250.1.59.3.0.3.3.1", "Implementation Version Name"=>"eFilm/efDICOM", "Source Application Entity Title"=>nil, "Group Length"=>166, "Specific Character Set"=>"ISO_IR 100", "SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Station Name"=>"TEST", "Manufacturer's Model Name"=>"\u00D5nc\u00EAntr\u00E5 M\u00E6st\u00F8rPl\u00E0\u00F1"},
       - {"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "Media Storage SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Transfer Syntax UID"=>"1.2.840.10008.1.2.1", "Implementation Class UID"=>"1.2.250.1.59.3.0.3.3.1", "Implementation Version Name"=>"eFilm/efDICOM", "Source Application Entity Title"=>nil, "Group Length"=>12, "Specific Character Set"=>"ISO_IR 100", "Image Type"=>"ORIGINAL\\PRIMARY\\DOSE", "Instance Creation Date"=>"20080222", "Instance Creation Time"=>"105924", "SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Study Date"=>"20040707", "Content Date"=>"20080222", "Study Time"=>"093105.00", "Content Time"=>"105924", "Accession Number"=>nil, "Modality"=>"RTDOSE", "Manufacturer"=>"Nucletron", "Referring Physician's Name"=>nil, "Timezone Offset From UTC"=>"+0100", "Station Name"=>"TheStation", "Study Description"=>"Helax-TMS generated study", "Institutional Department Name"=>"DoseInc", "Manufacturer's Model Name"=>"Oncentra MasterPlan", "Samples per Pixel"=>1, "Photometric Interpretation"=>"MONOCHROME2", "Number of Frames"=>"126", "Frame Increment Pointer"=>nil, "Rows"=>6, "Columns"=>82, "Pixel Spacing"=>"2.000000\\2.000000", "Bits Allocated"=>16, "Bits Stored"=>16, "High Bit"=>15, "Pixel Representation"=>0, "Grid Frame Offset Vector"=>"0.00"}]
       +[{"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "Media Storage SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Transfer Syntax UID"=>"1.2.840.10008.1.2.1", "Implementation Class UID"=>"1.2.250.1.59.3.0.3.3.1", "Implementation Version Name"=>"eFilm/efDICOM", "Source Application Entity Title"=>nil, "Group Length"=>12, "Specific Character Set"=>"ISO_IR 100", "Image Type"=>"ORIGINAL\\PRIMARY\\DOSE", "Instance Creation Date"=>"20080222", "Instance Creation Time"=>"105924", "SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Study Date"=>"20040707", "Content Date"=>"20080222", "Study Time"=>"093105.00", "Content Time"=>"105924", "Accession Number"=>nil, "Modality"=>"RTDOSE", "Manufacturer"=>"Nucletron", "Referring Physician's Name"=>nil, "Timezone Offset From UTC"=>"+0100", "Station Name"=>"TheStation", "Study Description"=>"Helax-TMS generated study", "Institutional Department Name"=>"DoseInc", "Manufacturer's Model Name"=>"Oncentra MasterPlan", "Samples per Pixel"=>1, "Photometric Interpretation"=>"MONOCHROME2", "Number of Frames"=>"126", "Frame Increment Pointer"=>nil, "Rows"=>6, "Columns"=>82, "Pixel Spacing"=>"2.000000\\2.000000", "Bits Allocated"=>16, "Bits Stored"=>16, "High Bit"=>15, "Pixel Representation"=>0, "Grid Frame Offset Vector"=>"0.00"},
       + {"File Meta Information Group Length"=>210, "File Meta Information Version"=>nil, "Media Storage SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "Media Storage SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Transfer Syntax UID"=>"1.2.840.10008.1.2.1", "Implementation Class UID"=>"1.2.250.1.59.3.0.3.3.1", "Implementation Version Name"=>"eFilm/efDICOM", "Source Application Entity Title"=>nil, "Group Length"=>166, "Specific Character Set"=>"ISO_IR 100", "SOP Class UID"=>"1.2.840.10008.5.1.4.1.1.481.2", "SOP Instance UID"=>"1.3.6.1.4.1.2452.6.164597922.1249989320.2326663826.3216872486", "Station Name"=>"TEST", "Manufacturer's Model Name"=>"\u00D5nc\u00EAntr\u00E5 M\u00E6st\u00F8rPl\u00E0\u00F1"}]
     # ./spec/dicom/dicom_spec.rb:127:in `block (3 levels) in <module:DICOM>'

  3) DICOM::DObject::read should log a warning when encountering duplicate elements
     Failure/Error: DICOM.logger.expects(:warn).at_least_once

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected at least once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x40c2548>.warn(any_parameters)
       satisfied expectations:
       - allowed any number of times, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x40c2548>.error(any_parameters)
       - allowed any number of times, invoked once: #<DICOM::Logging::ClassMethods::ProxyLogger:0x40c2548>.info(any_parameters)
       - allowed any number of times, invoked once: #<DICOM::Logging::ClassMethods::ProxyLogger:0x40c2548>.debug(any_parameters)
     # ./spec/dicom/duplicate_elements_spec.rb:47:in `block (3 levels) in <module:DICOM>'

  4) With :mini_magick as image processor DICOM::ImageItem#image should log a warning when it fails to decompress compressed pixel data
     Failure/Error: DICOM.logger.expects(:warn)

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x2dff2d0>.warn(any_parameters)
     # ./spec/dicom/image_minimagick_spec.rb:22:in `block (4 levels) in <module:DICOM>'

  5) With :rmagick as image processor DICOM::ImageItem#image should log a warning when it fails to decompress compressed pixel data
     Failure/Error: DICOM.logger.expects(:warn)

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x2dff2d0>.warn(any_parameters)
     # ./spec/dicom/image_rmagick_spec.rb:27:in `block (4 levels) in <module:DICOM>'

  6) With :rmagick as image processor DICOM::ImageItem#images should decompress the JPEG2K encoded multiframe pixel data of this DICOM file and return the image objects in an array
     Failure/Error: expect(images.length).to eql 8

       expected: 8
            got: 0

       (compared using eql?)
     # ./spec/dicom/image_rmagick_spec.rb:147:in `block (4 levels) in <module:DICOM>'

  7) DICOM::Parent#delete should log a warning when the argument is not a string or integer
     Failure/Error: DICOM.logger.expects(:warn).once

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
     # ./spec/dicom/parent_spec.rb:482:in `block (3 levels) in <module:DICOM>'

  8) DICOM::Parent#delete should log a warning when the argument is not a valid tag
     Failure/Error: DICOM.logger.expects(:warn).once

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
     # ./spec/dicom/parent_spec.rb:487:in `block (3 levels) in <module:DICOM>'

  9) DICOM::Parent#delete should log a warning when the argument is a negative integer
     Failure/Error: DICOM.logger.expects(:warn).once

     Mocha::ExpectationError:
       not all expectations were satisfied
       unsatisfied expectations:
       - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
     # ./spec/dicom/parent_spec.rb:492:in `block (3 levels) in <module:DICOM>'

  10) DICOM::Parent#value should log a warning when the argument is not a string or integer
      Failure/Error: DICOM.logger.expects(:warn).once

      Mocha::ExpectationError:
        not all expectations were satisfied
        unsatisfied expectations:
        - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
      # ./spec/dicom/parent_spec.rb:668:in `block (3 levels) in <module:DICOM>'

  11) DICOM::Parent#value should log a warning when the argument is not a valid tag
      Failure/Error: DICOM.logger.expects(:warn).once

      Mocha::ExpectationError:
        not all expectations were satisfied
        unsatisfied expectations:
        - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
      # ./spec/dicom/parent_spec.rb:673:in `block (3 levels) in <module:DICOM>'

  12) DICOM::Parent#value should log a warning when the argument is a negative integer
      Failure/Error: DICOM.logger.expects(:warn).once

      Mocha::ExpectationError:
        not all expectations were satisfied
        unsatisfied expectations:
        - expected exactly once, not yet invoked: #<DICOM::Logging::ClassMethods::ProxyLogger:0x28e3e68>.warn(any_parameters)
      # ./spec/dicom/parent_spec.rb:678:in `block (3 levels) in <module:DICOM>'

Finished in 12.49 seconds (files took 1.19 seconds to load)
917 examples, 12 failures

Failed examples:

rspec ./spec/dicom/d_object_spec.rb:85 # DICOM::DObject::parse should register one or more errors/warnings/debugs in the log when failing to successfully parse a DICOM string
rspec ./spec/dicom/dicom_spec.rb:119 # DICOM::load should return an array containing the expected DObject instances when given a directory (with sub-directories) which contains multiple DICOM files
rspec ./spec/dicom/duplicate_elements_spec.rb:45 # DICOM::DObject::read should log a warning when encountering duplicate elements
rspec ./spec/dicom/image_minimagick_spec.rb:20 # With :mini_magick as image processor DICOM::ImageItem#image should log a warning when it fails to decompress compressed pixel data
rspec ./spec/dicom/image_rmagick_spec.rb:25 # With :rmagick as image processor DICOM::ImageItem#image should log a warning when it fails to decompress compressed pixel data
rspec ./spec/dicom/image_rmagick_spec.rb:143 # With :rmagick as image processor DICOM::ImageItem#images should decompress the JPEG2K encoded multiframe pixel data of this DICOM file and return the image objects in an array
rspec ./spec/dicom/parent_spec.rb:481 # DICOM::Parent#delete should log a warning when the argument is not a string or integer
rspec ./spec/dicom/parent_spec.rb:486 # DICOM::Parent#delete should log a warning when the argument is not a valid tag
rspec ./spec/dicom/parent_spec.rb:491 # DICOM::Parent#delete should log a warning when the argument is a negative integer
rspec ./spec/dicom/parent_spec.rb:667 # DICOM::Parent#value should log a warning when the argument is not a string or integer
rspec ./spec/dicom/parent_spec.rb:672 # DICOM::Parent#value should log a warning when the argument is not a valid tag
rspec ./spec/dicom/parent_spec.rb:677 # DICOM::Parent#value should log a warning when the argument is a negative integer

/usr/local/bin/ruby -I/usr/local/bundle/gems/rspec-core-3.5.4/lib:/usr/local/bundle/gems/rspec-support-3.5.0/lib /usr/local/bundle/gems/rspec-core-3.5.4/exe/rspec --pattern spec/\*\*/\*_spec.rb -c -f progress -r ./spec/spec_helper.rb failed
The command '/bin/sh -c bundle exec rake spec' returned a non-zero code: 1

why this method not working in the new version of DICOM

dcm.value('0018,6018', :array => true)

in the last version we write like this dcm.get_value('0018,6018', :array => true)
but in the new version dcm.value('0018,6018', :array => true)
not working

I use OsiriX(http://www.osirix-viewer.com/) to see DICOM files.
After I did simple annonymization described in tutorials to a DICOM file, image data does not appear on OsiriX.
I found that it is because "Transfer Syntax UID"(0002,0010) tags are removed, so I could fix the problem by skipping that process by overriding DICOM::Parent#delete_group method like the sample source below.
I am new to this medical industry, so not sure if this is a bug or not, but I want to send this feedback, so opened this issue.

require 'dicom'

module DICOM
  class Parent
    def delete_group(group_string)
      group_elements = group(group_string)
      group_elements.each do |element|
        next if element.tag == '0002,0010'
        delete(element.tag)
      end
    end
  end
end

dcm = DICOM::DObject.read('sensitive.dcm')
dcm.anonymize
dcm.write('clean.dcm')

Needs some work for ruby 1.9 compatibility.

Recently, the 2011 edition of the DICOM Standard was released. See David Clunie's announcement here:
https://groups.google.com/forum/#!topic/comp.protocols.dicom/Nzd5Pi0On4U

The actual files can be found here:
ftp://medical.nema.org/medical/dicom/2011/

It would be nice to update our dictionary to this new 2011 edition. In the past, I have done this semi-manually, copying the contents of the relevant section of the pdf, cleaning it up somewhat, and running a script to convert it to our actual dictionary.rb code. This involves some tedious work however, and it would be nice to fully automate it, making it a two step process of just downloading the latest edition and running a script to produce the new dictionary.

If anyone would be interested in having a go at this, that would be excellent!
Link to the dictionary part of the standard:
PDF:
ftp://medical.nema.org/medical/dicom/2011/11_06pu.pdf
Word document:
ftp://medical.nema.org/medical/dicom/2011/11_06pu.doc

Currently, there are three columns of the data dictionary we are not using in ruby-dicom: Keyword, VM, and Retired?. It would be nice to include information on whether or not a particular tag is retired, as this would enable us to make a convenience method remove_retired, similar to the existing remove_private method.

Regards,
Chris

Historically, ruby-dicom has had RMagick image methods integrated, for easy extraction and insertion of images from/to DICOM objects. However, not everyone is too happy with RMagick. It is resource intensive, it is not actively maintained any more, and it is a hassle to install on Windows.

Ideally, ruby-dicom should be able to utilize any image library for exporting/importing images. Therefore, I have started work to introduce the concept of image processors. After requiring ruby-dicom, the user may select which of the supported image libraries he wishes be used by the buildt in image methods. This has the advantage of making ruby-dicom even more modular and accessible, but another positive side effect is that I believe the image code will become cleaner.

As a starting point, RMagick and mini_magick will be the supported image processors.

The "tags" member of DObject and DRead seem to be invalid in the latest commit. Was "labels" replaced by "tags" in these objects? Is there a hash that hold the names and values paired together?

I've created my own branch and started working on rdoc. I've added rdoc to rake file so we can start to generate the rdoc.

I have noticed that when performing the following type of query against dcm4chee.

results = node.find_studies("0020,000D" => params[:studyUID], "0008,1030"=>"")
or
results = node.find_series("0020,000D" => params[:studyUID], "0008,103E"=>"")

that it takes usually at least 10 seconds, and up to 30 seconds. Sometimes it times out and returns nil.

When I downgraded to Ruby 1.8.7 and dicom 0.9.1 the problem went away.

Only 50MB's file is uploading but larger files are not uploading.

I am using this code

let fileUploaded = Async.runSync(function(done) { 
    let url =  `curl -X POST http://localhost/peers/peer2/store -d *********************`;
    console.log(url);
    new Fiber(function() {
    childProcess.exec(url, function (error, stdout, stderr) {
         if (error) {
		      	done(error);
		    } else {
		       	done(null, 'File uploded')
		    }
	});
   }).run();
});

If you test the file using for example dcm2xml (from dcm4che tools package) you'll get:

20:12:19,029 WARN - Missing or wrong (0002,0000) Group Length of File Meta Information

Even if I try obj.add DataElement.new('0002,0000',188, :vr => 'UL')
and then write the object it still seems to be missing.

This is when reading a file using ruby dicom and then writing it to disk again with no modifications.
The original file doesn't exhibit this behavior, so it is something that ruby dicom does or doesnt do. (This is from branch master 0.7.7b)

Ruby DICOM fails reading files, which have more data after a pixel data sequence. As far as I know storing additional tags after the pixel data is not recommend by the DICOM standard but not prohibited. In fact GE cardiac ultrasound systems does it for private data.

@dicom : I am working on getting you some example data. I have to clarify, if I can share it. Anyway, it is too big to simple put it into the repository.

I have a fix already 95e4c11. On the one hand can you have a look at my change on the other hand can you point me to where I can add a test for the change?

That's the only log I am getting.

SystemStackError (stack level too deep): dicom (0.9.6) lib/dicom/general/logging.rb:148

Ruby 1.9.3
dicom 0.9.6
Ubuntu 16.04.3

In the previous gem release, complete rdoc documentation was one of the big news. For the next gem release, one of the goals is to have implemented a full specification for ruby-dicom. It is somewhat boring work, but it has to be done in order to mature the ruby-dicom library further and ensure that it behaves as intended and is free of bugs. Ruby-dicom uses Rspec 2 and mocha for its test suite/specification.

Hi all,
I'm getting a: NoMethodError: undefined method `to_json' for #Hash:0x007fd7a83fa1b0

When trying to convert a DObject to json. using dcm.to_json

.to_hash method works correctly.

The object was derived from reading a DICOM Enhanced MR Multiframe file.