CD-R Media FSC and ISO 9660 Level 1 - DICOM

This is a discussion on CD-R Media FSC and ISO 9660 Level 1 - DICOM ; Hi, 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: CD-R Media FSC and ISO 9660 Level 1

  1. CD-R Media FSC and ISO 9660 Level 1

    Hi,

    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



  2. Re: CD-R Media FSC and ISO 9660 Level 1

    > 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.




  3. Re: CD-R Media FSC and ISO 9660 Level 1

    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

  4. Re: CD-R Media FSC and ISO 9660 Level 1

    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


  5. Re: CD-R Media FSC and ISO 9660 Level 1

    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

+ Reply to Thread