Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Sun, 2018-02-25, 10:47

All times are UTC + 1 hour

Search found 1213 matches
Search these results:

Author Message

 Forum: DCMTK - General   Topic: dcmj2pnm: RLE Lossless problem with US Singleframe Image

Posted: Mon, 2018-02-19, 15:52 

Replies: 6
Views: 77

No, I don't think so. The error is somewhere in the middle of the RLE bytestream, and I cannot imagine any network receiver or CD/DVD burning tool to mess with this at this low level. My best guess is that the invalid RLE bytestream comes directly from the modality. The easiest way of avoiding that ...

 Forum: DCMTK - General   Topic: Open SSL Cipher Suites

 Post subject: Re: Open SSL Cipher Suites
Posted: Mon, 2018-02-19, 15:48 

Replies: 10
Views: 170

Well, at this point you'll probably have to check things with the debugger. I noticed that the new cipher suites you refer to are TLSv1.2 suites. You should probably check which TLS version is proposed by the client, and which version(s) the server is willing to accept. The error code "unspecif...

 Forum: DCMTK - General   Topic: dcmj2pnm: RLE Lossless problem with US Singleframe Image

Posted: Sun, 2018-02-18, 12:19 

Replies: 6
Views: 77

Thanks for the sample image. The patch you refer is indeed in the code, but does not help here. The workaround to fill in the last missing pixels with the value of the last pixel only works at the very end of the pixel data element, i.e. if the pixel data element is for some reason truncated. In thi...

 Forum: DCMTK - General   Topic: Open SSL Cipher Suites

 Post subject: Re: Open SSL Cipher Suites
Posted: Tue, 2018-02-13, 10:24 

Replies: 10
Views: 170

In order to add support for a specific TLS ciphersuite in DCMTK, you have to do the following: ⋅  Make sure that the ciphersuite is supported in the OpenSSL library you compile against (e.g. OpenSSL 1.1.0 needs to be compiled with specific flags to enable 3DES) ⋅  Add the ciphers...

 Forum: DCMTK - General   Topic: Issue related to FAQ: cannot change to unencapsulated repres

Posted: Tue, 2017-12-19, 17:18 

Replies: 11
Views: 493

To my knowledge, the "Se" parameter is used for spectral selection in progressive, lossy JPEG and should never be != 0 in a lossless JPEG bitstream. So this really looks like an invalid JPEG bitstream. Viewers that can successfully open it might either internally use the defective codec th...

 Forum: DCMTK - FAQ   Topic: FAQ #49: DCMTK for other languages than C++?

Posted: Mon, 2017-11-13, 09:38 

Replies: 0
Views: 412

:?: Is DCMTK available in other programming languages than C++? :!: No, we do not offer any other version of DCMTK. If you need an open source DICOM library for other programming languages/environments, you will have to look elsewhere. Some possible alternatives are: ⋅  Java: DCM4CHE Toolk...

 Forum: DCMTK - Installation   Topic: DCMTK on visual studio 2017 with ssl

Posted: Fri, 2017-11-03, 09:36 

Replies: 15
Views: 2302

The following post https://www.openssl.org/blog/blog/2016/08/24/sweet32/ explains the issue: Starting with OpenSSL 1.1.0, support for the 3DES ciphers is disabled by default. OpenSSL has to be configured with the “enable-weak-ssl-ciphers” option before compiling to re-active 3DES support. I guess we...

 Forum: DCMTK - General   Topic: dcmj2pnm segfault with large multiframe US

Posted: Thu, 2017-09-28, 14:15 

Replies: 20
Views: 2397

The bug has been registered in our bug tracker as issue #793: http://support.dcmtk.org/redmine/issues/793

 Forum: DCMTK - General   Topic: dcmj2pnm segfault with large multiframe US

Posted: Thu, 2017-09-28, 14:05 

Replies: 20
Views: 2397

It seems that you have found a bug in DCMTK here. The sample image you sent cannot be converted to an uncompressed DICOM format because the pixel data would be larger than 4 GBytes (1802 frames, 1280x960, RGB results in ca. 6.3 GBytes uncompressed). The dcmj2pnm tool is not too clever when it comes ...

 Forum: DCMTK - General   Topic: improving DIMSE_createFilestream

Posted: Mon, 2017-09-25, 16:48 

Replies: 1
Views: 211

Thanks for the suggestion. I have put that as a feature request http://support.dcmtk.org/redmine/issues/791 into our bugtracker.
However, this will not likely be implemented soon.

 Forum: DCMTK - General   Topic: Error while writing private tags in DcmDataset

Posted: Fri, 2017-08-18, 15:19 

Replies: 2
Views: 570

Lookup of Value Representations based on a private creator is not active when you create a dataset.
You have to include the VR explicitly in your call to putAndInsertString, just as you do here:
putAndInsertString(DcmTag(0x0029, 0x0010,EVR_LO), "mycomp")

 Forum: Other DICOM Tools   Topic: having trouble decoding an image with dcmdjp2k

Posted: Tue, 2017-08-15, 10:54 

Replies: 1
Views: 434

The dcmdjp2k tool is part of the DCMJP2K library, which is indeed a licensed product that extends DCMTK with JPEG 2000 support. The latest version is 3.6.2 (just as for the toolkit), but I don't think that any change to the JPEG 2000 decoder has taken place since the release mentioned in your post. ...

 Forum: DCMTK - General   Topic: Image displays white-out

Posted: Tue, 2017-08-15, 10:47 

Replies: 1
Views: 323

The image has a contrast depth of 16 bit/pixel (BitsStored = 16). A Windows DIB only offers 8 bit/pixel monochrome, so a reduction takes place during the conversion. You have to apply the VOI LUT transformation (e.g. based on the parameters Window Center and Window Width encoded in the image) to get...

 Forum: DCMTK - General   Topic: JPEG Lossless compression with bit-depth=12 possible?

Posted: Tue, 2017-08-15, 10:43 

Replies: 3
Views: 531

The bit depth is encoded in the JPEG bitstream, so the decoder can (and has to) determine from there what to do. Since the process you are referring to is lossless, In both cases the pixel data will be compressed without modification. With regard to the fact that DCMTK selects the 16 bit process in ...

 Forum: DCMTK - General   Topic: Issue with constructing cine loop from still images

Posted: Fri, 2017-07-28, 11:30 

Replies: 1
Views: 363

Perhaps your second frame image contains trailing "garbage" bytes at the end of the pixel data element, which would cause the effect you describe. You should perhaps compare the size of the PixelData element with the expected size (Rows * Columns * (BitsAllocated+7)/8). If the real size is...
Sort by:  
Page 1 of 81 [ Search found 1213 matches ]

All times are UTC + 1 hour

Jump to:  
Powered by phpBB® Forum Software © phpBB Group