[GRASS-dev] Re: i.rgb.his/i.his.rgb and 16bit images

Hamish · September 30, 2009, 4:12pm

Georg wrote:

Georg Kaspar wrote:
> this could be corrected by replacing the constant 255
with a variable according to the encoding of the image.
> i'm not quite shure how to do this (only did some
scripting so far) - can somebody help?

see also 'gdalinfo -stats' on raw data and 'r.info -r' on grass
maps.

where is rgb2his.c, I don't see it in grass 6.5

if that is a C module, ideally the 256 should be made a
module option which defaults to 256.

see attached patch x6.5, I'm not quite sure if the approach is
right though so haven't applied it.

Also, for a long time I have wanted to replace the quick
sexidecimal method with propper cone geometry math, but not
found the time. It doesn't seem too hard, and computers are
much faster these days.

to be more precise: how can i read-out the encoding of a
raster file (or the maximum value) in c? I already took a
look at the programmer's manual but didn't find what i'm
looking for (i'm accustomed to javadoc...).

from d.legend:

struct Range range;
struct FPRange fprange;

...
    if (!fp) {
        if (G_read_range(map_name, mapset, &range) == -1)
            G_fatal_error(_("Range information for <%s> not available (run r.support)"),
                          map_name);

        G_get_range_min_max(&range, &min_ind, &max_ind);
        if (G_is_c_null_value(&min_ind))
            G_fatal_error(_("Input map contains no data"));

.
.
.

    else { /* is fp */
        if (G_read_fp_range(map_name, mapset, &fprange) == -1)
            G_fatal_error(_("Range information for <%s> not available"),
                          map_name);

G_get_fp_range_min_max(&fprange, &dmin, &dmax);

but the max value should be the channel's max, not the observed
max, so I think the module option is better.

as for dull greys, the grey255 color map is there to force min=0
max=255. If you want grey66535 just copy the 255 file and edit
to suit.

Hamish

(attachments)

i_rgb_his_depth.diff (5.03 KB)

Hamish · September 30, 2009, 4:37pm

Hamish wrote:

where is rgb2his.c, I don't see it in grass 6.5

if that is a C module, ideally the 256 should be made a
module option which defaults to 256.

[... time passes ... I found it ...]

see attached patch x6.5,

H

Georg_Kaspar1 · October 1, 2009, 2:06pm

Hamish wrote:

see attached patch x6.5, I'm not quite sure if the approach is
right though so haven't applied it.

thanks for the effort. i compiled the module with the applied patch, but the output is still encoded in 8 bit. can'ts see why though...

Hamish · October 1, 2009, 5:38pm

[16bit quickbird images + i.rgb2his, i.his2rgb]

Hamish wrote:

> see attached patch x6.5, I'm not quite sure if the approach is
> right though so haven't applied it.

Georg Kaspar wrote:

thanks for the effort. i compiled the module with the
applied patch, but the output is still encoded in 8 bit.
can'ts see why though...

Very sorry if this is a dumb question, but did you set n_levels=
to 65535? (it defaults to 8bit)
Does 'i.rgb2his --help' show the option?
what does 'r.info -r' say about the 3 r,g,b bands?

really that option name is misleading, it should be max_level=255
or n_levels=256 or bitdepth=8. I think to go with bitdepth= with
8,16 as the only options. Anyone know if 32bit or other bits
satellite/imagery data exist?

set colors with:

r.colors band.red color=rules
0 black
65535 white
end

etc.

note that i.his2rgb has not been modified; experimenting with
i.rgb2his first.

do you know of any free-for-download QB data for testing it
with?

Hamish

Georg_Kaspar1 · October 2, 2009, 11:21am

Hamish wrote:

Very sorry if this is a dumb question, but did you set n_levels= to
65535? (it defaults to 8bit)

actually i set it to 2048 but i guess i should have used 2047. the data
seems to be encoded using 11bits

Does 'i.rgb2his --help' show the option? what does 'r.info -r' say about
the 3 r,g,b bands?

yes, the option is shown.

r.info -r on initial datasets
min=0
max=2047

really that option name is misleading, it should be max_level=255 or
n_levels=256 or bitdepth=8. I think to go with bitdepth= with 8,16 as
the only options. Anyone know if 32bit or other bits satellite/imagery
data exist?

yes, quickbird seems to use 11bit
but i guess grass will use 16bit to store the data anyway...

set colors with:

r.colors band.red color=rules
0 black
65535 white
end

etc.

note that i.his2rgb has not been modified; experimenting with i.rgb2his
first.

do you know of any free-for-download QB data for testing it with?

http://glcf.umiacs.umd.edu/data/quickbird/

bests,
Georg

Hamish · October 5, 2009, 2:58am

Georg Kaspar wrote:

> do you know of any free-for-download QuickBird data for testing it
> with?

http://glcf.umiacs.umd.edu/data/quickbird/

I have tried to load some of that and found a few things.
Now documented in the GRASS wiki:
http://grass.osgeo.org/wiki/QuickBird

With that I can get a RGB image that looks mostly-pseudo-true-color.

* red and blue bands are imported backwards and must be renamed.

This post claims it is a data provider problem, but I quietly suspect
that it may be a GDAL problem after all. (?)
http://osdir.com/ml/gis.gdal.devel/2004-03/msg00025.html

* data is excessively dark and green band is higher gain than rest.

You can use i.landsat.rgb to rebalance the RGB, but gains/saturation is
still a bit off. I'm not sure if you are supposed to use the Panchromatic
channel to set the brightness, or... ? ISTR that some commercial provider
intentionally degraded Freebie offerings, not sure if that is the case
here or there is some calibration issue that we are not aware of.

Was your desire to use i.rgb2his in order to fix the brightness issue, or
was it for some analysis purpose?

Hamish

Georg_Kaspar1 · October 5, 2009, 12:54pm

Hamish wrote:

Was your desire to use i.rgb2his in order to fix the brightness issue, or
was it for some analysis purpose?

Actually the purpose was pansharpening. This could also be done with principal components, but grass lacks an inverse-pca module as far as i know...

Hamish · October 5, 2009, 7:17pm

Georg wrote:

Actually the purpose was pansharpening.

i.fusion.brovey -q

http://grass.osgeo.org/grass64/manuals/html64_user/i.fusion.brovey.html

example added on wiki page

This could also be done with principal components, but grass
lacks an inverse-pca module as far as i know...

maybe Nikos could comment.

Note that with the R-grass bridge you can use any of the many R
statistical methods + functions.

regards,
Hamish

ps- patch added in the trac system to allow i.rbg2his to work
with 11-bit data (I fixed the truncation to 255 you saw before),
but d.his and i.his2rgb are still 8-bit only for now. Waiting
on word that I'm on the right track before moving onto the other
modules.

Georg_Kaspar1 · October 7, 2009, 7:06am

Hamish wrote:

Georg wrote:

Actually the purpose was pansharpening.

i.fusion.brovey -q

yes, i know this module, but i wanted to compare different approaches

This could also be done with principal components, but grass
lacks an inverse-pca module as far as i know...

maybe Nikos could comment.

Note that with the R-grass bridge you can use any of the many R
statistical methods + functions.

R is great as long as your datasets are small. problems arise when you try to process l a r g e image files in R...

ps- patch added in the trac system to allow i.rbg2his to work
with 11-bit data (I fixed the truncation to 255 you saw before),
but d.his and i.his2rgb are still 8-bit only for now. Waiting
on word that I'm on the right track before moving onto the other
modules.

thanks for that. i'm shure this is a nice improvement and one reason less to use erdas...

Georg_Kaspar1 · March 31, 2010, 10:08am

Hamish schrieb:

ps- patch added in the trac system to allow i.rbg2his to work
with 11-bit data (I fixed the truncation to 255 you saw before),
but d.his and i.his2rgb are still 8-bit only for now. Waiting
on word that I'm on the right track before moving onto the other
modules.

Hi,
the last release candidate still does not support images with more than 8 bit. I did apply the patch and it worked out for me - would be nice to see the improvement in the release...
regards,
Georg

neteler · March 31, 2010, 4:09pm

On Wed, Mar 31, 2010 at 12:08 PM, Georg Kaspar <georg@muenster.de> wrote:

Hamish schrieb:

ps- patch added in the trac system to allow i.rbg2his to work
with 11-bit data (I fixed the truncation to 255 you saw before),
but d.his and i.his2rgb are still 8-bit only for now. Waiting
on word that I'm on the right track before moving onto the other
modules.

Hi,
the last release candidate still does not support images with more than 8
bit. I did apply the patch and it worked out for me - would be nice to see
the improvement in the release...

Georg,

please (if not there) open an enhancement ticket with milestone 6.4.1 for
this and attach the patch against 6.40RC6.

thanks
Markus

Glynn_Clements1 · March 31, 2010, 8:26pm

Georg Kaspar wrote:

> ps- patch added in the trac system to allow i.rbg2his to work
> with 11-bit data (I fixed the truncation to 255 you saw before),
> but d.his and i.his2rgb are still 8-bit only for now.

d.his uses the maps' associated colour tables, which only support 8
bits per component, as does the display architecture, so this
restriction be changed (and mostly isn't relevant; 16-bit or
floating-point rasters work fine, so long as they have a suitable
colour table).

It seems to me that i.rgb.his and i.his.rgb would be better
implemented as scripts which use r.mapcalc. Either way, the
calculation should be performed using floating-point values in the
range 0.0 to 1.0, which conversion on input and output.

--
Glynn Clements <glynn@gclements.plus.com>