X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;f=Doc%2FWebsite%2FNews.html;h=9b8e5fba7c19939da00f1d6dbcc71c11a31b71de;hb=bcbba24e317b815f9ae86263001d97551c3e8db3;hp=f6999f5622389f9ae2f14f9b041a33d050fb3170;hpb=3584d48e02394be2bd827ad96d5e14b962cdf82e;p=gdcm.git

diff --git a/Doc/Website/News.html b/Doc/Website/News.html
index f6999f56..9b8e5fba 100644
--- a/Doc/Website/News.html
+++ b/Doc/Website/News.html
@@ -103,10 +103,14 @@ Any contribution is welcome.
    <UL>
       <LI> 16-bits-LUT full Management
       <LI> User friendly management of <TT>Rescale Slope</TT> and
-           <TT>Rescale Intercept</TT>
+           <TT>Rescale Intercept</TT>.<br>
+           (Well... Maybe it's up to the application to deal with it, not to
+           gdcm ?)
       <LI> Allow manual adjunction / automatic recognition (pfff!...)
            of the private <TT>Dicom Dictionary</TT>
            to be used to parse <TT>Shadow groups</TT> against.
+      <LI> User friendly way of anonymizing image when Patient's name is
+           carved in the Pixels :-(
    </UL>
 </UL>
 <!#######################################################################>
@@ -122,31 +126,189 @@ Any contribution is welcome.
    <LI>State of the art
    <UL>    
       <LI>
-         <a href="uml-gdcm.pdf">gdcm UML Class Diagram</a> current version.
-      <LI> <a href= "Doc1.2/html.user/index.html">User Documentation</a>
-      <LI> <a href= "Doc1.2/html.developper/index.html">Developper
+         <a href="uml-gdcmV1.2.pdf">gdcm UML Class Diagram</a> current version.
+      <LI> <a href= "DocCVS/html.user/index.html">User Documentation</a>
+      <LI> <a href= "DocCVS/html.developper/index.html">Developper
          Documentation</a> 
    <LI> New Features
    <UL>
-      <LI>
+      <LI> To <i>try to</i> make gdcm images PACS usable, user is now allowed to
+           gdcm what kind of image he wants to write, using :  <br>
+   <TT>void FileHelper::SetContentType (ImageContentType c);</TT> <br>
+   Four different types are identify (probabely more will be added) :
+      <UL> 
+         <LI>
+      1) user created ex nihilo his own image and wants to write it as a Dicom image.<br>
+          c : <TT>USER_OWN_IMAGE</TT>
+         <LI>
+      2) user modified the pixels of an existing image, using mathematical operations.<br>
+          c : <TT>FILTERED_IMAGE</TT>
+         <LI>
+      3) user created a new image, using existing images (eg MIP, MPR, cartography image)<br>
+          c : <TT>CREATED_IMAGE</TT>
+         <LI>
+       4) user modified/added some tags *without processing* the pixels (anonymization, etc)<br>
+         c : <TT>UNMODIFIED_PIXELS_IMAGE</TT> 
+      </UL>
+      <LI> Stupid difference between <TT>gdcm::ValEntry</TT> 
+           and <TT>gdcm::BinEntry</TT> removed. <br>
+           Only <TT>gdcm::DataEntry</TT> exist, now. 
+           Should have been considered as a 'Bug Fix'.<br>
+           Actually, it's an API breaking modification ...
+      <UL>
+         <LI>
+            <TT>std::string const &DataEntry::GetString() const</TT><br>
+            returns as a string (when possible) the value of the DataEntry
+         <LI>
+            <TT>void DataEntry::SetString(std::string const &value)</TT><br>
+             Sets the 'value' of a DataEntry, passed as a std::string 
+         <LI>
+            <TT>void DataEntry::SetBinArea( uint8_t *area, bool self ) </TT><br>
+             Sets the value (non string) of the current Dicom DataEntry
+         <LI>
+              <TT>void DataEntry::CopyBinArea( uint8_t *area, uint32_t length )</TT><br>
+               Inserts the value (non string) into the current DataEntry 
+         <LI>
+               <TT>void DataEntry::SetValue(const uint32_t &id, const double
+ &val)</TT><br>
+               Inserts the elementary (non string) value into the current
+               (multivaluated) DataEntry, at the <TT>id></TT> position.
+         <LI>
+               <TT>double DataEntry::GetValue(const uint32_t &id) const </TT><br>
+               returns, as a double one of the values (when entry is 
+               multivaluated), identified by its index <TT>id</TT>. 
+      </UL>
+      <LI> 
+   <TT>DocEntrySet::GetEntryValue()</TT> replaced by
+           <TT>DocEntrySet::GetEntryString()</TT> <br>
+      <LI> SerieHelper : <br>     
+           Add some methods, to split a 'SingleSerieUID' Fileset into 
+           'Extra Coherent'  FileSets. <br>
+           They return a std::map of 'Filesets' (actually : std::vector 
+           of gdcm::File*)<br>
+           The key is the 'Orientation', the 'Position' 
+           or the value of a user choosen 'Tag' <br>
+           -  <TT>XCoherentFileSetmap SplitOnOrientation(FileList *fileSet);
+              </TT><br>
+           -  <TT>XCoherentFileSetmap SplitOnPosition(FileList *fileSet);
+              </TT> <br>
+           -  <TT>XCoherentFileSetmap SplitOnTagValue(FileList *fileSet,
+                                       uint16_t group, uint16_t element);
+              </TT><br>
+           These methods must be called by user, depending on what he wants 
+           to do, at application time.- *he* only  knows what his Series 
+           contain !-
+      <LI> To avoid memory leaks and seg faults the user intended classes
+           use now a Reference Counter.<br>
+      <UL>
+         <LI> <TT>new()</TT> and <TT>delete()</TT> are replaced by
+              <TT>New()</TT> and <TT>Delete()</TT>
+         <LI> <TT>Register()</TT> and <TT>Unregister()</TT> methods are 
+         available.
+         <LI> --> Well ... People from ITK don't seem to agree too much with 
+             that feature.<br>
+          They demand to be allowed to allocate gdcm objects in the stack as
+          well, not only in the heap.
+      </UL>
       <LI>
    </UL>
 
