[GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

GRASS GIS GRASS GIS developer
1

Dear all,

I want to integrate the "AHPF" fusion algorithm, <i.fusion.hpf> [0], into <i.pansharpen> [1]. And I need some assistance.

1. <i.pansharpen> has the following, simple, interface:

i.pansharpen [-sl] red=name green=name blue=name pan=name
    output=basename method=value [--overwrite] [--help] [--verbose]
    [--quiet] [--ui]

plus

Flags:
   -s Serial processing rather than parallel processing
   -l Rebalance blue channel for LANDSAT

while the HPF implementation looks like:

i.fusion.hpf [-l2c] pan=filename msx=filename(s)[,filename(s),...]
    outputsuffix=suffix string [ratio=rational number] [center=string]
    [center2=string] [modulation=string] [modulation2=string]
    [trim=rational number] [--overwrite] [--help] [--verbose] [--quiet]
    [--ui]

plus

Flags:
   -l Linearly match histogram of Pan-sharpened output to Multi-Spectral input
   -2 2-Pass Processing (recommended) for large resolution ratio (>=5.5)
   -c Match color table of Pan-Sharpened output to Multi-Spectral input

While the first module appears to be simple and straightforward, it has its limitations (rgb required, underlying ihs method restricted to 8-bit data). The second module appears complex, but it works right away by simply feeding a pan and a multi-spectral band (or bands) and, offers many fine-tuning options.

2. <i.pansharpen> has the R-G-B logic hardcoded (one pan and three multi-spectral bands required), while <i.fusion.hpf> will work simply with a pan and only one or any number of multiple low-resolution bands.

If all of the fine-tuning options for HPF will be merged into i.pansharpen, it'll get "heavy" and complex. I am asking for help to design the integration (not for the actual coding). Any ideas?

Thank you, Nikos

--
[0] <https://github.com/NikosAlexandris/i.fusion.hpf&gt;
[1] <http://grass.osgeo.org/grass70/manuals/i.pansharpen.html&gt;

2

Would it make sense to let it be separate?

On Dec 20, 2014 11:52 PM, “Nikos Alexandris” <nik@nikosalexandris.net> wrote:

Dear all,

I want to integrate the “AHPF” fusion algorithm, <i.fusion.hpf> [0], into <i.pansharpen> [1]. And I need some assistance.

  1. <i.pansharpen> has the following, simple, interface:

i.pansharpen [-sl] red=name green=name blue=name pan=name
output=basename method=value [–overwrite] [–help] [–verbose]
[–quiet] [–ui]

plus

Flags:
-s Serial processing rather than parallel processing
-l Rebalance blue channel for LANDSAT

while the HPF implementation looks like:

i.fusion.hpf [-l2c] pan=filename msx=filename(s)[,filename(s),…]
outputsuffix=suffix string [ratio=rational number] [center=string]
[center2=string] [modulation=string] [modulation2=string]
[trim=rational number] [–overwrite] [–help] [–verbose] [–quiet]
[–ui]

plus

Flags:
-l Linearly match histogram of Pan-sharpened output to Multi-Spectral input
-2 2-Pass Processing (recommended) for large resolution ratio (>=5.5)
-c Match color table of Pan-Sharpened output to Multi-Spectral input

While the first module appears to be simple and straightforward, it has its limitations (rgb required, underlying ihs method restricted to 8-bit data). The second module appears complex, but it works right away by simply feeding a pan and a multi-spectral band (or bands) and, offers many fine-tuning options.

  1. <i.pansharpen> has the R-G-B logic hardcoded (one pan and three multi-spectral bands required), while <i.fusion.hpf> will work simply with a pan and only one or any number of multiple low-resolution bands.

If all of the fine-tuning options for HPF will be merged into i.pansharpen, it’ll get “heavy” and complex. I am asking for help to design the integration (not for the actual coding). Any ideas?

Thank you, Nikos

–
[0] <https://github.com/NikosAlexandris/i.fusion.hpf>
[1] <http://grass.osgeo.org/grass70/manuals/i.pansharpen.html>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

On 20.12.2014 20:43, Yann Chemin wrote:

Would it make sense to let it be separate?

For me that is the easiest. But it would be nice to gather algorithms of a kin to one place, make grass more attractive, compact and integrated.

Thank you Yann. Please, other voices?

Thank you all, Nikos

[..]

4

NikosAlexandris wrote

On 20.12.2014 20:43, Yann Chemin wrote:

Would it make sense to let it be separate?

For me that is the easiest. But it would be nice to gather algorithms
of a kin to one place, make grass more attractive, compact and
integrated.

Thank you Yann. Please, other voices?

Thank you all, Nikos

guisections for each algorithm?

"A "guisection" field may be added to each option and flag to specify that
the options should appear in multiple tabs in the auto-generated GUI."[1]

[1] http://grass.osgeo.org/grass70/manuals/g.parser.html

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/On-integrating-i-fusion-hpf-into-i-pansharpen-tp5178698p5178722.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

5

On Sun, Dec 21, 2014 at 11:09 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

On 20.12.2014 20:43, Yann Chemin wrote:

Would it make sense to let it be separate?

For me that is the easiest. But it would be nice to gather algorithms of a
kin to one place, make grass more attractive, compact and integrated.

Yes, and it produces great results:

http://courses.neteler.org/landsat-8-captures-trentino-november-2014/

Markus

6

Helmut Kudrnovsky wrote:

..

guisections for each algorithm?
"A "guisection" field may be added to each option and flag to specify that
the options should appear in multiple tabs in the auto-generated GUI."[1]
[1] http://grass.osgeo.org/grass70/manuals/g.parser.html

This will help for the GUI. But the command, wildly guessing, still will be something like:

i.pansharpen [-slh2c] pan=name red=name green=name blue=name msx=name[,name(s),...] output=suffix method=value [ratio=rational number] [center=string] [center2=string] [modulation=string] [modulation2=string]
    [trim=rational number] [--overwrite] [--help] [--verbose] [--quiet] [--ui]

where none of red, green, blue or msx will be required!? How would that look like?

Nikos