Search found 99 matches
- Mon, 2020-04-06, 15:30
- Forum: DCMTK - General
- Topic: Transfersyntax and VR of pixel data
- Replies: 7
- Views: 3992
Re: Transfersyntax and VR of pixel data
Yes, sorry. checkAndUpdateVR() was what I meant. I have tried saving and loading, and it works fine. To do so, I had to change the call for setting the (8-bit) pixel data to putAndInsertUint8Array() of course. Then I tried: DcmFileFormat file(&dataset); ofResult = file.saveFile("e:\\temp\\E...
- Mon, 2020-04-06, 07:30
- Forum: DCMTK - General
- Topic: Transfersyntax and VR of pixel data
- Replies: 7
- Views: 3992
Re: Transfersyntax and VR of pixel data
Thank you for your counter-questions, Jörg. Here are the answers: Short question: why do you call putAndInsertUint16Array() if the pixel data is 8 bits/pixel? Because PS3.5, A.1c says (for TS Implicit Little Endian): Pixel Data (7FE0,0010) has the Value Representation OW and shall be encoded in Litt...
- Fri, 2020-04-03, 13:37
- Forum: DCMTK - General
- Topic: Transfersyntax and VR of pixel data
- Replies: 7
- Views: 3992
Transfersyntax and VR of pixel data
Dear experts, I am currently investigating how the requirements of PS3.5, Appendix A are implemented and whether we have to consider them in our code using DCMTK or if DCMTK has built-in methods doing the job. If I got it correctly, the baseline for Little Endian Implicit/Explicit is: - if the TS is...
- Fri, 2020-04-03, 13:18
- Forum: DCMTK - General
- Topic: movescu - Move Request Failed: 0006:0317
- Replies: 2
- Views: 2968
Re: movescu - Move Request Failed: 0006:0317
It seems that the Move SCP you are talking to just closes the association while it should better return a C-MOVE-Response which is helpful for debugging. But a few guesses of what typically goes wrong in C-MOVE: - the Move Destintation (testAET) must be configured on the Move SCP side. It should res...
- Thu, 2020-03-26, 09:40
- Forum: DCMTK - General
- Topic: Preblem with DJDecoderRegistration
- Replies: 10
- Views: 4568
Re: Preblem with DJDecoderRegistration
Including the header is not the same as linking to the libraries. You need to have the libraries built as ".lib" and potentially ".dll" or ".so" files, and you have to instruct your linker to add them to your project.
- Wed, 2020-03-25, 08:48
- Forum: DCMTK - General
- Topic: Preblem with DJDecoderRegistration
- Replies: 10
- Views: 4568
Re: Preblem with DJDecoderRegistration
The IJG libraries are shipped with DCMTK, so you just compile jpg8, jpg12 and jpg16 and then link to them like you link to other DCMTK libraries as well.
- Tue, 2020-03-24, 13:53
- Forum: DCMTK - General
- Topic: Preblem with DJDecoderRegistration
- Replies: 10
- Views: 4568
Re: Preblem with DJDecoderRegistration
Are you linking to the dcmjpeg and to the IJG libraries?
- Fri, 2020-03-20, 09:38
- Forum: DCMTK - General
- Topic: Attributes changed by on.the-fly lossy compression
- Replies: 6
- Views: 3420
Re: Attributes changed by on.the-fly lossy compression
We have now changed the implementation of DJCodecEncoder::updateDerivationDescription() to: [...] OFCondition result = dataset->putAndInsertString(DCM_DerivationDescription, derivationDescription.c_str()); if (result.good()) { // assume we can cast the codec parameter to what we need DJCodecParamete...
- Thu, 2020-03-12, 12:13
- Forum: DCMTK - General
- Topic: Attributes changed by on.the-fly lossy compression
- Replies: 6
- Views: 3420
Re: Attributes changed by on.the-fly lossy compression
Thank you very much for your assessment, Marco. Meanwhile we have investigated the issue in more detail. We think that the problem is caused by DJCodecEncoder::updateDerivationDescription(), and we found discrepancies between the behavior of the command line tools (dcmcjpeg) and DCMTK integrated in ...
- Wed, 2020-02-19, 08:57
- Forum: DCMTK - General
- Topic: Attributes changed by on.the-fly lossy compression
- Replies: 6
- Views: 3420
Re: Attributes changed by on.the-fly lossy compression
Hi Jörg, thank you very much for your reply. ad 1: Sorry for the confusion. I figured out that the Image Type was not included at all in this case. It was a CR image, for which Image Type is a Type 3 attribute, so the value changed from "<nothing>" to "DERIVED". It is not so nice...
- Mon, 2020-02-17, 15:49
- Forum: DCMTK - General
- Topic: Attributes changed by on.the-fly lossy compression
- Replies: 6
- Views: 3420
Attributes changed by on.the-fly lossy compression
[EDIT - moved this question from Installation to General] Dear DCMTK-forum, I have a question about changes which are applied to DICOM image attributes upon (lossy) on-the-fly compression. We can handle the DCMTK good enough to change the behaviour if needed, but we would like to understand the deci...
- Tue, 2018-10-23, 14:05
- Forum: DCMCHECK
- Topic: Updating the Data Dictionary of dcmcheck
- Replies: 2
- Views: 14177
Re: Updating the Data Dictionary of dcmcheck
Thanks a lot! We will try that and post the results here.
- Tue, 2018-10-23, 11:56
- Forum: DCMCHECK
- Topic: Updating the Data Dictionary of dcmcheck
- Replies: 2
- Views: 14177
Updating the Data Dictionary of dcmcheck
Hi all, today I have received an evaluation copy of dcmckeck. For a quick test, I checked a Secondary Capture Object with veterinary attributes. I suppose that as the tool itself, its built in Data Dictionary is from 2003. So e.g. the output contains messages like this: Informational I-06: Attribute...
- Thu, 2017-04-20, 11:42
- Forum: DCMTK - General
- Topic: Copyright Statement in tstring.cc - correct???
- Replies: 3
- Views: 3523
Re: Copyright Statement in tstring.cc - correct???
Hi Jörg, thank you for your reply. In fact, I really overlooked the passage you are pointing out ("GPL" is an eye catcher for commercial developers :lol: ), however, I do not see how that helps in assessing the licensing constraints. In particular: [*] In that context, I would interpret th...
- Wed, 2017-04-19, 14:29
- Forum: DCMTK - General
- Topic: movescu behavior
- Replies: 1
- Views: 2102
Re: movescu behavior
2- when application A finished sending the data to Application B