Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lossy Compression(New SOP Instance UID Created)

87 views
Skip to first unread message

Akshaybar Kumar Singh

unread,
Jul 8, 2014, 6:11:11 AM7/8/14
to
Dear All,

I am compression the DICOM file using DCMTK 3.6.0 withh Lossy Compression(EXS_JPEGProcess10_12TransferSyntax).

I have register the codec before going to compress the file. Lossy compression has been done by DCMTK but it creates NEW SOP INSTANCE UID for the same image & updating the tag (0008,0018) with new SOPInstanceUID.

My requirement is to not update SOPInstanceUID with new sopUID, it shall be with original SOP Instance UID.

Kindly help to do the same. How can i stop the creation of new SOP Instance UID for Lossy Compression?



Thanks & Regards
Akshay

Marco Eichelberg

unread,
Jul 8, 2014, 6:50:15 AM7/8/14
to
Dear Akshay,
DCMTK specific questions are considered out of scope in this newsgroup
and should rather be posted to the DCMTK discussion forum at
http://forum.dcmtk.org/.

That said, DJEncoderRegistration::registerCodecs() has a number of optional
parameters, and the second one (pCreateSOPInstanceUID) controls the
policy for the creation of new SOP Instance UIDs.

Note, however, that the change of SOP Instance UID is a requirement
according to the DICOM standard, since any lossy compression is likely
to cause differences in the diagnostic value of th image. So if you
apply lossy compression, and you don't change the SOP Instance UID,
funny things may happen, e.g. if one device receives both images,
original and compressed, which are different but have the same
SOP Instance UID.

Best regards,
Marco Eichelberg
OFFIS, DCMTK Team.

David Clunie

unread,
Jul 8, 2014, 7:44:32 AM7/8/14
to
Hi Akshay

Just to reinforce Marco's comment, you really do need to create
a new SOP Instance UID when lossy compressing a previous instance.

There may be many reasons why folks argue not to do this, but the
bottom line is that given the assumptions in the DICOM services
and the behavior of the installed base of systems, it is a not a
good idea to reuse the same SOP Instance UID for this. Since we now
live in a very connected environment with central archives, image
sharing services on the network, not to mention CDs given to
patients, etc, one has to take the "global" reliability of UIDs
seriously, perhaps more seriously than has been the case in the
past when everyone was more "inwardly" focused.

Don't forget, by the way, when performing lossy image compression,
to record the fact in Lossy Image Compression, as well as add the
method to Lossy Image Compression Method, and the ratio to Lossy
Image Compression Ratio, set the Image Type Value 1 to DERIVED,
update Derivation Description, and add an Item to Contributing
Equipment Sequence identifying your compression software.

You should also add a reference to the uncompressed predecessor
in Source Image Sequence (which is a reference to its UID, which
should make obvious the need to use a different UID for the
compressed successor).

David

PS. And before someone asks, yes, if you are lossy compressing
a whole bunch of stuff in an archive that was previously not
lossy compressed, you should definitely change the UIDs, even
though that also means updating all the presentation states,
key objects, SRs and anything else that contains references,
in order to maintain referential integrity within the archive.

And yes this means that outside systems' old instance-level
or series-level links to UIDs will go stale, which is why they
might want to use IID instead (though a clever PACS, WADO or
whatever server when asked for an uncompressed instance might
think of returning the compressed one instead if it "knows",
and that's all it has, though there are issues with this, which
have been discussed here before).

I have been told that some VNA and migration companies may offer
to do it without changing the UIDs, but if so, they are naughty.


On 7/8/14 6:50 AM, Marco Eichelberg wrote:
>On 7/8/14 6:11 AM, Akshaybar Kumar Singh wrote:
>> My requirement is to not update SOPInstanceUID with new sopUID, it
>> shall be with original SOP Instance UID.
>> Kindly help to do the same. How can i stop the creation of new SOP
>> Instance UID for Lossy Compression?
...
> Note, however, that the change of SOP Instance UID is a requirement
> according to the DICOM standard, since any lossy compression is likely
> to cause differences in the diagnostic value of the image. So if you
0 new messages