[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 Nikos Alexandris):

 Replying to [comment:35 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.

 I will, as soon as I find some time.


 > 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.

 I understand.  Let's go step by step then.


 > 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 agree. Yet, my understanding is, no rescaling should be performed.  What
 goes in, should go out. Some loss of precision due to rounding applies.
 But no other loss should be justified.  And this should be our target.
 Histogram matching doesn't or shouldn't care either about the input range.
 It should respect the given range, be it 4-bit or 64-bit.  Some histogram
 matching routines, though, will introduce values to fill-in gaps while
 trying to match a "real world" histogram with the one of a function. But
 this is not rescaling.

 > 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.

 Pan-sharpening fuses low and high spatial resolution images. These images
 are expected to capture the same object, in different dimensions. If we
 have 4-bit images, one high-res at 1m and one, or more, low-res at 4m,
 then these will be a valid subject for pan-sharpening.  Please correct me
 if I am wrong.


 > 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?

 What about we support the maximum possible bitness that the GRASS raster
 engine can handle?

 > 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.


 I did and I did not read any error. Unless I did not try your latest
 update.
 In any case, thanks for taking the time to work on it.

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