Search found 24 matches

by andreasb
Mon, 2016-02-01, 12:58
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

Re: dcmmkdir crash under Windows 8 32 bit (SOLVED)

Thanks Jörg - that was fast!
- Andreas
by andreasb
Mon, 2016-02-01, 08:07
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

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?
by andreasb
Thu, 2015-08-13, 17:01
Forum: DCMTK - General
Topic: storescu fails to convert private pixel data
Replies: 2
Views: 12479

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
by andreasb
Wed, 2015-08-12, 13:50
Forum: DCMTK - General
Topic: storescu fails to convert private pixel data
Replies: 2
Views: 12479

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 ...
by andreasb
Wed, 2015-08-12, 12:17
Forum: Other DICOM Tools
Topic: storescu crash with large JPEG Baseline coded dataset
Replies: 4
Views: 10089

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, ...
by andreasb
Wed, 2015-08-12, 08:42
Forum: Other DICOM Tools
Topic: storescu crash with large JPEG Baseline coded dataset
Replies: 4
Views: 10089

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...
by andreasb
Wed, 2015-08-12, 07:35
Forum: Other DICOM Tools
Topic: storescu crash with large JPEG Baseline coded dataset
Replies: 4
Views: 10089

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()...
by andreasb
Tue, 2015-08-11, 16:38
Forum: Other DICOM Tools
Topic: storescu crash with large JPEG Baseline coded dataset
Replies: 4
Views: 10089

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...
by andreasb
Wed, 2015-07-22, 12:16
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

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...
by andreasb
Tue, 2015-07-21, 09:03
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

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?
by andreasb
Tue, 2015-07-21, 08:51
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

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...
by andreasb
Mon, 2015-07-20, 16:47
Forum: DCMTK - General
Topic: dcmmkdir crash under Windows 8 32 bit (SOLVED)
Replies: 8
Views: 17121

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 (...
by andreasb
Mon, 2011-09-05, 17:12
Forum: DCMTK - General
Topic: Padding byte in multi-frame images
Replies: 7
Views: 8696

Ok, thanks. You are right - detecting an intra-frame padding is possible only by calculating the frame length from the value length and the number of frames, and it is generally not possible to differentiate it from "excess padding" at the end of the value. Ah, the joy of interpreting the ...
by andreasb
Mon, 2011-09-05, 14:52
Forum: DCMTK - General
Topic: Padding byte in multi-frame images
Replies: 7
Views: 8696

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...
by andreasb
Mon, 2011-09-05, 14:43
Forum: DCMTK - General
Topic: Padding byte in multi-frame images
Replies: 7
Views: 8696

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 ...