ImageReadWrite.cxx 7.03 KB
Newer Older
1 2
/*
 * Copyright (C) 1999-2011 Insight Software Consortium
Julien Michel's avatar
Julien Michel committed
3
 * Copyright (C) 2005-2019 Centre National d'Etudes Spatiales (CNES)
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
 *
 * This file is part of Orfeo Toolbox
 *
 *     https://www.orfeo-toolbox.org/
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
21

22

23 24 25 26 27 28
//  The classes responsible for reading and writing images are located at the
//  beginning and end of the data processing pipeline. These classes are
//  known as data sources (readers) and data sinks (writers).
//  Generally speaking they are referred to as filters, although readers have
//  no pipeline input and writers have no pipeline output.
//
29 30
//  The reading of images is managed by the class \doxygen{otb}{ImageFileReader}
//  while writing is performed by the class \doxygen{otb}{ImageFileWriter}. These
31 32 33
//  two classes are independent of any particular file format. The actual low
//  level task of reading and writing specific file formats is done behind
//  the scenes by a family of classes of type
34
//  \doxygen{itk}{ImageIO}. Actually, the OTB image Readers and
35 36 37 38 39 40
//  Writers are very similar to those of ITK, but provide new
//  functionnalities which are specific to remote sensing images.
//
//  The first step for performing reading and writing is to include the
//  following headers.
//
41
//  \index{otb::ImageFileReader}
42 43
//  \index{otb::ImageFileReader!header}
//
44
//  \index{otb::ImageFileWriter}
45 46 47 48 49
//  \index{otb::ImageFileWriter!header}

#include "otbImageFileReader.h"
#include "otbImageFileWriter.h"

50
#include "otbImage.h"
51

52
int main(int argc, char* argv[])
53 54
{
  // Verify the number of parameters in the command line
OTB Bot's avatar
STYLE  
OTB Bot committed
55
  if (argc < 3)
56
  {
57 58 59
    std::cerr << "Usage: " << std::endl;
    std::cerr << argv[0] << " inputImageFile  outputImageFile " << std::endl;
    return EXIT_FAILURE;
60
  }
61 62 63 64 65 66 67 68 69 70 71 72 73 74

  //  Then, as usual, a decision must be made about the type of pixel used to
  //  represent the image processed by the pipeline. Note that when reading
  //  and writing images, the pixel type of the image \textbf{is not
  //  necessarily} the same as the pixel type stored in the file.  Your
  //  choice of the pixel type (and hence template parameter) should be
  //  driven mainly by two considerations:
  //
  //  \begin{itemize}
  //  \item It should be possible to cast the file pixel type in the file to
  //  the pixel type you select. This casting will be performed using the
  //  standard C-language rules, so you will have to make sure that the
  //  conversion does not result in information being lost.
  //  \item The pixel type in memory should be appropriate to the type of
75
  //  processing you intended to apply on the images.
76 77 78 79 80
  //  \end{itemize}
  //
  //  A typical selection for remote sensing images is illustrated in
  //  the following lines.

81 82 83
  using PixelType              = unsigned short;
  const unsigned int Dimension = 2;
  using ImageType              = otb::Image<PixelType, Dimension>;
84 85 86 87 88 89 90 91 92 93

  //  Note that the dimension of the image in memory should match the one of
  //  the image in file. There are a couple of special cases in which this
  //  condition may be relaxed, but in general it is better to ensure that both
  //  dimensions match. This is not a real issue in remote sensing,
  //  unless you want to consider multi-band images as volumes (3D) of data.
  //
  //  We can now instantiate the types of the reader and writer. These two
  //  classes are parameterized over the image type.
  //
94 95
  //  \index{otb::ImageFileReader!Instantiation}
  //  \index{otb::ImageFileWriter!Instantiation}
96

97 98
  using ReaderType = otb::ImageFileReader<ImageType>;
  using WriterType = otb::ImageFileWriter<ImageType>;
99 100

  //  Then, we create one object of each type using the New() method and
101
  //  assigning the result to a \doxygen{itk}{SmartPointer}.
102 103 104 105 106 107 108 109 110 111 112
  //
  //  \index{otb::ImageFileReader!New()}
  //  \index{otb::ImageFileWriter!New()}
  //  \index{otb::ImageFileReader!SmartPointer}
  //  \index{otb::ImageFileWriter!SmartPointer}

  ReaderType::Pointer reader = ReaderType::New();
  WriterType::Pointer writer = WriterType::New();

  // Here we recover the file names from the command line arguments
  //
113 114
  const char* inputFilename  = argv[1];
  const char* outputFilename = argv[2];
115 116

  //  The name of the file to be read or written is passed with the
117
  //  SetFileName() method.
118 119 120 121 122 123
  //
  //  \index{otb::ImageFileReader!SetFileName()}
  //  \index{otb::ImageFileWriter!SetFileName()}
  //  \index{SetFileName()!otb::ImageFileReader}
  //  \index{SetFileName()!otb::ImageFileWriter}

OTB Bot's avatar
STYLE  
OTB Bot committed
124 125
  reader->SetFileName(inputFilename);
  writer->SetFileName(outputFilename);
126 127 128 129 130

  //  We can now connect these readers and writers to filters to create a
  //  pipeline. For example, we can create a short pipeline by passing
  //  the output of the reader directly to the input of the writer.

OTB Bot's avatar
STYLE  
OTB Bot committed
131
  writer->SetInput(reader->GetOutput());
132 133 134 135 136 137 138 139 140

  //  At first view, this may seem as a quite useless program, but it is
  //  actually implementing a powerful file format conversion tool! The
  //  execution of the pipeline is triggered by the invocation of the
  //  \code{Update()} methods in one of the final objects. In this case, the final
  //  data pipeline object is the writer. It is a wise practice of defensive
  //  programming to insert any \code{Update()} call inside a \code{try/catch} block
  //  in case exceptions are thrown during the execution of the pipeline.

141
  try
142
  {
143
    writer->Update();
144
  }
OTB Bot's avatar
STYLE  
OTB Bot committed
145
  catch (itk::ExceptionObject& err)
146
  {
147 148
    std::cerr << "ExceptionObject caught !" << std::endl;
    std::cerr << err << std::endl;
149
    return EXIT_FAILURE;
150
  }
151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166

  //  Note that exceptions should only be caught by pieces of code that know
  //  what to do with them. In a typical application this \code{catch} block
  //  should probably reside on the GUI code. The action on the \code{catch}
  //  block could inform the user about the failure of the IO operation.
  //
  //  The IO architecture of the toolkit makes it possible to avoid explicit
  //  specification of the file format used to read or write
  //  images.\footnote{In this example no file format is specified; this
  //  program can be used as a general file conversion utility.}  The object
  //  factory mechanism enables the ImageFileReader and ImageFileWriter to
  //  determine (at run-time) with which file format it is working
  //  with. Typically, file formats are chosen based on the filename
  //  extension, but the architecture supports arbitrarily complex processes
  //  to determine whether a file can be read or written. Alternatively, the
  //  user can specify the data file format by explicit instantiation and
167
  //  assignment the appropriate \doxygen{itk}{ImageIO} subclass.
168 169 170 171
  //

  return EXIT_SUCCESS;
}