Application profile indication in DICOM File sets
Anthony Patrinos
various relevant parts of the standard if, and if so, where the
application profile used to create the file set is stored.
Is it only to be found in a conformance statement?
I expected to a relevant attribute in the specification of the DICOMDIR
struture, but I did not.
Am I searching in vain?
Regards to all,
Tony Patrinos
Escape Information Services
http://www.escape.gr/
David Clunie
not of the media itself.
Therefore, conformance statements for devices describe which profile
(s) and role(s) (creator, updater, reader) they conform to, but
this is not recorded on the media itself.
Indeed it is very important to realize that one piece of media
may contain objects written by different devices conforming to
different profiles, or one device that supports multiple profiles.
For example, a single device might support the basic cardiac angio
CD profile as an FSC and put JPEG XA images on the CD, and
at the same time conform to one of the ultrasound profiles and
write RLE US images on the media, and at the same time conform
to the general purpose profile and write uncompressed secondary
capture images and structured reports. I.e. the one piece of
media contains objects written by a device conforming to three
different FSC profiles.
From an FSR perspective, one is required to gracefully ignore
instances of SOP Classes and Transfer Syntaxes that one does not
support. E.g. an basic cardiac profile FSR (only) device would
be expected to not freak out when it saw the US or SC or SR
objects in the example described.
Even for a single SOP Class instance on the media (i.e. one
file), there is no indication kept of which profile the device
that wrote that particular file in the meta information header.
david
Anthony Patrinos
I appreciate your reply. There is one thing I'm not sure about however
-- I elaborate in context.
In article <3E29A4BE...@dclunie.com>,
David Clunie <dcl...@dclunie.com> wrote:
> The Media Application Profile is a characteristics of a device,
> not of the media itself.
>
> Therefore, conformance statements for devices describe which profile
> (s) and role(s) (creator, updater, reader) they conform to, but
> this is not recorded on the media itself.
>
> Indeed it is very important to realize that one piece of media
> may contain objects written by different devices conforming to
> different profiles, or one device that supports multiple profiles.
>
> For example, a single device might support the basic cardiac angio
> CD profile as an FSC and put JPEG XA images on the CD, and
> at the same time conform to one of the ultrasound profiles and
> write RLE US images on the media, and at the same time conform
> to the general purpose profile and write uncompressed secondary
> capture images and structured reports. I.e. the one piece of
> media contains objects written by a device conforming to three
> different FSC profiles.
>
Shouldn't these objects belong to different file sets, each with its own
DICOMDIR (if the Media Format Layer allows it)? It seems from you reply
that this is not the case, i.e. a FSU could potentiially update a File
Set and DICOMDIR under a different application profile.
On the other hand, if it is true that a single DICOM File Set
corresponds to a particular Application Profile, and taking into account
the fact that a File Set must contain a single DICOMDIR file, does it
not follow that there is a one to one correspondence between an
Application Profile and that DICOMDIR under which it was created? If
this is the case, then it seems to me that inclusion of the Application
Profile in the DICOMDIR would be a harmeless, maybe redundant but
potentially useful piece of information to have access to.
Tony
David Clunie
Anthony Patrinos wrote:
>>The Media Application Profile is a characteristics of a device,
>>not of the media itself.
>>
>>Therefore, conformance statements for devices describe which profile
>>(s) and role(s) (creator, updater, reader) they conform to, but
>>this is not recorded on the media itself.
>>
>>Indeed it is very important to realize that one piece of media
>>may contain objects written by different devices conforming to
>>different profiles, or one device that supports multiple profiles.
There is only one file-set and one DICOMDIR and lots of files
which may be created (or updated) by device(s) conforming to
many application profiles.
> Shouldn't these objects belong to different file sets, each with its own
> DICOMDIR (if the Media Format Layer allows it)?
No. In fact at the present time all media layers defined in
DICOM are strictly one volume per piece (side) of media and
one fileset per volume, therefore one DICOMDIR.
> It seems from you reply
> that this is not the case, i.e. a FSU could potentiially update a File
> Set and DICOMDIR under a different application profile.
Yes.
> On the other hand, if it is true that a single DICOM File Set
> corresponds to a particular Application Profile
It isn't.
> and taking into account
> the fact that a File Set must contain a single DICOMDIR file, does it
> not follow that there is a one to one correspondence between an
> Application Profile and that DICOMDIR under which it was created?
This is not the case
> If
> this is the case, then it seems to me that inclusion of the Application
> Profile in the DICOMDIR would be a harmeless, maybe redundant but
> potentially useful piece of information to have access to.
so this is not applicable.
david
Anthony Patrinos
Thank you for (as always) clearing this up David...
Tony Patrinos
In article <3E2F4107...@dclunie.com>,