Pixel origin convention

From OTBWiki
Revision as of 09:53, 25 September 2014 by Gpasero (Talk | contribs) (Filters to update)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page follow the status of the pixel convention used in OTB and other libraries such as GDAL. In addition, several filters need an update so that they are consistent with the convention chosen in OTB.

The dilemma

The georeferencing of images can be done by simply using an origin and a spacing. There are two major convention to link the physical space (ground coordinates) and the index space (indices coordinates) :

  • Pixel centred origin : the origin point corresponds to the location of the centre of the top-left pixel.
  • Corner origin : the origin point corresponds to the location of the top-left corner of the top-left pixel.

Which conventions are used ?

The pixel centred convention is used in OTB and ITK. Note that in older ITK versions ( before 4.0 ), both conventions were supported, using a compilation flag. At the moment, the goal is to use this convention everywhere in the OTB.

In GDAL, the corner origin convention is used. For instance, the geotransform given by GDAL is expressed in this convention : the terms GT(0) and GT(3) corresponds to the coordinates of the top-left corner of the image (regardless of the type of pixel : area or point).

Filters to update

This section list the filters that need an update. When the update has been done, struck out the name and give the corresponding commit. The line numbers given refer to changeset 16837. The corresponding Mantis bug is 942 : http://bugs.orfeo-toolbox.org/view.php?id=942

The first filters to update are the ImageIO's.


These filters use the geotransform given by GDAL :

The other ImageIOs have been updated to use a default origin at [0.5 , 0.5] to ensure consistency when reading/writing from 2 differents ImageIOs. (http://hg.orfeo-toolbox.org/OTB/rev/b5611cea6168)

  • Code/IO/otbBSQImageIO.cxx
  • Code/IO/otbLUMImageIO.cxx
  • Code/IO/otbMSTARImageIO.cxx
  • Code/IO/otbMWImageIO.cxx
  • Code/IO/otbONERAImageIO.cxx
  • Code/IO/otbRADImageIO.cxx
  • Code/IO/otbTileMapImageIO.cxx

Several OTB filters have been written using the corner-pixel convention. They are sorted by category. Some of them have been reviewed without any modification to do. If filters have not been spotted so far, they will be added.







  • Code/OBIA/otbLabelObjectToPolygonFunctor.txx : see line 550, Check methods WalkRight and WalkLeft, the computed offset should be between -0.5 and 0.5 (http://hg.orfeo-toolbox.org/OTB/rev/71079039f02b)
  • Code/OBIA/otbVectorDataToLabelMapWithAttributesFilter.txx : see line 145, Origin computed doesn"t takes into account the centered pixel convention, the filter assumes that vector data contains index coordinates values, see line 330  : Beware of confusion between bounding region and image origin (http://hg.orfeo-toolbox.org/OTB/rev/71079039f02b)


  • Code/MultiScale/otbMorphologicalPyramidResampler.txx : see line 145, the resampler keep the same origin between 2 pyramid levels, the transform used only accounts for the scale factor (http://hg.orfeo-toolbox.org/OTB/rev/2817106a9681). Now, with a factor 2 resampling, each resampled pixel equals the average of the corresponding block of 4 neighbours in the input image.


  • Code/Segmentation/otbOGRLayerStreamStitchingFilter.txx : see line 142 and after, the computation of the stream line in physical space doesn't correspond to the centred pixel convention. Also the computation of the spatial filters (line 164 and 208) seems inaccurate. (http://hg.orfeo-toolbox.org/OTB/rev/50c90708cd89) Now, the test obTuOGRLayerStreamStitchingFilter passes using the original baseline.


  • Code/FeatureExtraction/otbGenericRoadExtractionFilter.txx : obviously a bug, the m_Resolution parameter is never updated. Since the sigma value used by the gradient filter is constant in pixel units, let's use this unit in the gradient filter. (see http://hg.orfeo-toolbox.org/OTB/rev/42017ce0477b). The corresponding test (feTvRoadExtractionFilter) had 5 multi-baselines. One of them had comparable results to what is produced now. All multi-baselines have been removed, the present baseline has been updated.