]> Creatis software - gdcm.git/blob - TODO
COMP: Fix compilation on MacOSX
[gdcm.git] / TODO
1 -----------------------------------------------------------------------------
2 Proposed Template of an entry in this TODO:
3 (Note: Date is the date of registering of first demand.)
4
5 -------------
6 Description:
7 Date:
8 Attributed:
9 Details:
10 Comments:
11 -------------
12
13 ----------------------------------------------------------------------------
14 Description: Rewrite gdcmDebug so that it works
15 Date: 2004 Dec 07
16 Attributed: Mathieu
17 Details:
18 Comments:
19 ----------------------------------------------------------------------------
20 Description: Need to fix cygwin + wrong path (passing UNIX path when windows patch expected)
21 Date: 2004 Nov 16
22 Attributed: Mathieu
23 Details:
24 Comments:
25 ----------------------------------------------------------------------------
26 Description: Need a test for gdcmHeaderHelper (iterating over gdcmData) for instance
27 Date: 2004 Nov 16
28 Attributed: Mathieu
29 Details:
30 Comments: It used to seg fault when a README file was found
31 ----------------------------------------------------------------------------
32 Description:  gdcmJpeg8 is strictly a copy/paste of gdcmJpeg12.cxx.
33 Date: 2004 Oct 13
34 Attributed: 
35 Details:
36 We should write the code in a common place, then include this 'cxx' file so 
37 the define from gdcm_mangle redefine to the proper one.
38 Comments:
39 This will be usefull since I may need in the future a 16bits version of this 
40 reading
41 -----------------------------------------------------------------------------
42 Description: Change jpeg 'exit' call to standard c++ exception using the jpeg 
43              error
44 handler
45 Date: 2004 Oct 8
46 Attributed: 
47 Details:
48 Comments:
49 -----------------------------------------------------------------------------
50 Description: Add kwsys as a subdir somewhere in gdcm
51 Date: 2004 Oct 8
52 Attributed: Mathieu
53 Details:
54 Comments:
55 -----------------------------------------------------------------------------
56 Description: ljpeg
57 Date: 2004 Oct 8
58 Attributed: Mathieu
59 Details:
60 Comments: ljpeg was rip from medcon and not the official one. medcon tried to
61 optimised function using MACRO (doh!), so it make its very unreadable and very
62 hard to fix warnings. Should go back to official source, copy proper copyright
63 and fix warnings on dashboard
64 13/10: update apparently no dicom toolkit use this lib as it is too buggy. 
65 We should use the ls-patch for ijg instead. Thus we can safely get rid of that
66 lib.
67 14/10: PHILIPS_Gyroscan-12-MONO2-Jpeg_Lossless.dcm prove that I was right the 
68 old Cornwell lib is buggy and does not read anything.
69 -----------------------------------------------------------------------------
70 Description: Extent reading support
71 Date: 2004 Oct 8
72 Attributed: Mathieu
73 Details:
74 Comments: All ITK/VTK readers support selecting extent. gdcm should support 
75 selecting extent before being inserted into ITK
76 -----------------------------------------------------------------------------
77 Description: Generate new UID each time we write DICOM
78 Date: 2004 Oct 8
79 Attributed: Mathieu
80 Details:
81 Comments: According to DICOM ref a new UID should be created each we write a
82 DICOM images. I guess it should be an option so that we can still use md5sum to
83 check dicom file. The proposed way was:
84 http://www.creatis.insa-lyon.fr/pipermail/dcmlib/2004-September/000611.html
85
86 Bah, comme Win32 pose encore pb:
87   echo "gdcm" | od -b
88   0000000 147 144 143 155 012
89 et si on prenait:
90  radical + 147.144.143.155 + IP + time()
91
92 -----------------------------------------------------------------------------
93 Description: gdcmDicomDir and SQItem creation
94 Date: 2004 Nov 16
95 Attributed:
96 Details: DicomDir creates some SQItem (by new). After that, it creates
97   the corresponding DicomDirPatient, etc. using the content of the SQItem
98   (the content is composed with some DocEntry's that can't be destroyed).
99   So, if the SQItem is deleted, then it's content is deleted to. But the 
100   DicomDirPatient, etc. use the content of the SQItem. Then, the SQItem can't
101   be deleted, and when have memory leaks
102
103 -----------------------------------------------------------------------------
104 Description: [BUG] Better handling of unfound Dicom dictionary.
105              When gdcm doesn't find the Dicom dictionary (because it's
106              path to the directory of dictionary is uncorrect, either
107              because the install relative layout was broken after file moves
108              or because the environnement variable GDCM_DICT_PATH is 
109              unpropely set), gdcm will:
110              1/ print a warning
111              2/ throw an exception (that is internaly UNcatched by gdcm)
112                 that in most cases provoques the caller application to
113                 exit uncleanly (uncatched excpetions in fine call abort() ).
114              Additionaly on Win32 the warning print isn't displayed because
115              exiting occurs prior to cerr or cout is flushed properly.
116 Date: 2004 Oct 15
117 Attributed:
118 Details: fixes (from dirty to clean)
119          1/ force Win32 to flush it's buffer so at least the user gets some
120             reason why it's application exited (when called in command
121             environement). Note: it looks like the "cerr << flush" fails. Sigh.
122          2/ within gdcm catch the exception, display a decent warning, and
123             return to caller.
124          3/ see the comment below on how to enhance the API and fix things
125             really cleanly.
126 Comments: ENH proposal:
127           The caller migth not be aware of the path to the dictionaries
128           on invocation of gdcm (think this path is set by the Interface
129           because the caller wants to skip the default gdcm dictionary in order
130           to provide his own ones e.g. another language based one).
131              Hence, gdcm should postpone the parsing of the default dictionary
132           instead of doing it on library entry.
133           This would enable two things:
134            - It would give a chance to the caller to set the path to
135              the dictionaries he whishes to use, through a call to
136              newly created DictSet::SetDictionaryPath( string ).
137            - It would avoid the burden of using the GDCM_DICT_PATH
138              environnement variable and enable GDCM CONTROL FROM WITHIN
139              THE API. Optionaly, if the caller didn't use the API to
140              provide his prefered path, gdcm could still default to 
141              GDCM_DICT_PATH...
142 -----------------------------------------------------------------------------
143 Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
144 Date: 2004 Oct 1
145 Attributed:
146 Details: vtkGdcmReader::CheckFileCoherence() sets the DataOrigin[i]
147          but doesn't set the plane (image seen in 3D) normal (is it
148          possible any how). This plane normal could be extracted from 
149          the "orientation" info of the gdcmHeader ( refer to
150          grep "Orientation" Dicts/dicomV3.dic).
151          Problem exhibiting this defect: cine loop on a pile of images
152                whose Origin is correct, but whose normal is not set will
153                plainly suck !
154 Comments:
155         * vtkGdcmReader inherits from vtkImageReader which aggregates
156           a vtkTranform. vtkGdcmReader could store (when the user requires
157           it, see below) the origin/normal taken from the Dicom Header
158           within this vtkTransform (looks like a natural place to store
159           this spacial information).
160         * Both settings of the origin and/OR the normal of the plane (image)
161           should be an option defined with a flag (On/Off) in the
162           vtkGdcmReader...
163 -----------------------------------------------------------------------------
164 Description: Fix the Python wrappers
165 Date: 2004 Sep 24
166 Attributed: no
167 Details:
168 Comments:
169 -----------------------------------------------------------------------------
170 Description: clean up gdcmFile/gdcmHeader relationship
171 Date: 2004 Sep 24
172 Attributed:
173 Details:
174  * simplify the API for the user (no need to call GetImageData() before
175    calling Write().
176  * avoid memory leaks with with Pixel_Data.
177 Comments:
178 -----------------------------------------------------------------------------
179 Description: remove all autotools references
180 Date: 2004 Sep 24
181 Attributed: no
182 Details:
183 Comments:
184 -----------------------------------------------------------------------------
185 Description: introduce namespace "gdcm"
186 Date: 2004 Jul 30
187 Attributed:
188 Details:
189 Comments:
190   1/ Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin 
191               causes problems.
192   2/ Question: when introducing the namespace, should we remove the gdcm
193               prefix from classes or keep it ?
194 -----------------------------------------------------------------------------
195 Description: complete the doxygen Documentation
196 Date: 2004 Sep 24
197 Attributed:
198 Details:
199 Comments:
200 -----------------------------------------------------------------------------
201 Description: test the private dictionary part.
202 Date: 2004 Sep 24
203 Attributed:
204 Details:
205 Comments:
206  * Frog: where can we obtain such a private/dictionary and the corresponding
207          Dicom file ? Any examples on-line ?
208 -----------------------------------------------------------------------------
209 Description: fix definitively the memory leaks problems.
210 Date: 2004 Sep 24
211 Attributed:
212 Details:
213 Comments: There is a nightly dashboard that run valgrind every night
214 (zorglub | GDCM-Linux-g++)
215 -----------------------------------------------------------------------------
216 Description: test gdcm on a big endian OS.
217 Date: 2004 Sep 24
218 Attributed:
219 Details:
220 Comments: There is a nightly dashboard that run on MacOSX each nite
221 (midworld.kitwarein | GDCM-DarwinG5-g++ )
222 -----------------------------------------------------------------------------
223 Description: More tests !
224 Date: 2004 Sep 24
225 Attributed:
226 Details:
227  * an example of new test could be to clone a Dicom image by 
228    copying gdcmDocEntry one after the other
229 Comments:
230  * look at traversal used in Example/FlatHashTablePrint.cxx
231 -----------------------------------------------------------------------------
232 Description: revoir la gestion des resources, win32 permet d'inclure des
233    fichiers texte (=dicomV3.dic) dans une dll ou quelquechose du genre.
234 Date: 2004 Sep 24
235 Attributed: Mathieu
236 Details:
237 Comments:
238  * Frog: no comprendo !? De plus est-ce portable ?
239  * To improve load time it could be usefull to have the dictionary directly in
240  'c++' code or in a more binary format.
241  * This will also solve some issues where /dummy/ user did nor set
242  GDCM_DICT_PATH properly neither 'make install'
243 -----------------------------------------------------------------------------
244 Description: Convert the C-like IO to C++ IO:
245 Date: 2004 Jul 30
246 Attributed:
247 Details:
248    remove all the C-oriented IO references like FILE*, fread...
249    and replace them with the C++ fstream notation.
250    Provide overload of operators << and >> for any gdcm class using file IO.
251 Comments:
252  * Question: the underlying jpeg libraries (written in C) use the FILE*
253    notation. Is there a way to still use fstream in gdcm, and 
254    build or pass the proper FILE* to jpeg libs ?
255  * Binary IO references are available at
256    http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
257  * The internal API should be rewritten so that gdcm speaking to jpeg lib is
258    done with stream/string and not directly opened FILE*
259  * No stdio.h anymore anywhere tolerated !
260 -----------------------------------------------------------------------------
261 Description: generate methods based on VM.
262 Date: 2004 Jul 30
263 Attributed:
264 Details:
265  * cmake should parse le DICOM dictionary to generate methods like
266    gdcm???::SetImagePosition(int, int)
267    {
268      //generated content do not edit
269      ...
270    }
271    gdcm???::SetImageNumber(int)
272    {
273      //generated content do not edit
274      ...
275    }
276 Comments:
277  * Regrain: a dicom dictionary entry name is NOT UNIQUE [this means
278      two tags=(group, element) can share the same name].
279      What should the wrapper do in such a case !?
280  * Frog: what does VM stand for ?
281  * VM = Value Multiplicity
282 -----------------------------------------------------------------------------
283 Description: Add information on supported imagers (constructor/model)
284 Date: 2004 9 7
285 Attributed:
286 Details: in order to promote gdcm make a list (on the web pages)
287          of images successfully parsed based on a constructor/model ordering
288 Comments: * frog: gdcmData only lists pathological images. How to collect
289     the ones gdcm works smoothly with (hopefully gdcmData is a small
290     subset of what we would like).        
291 -----------------------------------------------------------------------------
292 Description: Add a GetVersion() global function.
293 Date: 2003 july 7
294 Attributed:
295 Details: This is to be used for version assertion with gdcmPython
296 Comments:
297 -----------------------------------------------------------------------------
298 -----------------------------------------------------------------------------
299 * vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
300   be made at the cost of memory consumption (refer to header of 
301   vtk/vtkGdcmHeader.cxx)
302 -----------------------------------------------------------------------------
303 * gdcmElValSet::SetElValueLengthByNumber IMNSHO should be trashed.
304   It's only purpose is a onliner substitute to calling GetElValueByNumber
305   and then SetLength. This only obfuscates the caller code more than
306   clarifying it.
307   Besides the definition of gdcmElValSet::SetElValueLengthByNumber itself
308   it quite poor since it is a almost exact copy of
309   gdcmElValSet::GetElValueByNumber except for the returned code.
310   gdcmHeader::SetPubElValLengthByNumber (which is based on 
311   gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
312 -----------------------------------------------------------------------------
313 * Fix the bug in Test/bug1.cxx (see first comment line): Win32 only.
314 -----------------------------------------------------------------------------
315 * All (or at least many of) the methods of gdcmHeader whose only arguments
316   are an ElValue* (e.g.  FindLength, FindVR, LoadElementValue...) can
317   be moved away to ElValue class on condition of transmitting the
318   gdcmHeader.fp attribute. This change should be considered since it
319   would allow those method to avoid artificial calls to ElValue::GetElement(),
320   ElValue::GetVR()...
321 -----------------------------------------------------------------------------
322 * Eat leading_trailing_whitespace (found in python/gdcmPython/gdcmi) should
323   be used when parsing the dictionary in C++ !
324 -----------------------------------------------------------------------------
325 * Group length is not a unique tag in a file. Hence avoid putting it
326   in the element values dictionary without doing something smarter
327   (say, instead of storing the length store the group and the length
328    so we can related a length to a group).
329 -----------------------------------------------------------------------------
330 * GetPubElValByNumber doit faire la difference entre chaine vide 
331   et chaine pas touve''. Eventuellement raiser une exception ?
332 -----------------------------------------------------------------------------
333 * gdcmHeader::LoadElements only loads the element whose length is
334   below the specified size. When accessing the value of such an element
335   the content is unfound ! Find a decent way of loading the value on
336   explicit demand.
337 -----------------------------------------------------------------------------
338 * JPR: fournir une method qui ne fait que lire les elements passes en arguments
339   sous forme d'une liste.
340 -----------------------------------------------------------------------------
341 * JPR: gdcmHeader::CheckSwap() dans le cas ACR pas propre, degager tout de
342   suite si on a deduit que c'en est pas...
343 -----------------------------------------------------------------------------
344 * python /usr/lib/python2.2/site-packages/DaVaW/demo/dvwDcmReader.py
345   and load image /home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
346   will yield wrong coloring scheme as opposed to 
347   affim filein=/home/frog/cvs/DCMlib/Data/CT-MONO2-16-ankle.dcm
348 -----------------------------------------------------------------------------
349 * gdcmFile should implement the following API:
350    gdcmFile WriteDicom;
351    WriteDicom.SetFileName("MyDicomFile.dcm");
352    string * AllTags = gdcmHeader.GetDcmTagNames();
353    WriteDicom.SetDcmTag(AllTags[5], "253");
354    WriteDicom.SetDcmTag("Patient Name", "bozo");
355    WriteDicom.SetDcmTag("Patient Name", "bozo");
356    WriteDicom.SetImageData(Image);
357    WriteDicom.Write();
358
359    Anonymize(ostream& output) {
360       a = gdcmFile("toto1");
361       a.SetPubValueByName("Patient Name", "");
362       a.SetPubValueByName("Date", "");
363       a.SetPubValueByName("Study Date", "");
364       a.write(output);
365    }
366 -----------------------------------------------------------------------------
367