I apologize in advance, but I cannot understand how storescu.cfg works and after reading the doc, I still can't make any sense of it. Could someone help me understand how to modify the storescu.cfg file properly?
For storescu, the transfer is failing because of the wrong protocol:
Transfer: JPEG2000LosslessOnly -> LittleEndianImplicit
If I override the protocol to be EXS_JPEG2000LosslessOnly, the transfer works. Given that, how do I then modify storescu.cfg to choose JPEG2000LosslessOnly, rather than LittleEndianImplicit?
I thought something like this would work but it does not:
[JPEG2000LosslessOnly]
TransferSyntax1 = JPEG2000LosslessOnly
Any hints appreciated!!!
Question on storescu.cfg
Moderator: Moderator Team
-
- DCMTK Developer
- Posts: 2073
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: Question on storescu.cfg
Hi,
The storescu.cfg file is able to store different profiles. Each profile lists which presentation contexts, i.e. which SOP classes should be proposed using which transfer syntaxes.
If you start storescu, you have to select a single profile from the ones in the configuration file (the template configuration file only has a single profile named "Default"). You tell storescu to use the configuration file using option "-xf" or --config-file.
The best way to read the configuration file to to start at the bottom. You see that the Default profile is defined as "PresentationContexts = StorageCompressedAndUncompressed". Now, look how StorageCompressedAndUncompressed is defined above. You will see that it defines all Presentation Contexts to be proposed. Each Presentation Context gives the SOP Class and the transfer syntaxes to be used, e.g. the three Presentation Contexts for MR:
So if you scroll up further you see that for example the definition for uncompressed:
So, if you like to propose JPEG2000, you either can edit the Presentation Context Lines that correspond to the SOP class you like to send. Enter behind the SOP class the JPEG2000 transfer syntax you like to use instead, e.g. for the MR example above, change the text to
Note that I removed any other presentation contexts for the SOP class, in our case PresentationContext38 and 39. The reason is that if we propose that to the server, and the server accepts these instead of the JPEG2000 one, then you would have to be able to decompress your JPEG2000 files for transfer (or re-code them to the proposed transfer syntax). storescu is _not_ able to do that for you automatically, so I don't like the server to have the chance to accept one of those transfer syntaxes.
Also, one more step is needed. You need to define "JPEG2000" and "JPEG2000LosslessOnly" as valid transfer syntax identifiers in the beginning of the file, where you find notions like Uncompressed and so on. Add lines like the one for JPEGBaseline, e.g.
HTH,
Michael
The storescu.cfg file is able to store different profiles. Each profile lists which presentation contexts, i.e. which SOP classes should be proposed using which transfer syntaxes.
If you start storescu, you have to select a single profile from the ones in the configuration file (the template configuration file only has a single profile named "Default"). You tell storescu to use the configuration file using option "-xf" or --config-file.
The best way to read the configuration file to to start at the bottom. You see that the Default profile is defined as "PresentationContexts = StorageCompressedAndUncompressed". Now, look how StorageCompressedAndUncompressed is defined above. You will see that it defines all Presentation Contexts to be proposed. Each Presentation Context gives the SOP Class and the transfer syntaxes to be used, e.g. the three Presentation Contexts for MR:
This means: Propose three different presentation contexts for MR, one proposing it with JPEG Baseline tranfersyntax, one proposing it with JPEG Lossless transfersyntax, and one proposing it with one of the uncompressed transfer syntaxes. Every one of the transfer syntaxes mentioned via "keyword" here (JPEGBaseline, JPEGLossless, Uncompressed) are defined at the beginning of the config file in the section [[TransferSyntaxes]].PresentationContext37 = MRImageStorage\JPEGBaseline
PresentationContext38 = MRImageStorage\JPEGLossless
PresentationContext39 = MRImageStorage\Uncompressed
So if you scroll up further you see that for example the definition for uncompressed:
This means, that in PresentationContext39 the SOP Class "MR Image Storage" will be proposed with the three uncompressed Transfer Syntaxes Little Endian Explicit, Big Endian Explicit and Little Endian Implicit.[Uncompressed]
TransferSyntax1 = LittleEndianExplicit
TransferSyntax2 = BigEndianExplicit
TransferSyntax3 = LittleEndianImplicit
So, if you like to propose JPEG2000, you either can edit the Presentation Context Lines that correspond to the SOP class you like to send. Enter behind the SOP class the JPEG2000 transfer syntax you like to use instead, e.g. for the MR example above, change the text to
for lossless JPEG 2000, orPresentationContext37 = MRImageStorage\JPEG2000LosslessOnly
for lossy JPEG2000.PresentationContext37 = MRImageStorage\JPEG2000
Note that I removed any other presentation contexts for the SOP class, in our case PresentationContext38 and 39. The reason is that if we propose that to the server, and the server accepts these instead of the JPEG2000 one, then you would have to be able to decompress your JPEG2000 files for transfer (or re-code them to the proposed transfer syntax). storescu is _not_ able to do that for you automatically, so I don't like the server to have the chance to accept one of those transfer syntaxes.
Also, one more step is needed. You need to define "JPEG2000" and "JPEG2000LosslessOnly" as valid transfer syntax identifiers in the beginning of the file, where you find notions like Uncompressed and so on. Add lines like the one for JPEGBaseline, e.g.
Then, it should work as expected. Note that life could also be easier for you if you use the "new" tool dcmsend which is available in one of the current snapshots. It proposes presentation contexts more intelligently than storescu. However, with storescu.cfg you can fine-tune the proposed transfer syntaxes as required.[JPEG2000]
TransferSyntax1 = JPEG2000
[JPEG2000LosslessOnly]
TransferSyntax1 = JPEG2000LosslessOnly
HTH,
Michael
Re: Question on storescu.cfg
Thank you very, very much. I was able to get things working.
- D
- D
Re: Question on storescu.cfg
I asked a question base on this post by mail, and Dr. Marco Eichelberg kindly answer it.
Add the question and answer here for reference.
Question
In the post, there is an example of the MRImageStorage presentation context list.
My question is, during the negotiation, if the SCP supports JPEGBaseline , JPEGLossless and LittleEndianImplicit, will the storescu use JPEGBaseline as first priority? Does the smaller presentation context ID in the configuration file has the higher priority?
Answer
First of all, if the SCP supports JPEG baseline, lossless and uncompressed, it will simply accept all presentation contexts proposed by the SCU with a known SOP class (MRImageStorage in this example) and one of these transfer syntaxes. The choice of which presentation context to use for an individual image transfer (C-STORE-RQ) is then up to the SCU to decide.
The DICOM standard defines no requirements on how the SCU selects the best presentation context for a task. The presentation context ID is no priority or order, and the algorithm for choosing is totally implementation dependent.
As far as I remember (since this part of the code was written some 15 years ago), the policy of StoreSCU in DCMTK is to first check if there is a presentation context that matches the transfer syntax of the image, and if not, it will look for an uncompressed presentation context and try to decompress the image (which fails in most cases, unless StoreSCU has been compiled to include the decoders for JPEG, JPEG-LS etc.) If the source image is uncompressed, StoreSCU will first look for an uncompressed transfer syntax with explicit VR and the same byte order as the source image, then for explicit VR and opposite byte order, and only then for Implicit VR Little Endian.
However, there is no guarantee that other SCUs will behave like this. This is implementation dependent behaviour and cannot be controlled or affected by the SCP.
Add the question and answer here for reference.
Question
In the post, there is an example of the MRImageStorage presentation context list.
PresentationContext37 = MRImageStorage\JPEGBaseline
PresentationContext38 = MRImageStorage\JPEGLossless
PresentationContext39 = MRImageStorage\Uncompressed
My question is, during the negotiation, if the SCP supports JPEGBaseline , JPEGLossless and LittleEndianImplicit, will the storescu use JPEGBaseline as first priority? Does the smaller presentation context ID in the configuration file has the higher priority?
Answer
First of all, if the SCP supports JPEG baseline, lossless and uncompressed, it will simply accept all presentation contexts proposed by the SCU with a known SOP class (MRImageStorage in this example) and one of these transfer syntaxes. The choice of which presentation context to use for an individual image transfer (C-STORE-RQ) is then up to the SCU to decide.
The DICOM standard defines no requirements on how the SCU selects the best presentation context for a task. The presentation context ID is no priority or order, and the algorithm for choosing is totally implementation dependent.
As far as I remember (since this part of the code was written some 15 years ago), the policy of StoreSCU in DCMTK is to first check if there is a presentation context that matches the transfer syntax of the image, and if not, it will look for an uncompressed presentation context and try to decompress the image (which fails in most cases, unless StoreSCU has been compiled to include the decoders for JPEG, JPEG-LS etc.) If the source image is uncompressed, StoreSCU will first look for an uncompressed transfer syntax with explicit VR and the same byte order as the source image, then for explicit VR and opposite byte order, and only then for Implicit VR Little Endian.
However, there is no guarantee that other SCUs will behave like this. This is implementation dependent behaviour and cannot be controlled or affected by the SCP.
Who is online
Users browsing this forum: Google [Bot] and 1 guest