DICOM identifiers for Mac OSX - DICOM

This is a discussion on DICOM identifiers for Mac OSX - DICOM ; Hello, This may be a strange question, particulary to the 95-97% of you who do not use a Macintosh computer, but I can't think of a better place to post this: As many of the 3-5% of you know, the ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: DICOM identifiers for Mac OSX

  1. DICOM identifiers for Mac OSX

    Hello,

    This may be a strange question, particulary to the 95-97% of you who do
    not use a Macintosh computer, but I can't think of a better place to
    post this:

    As many of the 3-5% of you know, the latest version of Mac OSX inlcudes
    a powerfull search engine called spotlight. It is sort of a google for
    your desktop in that it keeps a fast database of metadata for each file
    (that it understands) to allow fast saerching basd on file content as
    well as file names. Developers can extend this search capability by
    creating custom metadata importers that the OS can call when a file
    matching a "Uniform Type Identifier" (UTI) is encountered. UTIs
    "uniquely identify a class of entities considered to have a 'type.'".
    Applications can define UTIs for their proprietary files so the OS can
    figure out, for example, what application to launch whe the user
    double-clicks on a file. For Windows and Unix, UTIs would simply be the
    file's extension. On the Mac, there are other methods of tagging a file,
    which I will not bore you with.

    To make a long story short, each UTI has a labelling scheme similar to
    an internet address. For example, the UTI label associated with my
    software might be "com.myCompany.myDocument". Also, there are public
    domain file types that are now owned by anyone but might be important to
    everyone like "public.image" or "public.jpeg". "public.jpeg" might be
    associated with any file with the extensions jpeg, jpg or with Mac type
    code JPEG. The application does not need to care as long as they ask for
    files with the public.jpeg UTI label. UTIs for these public domain files
    are defined by apple and listed in a reference for developers. The gray
    zone occurs for files like DICOM that are not defined by Apple, whose
    ownership is either unclear or not by someone who is particularly
    interested in Mac or UTIs. It would be simple for an application to
    define their own UTI for a DICOM image (e.g.
    "com.myCompany.foreignFile.DICOM" and associate it with the extension
    ..dcm) but it can be redundant to have any application who processed
    DICOM files to do this so it makes sense to agree on a common one. I
    noticed that OsiriX on OSX defines a UTI for DICOM images called
    "public.dicom", which makes sense, however public.anything is reserved
    by Apple. The way I see it is there are 2 routes:

    1: Agree on a common label (e.g. org.nema.dicom.dicomFile or just
    org.nema.dicom) and anyone aware of it can use it

    OR

    2: Use public.dicom and get Apple to define it in the future.

    Option 2 is probably the best route, however before I ask Apple to do
    tha (which they probably will), does the "organization" that defines the
    dicom standard have anything to say in the matter? Would they mind?

    Sorry if sounds like nit-picking, but I simple question at this point
    may save some issues for us Mac developers down the road.

    Regards,

    Roch Comeau
    Rogue Research Inc.

  2. Re: DICOM identifiers for Mac OSX

    Maybe you've already thought of this and have discarded it for some
    reason that is not apparent; but I don't understand why you wouldn't
    simply use the SOP Class UID which is embedded in every DICOM object as
    the identifier for what "type" of image it is.


  3. Re: DICOM identifiers for Mac OSX

    In article <1115314528.255946.136420@f14g2000cwb.googlegroups. com>,
    eric.goodall@gmail.com wrote:

    > Maybe you've already thought of this and have discarded it for some
    > reason that is not apparent; but I don't understand why you wouldn't
    > simply use the SOP Class UID which is embedded in every DICOM object as
    > the identifier for what "type" of image it is.


    Uniform Type Identifiers (UTIs) are not to distinguish one DICCOM file
    from another, but rather for the computer OS to distinguish a DICOM file
    from a photoshop file, or PowerPoint presentation, from one "class" of
    files from another. The OS does not read the file's content for this,
    and in the case of dicom files, relies on the file's extension (like in
    the Windows and Unix worlds). For example, when you double-click on a
    file with .html as an extension, the OS uses it's list of known UTIs to
    determine what type fo file it is, and then checks it's list of
    installed applications to see if one accepts files from that type. It
    then launches that application and sends it a message to open that file.
    For Spotlight, there is built-in functionality that can examine many
    files of common UTIs on your hard disk and extract metadata and keep
    that in a database. You can then quickly enter a few keywords and
    Spotlight will give you a list of files that have one or more of those
    words in their metadata.

    UTIs are more flexible than extensions because you can define more than
    one extension for a given UTI. For example, ".jpg, .jpeg can be assigned
    to the same public.jpeg UTI. Om the Mac, there are other tags that can
    be part of a UTI definition as well.

    If one were to write a Spotlight plug-in for JPEG files, you would have
    to do 2 things (among others). First, you need to tell the OS (the part
    that manages Spotlight) that you want to be invoked whever Spotlight
    wants to index a file whose UTI is "public.jpeg". Then you would
    implement the function that the OS would call each time a jpeg file is
    to be indexed. Your function would then open that file and extract any
    metadata you wated to extract and submit it to Spotlight. Anyone could
    then type a keyword that your plug-in extracted and that file would show
    up in the search results.

    For DICOM, there is no official UTI since it is a bit obscure in the
    everyday computer world (when compared to html or jpeg files for
    example) so I need to define a DICOM UTI, and then tell the OS I want to
    be notified to help index files of that UTI. The obvious one would be
    org.nema.dicom but I would be acting on nema's behalf if I did this. If
    it were considered a public domain format, then public.dicom would make
    sense. I just wanted to see if anyone had an opinion on the topic before
    I went ahead and picked soemthing. I can change it doen the road so I'll
    just go ahead and pick something...

    FYI, my plug-in will allow one to pick what DICOM fields they want
    extracted as metadata for searches, so if you were to type in a patient
    name, or scanner manufacturer or any field you had indexed, all dicom
    images on your disk fitting that criteria would be shown. This can
    change the way we conceptualize file folder structures as you can search
    your entire disk in a couple of seconds to find any DICOM file you want.
    The search field can also be incorporated into the file dialog of an
    application so you can quickly sort through all your images to load what
    you want.

    Anyway, if you have reasd this far, I am impressed! Thanks for your
    input and anyne else whao chimed in. For any Mac users out there, I hope
    to have this plug-in available sometime next week as free-ware so check
    Apple's Spotlight download page towards the end of next week if you are
    interested. I am doing this to get my feet wet with dcmtk and some new
    development tools from Apple, and this is a small manageable project
    that might actually be usefull.

    Regards,

    Roch Comeau

  4. Re: DICOM identifiers for Mac OSX

    Your terminology threw me for a moment. There is standard MIME tag for
    DICOM objects. It is defined in IETF RFC3240 = application\dicom. If
    you need a URI as part of the id mapping, that URI should be
    http://medical.nema.org/


    Regarding UIDs. There are many different UIDs in DICOM. Some, as you
    apparently are aware, are unique identifiers for the images themselves.
    SOP Class UIDs identify sub types below the level of the general class
    of "dicom images". Different DICOM objects have different required
    elements and semantic constraints on those elements. There is a base
    set of elements and sematic constraints common to all dicom objects,
    hence the application\dicom mime can be assigned and used; but there
    are very few, if any, universal DICOM handler applications. Most
    handle greater or lesser subsets of the total set of DICOM objects. So
    for example, an application which handles CR, CT, MR, DX, US objects
    may or may not handle DICOM Waveforms, (EKGs) or Radiation Therapy
    Beams, Plan, or other limited domain DICOM SOP Classes.
    The SOP Class UID is the internal tag within the object that will
    provides a definitive identification of the DICOM subtype. To be truly
    useful a workstation handler is going to need to map below the level of
    DICOM object to assign handler applications. I suggest you consider
    application\dicom\ or application\dicom\sopclassname (if
    you want it to be human rather than machine readability)


  5. Re: DICOM identifiers for Mac OSX

    A MIME tag is different than a file extension. I don't know how the mac
    works, but it SOUNDS like it keys off of the file extension. I know
    Windows works this way.

    I understand that the recommended extension for dicom files is that
    they have NO extension... that information comes from a fairly
    unreliable source, but it seems to be born out by most sample DICOM
    files I have, so I'd love to be corrected on this, and would LOVE for
    all my dicom files to be *.dicom extensions... if that's ok.

    -Kelly

    eric.good...@gmail.com wrote:
    > Your terminology threw me for a moment. There is standard MIME tag

    for
    > DICOM objects. It is defined in IETF RFC3240 = application\dicom. If
    > you need a URI as part of the id mapping, that URI should be
    > http://medical.nema.org/



  6. Re: DICOM identifiers for Mac OSX

    Roch M. Comeau wrote in "news:comp.protocols.dicom":

    > Hello,
    >
    > This may be a strange question, particulary to the 95-97% of you who do
    > not use a Macintosh computer, but I can't think of a better place to
    > post this:
    >
    > As many of the 3-5% of you know, the latest version of Mac OSX inlcudes
    > a powerfull search engine called spotlight. It is sort of a google for
    > your desktop in that it keeps a fast database of metadata for each file
    > (that it understands) to allow fast saerching basd on file content as
    > well as file names. Developers can extend this search capability by
    > creating custom metadata importers that the OS can call when a file
    > matching a "Uniform Type Identifier" (UTI) is encountered. UTIs
    > "uniquely identify a class of entities considered to have a 'type.'".
    > Applications can define UTIs for their proprietary files so the OS can
    > figure out, for example, what application to launch whe the user
    > double-clicks on a file. For Windows and Unix, UTIs would simply be the
    > file's extension. On the Mac, there are other methods of tagging a file,
    > which I will not bore you with.
    >
    > To make a long story short, each UTI has a labelling scheme similar to
    > an internet address. For example, the UTI label associated with my
    > software might be "com.myCompany.myDocument". Also, there are public
    > domain file types that are now owned by anyone but might be important to
    > everyone like "public.image" or "public.jpeg". "public.jpeg" might be
    > associated with any file with the extensions jpeg, jpg or with Mac type
    > code JPEG. The application does not need to care as long as they ask for
    > files with the public.jpeg UTI label. UTIs for these public domain files
    > are defined by apple and listed in a reference for developers. The gray
    > zone occurs for files like DICOM that are not defined by Apple, whose
    > ownership is either unclear or not by someone who is particularly
    > interested in Mac or UTIs. It would be simple for an application to
    > define their own UTI for a DICOM image (e.g.
    > "com.myCompany.foreignFile.DICOM" and associate it with the extension
    > .dcm) but it can be redundant to have any application who processed
    > DICOM files to do this so it makes sense to agree on a common one. I
    > noticed that OsiriX on OSX defines a UTI for DICOM images called
    > "public.dicom", which makes sense, however public.anything is reserved
    > by Apple. The way I see it is there are 2 routes:
    >
    > 1: Agree on a common label (e.g. org.nema.dicom.dicomFile or just
    > org.nema.dicom) and anyone aware of it can use it
    >
    > OR
    >
    > 2: Use public.dicom and get Apple to define it in the future.
    >
    > Option 2 is probably the best route, however before I ask Apple to do
    > tha (which they probably will), does the "organization" that defines the
    > dicom standard have anything to say in the matter? Would they mind?
    >
    > Sorry if sounds like nit-picking, but I simple question at this point
    > may save some issues for us Mac developers down the road.
    >
    > Regards,
    >
    > Roch Comeau
    > Rogue Research Inc.


    For those who don't know what a UTI is, they can read about it (and
    in particular how it differs from a MIME type and a file extension)
    at:

    http://developer.apple.com/documenta...standing_utis/

    I agree that "public.dicom" is probably the best
    choice, and if in future it is desirable to subdivide that space
    (e.g. into public.dicom.image versus public.dicom.presentationstate,
    etc.), that could be addressed.

    Whether or not the UTI public.dicom should conform to public.image is
    a question. A more specific UTI such as public.dicom.image probably
    should.

    Whether or not Osirix should have used a UTI in the public hierarchy
    or not, without authorization by Apple, is another matter, but it
    is still the most sensible choice. When I look at Osirix's property
    list I see "public.dcm" (not "public.dicom"), corresponding to a
    public.filename-extension UTTypeTagSpecification value of ".dcm";
    the type conforms to public.image.

    I would think that prior to Apple defining a public type for DICOM,
    Osirix should not be using "public.dcm" but rather "osirix.dicom" or
    similar (e.g. "ch.something.osirix.dicom").

    Further, the "public.dicom" type should be equated to the old Apple
    file type (com.apple.macos.ostype) of "DICM", which we had Apple
    register years ago, as well as a public.mime-type of "application/dicom",
    which the committee registered with IANA in RFC 3240 (see
    http://www.faqs.org/rfcs/rfc3240.html). As should probably the Osirix
    proprietary UTI used in the Osirix application property list.

    I will cross-post this to the Osirix list.

    If folks think it is worthwhile, the DICOM Committee can approach
    Apple on formally defining an appropriate public UTI. I can ask
    Howard Clark at NEMA to take care of this.

    This is something that should be done by the committee, and not an
    individual company.

    David

  7. DICOM file extensions, was Re: DICOM identifiers for Mac OSX

    kellyatdentrix@gmail.com wrote:

    > I understand that the recommended extension for dicom files is that
    > they have NO extension... that information comes from a fairly
    > unreliable source, but it seems to be born out by most sample DICOM
    > files I have, so I'd love to be corrected on this, and would LOVE for
    > all my dicom files to be *.dicom extensions... if that's ok.


    Internally (in a product or software or archive) one can do whatever one
    wants with respects to file extensions. The standard has no concept of
    a file or name in those settings.

    On DICOM interchange media however, extensions are not (and likely
    never will be) permitted, since they cannot be represented in the CS VR
    that is used to encode the File ID components inside the DICOMDIR. So
    in short, no extensions on your ISO 9660 CDs or UDF DVDs.

    This is a problem that is easily overcome even on media through the use
    of symbolic links or similar, if it excites you enough to want to bother.

    Generally it is not a practical problem, since ordinary users (as
    opposed to programmers and engineers who get aroused by such
    things) don't look at single image files at a time, though it
    does make folder drag-and-drop operations harder.

    For interchange within the context of email or the web, RFC 3240
    suggests but does not require a ".dcm" extension (as distinct from
    the DICOMDIR compatible name in the id parameter of the mime type),
    so if you are going to use a file extension internally, the ".dcm"
    rather than something else that you make up as an extension probably
    makes sense.

    David

  8. Re: DICOM identifiers for Mac OSX

    I think this is a good idea. Even though Macs are a small percentage of
    the user community, there is no reason not to allow them to take advantage
    of the features that Apple provides. And if the request should be made by
    the Committee, then please forward it on. Apple isn't very good at
    broadcasting its efforts like this--I used to create Dicom files on the
    Mac but never knew 'DICM' was a registered type and just had to use
    '????'. So, this forum may be the only place this UTI type ever gets
    discussed.

    In article <427C9B9A.7060201@dclunie.com>,
    David Clunie wrote:
    >
    >If folks think it is worthwhile, the DICOM Committee can approach
    >Apple on formally defining an appropriate public UTI. I can ask
    >Howard Clark at NEMA to take care of this.
    >
    >This is something that should be done by the committee, and not an
    >individual company.
    >
    >David



  9. Re: DICOM file extensions, was Re: DICOM identifiers for Mac OSX

    Hi,

    I am not sure if this adds any value to this thread, but I have written a
    DICOM indexing
    plugin for Google Desktop Search.
    I am using the OFFIS DCMTK's dcmdump.exe for creating a textual dump
    of the DICOM files and sending this as the indexable content to Google.
    I have already submitted my plugin to Google and hope they add it in their
    list of
    plugins soon.
    Once it is added, users can very easily search(using Google Desktop Search)
    DICOM files in their entire system based on various tags/values.
    However this plugin works only with DICOM files with extensions .dcm and
    ..ima.
    (Yes I know that the vast majority of DICOM files do not have any extension,
    but AFAIK the current Google Indexing API relies on file extensions and not
    on MIME
    types. Hope this will change for the better.)
    Hope this plugin will be of use to the DICOM community.

    Note(mainly to OFFIS DCMTK people) :
    ------------------------------------------
    I read the OFFIS DCMTK FAQ about redistributing in binary form and
    I added the copyright notice, disclaimer, redistribution conditions,etc to
    my readme.html.
    But still I am not completely sure whether I statisfied all the regulations.
    So I request you to kindly tell me if I am missing something.
    The license can be seen at http://www.geocities.com/chinnitv/indexdcm.html
    The plugin is currently submitted as a BETA and based on the feedback, I
    will
    release it as a freeware.

    Thanks a lot,
    Anand Mohan


    "David Clunie" wrote in message
    news:427DF20F.7090402@dclunie.com...
    > kellyatdentrix@gmail.com wrote:
    >
    > > I understand that the recommended extension for dicom files is that
    > > they have NO extension... that information comes from a fairly
    > > unreliable source, but it seems to be born out by most sample DICOM
    > > files I have, so I'd love to be corrected on this, and would LOVE for
    > > all my dicom files to be *.dicom extensions... if that's ok.

    >
    > Internally (in a product or software or archive) one can do whatever one
    > wants with respects to file extensions. The standard has no concept of
    > a file or name in those settings.
    >
    > On DICOM interchange media however, extensions are not (and likely
    > never will be) permitted, since they cannot be represented in the CS VR
    > that is used to encode the File ID components inside the DICOMDIR. So
    > in short, no extensions on your ISO 9660 CDs or UDF DVDs.
    >
    > This is a problem that is easily overcome even on media through the use
    > of symbolic links or similar, if it excites you enough to want to bother.
    >
    > Generally it is not a practical problem, since ordinary users (as
    > opposed to programmers and engineers who get aroused by such
    > things) don't look at single image files at a time, though it
    > does make folder drag-and-drop operations harder.
    >
    > For interchange within the context of email or the web, RFC 3240
    > suggests but does not require a ".dcm" extension (as distinct from
    > the DICOMDIR compatible name in the id parameter of the mime type),
    > so if you are going to use a file extension internally, the ".dcm"
    > rather than something else that you make up as an extension probably
    > makes sense.
    >
    > David




  10. Re: DICOM file extensions, was Re: DICOM identifiers for Mac OSX

    John Smith wrote:
    > Note(mainly to OFFIS DCMTK people) :
    > ------------------------------------------
    > I read the OFFIS DCMTK FAQ about redistributing in binary form and
    > I added the copyright notice, disclaimer, redistribution conditions,etc to
    > my readme.html.
    > But still I am not completely sure whether I statisfied all the regulations.


    I've checked your page and everything looks fine.

    Best regards,
    Marco Eichelberg
    OFFIS

  11. Re: DICOM identifiers for Mac OSX

    In article <427C9B9A.7060201@dclunie.com>,
    David Clunie wrote:

    < snip... >

    >
    > For those who don't know what a UTI is, they can read about it (and
    > in particular how it differs from a MIME type and a file extension)
    > at:
    >
    > http://developer.apple.com/documenta...standing_utis/
    >
    > I agree that "public.dicom" is probably the best
    > choice, and if in future it is desirable to subdivide that space
    > (e.g. into public.dicom.image versus public.dicom.presentationstate,
    > etc.), that could be addressed.
    >
    > Whether or not the UTI public.dicom should conform to public.image is
    > a question. A more specific UTI such as public.dicom.image probably
    > should.
    >
    > Whether or not Osirix should have used a UTI in the public hierarchy
    > or not, without authorization by Apple, is another matter, but it
    > is still the most sensible choice. When I look at Osirix's property
    > list I see "public.dcm" (not "public.dicom"), corresponding to a
    > public.filename-extension UTTypeTagSpecification value of ".dcm";
    > the type conforms to public.image.
    >
    > I would think that prior to Apple defining a public type for DICOM,
    > Osirix should not be using "public.dcm" but rather "osirix.dicom" or
    > similar (e.g. "ch.something.osirix.dicom").
    >
    > Further, the "public.dicom" type should be equated to the old Apple
    > file type (com.apple.macos.ostype) of "DICM", which we had Apple
    > register years ago, as well as a public.mime-type of "application/dicom",
    > which the committee registered with IANA in RFC 3240 (see
    > http://www.faqs.org/rfcs/rfc3240.html). As should probably the Osirix
    > proprietary UTI used in the Osirix application property list.
    >
    > I will cross-post this to the Osirix list.
    >
    > If folks think it is worthwhile, the DICOM Committee can approach
    > Apple on formally defining an appropriate public UTI. I can ask
    > Howard Clark at NEMA to take care of this.
    >
    > This is something that should be done by the committee, and not an
    > individual company.
    >
    > David


    Thanks, David!

    I plan on supporting image files at first. If I can trouble you for one
    more opinion, Until Apple defines a public.dicom.image (or the committee
    defines org.nema.dicom.image, which is OK as well IMHO), I will define
    in my software:

    com.rogue-research.foreignFile.dicom.image
    conforms to public.image

    extension: dcm
    file type: com.apple.macos.ostype of "DICM"
    public.mime-type of "application/dicom"

    I hope the committee contacts Apple and public.dicom.image gets defined
    (or org.nema.dicom.image). When that happens, I'll change it to that. I
    agree that the committee should do this, but I was not sure if this was
    something they would be interested in.

    Thanks,

    Roch Comeau

+ Reply to Thread