I am not sure why it happen this way, obviously I am missing a piece
of info here.

Steps:

1. Startup your favorite dcmqrscp instance.
Eg:
$ dcmqrscp +B --require-find --check-find -c /etc/dcmtk/dcmqrscp.cfg 5679

2. C-STORE the file to the running dcmqrscp instance.
Eg:
$ storescu --call REMOTE localhost 5679 jpip.dcm
$ echo $?
0

3. Try to get back this instance:
$ movescu --aetitle LOCAL --call REMOTE localhost 5679 -k 8,52=STUDY
-S -k 0020,000d=1.2.826.0.1.3680043.2.1143.7924579604516633137721048893001654588
 +P 5680
$ echo $?
0
$ dcmdump SC.1.2.826.0.1.3680043.2.1143.7139949432470124311062788032909908205
| grep Used
# Used TransferSyntax: Little Endian Explicit
# Used TransferSyntax: Little Endian Explicit


Well that is where I failed to understand what just happened. I have
been thinking real hard (really!), I do not understand why this is
legal to convert JPIP Transfer Syntax to Little Endian Explicit. I
believe this is wrong. Indeed, now that the file is written out as
Little Endian Explicit, the file is illegal since there is no
PixelData element, and there is no way to tell (anymore) that one
should look into PixelDataProviderURL...

dcmqrscp does handle gracefully other transfer syntax telling me when
this is impossible to go from one to the other. But in this case
everything went smoothly...

Hi Mathieu,

thank you for the report. I can confirm that the current "implementation" of
the two JPIP transfer syntaxes is unsatisfying. storescu (and probably other
DCMTK tools) treats these transfer syntaxes in the same manner as Little
Endian Explicit, which is caused by the current definition in "dcxfer.cc".

I've added a new bug entry to our internal tracking system. It will take some
time to fix it, but don't worry I've set the "target version" to "3.6.2" (i.e.
the next release).

Regards,
Jörg Riesmeier

This is an odd combination anyway. Closing as invalid.

This is an odd combination anyway. Closing as invalid.