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.

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

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)

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/

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

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

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

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

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

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