]> Creatis software - gdcm.git/blobdiff - TODO
* src/gdcmDebug.cxx last ditch attempt to get warning/error messages
[gdcm.git] / TODO
diff --git a/TODO b/TODO
index 4d2ca3b9dcaddded8c9b23e697083f39d9154e2a..343b8051904adbfe7d2c6ac750cee0ad7eae2e40 100644 (file)
--- a/TODO
+++ b/TODO
@@ -12,6 +12,99 @@ Comments:
 
 
 -----------------------------------------------------------------------------
+Description:  gdcmJpeg8 is strictly a copy/paste of gdcmJpeg12.cxx.
+Date: 2004 Oct 13
+Attributed: 
+Details:
+We should write the code in a common place, then include this 'cxx' file so the the define from gdcm_mangle redefine to the proper one.
+Comments:
+This will be usefull since I may need in the future a 16bits version of this reading
+-----------------------------------------------------------------------------
+Description: Change jpeg 'exit' call to standard c++ exception using the jpeg error
+handler
+Date: 2004 Oct 8
+Attributed: 
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: Add kwsys as a subdir somewhere in gdcm
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments:
+-----------------------------------------------------------------------------
+Description: ljpeg
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: ljpeg was rip from medcon and not the official one. medcon tried to
+optimised function using MACRO (doh!), so it make its very unreadable and very
+hard to fix warnings. Should go back to official source, copy proper copyright
+and fix warnings on dashboard
+13/10: update apparently no dicom toolkit use this lib as it is too buggy. We should use the ls-patch for ijg instead. Thus we can safely get rid of that lib.
+14/10: PHILIPS_Gyroscan-12-MONO2-Jpeg_Lossless.dcm prove that I was right the old Cornwell lib is buggy and does not read anything.
+-----------------------------------------------------------------------------
+Description: Extent reading support
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: All ITK/VTK readers support selecting extent. gdcm should support selecting
+extent before being inserted into ITK
+-----------------------------------------------------------------------------
+Description: Generate new UID each time we write DICOM
+Date: 2004 Oct 8
+Attributed: Mathieu
+Details:
+Comments: According to DICOM ref a new UID should be created each we write a
+DICOM images. I guess it should be an option so that we can still use md5sum to
+check dicom file. The proposed way was:
+http://www.creatis.insa-lyon.fr/pipermail/dcmlib/2004-September/000611.html
+
+Bah, comme Win32 pose encore pb:
+  echo "gdcm" | od -b
+  0000000 147 144 143 155 012
+et si on prenait:
+ radical + 147.144.143.155 + IP + time()
+
+-----------------------------------------------------------------------------
+Description: [BUG] Better handling of unfound Dicom dictionary.
+             When gdcm doesn't find the Dicom dictionary (because it's
+             path to the directory of dictionary is uncorrect, either
+             because the install relative layout was broken after file moves
+             or because the environnement variable GDCM_DICT_PATH is 
+             unpropely set), gdcm will:
+             1/ print a warning
+             2/ throw an exception (that is internaly UNcatched by gdcm)
+                that in most cases provoques the caller application to
+                exit uncleanly (uncatched excpetions in fine call abort() ).
+             Additionaly on Win32 the warning print isn't displayed because
+             exiting occurs prior to cerr or cout is flushed properly.
+Date: 2004 Oct 15
+Attributed:
+Details: fixes (from dirty to clean)
+         1/ force Win32 to flush it's buffer so at least the user gets some
+            reason why it's application exited (when called in command
+            environement). Note: it looks like the "cerr << flush" fails. Sigh.
+         2/ within gdcm catch the exception, display a decent warning, and
+            return to caller.
+         3/ see the comment below on how to enhance the API and fix things
+            really cleanly.
+Comments: ENH proposal:
+          The caller migth not be aware of the path to the dictionaries
+          on invocation of gdcm (think this path is set by the Interface
+          because the caller wants to skip the default gdcm dictionary in order
+          to provide his own ones e.g. another language based one).
+             Hence, gdcm should postpone the parsing of the default dictionary
+          instead of doing it on library entry.
+          This would enable two things:
+           - It would give a chance to the caller to set the path to
+             the dictionaries he whishes to use, through a call to
+             newly created DictSet::SetDictionaryPath( string ).
+           - It would avoid the burden of using the GDCM_DICT_PATH
+             environnement variable and enable GDCM CONTROL FROM WITHIN
+             THE API. Optionaly, if the caller didn't use the API to
+             provide his prefered path, gdcm could still default to 
+             GDCM_DICT_PATH...
 -----------------------------------------------------------------------------
 Description: vtk/vtkGdcmReader doesn't positionate the normal to the image
 Date: 2004 Oct 1
@@ -83,13 +176,15 @@ Description: fix definitively the memory leaks problems.
 Date: 2004 Sep 24
 Attributed:
 Details:
-Comments:
+Comments: There is a nightly dashboard that run valgrind every night
+(zorglub | GDCM-Linux-g++)
 -----------------------------------------------------------------------------
 Description: test gdcm on a big endian OS.
 Date: 2004 Sep 24
 Attributed:
 Details:
-Comments:
+Comments: There is a nightly dashboard that run on MacOSX each nite
+(midworld.kitwarein | GDCM-DarwinG5-g++ )
 -----------------------------------------------------------------------------
 Description: More tests !
 Date: 2004 Sep 24
@@ -103,10 +198,14 @@ Comments:
 Description: revoir la gestion des resources, win32 permet d'inclure des
    fichiers texte (=dicomV3.dic) dans une dll ou quelquechose du genre.
 Date: 2004 Sep 24
-Attributed:
+Attributed: Mathieu
 Details:
 Comments:
  * Frog: no comprendo !? De plus est-ce portable ?
+ * To improve load time it could be usefull to have the dictionary directly in
+ 'c++' code or in a more binary format.
+ * This will also solve some issues where /dummy/ user did nor set
+ GDCM_DICT_PATH properly neither 'make install'
 -----------------------------------------------------------------------------
 Description: Convert the C-like IO to C++ IO:
 Date: 2004 Jul 30
@@ -121,6 +220,9 @@ Comments:
    build or pass the proper FILE* to jpeg libs ?
  * Binary IO references are available at
    http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
+ * The internal API should be rewritten so that gdcm speaking to jpeg lib is
+   done with stream/string and not directly opened FILE*
+ * No stdio.h anymore anywhere tolerated !
 -----------------------------------------------------------------------------
 Description: generate methods based on VM.
 Date: 2004 Jul 30
@@ -142,6 +244,7 @@ Comments:
      two tags=(group, element) can share the same name].
      What should the wrapper do in such a case !?
  * Frog: what does VM stand for ?
+ * VM = Value Multiplicity
 -----------------------------------------------------------------------------
 Description: Add information on supported imagers (constructor/model)
 Date: 2004 9 7
@@ -227,13 +330,3 @@ Comments:
       a.write(output);
    }
 -----------------------------------------------------------------------------
-* Add kwsys as a subdir somewhere in gdcm ( assigned to: Mathieu ).
------------------------------------------------------------------------------
-* ljpeg: ljpeg was rip from medcon and not the official one. medcon tried to
-optimised function using MACRO (doh!), so it make its very unreadable and very
-hard to fix warnings. Should go back to official source, copy proper copyright
-and fix warnings on dashboard ( assigned to: Mathieu ).
------------------------------------------------------------------------------
-* All ITK/VTK readers support selecting extent. gdcm should support selecting
-extent before being inserted into ITK ( assigned to: Mathieu ).
------------------------------------------------------------------------------