Adding SC images to existing DICOMDIR

[oxymoron]

I´ve processed some SC images with SOPClassUID UID_SecondaryCaptureImageStorage and want to add them to a new series in an existing XA study.
The TS used is EXS_JPEGProcess14SV1TransferSyntax and when I try to add the image files to the DICOMDIR in order to burn a DVD, the CheckSOPClassAndXfer(...) function rejects it , though in table E.3.1 from PS 3.11 (2015c) I understand it says is a valid TS for that IOD.
Is it not possible to add compressed (Lossless JPEG) SC images to a study with XRayAngiographicImageStore files?

Thanks.

[oxymoron]

My mistake... the table I should have looked at was B-3.1...

[oxymoron]

As a final note to the post... I was (and still am) confused by a restriction in the standard that makes no sense to me. Why is not allowed for the AP STD-XA1K to add the Multiframe Grayscale WORD/BYTE Secondary Capture Image IODs? as I see they are exactly the IOD I would use to add a SC multiframe image to a DVD?

[Michael Onken]

The Application Profile STD-XA1K is much older than the "new" Secondary Capture SOP Classes and thus they probably did not want to break backwards compatibility.

Best,
Michael

[oxymoron]

I guess so.. keeping back compatibility is a big issue, but the current state of the standard does not allow to include a SC image with a bit depth beyond 8, or a compressed one, losing either grayscale resolution and/or storage.

[Michael Onken]

Maybe there are other profiles that would work for you, actually I don't know by heart...

[J. Riesmeier]

Actually, it is possible, but not with the STD-XA1K profile alone. That means, you would have to add these "incompatible" directory records based on another Media Storage Application Profile. According to the DICOM standard, not a storage medium is conformant to a certain profile but a system/implementation is (i.e. a FSC, FSU or FSR).

[Michael Onken]

However, it is not likely to mix application profiles though some (one? I dont mean Jörg;) ) DICOM guru explained that it is possible. I would not do it if you dont want to confuse your customers or media exchange partners, even if you are technically right in terms of the standard.

[J. Riesmeier]

It wasn't "someone" but the chairman of DICOM WG-05 (Exchange Media) and editor of the DICOM standard David Clunie, e.g. here: https://groups.google.com/d/msg/comp.pr ... NjjCWBS54J

[Michael Onken]

That's why I said guru. So you recommend this to anyone? I don't.

Best,
Michael