-   <LI> API breaking modiffications (since previous version)
+   <LI> API breaking modifications (since previous version)
    <UL>
-      <LI>   
+      <LI> Stupid difference between <TT>gdcm::ValEntry</TT> 
+           and <TT>gdcm::BinEntry</TT> removed. <br>
+           Only <TT>gdcm::DataEntry</TT> exist, now. <br>  
+   <pre>
+   ValEntry(DictEntry *e);
+   BinEntry(DictEntry *e);
+-->DataEntry *New(uint16_t group,uint16_t elem, VRKey const &vr);
+
+   std::string const &ValEntry::GetValue() const;
+   std::string const &BinEntry::GetValue() const;
+-->std::string const &DataEntry::GetString() const;
+
+   uint8_t *BinEntry::GetBinArea();
+-->uint8_t *DataEntry::GetBinArea();
+
+   void ValEntry::SetValue(std::string const &value);
+   void BinEntry::SetValue(std::string const &value);   
+-->void DataEntry::SetString(std::string const &value);
+
+   void BinEntry::SetBinArea( uint8_t *area, bool self = true );
+-->void DataEntry::SetBinArea( uint8_t *area, bool self = true );
+
+   void ValEntry::CopyValEntry(uint16_t gr, uint16_t el);
+-->void DataEntry::CopyDataEntry(uint16_t gr, uint16_t el, VRKey const &vr);
+</pre>
+
+<pre>
+Example :
+
+old way :
+        DocEntry *p3 = item2->GetDocEntry(0x0018,0x0050);
+        if( !p3 ) return false;
+        ContentEntry *entry2 = dynamic_cast<ContentEntry *>(p3);
+        std::string thickness = entry2->GetValue();
+
+new way :
+        DocEntry *p3 = item2->GetDocEntry(0x0018,0x0050);
+        if( !p3 ) return false;
+        DataEntry *entry2 = dynamic_cast<DataEntry *>(p3);
+        std::string thickness = entry2->GetString();
+
+</pre>
+
+<LI> Avoid tons of CPU time consuming accesses to DICOM Dictionnary
+<pre>
+   DataEntry *FileHelper::CopyDataEntry(uint16_t group, uint16_t elem);
+-->DataEntry *FileHelper::CopyDataEntry(uint16_t group, uint16_t elem, 
+                                        const VRKey &vr = GDCM_VRUNKNOWN);
+
+   void FileHelper::CheckMandatoryEntry(uint16_t group, uint16_t elem, std::string value);
+-->void FileHelper::CheckMandatoryEntry(uint16_t group, uint16_t elem, std::string value,
+                                        const VRKey &vr = GDCM_VRUNKNOWN);
+      
+   void FileHelper::SetMandatoryEntry(uint16_t group, uint16_t elem, std::string value);       
+-->void FileHelper::SetMandatoryEntry(uint16_t group, uint16_t elem, std::string value,
+                                      const VRKey &vr = GDCM_VRUNKNOWN);
+
+   void FileHelper::CopyMandatoryEntry(uint16_t group, uint16_t elem, std::string value);      
+-->void FileHelper::CopyMandatoryEntry(uint16_t group, uint16_t elem, std::string value,
+                                       const VRKey &vr = GDCM_VRUNKNOWN);
+</pre>
+CopyMandatoryEntry(0x0002,0x0003,sop)
+<LI> New features :
+<pre>
+For multivaluated numeric DataEntries
+-->void DataEntry::SetValue(const uint32_t &id,const double &val);
+-->double DataEntry::GetValue(const uint32_t &id) const;
+-->uint32_t DataEntry::GetValueCount() const;
+
+For converting 'Decimal String'
+-->bool GetDSValue(std::vector &lt;double&gt; &valueVector);  
+      </pre>
       <LI>
    </UL> 
       
    <LI> Bug fixes
    <UL>
