Opened 14 years ago

Last modified 5 years ago

#774 new enhancement

i.rgb.his, i.his.rgb, d.his support for >8 bit

Reported by: hamish Owned by: grass-dev@…
Priority: normal Milestone: 7.6.2
Component: Raster Version: svn-trunk
Keywords: i.rgb.his, i.his.rgb, d.his Cc:
CPU: All Platform: All

Description

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

Attachments (3)

irgbhis_16bit.diff (5.0 KB ) - added by hamish 14 years ago.
patch to add 16bit channel support to i.rgb.his
irgbhis_16bit2.diff (9.0 KB ) - added by hamish 14 years ago.
updated patch for i.rgb.his and i.his.rgb
i.rgb.his.diff (15.3 KB ) - added by Nikos Alexandris 8 years ago.
Rewritten, outputs in ranges as defined in the HSL/HSV color space model

Download all attachments as: .zip

Change History (28)

by hamish, 14 years ago

Attachment: irgbhis_16bit.diff added

patch to add 16bit channel support to i.rgb.his

comment:1 by hamish, 14 years ago

for d.his main.c we can probably pass HIS_to_RGB() something like (int)(value_[atcol]/pow(2, bitdepth-8)) to rescale >8bit to 0,255.

opt_bit_depth->options = "8-16";

(we can only set the color to 8-bit per channel, right? so we have to degrade at some point.. might as well be here)

Hamish

in reply to:  description comment:2 by glynn, 14 years ago

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

by hamish, 14 years ago

Attachment: irgbhis_16bit2.diff added

updated patch for i.rgb.his and i.his.rgb

comment:3 by hamish, 14 years ago

updated patch attached allowing >8 bit support for i.rgb.his and i.his.rgb. Patch is against latest 6.5svn.

Note round-trip is a little lossy due to hexagonal approximation to the color-cone. TODO: use real cone geometry maths.

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.

Hamish

in reply to:  3 comment:4 by glynn, 14 years ago

Replying to 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.
  1. 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.
  1. replacing both modules with scripts which use r.mapcalc.
  1. Offering the option of "conical" HSV, i.e. RGB->YUV, H=atan2(U,V).

comment:5 by hamish, 11 years ago

renewed interest, see #2048.

comment:6 by neteler, 8 years ago

Milestone: 6.5.07.0.4

See also #2048

comment:7 by martinl, 8 years ago

Milestone: 7.0.47.0.5

comment:8 by Nikos Alexandris, 8 years ago

I tried irgbhis_16bit2.diff​ without reading much the changes it introduces. Going from RGB to HIS and back to RGB gives NULL, for all red, blue and green input maps.

by Nikos Alexandris, 8 years ago

Attachment: i.rgb.his.diff added

Rewritten, outputs in ranges as defined in the HSL/HSV color space model

comment:9 by Nikos Alexandris, 8 years ago

The attached diff works for me, for bitnesses >8-bit. The outputs hue, saturation and intensity are in their expected range, as per the HSL/HSV color space model. There is still an issue on how to instruct the output to be DCELL and not FCELL. Accordingly, I'd like to modify i.his.rgb.

Source for the math of concern are:

The current/old implementation is identical to the one documented at ERDAS' field guide. I think, however, it was meant to deal/avoid the case when hue is undefined (this being the case when the max and min values of a band/image are identical) and, perhaps, other issues with floating point math(?).

See also:

comment:10 by martinl, 8 years ago

Milestone: 7.0.57.3.0

comment:11 by martinl, 8 years ago

Milestone: 7.3.07.4.0

Milestone renamed

comment:12 by Nikos Alexandris, 8 years ago

comment:13 by Nikos Alexandris, 8 years ago

Modified versions for i.rgb.his and i.his.rgb in respective directories at https://trac.osgeo.org/grass/browser/sandbox/alexandris?order=name.

I have reasons to support closing this ticket, after checking and updating all relevant modules or scripts that use them, of course!

A reproducible session, below, to verify that:

  • i.rgb.his
    • supports for various input bitnesses (ie 8-bit Landsat 7, or 11-bit QuickBird2)
    • exports hue ranging in [0,360], intensity and saturation ranging in [0,1]
  • i.his.rgb
    • expects hue ranging in [0,360], intensity and saturation ranging in [0,1]
    • support for various output bitnesses
    • exports to user defined bitness, anything from 2 up to 16 (ie export to 6-bit [0,63], export to 8-bit [0,255], export to 16-bit [0,65535]

Note, however, the modified versions of the modules break the current functionality of i.pansharpen. This is because the the intensity values, after the modified i.rgb.his, play between 0 and 1. Before, intensity was ranging in [0,255]. The fix should be, at least, conceptually, fairly easy. See also past discussions in #2048.

# Reproducible session

Error: Failed to load processor bash
No macro or processor named 'bash' found
Version 0, edited 8 years ago by Nikos Alexandris (next)

comment:14 by martinl, 6 years ago

The status of this issue is not clear.

comment:15 by neteler, 6 years ago

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:16 by mlennert, 6 years ago

Nikos, how confident are you about your version in the sandbox ? Can it replace the version in trunk ?

comment:17 by Nikos Alexandris, 6 years ago

The statistics in https://trac.osgeo.org/grass/ticket/774#comment:13, show that going from either an 8-bit or 16-bit RGB to HIS and back to RGB, figures are not scrambled. Some rounding applies, as exemplified in the same stats above. Even visually, I confirmed (not documented here) that the old and the new versions perform the same.

It will break i.pansharpen, unless i.pansharpen treats intensity ranging in [0,1].

Nevertheless, another set of tests would be certainly good to have to confirm the correctness of the new version.

Last edited 6 years ago by Nikos Alexandris (previous) (diff)

in reply to:  17 comment:18 by neteler, 6 years ago

Version: svn-develbranch6svn-trunk

Replying to Nikos Alexandris:

The statistics in https://trac.osgeo.org/grass/ticket/774#comment:13, show that going from either an 8-bit or 16-bit RGB to HIS and back to RGB, figures are not scrambled. Some rounding applies, as exemplified in the same stats above. Even visually, I confirmed (not documented here) that the old and the new versions perform the same.

This sounds very promising.

It will break i.pansharpen, unless i.pansharpen treats intensity ranging in [0,1].

Would it be hard to add that to i.pansharpen?

Nevertheless, another set of tests would be certainly good to have to confirm the correctness of the new version.

I'd suggest to "svn move" it from sandbox to addons for wider testing with g.extention.

in reply to:  16 ; comment:19 by wenzeslaus, 6 years ago

Replying to mlennert:

Nikos, how confident are you about your version in the sandbox ? Can it replace the version in trunk ?

This is a computational danger zone, I think also automatic tests are required. I suggest to add tests to the modules in trunk and use them to test the new modules (whether they are in sandbox or addons).

in reply to:  19 comment:20 by Nikos Alexandris, 6 years ago

Replying to wenzeslaus:

Replying to mlennert:

Nikos, how confident are you about your version in the sandbox ? Can it replace the version in trunk ?

This is a computational danger zone, I think also automatic tests are required. I suggest to add tests to the modules in trunk and use them to test the new modules (whether they are in sandbox or addons).

I fully agree. These tests would be another good exercise for me. If I only can make it to the upcoming code sprint, I will work on these.

Please, see also/don't forget the other two:

comment:21 by Nikos Alexandris, 6 years ago

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

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?

comment:22 by neteler, 6 years ago

Milestone: 7.4.17.4.2

comment:23 by martinl, 6 years ago

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:24 by martinl, 5 years ago

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:25 by martinl, 5 years ago

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.