[Gdcm-hackers] gdcm-git:Grassroots DICOM branch master updated. 84cac81e6d87b13a078489f227866f6154876c45

[Mathieu M. <ma...@us...>]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Grassroots DICOM".

The branch, master has been updated
       via  84cac81e6d87b13a078489f227866f6154876c45 (commit)
      from  622072cf84276c3e53b0331366cccb405255d317 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://gdcm.git.sourceforge.net/git/gitweb.cgi?p=gdcm/gdcm;a=commit;h=84cac81e6d87b13a078489f227866f6154876c45

commit 84cac81e6d87b13a078489f227866f6154876c45
Author: Mathieu Malaterre <mat...@gm...>
Date:   Thu Feb 3 15:15:50 2011 +0100

    Add a new option for specifying the ImageFormat

diff --git a/Source/MediaStorageAndFileFormat/gdcmImageChangePhotometricInterpretation.cxx b/Source/MediaStorageAndFileFormat/gdcmImageChangePhotometricInterpretation.cxx
index 2d1a0f3..ca6ca61 100644
--- a/Source/MediaStorageAndFileFormat/gdcmImageChangePhotometricInterpretation.cxx
+++ b/Source/MediaStorageAndFileFormat/gdcmImageChangePhotometricInterpretation.cxx
@@ -26,14 +26,28 @@ namespace gdcm
  * http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/1190189387c1702c
  * http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/a9e118fbbf6dcc9f
  * http://forum.dcmtk.org/viewtopic.php?p=5441&sid=61ad1304edb31203c4136890ab651405
-YBR_FULL as Photometric Interpretation is really the right thing to do. The problem is that the JPEG bitstream as such does not contain any indication of the color model - it just specifies that there are three samples per pixel. In theory it is well possible to apply baseline JPEG compression to RGB pixel data, although this is an unusual approach since YCbCr provides for better compression ratio at given image quality. A JFIF header would contain that information, but the JFIF header is neither required nor recommended in the DICOM JPEG bitstream. In the absence of that information, and with a JPEG compressed DICOM file where Photometric Interpretation is "RGB", the parser needs to decide whether the encoder did something unsual but legal and decompress the JPEG bitstream as RGB, or whether the encoder just failed to correctly encode the color model of the JPEG bitstream (which in my experience is in most cases the correct assumption) and ignore Photometric Interpretation (and thus incorrectly decode unusual but legal images).
+
+YBR_FULL as Photometric Interpretation is really the right thing to do. The
+problem is that the JPEG bitstream as such does not contain any indication of
+the color model - it just specifies that there are three samples per pixel. In
+theory it is well possible to apply baseline JPEG compression to RGB pixel
+data, although this is an unusual approach since YCbCr provides for better
+compression ratio at given image quality. A JFIF header would contain that
+information, but the JFIF header is neither required nor recommended in the
+DICOM JPEG bitstream. In the absence of that information, and with a JPEG
+compressed DICOM file where Photometric Interpretation is "RGB", the parser
+needs to decide whether the encoder did something unsual but legal and
+decompress the JPEG bitstream as RGB, or whether the encoder just failed to
+correctly encode the color model of the JPEG bitstream (which in my experience
+is in most cases the correct assumption) and ignore Photometric Interpretation
+(and thus incorrectly decode unusual but legal images).
 */
 bool ImageChangePhotometricInterpretation::ChangeMonochrome()
 {
   // Ok let's give up on this one for now.
-  // We would need to take care of Pixel Padding Value to actually be able to invert the image
-  // without this information we potentially will be making mistake. just like Largest Image Pixel Value and other
-  // would be wrong
+  // We would need to take care of Pixel Padding Value to actually be able to
+  // invert the image without this information we potentially will be making
+  // mistake. just like Largest Image Pixel Value and other would be wrong
   return false;
   const Pixmap &image = *Input;
   PhotometricInterpretation pi = image.GetPhotometricInterpretation();
diff --git a/Utilities/VTK/Applications/gdcm2vtk.cxx b/Utilities/VTK/Applications/gdcm2vtk.cxx
index a95170f..58e30d0 100644
--- a/Utilities/VTK/Applications/gdcm2vtk.cxx
+++ b/Utilities/VTK/Applications/gdcm2vtk.cxx
@@ -87,6 +87,7 @@ void PrintHelp()
   std::cout << "  -T --study-uid        Study UID." << std::endl;
   std::cout << "  -S --series-uid       Series UID." << std::endl;
   std::cout << "     --root-uid         Root UID." << std::endl;
+  std::cout << "     --imageformat      Image Format [1-8] (aka PhotometricInterpretation)." << std::endl;
   std::cout << "Compression Types (lossless):" << std::endl;
   std::cout << "  -J --jpeg                           Compress image in jpeg." << std::endl;
   std::cout << "  -K --j2k                            Compress image in j2k." << std::endl;
@@ -130,8 +131,10 @@ int main(int argc, char *argv[])
   int lowerleft = 0;
   int oshift = 0;
   int oscale = 0;
+  int oimageformat = 0;
   double shift = 0.;
   double scale = 1.;
+  int imageformat = 0;
 
   int verbose = 0;
   int warning = 0;
@@ -164,6 +167,7 @@ int main(int argc, char *argv[])
         {"lower-left", 0, &lowerleft, 1}, // use FileLowerLeftOn
         {"shift", 1, &oshift, 1}, //
         {"scale", 1, &oscale, 1}, //
+        {"imageformat", 1, &oimageformat, 1}, //
 
 // General options !
         {"verbose", 0, &verbose, 1},
@@ -228,6 +232,11 @@ int main(int argc, char *argv[])
             assert( strcmp(s, "scale") == 0 );
             scale = atof(optarg);
             }
+          else if( option_index == 17 ) /* imageformat */
+            {
+            assert( strcmp(s, "imageformat") == 0 );
+            imageformat = atoi(optarg);
+            }
           //printf (" with arg %s", optarg);
           }
         //printf ("\n");
@@ -746,6 +755,10 @@ int main(int argc, char *argv[])
     {
     writer->SetScale( scale );
     }
+  if( oimageformat )
+    {
+    writer->SetImageFormat( imageformat );
+    }
 
   // Pass on the filetime of input file
   time_t studydatetime = gdcm::System::FileTime( filename );
diff --git a/Utilities/doxygen/man/gdcm2vtk.man b/Utilities/doxygen/man/gdcm2vtk.man
index c76e568..1a26888 100644
--- a/Utilities/doxygen/man/gdcm2vtk.man
+++ b/Utilities/doxygen/man/gdcm2vtk.man
@@ -143,12 +143,38 @@ $ gdcm2vtk input.dcm output.dcm
 \endverbatim
 
 vtkGDCMImageReader will be used to read in a DICOM file, not the default vtkDICOMImageReader.
+See option --use-vtkdicom to use vtkDICOMImageReader.
 
-IMPORTANT NOTE: The internal VTK structured will be filled from the input DICOM, and then pass to the output DICOM writer. Some information might be lost during the conversion DICOM to VTK to DICOM. This option is mostly used to test the vtkGDCMImageReader/vtkGDCMImageWriter combination.
+\section round_tripmhd RoundTrip DICOM to MHD to DICOM
 
-IMPORTANT NOTE: When converting from a lossy format such as JPEG, the information of lossiness is important. The output DICOM will contains the required Lossy Image Compression attribute that indicates that image was lossy-compressed somewhere along the pipeline. See also gdcmimg (better handling of JPEG in general).
+\verbatim
+$ gdcm2vtk input_ybr.dcm output.mhd
+$ gdcm2vtk --modality US --imageformat 7 output.mhd output.dcm
+\endverbatim
 
-IMPORTANT NOTE: When using --use-vtkdicom the output DICOM file will always be written as MR Image Storage as this information is not available from the reader itself. This allow setting the Image Orientation (Patient) properly.
+The above section shows how to convert a DICOM using the Photometric Interpretation of YBR_FULL
+(or even YBR_FULL_422 is lossy) into another file format: MetaImage (mhd). Since this
+file format does not handle color space, we have to explicitely set it using the --imageformat
+command line option.
+The --modality command line option is required in this case since the default Secondary Capture
+Image Storage Class family does not allow for YBR Photometric Interpretation.
+
+\section gdcm2vtk_notes gdcm2vtk notes
+
+IMPORTANT NOTE: The internal VTK structured will be filled from the input
+DICOM, and then pass to the output DICOM writer. Some information might be lost
+during the conversion DICOM to VTK to DICOM. This option is mostly used to test
+the vtkGDCMImageReader/vtkGDCMImageWriter combination.
+
+IMPORTANT NOTE: When converting from a lossy format such as JPEG, the
+information of lossiness is important. The output DICOM will contains the
+required Lossy Image Compression attribute that indicates that image was
+lossy-compressed somewhere along the pipeline. See also gdcmimg (better
+handling of JPEG in general).
+
+IMPORTANT NOTE: When using --use-vtkdicom the output DICOM file will always be
+written as MR Image Storage as this information is not available from the
+reader itself. This allow setting the Image Orientation (Patient) properly.
 
 \section see_also SEE ALSO
 

-----------------------------------------------------------------------

Summary of changes:
 .../gdcmImageChangePhotometricInterpretation.cxx   |   22 +++++++++++--
 Utilities/VTK/Applications/gdcm2vtk.cxx            |   13 ++++++++
 Utilities/doxygen/man/gdcm2vtk.man                 |   32 ++++++++++++++++++--
 3 files changed, 60 insertions(+), 7 deletions(-)


hooks/post-receive
-- 
Grassroots DICOM