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