[GRASS-dev] i.fusion.hpf addon: observing strong range change

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612

Is that intentional?

thanks,
Markus

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Moritz

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 27/10/19 18:52, Markus Neteler wrote:
> Hi,
>
> I am using i.fusion.hpf on Worldview-2 data and see that the resulting
> range is completely different:
>
> # orig
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
> min=0
> max=1509
>
> # HPF
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
> min=-1045.79783524995
> max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
sep=comma) -c --o

# band 8
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn't seem to have any effect here.

Markus

On 28/10/19 12:33, Markus Neteler wrote:

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
sep=comma) -c --o

# band 8
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn't seem to have any effect here.

Sorry, wrong flag, should have been -l ("Linearly match histogram of Pan-sharpened output to Multi-Spectral input")

And if you rescale the output manually to the input value range, do you still see a good fusion result ? If yes, then this could be added as a last step to the module.

Moritz

* Markus Neteler <neteler@osgeo.org> [2019-10-28 12:33:44 +0100]:

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 27/10/19 18:52, Markus Neteler wrote:
> Hi,
>
> I am using i.fusion.hpf on Worldview-2 data and see that the resulting
> range is completely different:
>
> # orig
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
> min=0
> max=1509
>
> # HPF
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
> min=-1045.79783524995
> max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
sep=comma) -c --o

# band 8
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn't seem to have any effect here.

Mean values (and StdDev) don't change too much though. As I am looking
over the algorithm again, these days, I'll try to answer this in the
best possible way.

Cheers, Nikos

* Nikos Alexandris <nik@nikosalexandris.net> [2019-10-28 17:14:54 +0100]:

* Markus Neteler <neteler@osgeo.org> [2019-10-28 12:33:44 +0100]:

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
sep=comma) -c --o

# band 8
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn't seem to have any effect here.

Mean values (and StdDev) don't change too much though. As I am looking
over the algorithm again, these days, I'll try to answer this in the
best possible way.

Cheers, Nikos

Also, try the histograms too. Shapes are rather preserved. Scales are
not.

Here some images:
https://send.firefox.com/download/87f58d62ece20cb4/#6YJsCoKi7yW5wUiMbcs1LQ
(link expires after 5 downloads or 7 days).

Nikos

--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3

On Mon, Oct 28, 2019 at 4:44 PM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 28/10/19 12:33, Markus Neteler wrote:
> On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
> <mlennert@club.worldonline.be> wrote:
>> On 27/10/19 18:52, Markus Neteler wrote:
>>> Hi,
>>>
>>> I am using i.fusion.hpf on Worldview-2 data and see that the resulting
>>> range is completely different:
>>>
>>> # orig
>>> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
>>> min=0
>>> max=1509
>>>
>>> # HPF
>>> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
>>> min=-1045.79783524995
>>> max=3416.06793724612
>>
>> Just guessing here, but did you try the -c flag ?
>
> Now yes:
>
> i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
> sep=comma) -c --o
>
> # band 8
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
> min=0
> max=1605
>
> r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
> min=-1163.98434592277
> max=3879.99538075697
>
> So, -c doesn't seem to have any effect here.
>

Sorry, wrong flag, should have been -l ("Linearly match histogram of
Pan-sharpened output to Multi-Spectral input")

This comes with -l:

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-932.700879728634
max=3456.94617091076

And if you rescale the output manually to the input value range, do you
still see a good fusion result ? If yes, then this could be added as a
last step to the module.

In lack of time I cannot test that right now.

Nikos has a subset of my data, maybe he's able to check with that.

Markus

Hi,

I had the same problem last time I used i.fusion.hpf for pansharpening a SPOT image (6m to 1.5m). Question is in my view if the resulting values mean anything (i.e., they can be used for estimation of spectral indices) or it is just for visual purposes? Sorry for my ignorance, but I haven’t found a clear-cut answer to this…

On the other hand, i.pansharpen does include a re-scaling step, but whatever bit depth is passed as input it will be re-scaled to 8-bit. If the input data is >8-bit, it is a bit of a loss of radiometric resolution (if the resulting values can be used for indices estimation)…

I’d appreciate your insights

Cheers,
Vero

El lun., 28 oct. 2019 a las 17:40, Markus Neteler (<neteler@osgeo.org>) escribió:

On Mon, Oct 28, 2019 at 4:44 PM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 28/10/19 12:33, Markus Neteler wrote:

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

orig

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

HPF

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612

Just guessing here, but did you try the -c flag ?

Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern=“$COLORPREFIX.?”
sep=comma) -c --o

band 8

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn’t seem to have any effect here.

Sorry, wrong flag, should have been -l (“Linearly match histogram of
Pan-sharpened output to Multi-Spectral input”)

This comes with -l:

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-932.700879728634
max=3456.94617091076

And if you rescale the output manually to the input value range, do you
still see a good fusion result ? If yes, then this could be added as a
last step to the module.

In lack of time I cannot test that right now.

Nikos has a subset of my data, maybe he’s able to check with that.

Markus


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

On 29/10/19 19:11, Veronica Andreo wrote:

On the other hand, i.pansharpen does include a re-scaling step, but whatever bit depth is passed as input it will be re-scaled to 8-bit. If the input data is >8-bit, it is a bit of a loss of radiometric resolution (if the resulting values can be used for indices estimation)...

IIRC, this rescaling is due to the histogram matching step. This should probably be rewritten to allow arbitrary radiometric resolution.

Moritz

Hi,

Back to this issue, some news:

On Sun, Oct 27, 2019 at 6:52 PM Markus Neteler <neteler@osgeo.org> wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

Since we currently use i.fusion.hpf in a project, Markus Metz has
fixed the range issues in i.fusion.hpf:

https://github.com/OSGeo/grass-addons/commit/4d940b86d0805c1889b31d50fed483751b0e1819

Works nicely now, range problem solved (output comparable to input).

Cheers,
markusN

--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog