[GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-------------------------+-------------------------------------------------
  Reporter:  Nikos       |      Owner:  grass-dev@…
  Alexandris             |
      Type:  defect      |     Status:  new
  Priority:  normal      |  Milestone:  7.6.1
 Component:  Imagery     |    Version:  svn-trunk
Resolution:              |   Keywords:  i.pansharpen, sharpening, fusion,
                         |  brovey, ihs, pca, 8-bit
       CPU:  All         |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by cmbarton):

 I am hoping that someone can test the revised code. I'll work on updating
 the docs a bit to match the new options.

 The algorithms used in the script were devised with assumed 8bit image
 channels. The math might work with other bit depths, but other assumptions
 might be violated. Maybe someone else can clarify. Beyond that, the
 histogram matching method would need to be redesigned to accommodate
 imagery other than 8bit.  Allowing for floating point image value would
 require yet more reworking, including new versions of i.rgb.his and
 i.his.rgb. Hence, rescaling the original images to 8 bit seems like a good
 solution at the present.

 While I'm comfortable with downscaling from higher to lower bit depth
 (e.g., 16 down to 8), I'm less comfortable with upscaling imagery at less
 than 8 bits. I tried this on 3bit imagery (rescaled from 8bit landsat) and
 it produced visually poor results that do not show the level of feature
 differentiation seen in the 3 bit pan channel alone. So keeping it at
 ≥8bit seems advisable unless there is a reason pan "sharpening" of lower
 bit depth is actually useful for something. The cutoff at 32 bits is
 arbitrary and could easily be increased to higher values. Any reason to do
 this or not do this if the images are rescaled to 8bits for processing
 anyway?

 If you run i.pansharpen in the terminal, anything outside the 8-32 bit
 range will already generate an error with a message that bit depth is
 outside the allowed range. If you do it in the GUI, a message will only be
 generated in the console. I could add a wxPython pop up, but not sure it
 is worth it. Maybe the best is to have the module fail (i.e., with a
 return) if bit depth is outside the acceptable range rather than set it
 back to 8.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:35>
GRASS GIS <https://grass.osgeo.org>