[Dcmlib] GDCM problems with created dicom]

[Jean-Pierre ROUX]

At 11:26 -0500 20/12/04, Mathieu Malaterre wrote:
>Jean-Pierre ROUX wrote:
>>Bonjour.
>>
>>Maintenant, nous savons *ou* David Clunie va chercher l'info 
>>'BytesPerWord' : dans la 'Value Representation' de 7FE0,0010.
>>Qui est une info facultative.
>>Et, lorsqu'elle y est, si ca ne matche pas avec le reste, il sort 
>>en erreur, alors que même e-film s'en tape ...
>>
>>La conclusion de ca, c'est qu'il faudra verifier que nos images, en 
>>plus d'etre efilm-readable soient egalement D.Clunie-readable
>>Et vtkgdcmViewer-displayable ... car les images avec 
>>PixelSpacing=0.0 dans les 2 dimensions, telles qu'en propose 
>>D.Clunie dans son Data set Compression, c'est pas terrible !
>>
>>Pour ce qui est de la modif de la VR de 7fe0,000 en fonction du contexte ...
>>est-ce que ca parrait une idee raisonable de creer une Virtual 
>>DictEntry des que l'on a fini le parsing, et de lui affecter une VR 
>>qui matche BitsAllocated (et surtout, qui soit modifiable par la 
>>suite sans tout peter).
>>Au moment d'une eventuelle ecriture du fichier en utilisant ce 
>>Header, on pourra remettre cette VR en concordance avec le reste 
>>(si l'utilisateur a, par exemple, 'fabriqué' une image 8 bits a 
>>partir d'une image 16 bits)
>
>JP,
>
>	Voila le fix qui a ete fais sur ITK-gdcm:
>
>http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/gdcm/Dicts/dicomV3.d 
>ic.diff?cvsroot=Insight&r1=1.1&r2=1.2
>
>	Est-ce que je peux faire la meme chose ou il y a un truc que 
>j'ai manquer ?


C'est la modif que proposait Bill, n'est-ce pas?
On peut la commiter ainsi, immédiatement.
Ca resoudra le probleme des images 16 bits generees par gdcm -la 
plupart des images, vraisemblablement-
Mais on aura le pb symetrique, pour d'éventuelles images 8 bits 
générées par gdcm, qui continueront a etre efilm-readable, mais qui 
planteront, et ca sera nouveau, sur Dicom3Tools.
Ou pour des images, transformées de 16 en 8, par exemple, par un 
utilisateur qui aurait fait le boulot proprement, mais qui sera dans 
l'impossibilité de modifier la VR de l'element (7FE0,0010).
C'est pourquoi je proposais la creation, des la fin du parsing, d'une 
'Virtual Dict Entry', contenant une VR qui matche à coup sûr les 
pixels (BitsAllocated), et surtout, dont la VR sera etre modifiée, 
lors du Write, pour continuer a matcher les Pixels, si un utilisateur 
a fait une modif.

Le pb de la creation ex nihilo d'une image Dicom, quel que soit la 
valeur de son BitsAllocated, sera resolu ipso facto.

>
>Mathieu
>Ps: je vais voir si c'est complique' d'ajouter des tests dans gdcm 
>qui depende de dcmtk/clunie.

Ca obligerait d'avoir Dicom3Tools pour lancer la testsuite de gdcm?

Il faudra, de toute façon, continuer a verifier 'a la main' que les 
images generees par gdcm sont e-film readable (il me semble avoir 
remarque, par le passe, que les images pour lesquelles le champs 
SamplesPerPixel etait absent plantient sous efilm -c'est toujours le 
cas- et passaient partout ailleurs -dont Dicom3Tools-)


JPRx








  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr