Review of Draft Supplement 57 - Revised Secondary Capture Objects
David Clunie
Here is the call for comments on Sup 57 forwarded from NEMA
to "news:comp.protocols.dicom".
david
-- begin forwarded message --
October 26, 2000
Subject: Review of Draft Supplement 57- Revised Secondary Capture
Objects
Comments are being solicited from interested groups and individuals
outside NEMA and the DICOM Committee on the Draft Supplement 57- Revised
Secondary Capture Objects. The latest draft is dated September 27,
2000.
It may be obtained from the NEMA ftp site at:
ftp://medical.nema.org/medical/dicom/supps
The filename is "sup57_pc.pdf". Please provide any comments you may
wish
to make on the draft.
To assist in processing, analyzing, and the incorporation of
pertinent comments, we would appreciate your following these guidelines.
* For all comments, please state the commentator's full name, title
and address; phone and fax number.
* Provide full name and address when filing for an organization.
* Clearly differentiate between editorial, minor and major technical
comments.
* Comments should be constructive.
* In cases of unclear statements and text it is best to rephrase the
questionable text as interpreted.
* Provide alternative language for items of editorial nature.
* Provide recommendations for solving technical problems.
Be specific, and when possible, include references from the literature
to
support your comments.
* Whenever possible include supportive data.
* Organize and identify all comments in accordance with the format
provided
by the standard and consecutively number all comments. Each comment
should
be referenced and discussed as follows:
Section or Annex
Page number, paragraph and line
Comment
Rationale
Suggestion and alternative to remedy situation
Note: Comments accompanied by a disk are most welcome.
All comments should be submitted by December 10, 2000 to:
David Snavely, Industry Manager
NEMA
1300 North 17th Street, Suite 1847
Rosslyn, VA 22209
Fax: (703)841-3385 Tel: (703)841-3285
E-mail: dav_s...@nema.org
We are very appreciative for your taking the time to comment, and
every consideration will be given to incorporate your comments into the
draft.
Sincerely,
David R. Snavely
Industry Manager
NEMA
-- end forwarded message --
Gilles MEVEL
I had a quick look at this supp. 57 and don't really understand
why things have to be so complicated...
I agree that Multiframe SC is necessary in DICOM, but I should like to
know why 5 new IODs have to be defined.
The main difference between those IODs seems to only concern pixel
data format : One bit/pixel, Byte Grayscale/pixel, Word
Grayscale/pixel, Palette or RGB color.
Why not a single IOD just like for traditional single-frame SC ?
I think WG6 has good reasons for that, and perhaps my question is
stupid, but could someone clarify this ?
Have a nice day
Gilles Mevel
ETIAM
------------------------
On Thu, 26 Oct 2000 09:53:43 -0400, David Clunie <dcl...@idt.net>
wrote:
------------------------
David Clunie
Extremely good question !
The answer is because conformance to limited types of pixel
data has been the key failure of the existing SC object.
Some people support 8 bit, some 16 bit, some grayscale, some
RGB, etc. Probably no one supports single bit. Certainly no
one supports all possibilities, not even the common ones.
The intent is to specify new SOP Classes for specific purposes
so that when reading the conformance statement and negotiating
an association there is no question as to what forms of pixel
data are supported by the SCP (or FSR in the case of media).
david
Gilles MEVEL wrote:
>
> Hello all
>
> I had a quick look at this supp. 57 and don't really understand
> why things have to be so complicated...
>
> I agree that Multiframe SC is necessary in DICOM, but I should like to
> know why 5 new IODs have to be defined.
>
> The main difference between those IODs seems to only concern pixel
> data format : One bit/pixel, Byte Grayscale/pixel, Word
> Grayscale/pixel, Palette or RGB color.
>
> Why not a single IOD just like for traditional single-frame SC ?
>
> I think WG6 has good reasons for that, and perhaps my question is
> stupid, but could someone clarify this ?
>
> Have a nice day
>
> Gilles Mevel
> ETIAM
--
David A. Clunie mailto:dcl...@comview.com
Development Director, Medical Imaging Products http://www.comview.com/
ComView Corporation Work 914-332-4800 Fax 208-206-3566
220 White Plains Road, 5th Floor Home 570-897-7123 Fax 570-897-5117
Tarrytown NY 10591 http://idt.net/~dclunie/
dee csipo
This will eventually create a very interesting side effect. Either some
companies will exceed the maximum size of the A-ASSOCIATE_REQ or learn not
to include all the possible presentation contexts in the association
negotiation :-). I am for, more specific SOP classes to eliminate the
possibility of incompatibility of the message content. past the negotiation
phase.
DICOM has not achieved the level of inter-operability, as promised, right
out of the box. Plug and play is further away for DICOM than it is for
Microsoft (and even that is a fair distance). DICOM plug and play is
defined as "you plug it and then play until it works". (Although I must
admit the situation has vastly improved over the past couple years.) But we
have new players coming into the game. Have you been receiving images from
VL modalities? Most of them are a total disaster, with some exceptions
where the manufacturers had the foresight to turn to people who gained
expertise in the radiology arena. So more and more specific SOP classes are
the answer.
dee
;-D
BTW this is a strictly correct, and slightly tainted opinion :-}>
Hapo
I thought the definition of new IODs is the best way to simplify the complex
and huge DICOM Services.
The huge IODs will simplify the Objects contents.
And the SCU could directly process the object via the IOD definition.
It won't be necessary to distinguish the correct sub-type from the similar
objects.
Which traffic system you like ?
A. Multiple Entrances , but one direct way to the destination.
B.One Entrance , but you should pass a maze to the destination.
I like A.
I think this is a right way to make the DICOM fit the modern IT world.
Best regards ,
HAPO
David Clunie
highly specific storage IODs and SOP Classes. In both the SR and
Waveform supplements, there was an opportunity to define only a
very generic SOP Class, but this was not done. Instead very
specific SOP Classes were defined (application-specific in the
case of waveform, and in a hierarchy of increasing complexity in
the case of SR).
The limit that Dee refers to is the number of presentation contexts
that may be negotiated. There is one of these per combination of
SOP Class (abstract syntax) and transfer syntax, and it is conveyed
by a single 8-bit byte that may only be odd integers between 1 and
255, i.e. 128 maximum (PS 3.8 9.3.2.2). Note also that there is a
potential (lower than 128) limit on the number of presentation contexts
accepted: PS 3.8 8.3 "At least 16 presentation contexts per presentation
connection must be supported", although I am not sure if this applies
to the TCP-IP ULP or not.
In other words, it isn't practical to try to negotiate every combination
of storage SOP class and transfer syntax on a single association.
david
--
David A. Clunie mailto:dcl...@comview.com
Development Director, Medical Imaging Products http://www.comview.com/
ComView Corporation Work 914-332-4800 Fax 208-445-5867