OSGeo.org › OSGeo Software and Data Projects › GRASS › Grass - Dev

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

5 messages

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

Reply Threaded

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
-----------------------------------------+----------------------------------
Reporter: hamish | Owner: [hidden email]
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Keywords: i.rgb.his, i.his.rgb, d.his | Platform: All
Cpu: All |
-----------------------------------------+----------------------------------
Hi,

it would be nice if i.rgb.his, i.his.rgb, d.his modules could have support
for >8 bit colors.

attached is a patch which does this for i.rgb.his.

i.his.rgb and d.his are a bit deeper into the max=255 and casting CELLs to
unsigned char.

Hamish

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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

GRASS GIS

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

Reply Threaded

GRASS GIS

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

Reply Threaded

In reply to this post by GRASS GIS

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: [hidden email]
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 [ticket:774 hamish]:

> it would be nice if i.rgb.his, i.his.rgb, d.his modules could have
support for >8 bit colors.

> i.his.rgb and d.his are a bit deeper into the max=255 and casting CELLs
to unsigned char.

d.his uses the raster's colour table, so it will work with integer rasters
of any bit depth, as well as FP rasters. The use of 8 bits within d.his is
due to both GRASS' colour tables and the display architecture using 8-bit
intensity values.

I'm not sure that there is much point in changing the display architecture
when display hardware which supports more than 8-bit intensity is so rare
(I know that some image formats support more than this, but that's not
much use if the images are going to be displayed on hardware which only
supports 8 bits).

For i.* or r.* modules, you can either use the raster's colour table, or
you need an associated scale parameter for each input raster (and possibly
an offset parameter as well), or you require that all inputs be FP rasters
where 0.0 is black and 1.0 is white.

Using the colour table limits you to 8-bit resolution, but it does at
least allow you to use maps with more resolution as inputs.

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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

GRASS GIS

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

Reply Threaded

In reply to this post by GRASS GIS

GRASS GIS

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

Reply Threaded

In reply to this post by GRASS GIS

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: [hidden email]
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>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev