+// $Header: /cvs/public/gdcm/vtk/vtkGdcmReader.cxx,v 1.29 2003/12/22 12:46:19 regrain Exp $
+// //////////////////////////////////////////////////////////////
+// WARNING TODO CLENAME
+// Actual limitations of this code:
+//
+// /////// Redundant and unnecessary header parsing
+// In it's current state this code actually parses three times the Dicom
+// header of a file before the corresponding image gets loaded in the
+// ad-hoc vtkData !
+// Here is the process:
+// 1/ First loading happens in ExecuteInformation which in order to
+// positionate the vtk extents calls CheckFileCoherence. The purpose
+// of CheckFileCoherence is to make sure all the images in the future
+// stack are "homogenous" (same size, same representation...). This
+// can only be achieved by parsing all the Dicom headers...
+// 2/ ExecuteData is then responsible for the next two loadings:
+// 2a/ ExecuteData calls AllocateOutputData that in turn seems to
+// (indirectely call) ExecuteInformation which ends up in a second
+// header parsing
+// 2b/ the core of ExecuteData then needs gdcmFile (which in turns
+// initialises gdcmHeader in the constructor) in order to access
+// the data-image.
+//
+// Possible solution:
+// maintain a list of gdcmFiles (created by say ExecuteInformation) created
+// once and for all accross the life of vtkGdcmHeader (it would only load
+// new gdcmFile if the user changes the list). ExecuteData would then use
+// those gdcmFile and hence avoid calling the construtor:
+// - advantage: the header of the files would only be parser once.
+// - drawback: once execute information is called (i.e. on creation of
+// a vtkGdcmHeader) the gdcmFile structure is loaded in memory.
+// The average size of a gdcmHeader being of 100Ko, is one
+// loads 10 stacks of images with say 200 images each, you
+// end-up with a loss of 200Mo...
+//
+// /////// Never unallocated memory:
+// ExecuteData allocates space for the pixel data [which will get pointed
+// by the vtkPointData() through the call
+// data->GetPointData()->GetScalars()->SetVoidArray(mem, StackNumPixels, 0);]
+// This data is never "freed" neither in the destructor nor when the
+// filename list is extended, ExecuteData is called a second (or third)
+// time...
+// //////////////////////////////////////////////////////////////
+
+#include "gdcmFile.h"
+#include "gdcmHeaderHelper.h"
+#include "vtkGdcmReader.h"
+
+//#include <stdio.h>