Looking for Dicom-145 sample files

[John Stevenson-Hoare]

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.

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

BTW my comment around orientation is only that I found it difficult from the lack of information in the OpenSlide API to determine the orientation relative to the DICOM standard. I have no difficulty in understanding the standard in this respect.

Yves,

The purpose here is to provide a means for the requestors to see what a DICOM (supplement 145) file set contains. In the context of the project that it was developed, the tool allows us to take files for analysis from any vendor supported by the OpenSlide library. Analysis cannot be done directly through the OpenSlide library as we are running code in a browser to perform the analysis client-side as the files are too large to upload. Hence we standardised on DICOM as the source file type.

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.

John
________________________________
[FFEI_Logo_BoxOnly[1].png]<http://www.ffei.co.uk> [FFEI wins 3rd Queens award for innovation] <http://www.ffei.co.uk/ffei-wins-third-queens-award-for-innovation/>
CONFIDENTIALITY AND DISCLAIMER NOTICE

This message and any attachment is confidential and is protected by copyright. If you are not the intended recipient, please email the sender and delete this message and any attachment from your system.

Dissemination and or copying of this email is prohibited if you are not the intended recipient. We believe, but do not warrant, that this email and any attachments are virus free. You should take full responsibility for virus checking.

No responsibility is accepted by FFEI Ltd for personal emails or emails unconnected with FFEI Limited's business.

FFEI Limited is a limited company registered in England and Wales (Registered Number: 3244452).

[Join us on Linked In]<http://www.linkedin.com/company/ffei> [Follow @FFEI_ltd] <https://twitter.com/FFEI_ltd>  [FFEI YouTube Channel] <http://www.youtube.com/user/FFEIPrintTechnology>
Registered Office: The Cube, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 7DF, England.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20140805/fd32cc51/attachment.html