]> 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 1134eeb678bd4488025f0374ba4db18c8c4e2c36..343b8051904adbfe7d2c6ac750cee0ad7eae2e40 100644 (file)
--- a/TODO
+++ b/TODO
@@ -11,6 +11,14 @@ 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
@@ -33,6 +41,8 @@ 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
@@ -57,6 +67,45 @@ 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
 Attributed: