<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi John,<br>
<br>
I wasn't trying to be harsh, it's just once in a while somebody
appears here asking for dicom 145 sample files, and I still don't
have nothing official, appart from 'vendor interpretations'.<br>
<br>
<div class="moz-cite-prefix">El 05/08/14 11:23, John Stevenson-Hoare
escribió:<br>
</div>
<blockquote
cite="mid:3F7B3A750517124893CF96FCDAAE6B690B531B29@Exchange.ffei.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
{color:#0563C1;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
span.EmailStyle17
{font-family:"Calibri","sans-serif";
color:windowtext}
.MsoChpDefault
{font-family:"Calibri","sans-serif"}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
{}
-->
</style>
<div class="WordSection1">
<p class="MsoNormal">Alvaro,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It wasn’t clear to me what the original
requestors were asking for. I hoped that this utility would be
of some use in seeing what kind of content exists in each of
the elements of the file-set. I am very confident that the
content (in terms of elements and type) is correct because, as
I said I used the (un)official validation tool written by
David Clunie (who is a major player on the DICOM committee)
and have provided files to him personally that he has checked
also. Tools such as the DICOM parser also open the files and
viewers (such as the Santesoft viewer) can also open the
image, so I have confidence that the file is syntactically
correct.</p>
</div>
</blockquote>
We all know David Clunie, but I think you misunderstood the tool.
Being "DICOM correct" doesn't mean you're following correctly the
DICOM sup.145 correctly. Let me follow the information David Clunie
gives for dciodvfy:<br>
<br>
---- cut ----<br>
<br>
Features ...<br>
<br>
Checks attributes in file against requirements of IODs and Modules
defined in DICOM PS 3.3 Information Object Definition (dciodvfy)<br>
Checks encoding of data elements and values against encoding rules
of the DICOM PS 3.5 Data Structures and Encoding (dciodvfy)<br>
Checks data element value representation and multiplicity against
data dictionary in DICOM PS 3.6 Data Dictionary (dciodvfy)<br>
Checks consistency of attributes in multiple files that are supposed
to be the same for the same entity in all instances (dcentvfy)<br>
[...]<br>
<meta charset="utf-8">
FAQ ...<br>
<br>
- Are dciodvfy and dcentvfy an officially recognized or supported
tool for certifying DICOM compliance?<br>
No. Neither the DICOM Standards Committee nor MITA (NEMA) have any
official tool or certification mechanism. The dciodvfy tool is used
in IHE Connectathons, along with other tools like DVTK, as an aid in
establishing success or failure.<br>
<br>
- Is a file that passes dciodvfy with no errors or warnings
guaranteed to "work"?<br>
No. This is both because dciodvfy may not detect all errors, and
because DICOM compliance alone may not be sufficient to satisfy the
expectations for any particular application. E.g., the standard may
permit anatomical or orientation information to be absent, but the
user expects the images to be hung on the display in anatomical
order.<br>
<br>
---- cut ----<br>
<br>
So, you can form a DICOM file perfectly compliant to dciodvfy, as
you put the correct attributes, and encode the data elements the
right way, and so on, but not compliant with sup.145 because you
didn't order, or cut the images correctly, or didn't use multiframe
in the right way...<br>
<blockquote
cite="mid:3F7B3A750517124893CF96FCDAAE6B690B531B29@Exchange.ffei.local"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"> </p>
<p class="MsoNormal">You may be right when you say there are no
‘official nema’ images. I do not know how NEMA create other
‘official’ images but they are not a scanner manufacturer so
unless a vendor, such as FFEI Ltd (who I work for) generate
these files I do not see how they can make some without
converting in any case. Leica convert their internal format on
export to create DICOM files – they do not scan to DICOM (at
least not in their SCN400 series scanners, don’t know for
their Aperio scanners).</p>
</div>
</blockquote>
NEMA created the sup.145 together with Aperio (among others in the
WG26), so it's not like they created it out of the blue without
contacting anybody. They are a group formed by companies and users
of the industry.
<blockquote
cite="mid:3F7B3A750517124893CF96FCDAAE6B690B531B29@Exchange.ffei.local"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"> </p>
<p class="MsoNormal">Of course decompressing and re-compressing
lossy JPEG can lose information present in the original image.
This is not at issue. The DICOM media file format is primarily
intended as an interchange format. If the data does not need
to be de- and re-compressed for transit from scanner to image
storage (eg PACS) then this avoids your concern over image
quality. Of course vendors choose formats for all sorts of
reasons, some of them to avoid issues of IP, and consequently
result in apparently strange content. If the vendor format is
suitable (and I appreciate many are not) then there is no
reason to go through the de- and re-compress cycle.
Unfortunately if you use OpenSlide you are forced down this
route.</p>
</div>
</blockquote>
So the thing is: this is an issue unless 1) vendors begin to ship
natively DICOM images 2) we take uncompressed TIFF as source and
only compress once 3) use lossless compression.<br>
<br>
Sorry about the misunderstandings of not being a native english
speaker.<br>
<br>
Thanks<br>
<br>
</body>
</html>