Showing posts with label DICOM. Show all posts
Showing posts with label DICOM. Show all posts

Sunday, September 16, 2012

Un cancéreux pirate son dossier médical pour demander l’aide du Web

On parle de DICOM dans un site grand public [1]. Le titre est très accrocheur:
Un cancéreux pirate son dossier médical pour demander l’aide du Web
Après des années de travail sur GDCM (Grassroots DICOM), après avoir fait du reverse engineering sur des modes de compression privés utilisés par certains vendeurs et référencés sur le fameux "hall of shame" [2]. Je me suis dit "wow", j'ai peut-être trouvé la solution au dernier codec non-supporté dans GDCM, le fameux LOSSLESS ELSCINCT que je n'ai jamais pu utiliser !

Je continue donc l'article, qui devient de plus en plus intéressant:
Il décide donc de le « craquer » et de le publier sur son site pour demander de l'aide aux internautes.
Ça y est, on parle de crackage, c'est même plus un gentil hacker, Laconesi est carrément un crackeur ! Le héros des temps moderne, le John Draper des compressions d'images !

La suite de l'article devient beaucoup moins drôle, on parle de "format fermé et propriétaire", et un peu plus loin de "Dicom", j'imagine que l'auteur voulait parler de "DICOM", jusqu'à ce que l'académie française accepte le mot (radar, laser...), ça reste un acronyme, donc en majuscule.

La suite est encore pire "difficilement accessible". C'est là que j'ai arrêté la lecture et j'ai téléchargé ses données:
Je regarde le premier tarball:

$ gdcminfo TAC_CD_20120827_130200/DICOM/00000000 MediaStorage is 1.2.840.10008.5.1.4.1.1.2 [CT Image Storage]
TransferSyntax is 1.2.840.10008.1.2.4.90 [JPEG 2000 Image Compression (Lossless Only)]
[...]


Alors là je comprends ce qu'il s'est passé. Laconesi a pris la première implémentation DICOM qu'il a trouvée sur sf.net et/ou code.google.com et évidement le codec JP2 n'était pas disponible...d'où sa démarche. Pour le coup JP2 est une norme ISO dont l'accès à la norme est payant, alors que DICOM n'est pas une norme ISO et l'accès au standard (fichiers PDFs) est complètement et entièrement gratuit.

