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

diff --git a/Doc/Website/News.html b/Doc/Website/News.html
index f6999f56..ce1d90dd 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>
 <!#######################################################################>
@@ -128,25 +132,69 @@ Any contribution is welcome.
          Documentation</a> 
    <LI> New Features
    <UL>
-      <LI>
+      <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 ...
+           <br> <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.
+      </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>  
+      <LI>
       <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 +204,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 +481,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>