*FIX : gdcmHeader::LoadElements is now based
             on the ListTag listElem member,
             not longer on the TagElValueHT tagHt member
      *ENH : PrintPubElVal shows (temporarily) both results,
             with the tagHt member and the listElem member.
     (it's easier to 'see' the problems when using Printheader)

      *FIX : old private member LgrElem is now splitted into
             ReadLength   : Length actually found on disk (updated only
                    if bug fixing is necessary), for internal
    use only
     UsableLength : Updated by FixFoundLength, to fix a bug
                    or to allow Parser going on.
     Will allow to re-write a kosher header when a SeQuence
     with a length (not 0000) is found
      Warning : gdcmFile::Write still uses the TagHt (not ListElem)
        because gdcmElValSet::Add does not update ListElem
(to be written)

commit ChangeLog

  *FIX : gdcmHeader::LoadElements is now based
             on the ListTag listElem member,
             not longer on the TagElValueHT tagHt member
      *ENH : PrintPubElVal shows (temporarily) both results,
             with the tagHt member and the listElem member.
     (it's easier to 'see' the problems when using Printheader)

*ENH: Add Rescale Slope & Intercept helper, defaults are:
0 for Intercept
1 for Slope

update Changelog

 *ENH gdcmHeader::FixFoundLength now allow to 'go inside' tge SeQuences
          when they have an actual length (not 0000 nor FFFFF)
  (Nobody should care of it, but DICOMDIR explorers)

 *FIX misstyping in Transfert Syntax name table

*ENH: vtkgdcmViewer now works with LUT dicom (OT-PAL-face ...)

*ENH: vtkGdcmReader now supports LUT ! (vtkgdcmViewer for now is not able to use them though)

*** empty log message ***

*FIX: DOH again the same bug of unsigned vs. signed !

FIX: DOH !! [0 255[ doesn't contains 256 elements ! But [0 256[ does !!

* Fix :Oops ! Forgot to commit gdcmFile::GetImageDataSizeRaw();
       that returns the pixel area size to the *aware* (vtk) user
       that DOESN'T want to turn the PALETTE COLOR image into an RGB image

Benoit Regrain   : Modify the rules for checking the paths
                 : Explicit error messages
Jean-Pierre Roux : new files names for checking

Fix syntax gcc3 breaker pb

update Changelog

2003-11-03 Jean-Pierre Roux
     * add gdcmHeaderHelper::GetNumberOfScalarComponentsRaw()
           to be used by aware (vtk) users that want to manage
   LUT (and no to turn the PALETTE image into an RGB pixels one)
     * GetPixelType now returns 8U for 24 Bits images
                    (vtkGdcmReader compliant)

Update Changelog

removal of useless jBitsInJsample.h for both 8 and 12 Bits JPEG Libraries

*FIX: VC++ compilation, still for loop dummy stuff
*FIX: alpha start point was not set properly
*ENH: memset default everything to zero (in case lengthR/G/B is < 255)
*ENH: spare a few pointers operations :)

ChangeLog updated

 * ENH : Add the functions gdcmFile::GetImageDataRaw
                               gdcmFile::GetImageDataIntoVectorRaw
             that act as GetImageData and GetImageDataIntoVector
     except the making of an RGB Plane from Gray Plane + LUT
     Intended to aware (vtk) users who know how to manage
     such an image :
     After gdcmHeader :
        GetLUTRGBA return a R,G,B,A LUT if any
        lgrTotaleRaw gives the 'Raw' length
        GetImageDataRaw returns the gray Plane
     * FIX : no more dirty trick for 'Segmented xxx Palette Color Lookup' images
             (They stay Grey, just like with other Dicom viewers :-(
     * FIX : a VC++ intended syntax modif broke the 12/12 Bytes expanding

*FIX: Don't need to duplicate includes

Ops ! Forgot to commit the .h

  * FIX : a VC++ intended syntax modif broke the 12/12 Bytes expanding

2003-10-29 Jean-Pierre Roux
      * adding  gdcmHeader::GetLUTRGBA
               returns a 4 * 256 Bytes Reg/Green/Blue/Alpha vtk compliant LUT
       --> Mathieu, the modif u're waiting for is not yet committed
      * removal of now useless GetLUTRed,GetLUTGreen,GetLUTBlue,GetLUTRGB

*ENH: Can be used like this '$vtkgdcmViewer *.dcm' with *.dcm being coherents dicom files.

*FIX: only one function is being exported for now ! You should use GLOBAL(return type) see ljpg/jpeg.h for more info

*FIX: sorry !

*FIX: release compilation mode

*FIX: removed this files

*ENH: Add include dir to medcon lib

*FIX: more about medcon lib in DSP files

*FIX: DOH ! libgdcmijpg8 -> libgdcmljpeg

*ENH: Two steps is necessary to please VC++ compiler...

*ENH: Turn it into DOS file type to match libgdcmijpeg8.dsp file type

*FIX: DOH ! Forgot about windo$e users, they couldn't read lossless jpeg, from medcon lib !

To avoid pb with xmedcon-breaker CT McTwin Elscint images

removal of useless cout

ENH: For version prior to vtkImageViewer2 -r 1.19

*Removal of ido stuff

removal of now useless LibIDO Jpeg Lossless .h and .cxx

*ENH: Added CharEvent to browse throught a multiframe volume, press any key it will lopp over frames.

*ENH: vtkGdcmReader.cxx can now read multiframe dicom
*FIX: remove a call to ->Modified ... see comments
*FIX: vtkgdcmViewer.cxx was writting ASCII file...this is so slooooooow !

*ENH: Can read CT-MONO2-8-abdo.dcm now
*ENH: CT-MONO2-8-abdo.dcm is in color again, do not press 'r' or you'll loose the color

*FIX: More pragma disable fro VC++, I don't think I break something as it is also disable in VTK/ITK. But it fasten debug compilation time.

*FIX: gdcm/Makefile.am fix for generating ljpg medcon
*ENH: CMakeLists.txt now generate 'pygdcm.so' instead of 'libpygdcm.so'

*RMV: Remove some file from medcon lib that are not necesseray

doh

* FIX: Problem with path for libvtkgdcmPython
* ENH: Try adding a search script for python site-package

gdcm now deals with 16 Bits Run Length Encoded images

*FIX: When copying a Makefile.am to CMakeLists.txt one should remove the '\'

Makefile.am,CMakeLists.txt updated to deal with the new library

add the method
int gdcmHeader::GetBitsAllocated(void);

- garbage Siemens 'Leonardo' images dealt with
  (the patch is easy to remove)
- cosmetic changes to avoid warnings

- call of 'xmedcom' Jpeg Lossles libray (instead of the old LibIDO one)
- 'Compacted Files' (12 Bits Allocate, 12 Bits Stored) are now dealt with

add the files for 'xmedcon' Jpeg Lossless library

add the directory jpg, for 'xmedcon' Jpeg Lossless Library

* ENH: vtkgdcmViewer now autoscale color/window level on start-up, no need to press 'r' now.

gdcmHeader::gdcmHeader(const char *InFilename, bool exception_on_error)
no longer seg faults when file is not found

Emprovement of reading for Dicom encapsulated Jpeg LossLess MultiFrame images

Some more corrections

Missing elements added
(just to be affraid : have a look at
ftp://medical.nema.org/medical/dicom/2003/01v03dif/01v03_06.pdf
and do it again next year ;->

* TODO: *.in file to genereate a UseGDCM later

--> Some supposed-to-be Dicom Images have no preamble.
    OpenFile takes it into account

--> Jpeg LossLess 24 Bits images doesn-t break any longer gdcm

According to PS 3.3-2003 C.11.1.1.2 p 619, when each pixel of a PLATTE COLOR
is stored on 2 Bytes, theese 2 Bytes must be equal.
But there are NOT.
It's fixed !

* FIX: vtkgdcm was not being installed

* FIX: "jpeglib.h" was not found on VC++

ENH : OpenFile closes the file if it *really* doesn't look like
      an ACR-NEMA / DICOM one.

* FIX: PATH to dictionary was wrong (missing /)
* ENH: OpenFile, return true if the file looks like an ACR or DICOM file

* FIX: make install should be ok now on ùnix plateform

* ENH: Generate both user and dev documentation
* ENH: Should work on windows too
* ENH: Only one doxygen config.in file is needed

* FIX: CMake generate now documentation
* ENH: out of source doc build !

* FIX: force jpeg dir to the local one (gdcm/src/jpeg)

* doh, forgot the most important :)

* FIX: cygwin build failed

* FIX: http://www.cmake.org/pipermail/cmake/2003-October/004369.html
* FIX: http://www.cmake.org/pipermail/cmake/2003-October/004373.html

FIX: on cygwin Wsock32 doesn't exist

* doh, ADD_DEFINITIONS needed for now

* FIX: jpr !!!

* CMake-ification of gdcm, we have now two build system

Odd length strings are padded with '\0' (not with spaces, to remain compliant
with already defined strings, like Transfert Syntax UID and others)

FIX: VC++ warning about return type in main

FIX: CV++

* SpuriousFile.raw removed...

FIX : compilation process wad broken.
Changed gdcmViewer_sources to vtkgdcmViewer_sources

* removed these files, they were "Generated automatically from configure.in by autoheader."

* change GetXSpacing and GetYSpacing "%f\\%" is parsed backward.

* change gdcmViewer -> vtkgdcmViewer
See: http://www.creatis.insa-lyon.fr/pipermail/dcmlib/2003-October/000192.html

A few nasty patches to allow the reading of a lot of nasty images
( e.g : well known GE images with a wrong elem length,
      : Philips MRI Images with a wrong Huffman table)
--> still to be done : allow the reading of bugged LEONARDO Siemens images

One more JPEG LossLess type "JPEG Baseline (Process 14)" is now decoded.

* beware of trailing white space !

* added a gdcmViewer to vtk test, use mouse to control window level & window width

* vtkGdcmReader is now able to read rgb dicom file.
* src/gdcmHeaderHelper : GetNumberOfScalarComponents()

gdcmHeaderHelper::GetNumberOfScalarComponents() added, to allow displaying RGB images (not only by affim ;-)

gdcmFile::GetImageDataIntoVector now
 - deals with MultiFrames MultiFragments Run Length Encoded files
 - deals with YcBcR (YBR_FULL) files
 - deals with YBR_YBR_FULL_422 files (they work as RBG files ?!?)

WARNING : nothing was checked for YBR_PARTIAL_422, YBR_ICT, YBR_RCT files.
          (no sample found :-(

src/*.cxx removed pragma thingies to src/gdcmCommon.h
Two reasons: - clear things
             - third parties access gdcm through header files, so won't
             suffer anymore VC++ complains

* add argv[1]
* removed leaks

Now gdcmParse.cxx is 80 characters line long.

-->File gdcmParse.cxx added
gdcmFile::ParsePixelData(void); display the result
of Dicom-encapsulated JPEG or RLE files 'Pixels Element' parsing.
For checking purpose only.

-->modif to improve the processing of multi-Frames multi-Segments compressed files.