1 -----------------------------------------------------------------------------
2 Proposed Template of an entry in this TODO:
3 (Note: Date is the date of registering of first demand.)
14 -----------------------------------------------------------------------------
15 Description: Change jpeg 'exit' call to standard c++ exception using the jpeg error
21 -----------------------------------------------------------------------------
22 Description: Add kwsys as a subdir somewhere in gdcm
27 -----------------------------------------------------------------------------
32 Comments: ljpeg was rip from medcon and not the official one. medcon tried to
33 optimised function using MACRO (doh!), so it make its very unreadable and very
34 hard to fix warnings. Should go back to official source, copy proper copyright
35 and fix warnings on dashboard
36 -----------------------------------------------------------------------------
37 Description: Extent reading support
41 Comments: All ITK/VTK readers support selecting extent. gdcm should support selecting
42 extent before being inserted into ITK
43 -----------------------------------------------------------------------------
44 Description: Generate new UID each time we write DICOM
48 Comments: According to DICOM ref a new UID should be created each we write a
49 DICOM images. I guess it should be an option so that we can still use md5sum to
50 check dicom file. The proposed way was:
51 http://www.creatis.insa-lyon.fr/pipermail/dcmlib/2004-September/000611.html
53 Bah, comme Win32 pose encore pb:
55 0000000 147 144 143 155 012
57 radical + 147.144.143.155 + IP + time()
59 -----------------------------------------------------------------------------
60 Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
63 Details: vtkGdcmReader::CheckFileCoherence() sets the DataOrigin[i]
64 but doesn't set the plane (image seen in 3D) normal (is it
65 possible any how). This plane normal could be extracted from
66 the "orientation" info of the gdcmHeader ( refer to
67 grep "Orientation" Dicts/dicomV3.dic).
68 Problem exhibiting this defect: cine loop on a pile of images
69 whose Origin is correct, but whose normal is not set will
72 * vtkGdcmReader inherits from vtkImageReader which aggregates
73 a vtkTranform. vtkGdcmReader could store (when the user requires
74 it, see below) the origin/normal taken from the Dicom Header
75 within this vtkTransform (looks like a natural place to store
76 this spacial information).
77 * Both settings of the origin and/OR the normal of the plane (image)
78 should be an option defined with a flag (On/Off) in the
80 -----------------------------------------------------------------------------
81 Description: Fix the Python wrappers
86 -----------------------------------------------------------------------------
87 Description: clean up gdcmFile/gdcmHeader relationship
91 * simplify the API for the user (no need to call GetImageData() before
93 * avoid memory leaks with with Pixel_Data.
95 -----------------------------------------------------------------------------
96 Description: remove all autotools references
101 -----------------------------------------------------------------------------
102 Description: introduce namespace "gdcm"
107 1/ Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin
109 2/ Question: when introducing the namespace, should we remove the gdcm
110 prefix from classes or keep it ?
111 -----------------------------------------------------------------------------
112 Description: complete the doxygen Documentation
117 -----------------------------------------------------------------------------
118 Description: test the private dictionary part.
123 * Frog: where can we obtain such a private/dictionary and the corresponding
124 Dicom file ? Any examples on-line ?
125 -----------------------------------------------------------------------------
126 Description: fix definitively the memory leaks problems.
130 Comments: There is a nightly dashboard that run valgrind every night
131 (zorglub | GDCM-Linux-g++)
132 -----------------------------------------------------------------------------
133 Description: test gdcm on a big endian OS.
137 Comments: There is a nightly dashboard that run on MacOSX each nite
138 (midworld.kitwarein | GDCM-DarwinG5-g++ )
139 -----------------------------------------------------------------------------
140 Description: More tests !
144 * an example of new test could be to clone a Dicom image by
145 copying gdcmDocEntry one after the other
147 * look at traversal used in Example/FlatHashTablePrint.cxx
148 -----------------------------------------------------------------------------
149 Description: revoir la gestion des resources, win32 permet d'inclure des
150 fichiers texte (=dicomV3.dic) dans une dll ou quelquechose du genre.
155 * Frog: no comprendo !? De plus est-ce portable ?
156 * To improve load time it could be usefull to have the dictionary directly in
157 'c++' code or in a more binary format.
158 * This will also solve some issues where /dummy/ user did nor set
159 GDCM_DICT_PATH properly neither 'make install'
160 -----------------------------------------------------------------------------
161 Description: Convert the C-like IO to C++ IO:
165 remove all the C-oriented IO references like FILE*, fread...
166 and replace them with the C++ fstream notation.
167 Provide overload of operators << and >> for any gdcm class using file IO.
169 * Question: the underlying jpeg libraries (written in C) use the FILE*
170 notation. Is there a way to still use fstream in gdcm, and
171 build or pass the proper FILE* to jpeg libs ?
172 * Binary IO references are available at
173 http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
174 * The internal API should be rewritten so that gdcm speaking to jpeg lib is
175 done with stream/string and not directly opened FILE*
176 * No stdio.h anymore anywhere tolerated !
177 -----------------------------------------------------------------------------
178 Description: generate methods based on VM.
182 * cmake should parse le DICOM dictionary to generate methods like
183 gdcm???::SetImagePosition(int, int)
185 //generated content do not edit
188 gdcm???::SetImageNumber(int)
190 //generated content do not edit
194 * Regrain: a dicom dictionary entry name is NOT UNIQUE [this means
195 two tags=(group, element) can share the same name].
196 What should the wrapper do in such a case !?
197 * Frog: what does VM stand for ?
198 * VM = Value Multiplicity
199 -----------------------------------------------------------------------------
200 Description: Add information on supported imagers (constructor/model)
203 Details: in order to promote gdcm make a list (on the web pages)
204 of images successfully parsed based on a constructor/model ordering
205 Comments: * frog: gdcmData only lists pathological images. How to collect
206 the ones gdcm works smoothly with (hopefully gdcmData is a small
207 subset of what we would like).
208 -----------------------------------------------------------------------------
209 Description: Add a GetVersion() global function.
212 Details: This is to be used for version assertion with gdcmPython
214 -----------------------------------------------------------------------------
215 -----------------------------------------------------------------------------
216 * vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
217 be made at the cost of memory consumption (refer to header of
218 vtk/vtkGdcmHeader.cxx)
219 -----------------------------------------------------------------------------
220 * gdcmElValSet::SetElValueLengthByNumber IMNSHO should be trashed.
221 It's only purpose is a onliner substitute to calling GetElValueByNumber
222 and then SetLength. This only obfuscates the caller code more than
224 Besides the definition of gdcmElValSet::SetElValueLengthByNumber itself
225 it quite poor since it is a almost exact copy of
226 gdcmElValSet::GetElValueByNumber except for the returned code.
227 gdcmHeader::SetPubElValLengthByNumber (which is based on
228 gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
229 -----------------------------------------------------------------------------
230 * Fix the bug in Test/bug1.cxx (see first comment line): Win32 only.
231 -----------------------------------------------------------------------------
232 * All (or at least many of) the methods of gdcmHeader whose only arguments
233 are an ElValue* (e.g. FindLength, FindVR, LoadElementValue...) can
234 be moved away to ElValue class on condition of transmitting the
235 gdcmHeader.fp attribute. This change should be considered since it
236 would allow those method to avoid artificial calls to ElValue::GetElement(),
238 -----------------------------------------------------------------------------
239 * Eat leading_trailing_whitespace (found in python/gdcmPython/gdcmi) should
240 be used when parsing the dictionary in C++ !
241 -----------------------------------------------------------------------------
242 * Group length is not a unique tag in a file. Hence avoid putting it
243 in the element values dictionary without doing something smarter
244 (say, instead of storing the length store the group and the length
245 so we can related a length to a group).
246 -----------------------------------------------------------------------------
247 * GetPubElValByNumber doit faire la difference entre chaine vide
248 et chaine pas touve''. Eventuellement raiser une exception ?
249 -----------------------------------------------------------------------------
250 * gdcmHeader::LoadElements only loads the element whose length is
251 below the specified size. When accessing the value of such an element
252 the content is unfound ! Find a decent way of loading the value on
254 -----------------------------------------------------------------------------
255 * JPR: fournir une method qui ne fait que lire les elements passes en arguments
256 sous forme d'une liste.
257 -----------------------------------------------------------------------------
258 * JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
259 suite si on a deduit que c'en est pas...
260 -----------------------------------------------------------------------------
261 * python /usr/lib/python2.2/site-packages/DaVaW/demo/dvwDcmReader.py
262 and load image /home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
263 will yield wrong coloring scheme as opposed to
264 affim filein=/home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
265 -----------------------------------------------------------------------------
266 * gdcmFile should implement the following API:
268 WriteDicom.SetFileName("MyDicomFile.dcm");
269 string * AllTags = gdcmHeader.GetDcmTagNames();
270 WriteDicom.SetDcmTag(AllTags[5], "253");
271 WriteDicom.SetDcmTag("Patient Name", "bozo");
272 WriteDicom.SetDcmTag("Patient Name", "bozo");
273 WriteDicom.SetImageData(Image);
276 Anonymize(ostream& output) {
277 a = gdcmFile("toto1");
278 a.SetPubValueByName("Patient Name", "");
279 a.SetPubValueByName("Date", "");
280 a.SetPubValueByName("Study Date", "");
283 -----------------------------------------------------------------------------