[GRASS-dev] [GRASS GIS] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

[GRASS GIS]

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--------------------------+-----------------------------------------
  Reporter:  hamish       |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.4.1
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  i.rgb.his, i.his.rgb, d.his
       CPU:  All          |   Platform:  All
--------------------------+-----------------------------------------

Comment (by Nikos Alexandris):

 A `gunittest` is available at:
 https://github.com/NikosAlexandris/test_color_space_conversions/blob/master/test_color_space_roundtrips.py

 The tests compare the input R, G and B images (Landsat imagery from the
 `nc_spm_08_grass7` test data set)  from 6- up to 16-bit (by rescaling the
 original inputs) with the output R, G and B after a roundtrip from RGB to
 HIS and back to RGB color spaces.

 They confirm, as far as I understand, that the suggested modules

  * https://trac.osgeo.org/grass/browser/sandbox/alexandris/i.rgb.his/
  * https://trac.osgeo.org/grass/browser/sandbox/alexandris/i.his.rgb/

 work with precision levels 0.1 and 0.01. Setting the precision to 0.001,
 will cause the the test fail for `bits=` >= 15.

 HIS values are also tested for being inside the expected ranges.

 A review of the script would be much appreciated in order to confirm its
 functionality.

 Some points:

 * The script tests both the `i.rgb.his` and `i.his.rgb` modules. So, where
 should it be placed?

 * `r.rescale` smartly picks up the max value among any two values given in
 the `to=` parameter. This is a bit confusing and the tests will fail for
 bitnesses < 6. I think it is meaningful to test for bitnesses all the way
 down to 2-bit images.

 * Currently, the test counts 4 tests. Maybe it would make more sense to
 count as many as the different precision levels requested, and in addition
 as many as the different bitnesses tested.

 * Would be it better to create dynamically synthetic images instead of
 using "external" imagery?

 Can someone move the test to trunk as suggested by Vaclav?

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