+2004-11-22 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
+ * src/gdcmFile.h : fix compilation errors on zorglub linuc computer
+
+2004-11-19 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
+ * src/gdcmDocEntry.cxx : remove the copy of the DictEntry... there isn't
+ correct to copy it. The DictEntry is specified at the DocEntry creation,
+ then, it musn't change in the time.
+ * src/gdcmDocEntryArchive.[h|cxx] : new class. It's goal is to change the
+ header correctly. At this time, the change is only made for the first
+ level of the Document. In the future, it might consider sequences.
+ The change is made by replacing a DocEntry by an other that is created
+ outside the class. The old value is kept. When we restore the header
+ status, the added DocEntry is deleted and replaced by the old value.
+ * src/gdcmElementSet.h : Set the DocEntryArchive like friend.
+ * src/gdcmFile.[h|cxx] : Use the gdcmDocEntryArchive. Add methods to
+ set the write type to explicit VR, implicit VR or ACR. Add methods to set
+ the write mode to native, decompressed or RGB (but not used at this time)
+
+2004-11-15 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
+ * src/gdcmSeqEntry.cxx : add initialisation of variable SeqTerm
+ * src/gdcmDocument.cxx : add delete of DocEntry's to remove some memory leaks
+
+2004-11-15 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
+ * src/gdcmDocument.cxx : now, when using the ReplaceOrCreateByNumber to
+ set a BinEntry, the binArea is copied (like to set a ValEntry, the string
+ is copied).
+ * Test/TestCopyDicom.cxx, Example/TestCopyDicom.cxx : the image data isn't
+ set because already copied when copying the BinEntry's of the header
+ * Test/TestAllReadCompareDicom.cxx : remove warnings
+
+2004-11-15 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
+ * FIX : now, the DocEntries are all deleted in the gdcmElementSet.
+ Two problems appear when doing it :
+ - with the gdcmFile : when the GetImageData method is called, the pixels
+ are stored in the gdcmPixelConvert, but a gdcmBinEntry link to these
+ datas (pixels). And each structure destruct the datas when it's
+ destructed. So we have two destructions for the same datas. To solve it,
+ a flag is added in the gdcmBinEntry to indicate if the BinEntry owns the
+ datas or not. If it doesn't own datas, then they will not destroyed by
+ the gdcmBinEntry.
+ - with the gdcmDicomDir : the sequences (gdcmSQItem) contain DocEntry
+ elements. The DicomDir* (DicomDirPatient, etc.) inherit from SQItem.
+ Thus destruct the DicomDir* elements and the TagHT of the ElementSet
+ create a double destruction of the same DocEntry's. So, to solve it,
+ the TagHT is simply cleared and the DicomDir* elements are destroyed.
+ * TODO : add an entry concerning memory leaks in the DicomDir
+
2004-11-15 Benoit Regrain <Benoit.Regrain@creatis.insa-lyon.fr>
- * FIX : src/gdcmDocument.cxx Remove obvious code in the destructor
+ * FIX : src/gdcmDocument.cxx Remove obvious code in the destructor
* FIX : src/gdcmPixelConvert : Set to NULL the deleted structures in the
squeeze method
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff