Comments:
-------------
-
+----------------------------------------------------------------------------
+Description: Need to fix cygwin + wrong path (passing UNIX path when windows patch expected)
+Date: 2004 Nov 16
+Attributed: Mathieu
+Details:
+Comments:
+----------------------------------------------------------------------------
+Description: Need a test for gdcmHeaderHelper (iterating over gdcmData) for instance
+Date: 2004 Nov 16
+Attributed: Mathieu
+Details:
+Comments: It used to seg fault when a README file was found
+----------------------------------------------------------------------------
+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 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
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
+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
radical + 147.144.143.155 + IP + time()
-----------------------------------------------------------------------------
+Description: gdcmDicomDir and SQItem creation
+Date: 2004 Nov 16
+Attributed:
+Details: DicomDir creates some SQItem (by new). After that, it creates
+ the corresponding DicomDirPatient, etc. using the content of the SQItem
+ (the content is composed with some DocEntry's that can't be destroyed).
+ So, if the SQItem is deleted, then it's content is deleted to. But the
+ DicomDirPatient, etc. use the content of the SQItem. Then, the SQItem can't
+ be deleted, and when have memory leaks
+
+-----------------------------------------------------------------------------
+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:
a.write(output);
}
-----------------------------------------------------------------------------
+
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff