> We have a product that creates DICOM(??) CDs with our Viewer included.
> Some of Viewer related library files do not conform to ISO 9660 Level 1
> i.e they dont fit to the 8.3 file naming restriction.
> These files are not at all referenced in the DICOMDIR.
>
> So now I have a question:
> Does the ISO 9660 Level 1 regulations for DICOM CD-R media apply to all the
> files burnt into the CD-R media or
> do they apply only to the files referred to by the DICOMDIR.
>
> Since this makes a lot of difference to the basic DICOM fileset conformance
> of our CD-R Media,
> a quick response will be very much appreciated.
>
> Thanks a lot,
> Anand Mohan
>
> PS : Your Response Will Make a Difference

Hi Anand

Yes, all files on the media have to conform, including viewer
related library files.

The entire fileset has to be ISO 9660 Level 1, since this is a
characteristic of the fileset, not the individual files.

Any file referenced by the DICOMDIR can only be 8 characters with
no extension.

Other files on the media can be 8+3, but no more than that, and
what is more only upper case, digits and underscore - no spaces
or lower case.

Also, Rock Ridge and Joliet extensions must not be present.

The CD must be written with Mode 1, or Mode 2 Form 1 sectors.

The safest thing to do is write a single session, track-at-once or
disk-at-once - no packet writing allowed.

The best guide to this currently available is the IHE PDI supplement
at:

http://www.rsna.org/IHE/tf/IHE_TF_Su...2004-06-04.pdf

You have to wade through that document until you get past the other
stuff to the Portable Data for Imaging Profile.

There are various other IHE-specific requirements that are mandatory,
beyond what is specified in DICOM, for the non-DICOM content, that
it might be sensible for you to comply with in order to maximize
interoperability, or to to be able to claim conformance with the
IHE PDI profile

David

PS. If any of the non-DICOM files are HTML and contain links to other
files on the media, then within those HTML files, if you use lowercase
letters, even though the names of the referenced files are uppercase,
your links will work on all platforms, since Windows and Mac don't
care but most Unix and Linux systems do, and map to lower case on mounting
an ISO 9660 filesystem.

PPS. If you do include a viewer on the media, you should not auto-run it,
since auto-run is deprecated by IHE both for security reasons and to
prevent interference with viewers already running on the host.

Yes, the IHE PDI Integration Profile forbids to use Rock Ridge and
Joliet extensions. But is that really helpful for increasing the number
of system which can read such created media, compared to media
containing additional file system meta data. (Rock Ridge definitely does
not violet ISO 9660 Level 1; I am not sure about Microsofts Joliet
extension). - And I don't like the workaround with lowercase letters in
HTML links, assuming a particular file name mapping of potential readers
(now and in 20 years).

I known, I should better formulate that in a CP for the IHE Technical
Framework - but I am not sure, if I will find the time...

Regards,

gunter

David Clunie wrote:
> > We have a product that creates DICOM(??) CDs with our Viewer included.
> > Some of Viewer related library files do not conform to ISO 9660 Level 1
> > i.e they dont fit to the 8.3 file naming restriction.
> > These files are not at all referenced in the DICOMDIR.
> >
> > So now I have a question:
> > Does the ISO 9660 Level 1 regulations for DICOM CD-R media apply to
> all the
> > files burnt into the CD-R media or
> > do they apply only to the files referred to by the DICOMDIR.
> >
> > Since this makes a lot of difference to the basic DICOM fileset
> conformance
> > of our CD-R Media,
> > a quick response will be very much appreciated.
> >
> > Thanks a lot,
> > Anand Mohan
> >
> > PS : Your Response Will Make a Difference
>
> Hi Anand
>
> Yes, all files on the media have to conform, including viewer
> related library files.
>
> The entire fileset has to be ISO 9660 Level 1, since this is a
> characteristic of the fileset, not the individual files.
>
> Any file referenced by the DICOMDIR can only be 8 characters with
> no extension.
>
> Other files on the media can be 8+3, but no more than that, and
> what is more only upper case, digits and underscore - no spaces
> or lower case.
>
> Also, Rock Ridge and Joliet extensions must not be present.
>
> The CD must be written with Mode 1, or Mode 2 Form 1 sectors.
>
> The safest thing to do is write a single session, track-at-once or
> disk-at-once - no packet writing allowed.
>
> The best guide to this currently available is the IHE PDI supplement
> at:
>
> http://www.rsna.org/IHE/tf/IHE_TF_Su...2004-06-04.pdf
>
> You have to wade through that document until you get past the other
> stuff to the Portable Data for Imaging Profile.
>
> There are various other IHE-specific requirements that are mandatory,
> beyond what is specified in DICOM, for the non-DICOM content, that
> it might be sensible for you to comply with in order to maximize
> interoperability, or to to be able to claim conformance with the
> IHE PDI profile
>
> David
>
> PS. If any of the non-DICOM files are HTML and contain links to other
> files on the media, then within those HTML files, if you use lowercase
> letters, even though the names of the referenced files are uppercase,
> your links will work on all platforms, since Windows and Mac don't
> care but most Unix and Linux systems do, and map to lower case on mounting
> an ISO 9660 filesystem.
>
> PPS. If you do include a viewer on the media, you should not auto-run it,
> since auto-run is deprecated by IHE both for security reasons and to
> prevent interference with viewers already running on the host.
>
>
>


--
Gunter Zeilinger
Tiani Medgraph AG
http://www.tiani.com

Download my PGP public Key at
http://pgpkeys.pca.dfn.de:11371/pks/...4BDE1A40A7294D

Hi Gunter

Gunter Zeilinger wrote:

> Yes, the IHE PDI Integration Profile forbids to use Rock Ridge and
> Joliet extensions. But is that really helpful for increasing the number
> of system which can read such created media, compared to media
> containing additional file system meta data. (Rock Ridge definitely does
> not violet ISO 9660 Level 1; I am not sure about Microsofts Joliet
> extension).

The problem is that the presence of Rock Ridge and Joliet extensions
impairs the ability to reliably read the DICOM files, since their
presence interferes with the mapping of the DICOM file names on
various systems. If the extensions were required to be present and supported
that would not be a problem, but since they are not, their unpredictable
presence causes problems, hence they are forbidden.

> - And I don't like the workaround with lowercase letters in
> HTML links, assuming a particular file name mapping of potential readers
> (now and in 20 years).

Nobody likes workarounds but the fact remains that this work around
works for now. It is predicated on the default Unix/Linux ISO 9660 mount
behavior being to lowercase letters with no period and version number,
and that has been stable behavior for a very long time.

It will be interesting to see if filesystem changes in Longhorn or
later affect this.

> I known, I should better formulate that in a CP for the IHE Technical
> Framework - but I am not sure, if I will find the time...

If you can come up with a better suggestion, we would be happy to hear
it.

Regardless, it is important to remember that whatever DICOM and IHE
says, media creators will continue to have difficulty with this, so
it is important that applications reading and importing media be very
tolerant of case variations, filename length variations, and the
presence or absence of version numbers, periods and extensions, if
they want to present the user with a pleasant experience.

David

Hi David,

In my opinion, its better to rely on a standardized file name mapping as

SUSP - System Use Sharing Protocol Standard
(The base layer of the Rock Ridge Standard)
[http://www-uxsup.csx.cam.ac.uk/~bjh21/susp112.pdf]

and

RRIP - Rock Ridge Interchange Protocol Standard
(The high level part of Rock Ridge)
[http://www-uxsup.csx.cam.ac.uk/~bjh21/rrip112.pdf]

than to rely on the default mapping convention of (all?) Linux
distributions.

I even guess, using Joliet Extension as non-standard, but at least
published
[http://www-plateau.cs.berkeley.edu/p.../jolspec.html]
Specification, rather increases than decreases the number of systems
which are able to read the created media.

One more pragmatic argument for allowing Joliet is that I did not found
any hint in the documentation of MS Windows XP's IMAPI (Image Mastering
API)
[http://msdn.microsoft.com/library/de...ering_api.asp]
how to create CD-ROMS WITHOUT Joliet Extension with it - who wonders?.
So you have probable to install a commercial or free ware library for
creating the ISO Image and - it seems you cannot use IMAPI to burn an
external generated ISO image on the disk - also for controlling the
CD-Writer, to generate CD-ROMS without Joliet Extension. Even that is
not a technical challenge to do so, I guess, that some product managers
will decide to put up with breaking the IHE PDI Specification in favor
to avoid usage/bundling of an additional third-party library by/with
their products. If too many prefer the convenience using only build-in
features of MS WinXP, it may weaken the value of the IHE PDI Specification.

So I still think allowing Rock Ridge + Joliet + Apple's HFS
[http://developer.apple.com/technotes/fl/fl_36.html] - but further
restricting file names to ISO 9660 Level 1 compliance - is the better
choice.

But I am not a CD ROM file system expert at all, so may be we should
forward the question to a more qualified forum - if you have not already
done so and got the different conclusions.

Best Regards,

gunter

David Clunie wrote:
> Hi Gunter
>
> Gunter Zeilinger wrote:
>
>> Yes, the IHE PDI Integration Profile forbids to use Rock Ridge and
>> Joliet extensions. But is that really helpful for increasing the
>> number of system which can read such created media, compared to media
>> containing additional file system meta data. (Rock Ridge definitely
>> does not violet ISO 9660 Level 1; I am not sure about Microsofts
>> Joliet extension).
>
>
> The problem is that the presence of Rock Ridge and Joliet extensions
> impairs the ability to reliably read the DICOM files, since their
> presence interferes with the mapping of the DICOM file names on
> various systems. If the extensions were required to be present and
> supported
> that would not be a problem, but since they are not, their unpredictable
> presence causes problems, hence they are forbidden.
>
>> - And I don't like the workaround with lowercase letters in HTML
>> links, assuming a particular file name mapping of potential readers
>> (now and in 20 years).
>
>
> Nobody likes workarounds but the fact remains that this work around
> works for now. It is predicated on the default Unix/Linux ISO 9660 mount
> behavior being to lowercase letters with no period and version number,
> and that has been stable behavior for a very long time.
>
> It will be interesting to see if filesystem changes in Longhorn or
> later affect this.
>
>> I known, I should better formulate that in a CP for the IHE Technical
>> Framework - but I am not sure, if I will find the time...
>
>
> If you can come up with a better suggestion, we would be happy to hear
> it.
>
> Regardless, it is important to remember that whatever DICOM and IHE
> says, media creators will continue to have difficulty with this, so
> it is important that applications reading and importing media be very
> tolerant of case variations, filename length variations, and the
> presence or absence of version numbers, periods and extensions, if
> they want to present the user with a pleasant experience.
>
> David
>


--
Gunter Zeilinger
Tiani Medgraph AG
http://www.tiani.com

Download my PGP public Key at
http://pgpkeys.pca.dfn.de:11371/pks/...4BDE1A40A7294D