[GRASS-dev] Re: [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 at lists.osgeo.org  
      Type:  enhancement  |      Status:  new                        
  Priority:  normal       |   Milestone:  6.5.0                      
 Component:  Raster       |     Version:  svn-develbranch6           
Resolution:               |    Keywords:  i.rgb.his, i.his.rgb, d.his
  Platform:  All          |         Cpu:  All                        
--------------------------+-------------------------------------------------
Comment (by glynn):

 Replying to [comment:3 hamish]:

 > These modules write out colr/ tables as min,max of channel. Would it be
 better to write them out as 0,max_level for the particular bit-depth? e.g.
 0,255 for 8-bit and 0,2047 for 11-bit. Then d.rgb and d.his give natural
 looking results without subtle extra steps.

 Apart from anything else, assigning black/white to the min/max of the data
 is definitely wrong.

 Beyond that, I suggest:

 1. changing bit_depth= to max_level=, and reading the maps as DCELL, so
 that the modules work with both integer and FP data, including integer
 data where max isn't a power of two.

 2. making the output FCELL, with values in the range 0.0 to 1.0 (or
 possibly 0.0 to 360.0 for hue), and using those values for 0% and 100%
 intensity. Note that d.his uses G_get_raster_row_colors(), so it doesn't
 care about the actual values, only the corresponding colours.

 3. replacing both modules with scripts which use r.mapcalc.

 4. Offering the option of "conical" HSV, i.e. RGB->YUV, H=atan2(U,V).

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