Attributes' copy constructor changes private creators and private tags

[p.p...@synedra.com]

Hi!

I am currently working on some code to transcode dicom data with dcm4che3. This includes a DicomOutputStream to write the transcoded data to it's destination. The DicomOutputStream detects, whenever there is a change in endianess and, if a change was detected, creates a copy of the dataset to write, with org.dcm4che3.data.Attributes.Attributes(Attributes, boolean).

This works fine for most cases, but when private tags (and hence, private creators) with gaps between groups are used, this leads to a different result. The copy constructor will generate diefferent groups. The following testcase illustrates what I mean

@Test

public void testCopyAttributesWithGapsBetweenPrivateTags() {

Attributes attributes = new Attributes();

attributes.setString(Tag.AffectedSOPInstanceUID, VR.UI, "1.2.3.4.5.6");

attributes.setString(0x20010010, VR.LO, "PrivateCreator10");

attributes.setString(0x20010050, VR.LO, "PrivateCreator50");

attributes.setString(0x20010090, VR.LO, "PrivateCreator90");

attributes.setString(0x20011000, VR.SH, "PrivateTag10");

attributes.setString(0x20015000, VR.SH, "PrivateTag50");

attributes.setString(0x20019000, VR.SH, "PrivateTag90");

Attributes copy = new Attributes(attributes);

Attributes unexpectedCopy = new Attributes();

unexpectedCopy.setString(Tag.AffectedSOPInstanceUID, VR.UI, "1.2.3.4.5.6");

unexpectedCopy.setString(0x20010010, VR.LO, "PrivateCreator10");

unexpectedCopy.setString(0x20010011, VR.LO, "PrivateCreator50");

unexpectedCopy.setString(0x20010012, VR.LO, "PrivateCreator90");

unexpectedCopy.setString(0x20011000, VR.SH, "PrivateTag10");

unexpectedCopy.setString(0x20011100, VR.SH, "PrivateTag50");

unexpectedCopy.setString(0x20011200, VR.SH, "PrivateTag90");

Assert.assertEquals(copy.toString(), unexpectedCopy.toString()); // will match

Assert.assertEquals(copy.toString(), attributes.toString()); // will fail

}

So, my questions are

* What's the rationale behind this? To me, the code looks like this behavior was implemented on purpose, but the standard [1] does not seem to demand it. Am I missing something?

* Is there an easy way to implement correct (i.e. retaining private tags and creators) transcoding, aside from reimplementing parts of DicomOutputStream and Attributes copy code?

* Is this a bug after all, and should I file a bug report?

Cheers,

Patrick

[1] http://dicom.nema.org/dicom/2013/output/chtml/part05/sect_7.8.html

[p.p...@synedra.com]

I understand now, that the private creators are a kind of namespace mechanism, and that the String, not the tag, is the actual identifier. So, both versions should be the same, semantically. However, this is still not what I would have expected from a copy constructor, and for my usecase: I'd rather not change tags when transcoding, to avoid problems with other implementations that, for some reason, do rely on the tags.

Anyway, dcm4che5 does not change the tags, so my solution is to migrate.