Je rejoins l'article dans le sens où il y a beaucoup d’implémentations DICOM, mais elles ne sont pas toutes équivalentes. Mais c'est un autre débat, et des groupes comme debian-med ont par exemple rassemblé sous une seule organisation les meilleurs softs open-source pour le domaine médical, dans notre cas le sous-groupe debian-med est celui-ci:
On y retrouve quelques implémentations DICOM, dont GDCM qui elle implémente le codec JP2. Le problème est que plusieurs d'entres elles ne le supportent pas du tout. Ou alors le supportent mais utilisent Jasper (une implémentation JP2 invalide pour DICOM), comme expliqué lors de ma présentation à RMLL/2011 (et 2012 d'ailleurs):
Le titre de l'article est très accrocheur mais, à mon sens, il rate vraiment le principal :
  1. meilleur support de JPEG 2000 dans le monde opensource (vous pouvez me rejoindre @openjpeg)
  2. interface simplifiée pour relire les images (ginkgocadx est bien dans cette approche mais utilise DCMTK pour lire les fichiers DICOM, et DCMTK a décidé de ne pas distribuer gratuitement son module JPEG 2000 [3].
Sinon la fin de l'article évoque un problème intéressant: l’accès à des images numériques médicales. Là je suis entièrement d'accord avec l'auteur, cela devrait être simplifié. Mais comme l’Europe et l’Amérique du Nord ont des conditions très dures pour la diffusion des informations patient (Protected Health Information[4]), le plus simple c'est de ne pas diffuser du tout les informations patient.

Ce côté me rassure, car je ne serais pas du tout heureux d’apprendre que mon dossier médical traîne sur des réseaux sociaux. C'est pour cela que la démarche émane forcement du patient lui-même, et j'invite donc notre "apprenti craqueur" à transmettre ses données directement à Patient Contributed Image Repository (PCIR) [5] de façon à contribuer à une meilleure connaissance de DICOM par le grand public.

Si vous êtes arrivés jusque-là, merci de votre lecture et comme je le dis souvent, ramenez vos CD (écho, radio, IRM...) à votre domicile et vérifiez par vous-même que vous avez accès à vos propres données via un soft open source !

Saturday, March 19, 2011

GDCM accepted as GSoC mentoring organization !

I have the immense pleasure to tell you that GDCM has been accepted as one of the 175 organizations participating in GSoC 2011:

http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2011

I will send out more details in the next few days, but this is
definitely a fantastic news. I would like to thank everyone of you who
participated with ideas and suggestions.

Tuesday, March 15, 2011

Quadro 2000D

Review high-resolution, detailed patient imagery and make a confident diagnosis faster with the NVIDIA® Quadro® 2000D – the industry's most advanced diagnostic imaging graphics solution. Delivering best-in-class performance, two dual-link DVI connectors for display flexibility, support for 10/12bit grayscale monitors up to 10Mpixels, and DICOM monitor calibration capabilities – the Quadro 2000D enables more confident medical analysis.

http://www.nvidia.com/object/product-quadro-2000d-us.html

Monday, March 7, 2011

GDCM Goes GSoc !

An application for GDCM has been submitted to GSoc 2011 !

Here is the list of current proposals:
GDCM Summer of Code 2011


Read the announcement:

Mentoring Organization Applications Now Being Accepted for Google Summer of Code! - Google Open Source Blog

Saturday, April 10, 2010

Exporting the DICOM Standard to docbook

I have finally found sometime to update PS 3.3 XML in GDCM using the newest standard: PS 3.3 - 2009.

It seems however that there has been some internal changes in OpenOffice.org and the docbook export function does not work as well as it used to be.

For instance see this bug report:

http://www.openoffice.org/issues/show_bug.cgi?id=110762

Monday, December 14, 2009

PDF Library

In GDCM, I needed a PDF library in order to cope with Encapsulated PDF Storage (1.2.840.10008.5.1.4.1.1.104.1)

I thought poppler would fit the need, but anytime a new release would come out, the API would be badly broken. Eg:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555959

Today I found out, there is a new effort:

http://planet.gnu.org/gnupdf/

I'll have to keep an eye on it, and drop poppler which is only a rendering library (it pulls dependencies to fonts library !).

Monday, November 30, 2009

LC_NUMERIC

I was recently involved in a thread on ITK mailing list, where it was discussed the use of LC_NUMERIC. In DICOM it is very important to write floating point number in C-style format.

At first I thought I could test using:

http://groups.google.com/group/comp.lang.c++/browse_thread/thread/a881d87a65b260b7

well in fact it is much more complex:

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Testing/Source/DataStructureAndEncodingDefinition/Cxx/TestLCNumeric.cxx?view=markup

Now I can setup test to check whether GDCM is LC_NUMERIC independant or not !

Wednesday, November 25, 2009




You want the best from GDCM, but are you are using Activiz ? Well take the best from both.
You can now use GDCM directly from C# using the Activiz framework !

This image was a screenshot of:

$ mono ./bin/HelloActiviz3.exe ~/Creatis/gdcmData/012345.002.050.dcm

Enjoy.

Thursday, November 12, 2009

Private DICOM dictionary

Looking at the private dictionary for pydicom:

http://code.google.com/p/pydicom/

It says:

http://code.google.com/p/pydicom/source/browse/source/generate_dict/make_private_dict.py

...
# Generates output from a file from the MDCM project (http://code.google.com/p/mdcm),
...

The only issue is that mdcm is LGPL, while pydicom claims to be MIT... There is a clear conflict of license here.

So I filled in a bug report:

http://code.google.com/p/pydicom/issues/detail?id=61&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Difficulty

I cannot believe they prefered to used the dictionary from mdcm, instead of using the easy-to-parse XML dictionary from GDCM

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/privatedicts.xml?view=markup

oh well...