Thanks Jörg - that was fast!
- Andreas
Search found 24 matches
- Mon, 2016-02-01, 12:58
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
- Mon, 2016-02-01, 08:07
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
Re: dcmmkdir crash under Windows 8 32 bit (SOLVED)
You are welcome
Maybe it makes sense to incorporate this trivial fix into the trunk now, with Windows 10 out in the wild? Michael, Jörg, anyone?
Maybe it makes sense to incorporate this trivial fix into the trunk now, with Windows 10 out in the wild? Michael, Jörg, anyone?
- Thu, 2015-08-13, 17:01
- Forum: DCMTK - General
- Topic: storescu fails to convert private pixel data
- Replies: 2
- Views: 14727
Re: storescu fails to convert private pixel data
Ah, thanks - I did not see this part.
And yes, we use ON_THE_FLY_COMPRESSION. If we send the data without compression there are no problems.
Thanks,
Andreas
And yes, we use ON_THE_FLY_COMPRESSION. If we send the data without compression there are no problems.
Thanks,
Andreas
- Wed, 2015-08-12, 13:50
- Forum: DCMTK - General
- Topic: storescu fails to convert private pixel data
- Replies: 2
- Views: 14727
storescu fails to convert private pixel data
Hi, We have some data sets that storescu tries to convert to JPEG lossless as requested by the receiver, but fails due to some private sequence. The private sequence contains all tags needed to calculate the pixel data length, and a pixel data tag which contains much less data then expected, so the ...
- Wed, 2015-08-12, 12:17
- Forum: Other DICOM Tools
- Topic: storescu crash with large JPEG Baseline coded dataset
- Replies: 4
- Views: 12424
Re: storescu crash with large JPEG Baseline coded dataset
I agree - I just didn't want to integrate the size_t changes into our 3.6.0 version at the moment. The check will be needed anyway for 32 bit platforms because size_t is still 32 bit there and the crash would occur anyway. On 64 bit platforms, the check will always succeed with the site_t approach, ...
- Wed, 2015-08-12, 08:42
- Forum: Other DICOM Tools
- Topic: storescu crash with large JPEG Baseline coded dataset
- Replies: 4
- Views: 12424
Re: storescu crash with large JPEG Baseline coded dataset
The following prevents the crash (this is for the 3.6.0. version): Index: djcodecd.cc =================================================================== --- djcodecd.cc (revision 5186) +++ djcodecd.cc (working copy) @@ -152,21 +152,26 @@ { Uint32 frameSize = ((precision > 8) ? sizeof(Uint16) : size...
- Wed, 2015-08-12, 07:35
- Forum: Other DICOM Tools
- Topic: storescu crash with large JPEG Baseline coded dataset
- Replies: 4
- Views: 12424
Re: storescu crash with large JPEG Baseline coded dataset
Ok, just looked into it a little more - the uncompressed size of the data set is more than 4GB, so it causes an integer overflow in the uncompressed size calculation in DJCodecDecoder::decode(). Thus the allocated memory for the decompressed data is too small, and the crash happens later in memcpy()...
- Tue, 2015-08-11, 16:38
- Forum: Other DICOM Tools
- Topic: storescu crash with large JPEG Baseline coded dataset
- Replies: 4
- Views: 12424
storescu crash with large JPEG Baseline coded dataset
Hi, we use storescu 3.6.0 compiled with ON_THE_FLY_COMPRESSION under Windows 64 bit. With some specific large data sets (UltrasoundMultiframeImageStorage) encoded as JPEGBaseline (800x600 with over 3000 frames) storescu crashes during image decoding - looks like an access violation in memcpy(). Is t...
- Wed, 2015-07-22, 12:16
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
Re: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Hi again, I did not understand the real problem, but at least I could fix it. There is a call to SnmpExtensionQuery() in dcuid.cc that returns the number of available network adaptors. This call seems to be taken from example code (see http://tangentsoft.net/wskfaq/examples/getmac-snmp.html) where i...
- Tue, 2015-07-21, 09:03
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
Re: dcmmkdir crash under Windows 8 32 bit
Another note - as we do have a testing system (though not a developer system), is there anything we can try to help to understand the issue? Any log files that could help?
- Tue, 2015-07-21, 08:51
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
Re: dcmmkdir crash under Windows 8 32 bit
Thanks - good to know that the problem is under investigation. Do you have any idea of a workaround for the issue, maybe from the other users who have the problem? I guess the problem will happen in all tools generating new UIDs...
- Mon, 2015-07-20, 16:47
- Forum: DCMTK - General
- Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
- Replies: 8
- Views: 19743
dcmmkdir crash under Windows 8 32 bit (SOLVED)
Hi, We are using dcmmkdir (dcmtk 3.6.0) without problems on Windows 7 32 and 64 bit and Windows 8.1 64 bit. On Windows 8.1 32 bit however, it crashes about half of the time. The crash happens with an arbitrary single DICOM file, and with any option I tried. In debug mode, the crash does not happen (...
- Mon, 2011-09-05, 17:12
- Forum: DCMTK - General
- Topic: Padding byte in multi-frame images
- Replies: 7
- Views: 8734
- Mon, 2011-09-05, 14:52
- Forum: DCMTK - General
- Topic: Padding byte in multi-frame images
- Replies: 7
- Views: 8734
Ok, the reference I mentioned was indeed from the DICOM standard, as an additional note to the section you mentioned (this is from the 2009 standard): In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The individual frames shall be concatenated and p...
- Mon, 2011-09-05, 14:43
- Forum: DCMTK - General
- Topic: Padding byte in multi-frame images
- Replies: 7
- Views: 8734
Thanks - this is indeed the correct behavior, but in older versions of the standard this was not so clear (I have been told, I did not lookup this). Anyway, we will patch this locally to satisfy the customizers who use a PACS with the incorrect behavior. Eventually the PACS software will be updated ...