-      <LI>   
+      <LI> Implicit VR - Big Endian (G.E Private) Transfert Syntax 16 Bits 
+           images are now read correctly.  
+      <LI> File::GetZOrigin() returns accurate result in any case.
+      <LI>
       <LI>
    </UL>
    
    <LI> Known Bugs
    <UL>
-      <LI>   
+      <LI> Use of <TT>Implicit Value Representation</TT> writting mode may
+           causes troubles, when there are some <TT>SQ</TT> belonging to a 
+           <TT>Shadow Group</TT>. <br>
+           Better you use <TT>Explicit Value Representation</TT> writting mode ...
+      <LI> Troubles on 'Big endian' processors (i.e. Apple/Motorola, SunSparc
+           ...) when writting 16 Bits images.
+      <LI> Troubles on 64-bits processors.
+      <LI>
       <LI>
    </UL>
  
@@ -156,6 +318,9 @@ Any contribution is welcome.
 
   
 <!#######################################################################>
+<A CLASS="anchor" NAME="NewsPreviousVersions">
+<!#######################################################################>
+
 <HR size="1"><ADDRESS style="align: right;"></ADDRESS>
 <H2>
    <A CLASS="anchor" NAME="NewsVersion1_1">
@@ -430,13 +595,7 @@ Any contribution is welcome.
 
    <LI> Known bugs
    <UL>
-      <LI> Use of <TT>Implicit Value Representation</TT> writting mode may
-           causes troubles, when there are some <TT>SQ</TT> belonging to a 
-           <TT>Shadow Group</TT>. <br>
-           Better you use <TT>Explicit Value Representation</TT> writting mode ...
-      <LI> Troubles on 'Big endian' processors (i.e. Apple/Motorola, SunSparc
-           ...) when writting 16 Bits images.
-      <LI> Troubles on 64-bits processors.
+
    </UL>
 
 </UL>