Looking for Dicom-145 sample files

[Alvaro Gonzalez]

Hi John,

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

El 05/08/14 11:23, John Stevenson-Hoare escribió:
>
> Alvaro,
>
> 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.
>
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:

---- cut ----

Features ...

Checks attributes in file against requirements of IODs and Modules 
defined in DICOM PS 3.3 Information Object Definition (dciodvfy)
Checks encoding of data elements and values against encoding rules of 
the DICOM PS 3.5 Data Structures and Encoding (dciodvfy)
Checks data element value representation and multiplicity against data 
dictionary in DICOM PS 3.6 Data Dictionary (dciodvfy)
Checks consistency of attributes in multiple files that are supposed to 
be the same for the same entity in all instances (dcentvfy)
[...]
FAQ ...

- Are dciodvfy and dcentvfy an officially recognized or supported tool 
for certifying DICOM compliance?
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.

- Is a file that passes dciodvfy with no errors or warnings guaranteed 
to "work"?
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.

---- cut ----

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

Sorry about the misunderstandings of not being a native english speaker.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20140805/b643ab18/attachment-0001.html