[GRASS-dev] 6.4.4 planning

[Hamish]

on the grass-user ML Markus N wrote:
> (and it is time to get 6.4.4 out...)


fwiw,

I've gone through the two branches with kdiff3 and selectively backported
many of the differences between the branches. There are a number of
experiments and minor cosmetic changes which I didn't backport. One big
remaining hope I had for 6.4.4 was to backport the parallelization work
in the imagery scripts, e.g. i.landsat.rgb. I think they are pretty good
but I haven't tried them on WinGrass to learn how well MSys deals with
backgrounding jobs with "&". I had planned to merge scripts/ first, to
give them the maximum amount of testing in the stable branch, but it turned
out to be too big a job for the small windows of time I could give to it. But 
now I am mostly waiting on testing them in 6.5 nightly WinGrass.


"Important bugs concerning the next release"
  https://trac.osgeo.org/grass/report/13

The other two important tasks for 6.4.4 in my mind are to get python addon
scripts working with 6.4's g.extension.py, both for Linux and WinGrass (#1768,
just committed an experimental change to 6.5svn a few days ago; e.g. for
r.threshold), and secondly to get the Cairo driver working on WinGrass (#943).

The Cairo driver seems to need some G_spawn() pipe handling/closing in d.mon,
using SF_BACKGROUND and other popen flags which I just stumble around in the
dark with & need some assistance.


It's our busy field season right now and I'm just about to head back
out to sea, so I won't be here to work on things for the next few weeks
(... and then the holidays come).


Are there critical bugs fixed in 6.4.4svn since 6.4.3 that demand we ship
a fix for ASAP? If not, I'd like to put some energy into the above issues
first. If there is some critical need to release now, I don't mind putting
these other things off for a 6.4.5, but especially the 'running custom
python scripts' in 6.4 WinGrass seems like an important thing to have
working out of the box for end users.


thanks,
Hamish

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

[GRASS-dev] Failure to build on Itanium + Debian/sid

[Hamish]

Hi, coming back to and renaming this thread,

Moritz wrote:
> > Hamish, do you know what is going on for grass 6.4.3 ? I see that it hasn't
> > migrated to testing, yet, because of failure to build on ia64:
> >
> > http://release.debian.org/migration/testing.pl?package=grass

> On Friday, November 1, 2013 Markus Neteler replied:
...
> https://buildd.debian.org/status/fetch.php?pkg=grass&arch=ia64&ver=6.4.3-2&stamp=1380196645
> shows
...
> /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/driver.o: @gprel relocation
> against dynamic symbol db_driver_init
> /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/driver.o: @gprel relocation
> against dynamic symbol db_driver_finish
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[5]: ***
> [/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_dbmidriver.6.4.3.so]
> Error 1
> ...
>
> In an old thread here there is a suggestion:
> http://software.intel.com/en-us/forums/topic/267748
> "On Itanium-based systems running Linux, when the -shared switch is
> used to create a Dynamic Shared Object (.so), there may be some
> relocation against dynamic symbol" messages generated during the ld
> phase
> ...
>
> To fix this problem, add the switches -i_dynamic and -nofor_main to
> the command line.
> "
>
> see also
> http://www.opendx.org/cgi-bin/forum/YaBB.pl?num=1139610671/1
>
> A Debian geek may know...


Hi,

fyi Paul Gevers from Debian figured out the "where" of this problem,
and the fix, but the "why" is still a bit unknown.

see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728150#25

It's a conflict beween -fPIC and -fPIE. The same conflict was happening
for the previous Debian release so I had the work-around code in the
package build rules, left as commented out for anyone wanting to build
backported packages. Apparently the same work-around allows it to build
on Itanium.

I guess the short-term fix is to do some 
 if [ `uname -m` = "ia64" ] ; then
    ...

in the debian/rules? (which is essentialy a Makefile not a shell script)



Hamish

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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Michael Barton]

I agree that it would be best to have all pan sharpening algorithms together if 
possible. New ones should be addable as new classes or methods in the existing 
module. Note that I did employ parallel processing to the extent possible. It 
might be possible to apply this kind of processing to other sharpening 
algorithms.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Nov 15, 2013, at 8:20 AM, Nikos Alexandris 
mailto:n...@nikosalexandris.net>> wrote:

Moritz Lennert wrote:
..
> I just did a quick test:



> pan in:
> mean: 31.813
> standard deviation: 3.75447
>
> ms in:
> mean: 15.2307
> standard deviation: 3.55858
>
> pan out:
> mean: 15.6117
> standard deviation: 3.23408



> So for this example, mean seems to have been adjusted, but stddev not.



Thanks. Looks not to be the exact same here too.



> > > > ? Would it be desired to get the HPFA algorithm integrated in
> > > > i.pansharpen?



> > > Yes. I think that if we have a generic module such as i.pansharpen, it
> > > would be preferable to have all pansharpening methods in that one
> > > module.



> > There is one "difference" in that HPFA treats all bands to be sharpened
> > separately. And, in this manner, it can be (mis-)used to sharpen any
> > low-res band. For example, WorldView-2 products have 8 multi-spectral
> > bands. Hence the "not red= green= blue=" design so far from my side.



> i.pansharpen does not imply rgb either (although the description of the
> ms* parameters does suggest that. You can obviously use any ms bands you
> want.



Yes, I know. I just wanted to avoid this r= g= b= logic. Maybe I am wrong and 
perhaps it is better, indeed, to follow the common path.



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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Michael Barton]

I haven't had time today to look into this. I used a fairly standard histogram 
matching algorithm, for which I cited the reference. But I don't remember 
exactly how it went. Matching the SD was not part of it however. 

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Nov 15, 2013, at 3:20 AM, Moritz Lennert  
wrote:

> On 15/11/13 10:50, Nikos Alexandris wrote:
>> Nikos Alexandris wrote:
>> 
>> > > together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of
>> 
>> > > concept. At the moment, we have a custom shell script named
>> 
>> > > `i.fusion.hpf` (an attempt for a proper GRASS add-on), which implements
>> 
>> > > the High Pass Filter Additive (HPFA) Fusion Technique for
>> Pan-Sharpening
>> 
>> > > [*]. Nikos V started already porting to Python. How can we proceed in
>> 
>> > > sharing it?
>> 
>> >
>> 
>> > [...]
>> 
>> >
>> 
>> > > Two questions
>> 
>> > >
>> 
>> > > ? Can someone confirm that the part of the existing "i.pansharpen" code
>> 
>> > > that performs histogram matching (code lines 348 - 431), do so as
>> 
>> > > "linearly stretching an image to match another image's Mean and
>> StdDev"?
>> 
>> Moritz Lennert:
>> 
>> > AFAICT, it applies the method described in [1].
>> 
>> Is that a reference also indicated in i.pansharpen's manual?
> 
> It's not in the manual, but there's a long list of other references. But 
> Michael is the one who knows where the inspiration came from. AFAIK, this is 
> the classical, generic method of histogram matching.
> 
>> 
>> > I don't know (and don't have the time to think about) what this
>> method does
>> 
>> > in terms of mean and stddev.
>> 
>> My guess was/is that it is not the same, i.e. it does not match Mean and
>> StdDev. As a quick test, I tried the identical (me thinks) tool in
>> WhiteboxGIS "Histogram Matching (Two Images)", does not give identical
>> Means and StdDevs after the operation -- which is the case with
>> i.pansharpen too if I am not wrong.
>> 
> 
> I just did a quick test:
> 
> pan in:
> 
> mean: 31.813
> standard deviation: 3.75447
> 
> ms in:
> 
> mean: 15.2307
> standard deviation: 3.55858
> 
> pan out:
> 
> mean: 15.6117
> standard deviation: 3.23408
> 
> So for this example, mean seems to have been adjusted, but stddev not.
> 
>> > > ? Would it be desired to get the HPFA algorithm integrated in
>> 
>> > > i.pansharpen?
>> 
>> >
>> 
>> > Yes. I think that if we have a generic module such as i.pansharpen, it
>> 
>> > would be preferable to have all pansharpening methods in that one module.
>> 
>> There is one "difference" in that HPFA treats all bands to be sharpened
>> separately. And, in this manner, it can be (mis-)used to sharpen any
>> low-res band. For example, WorldView-2 products have 8 multi-spectral
>> bands. Hence the "not red= green= blue=" design so far from my side.
> 
> i.pansharpen does not imply rgb either (although the description of the ms* 
> parameters does suggest that. You can obviously use any ms bands you want.
> 
> Moritz

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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Markus Neteler]

On Fri, Nov 15, 2013 at 10:05 AM, Moritz Lennert
 wrote:
> On 14/11/13 02:25, Nikos Alexandris wrote:
>>
>> Dear GRASS GIS users,
>>
>> together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of
>> concept. At the moment, we have a custom shell script named
>> `i.fusion.hpf` (an attempt for a proper GRASS add-on), which implements
>> the High Pass Filter Additive (HPFA) Fusion Technique for Pan-Sharpening
>> [*]. Nikos V started already porting to Python.

Great!

>> ? Would it be desired to get the HPFA algorithm integrated in
>> i.pansharpen?
>
> Yes. I think that if we have a generic module such as i.pansharpen, it would
> be preferable to have all pansharpening methods in that one module.

+1
please integrate the method there...

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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Nikos Alexandris]

Nikos Alexandris wrote:

> BTW, it works really great with QuickBird imagery.

For the matter,

- the Pan: 


- the MS RGB: 


- the default HPFA Sharpening: 


And, finally, slightly tweaked (other parameters offered by the 
algorithm/script): 


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

Re: [GRASS-dev] [GRASS GIS] #2015: Missing file association dialog pops up all the time

[GRASS GIS]

#2015: Missing file association dialog pops up all the time
+---
 Reporter:  wenzeslaus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Python  | Version:  svn-trunk
 Keywords:  wingrass|Platform:  MSWindows 7  
  Cpu:  All |  
+---

Comment(by wenzeslaus):

 I can again confirm this issue with r58198. I got "Select application to
 open .py file" dialog on Win 8 on different machine then those before. I
 got it only once during the start. Other possibilities not tested. It does
 not happen on other user accounts on the same machine.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r58200 (attempt to fix failure when user name contains non-ascii characters)

[Vaclav Petras]

On Fri, Nov 15, 2013 at 10:50 AM, Vaclav Petras wrote:

>
>
>
> On Fri, Nov 15, 2013 at 10:21 AM, Glynn Clements  > wrote:
>
>>
>> Glynn Clements wrote:
>>
>> > > > What problem is it trying to fix?
>> > >
>> > > it fixes issue on Windows when user name contains non-ascii charecters
>> > > (which is quite common on this platform).
>> > >
>> > > > And how does it do that (if it does actually work)?
>> > >
>> > > I have created on my Windows machine such user and this patch was
>> > > necessary otherwise GRASS start script simply fails.
>> >
>> > How/why does it fail? And how does this change fix that?
>>
>> In the absence of any useful information, r58200 has been reverted for
>> lib/init/grass.py (the change to lib/python/script/core.py remains).
>>
>> I cannot test this because I'm not able to create user with non-ascii
> chars at my ms win machine, either because of domain issues or locale or
> both.
>
> Finally, I was able to create a user with non-ascii chars. I tried r58198
(before Martin's change) and GRASS runs, opens location, saves last open
location to user settings and loads them afterwards. So, r58200 is not
needed for that machine.

However, I was not able to create a location in my home directory. I cannot
test the other directories.

The test was done in US locale, I don't know how this would behave in some
non-ascii locale. I would guess that this can make difference. I've noticed
that in the command line, the user name was converted to ascii.

Other problem was that I got a "Select application to open .py file" dialog
once (this was reported in #2015). The nice thing about it is that it does
not happen on other user accounts on the same machine.

https://trac.osgeo.org/grass/changeset/58200
https://trac.osgeo.org/grass/changeset/58224
https://trac.osgeo.org/grass/ticket/2015


>  --
>> Glynn Clements 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] i.landsat.toar fails to convert DNs (bands 61 and 62) to temperature for Landsat 7 scene

[Nikos Alexandris]

This seems to not work again :-(.  This time using the MTL file (for the 
corresponding 
scene): LE71260592002195SGS00_MTL.txt. No "MTLold" available in the downloaded 
scene.

Nikos



On Thursday 14 of February 2013 15:33:17 Nikos Alexandris wrote:
> Nikos Alexandris wrote:
> > While  i.landsat.toar  works just fine with all bands in converting DNs to
> > Radiance/Reflectance (with some method=dos?), it seems, at least in once
> > case (scene LE71840312002041SGS00), it fails to convert bands 61 and 62 in
> > temperature!
> > 
> > Same happens (as described below in both G64 and G70).
> > Can anyone confirm or reject?
> 
> [deleted stuff]
> 
> Using the old metadata file (in this case: LE71840312002041SGS00_MTLold.txt)
> works fine.
> 
> GRASS 6.4.3svn (wgs84_utm_z34_test):~ > r.info -r B.DOS1.ToCR.61
> min=158.263805493393
> max=338.623091571347
> 
> GRASS 6.4.3svn (wgs84_utm_z34_test):~ > r.info -r B.DOS1.ToCR.62
> min=240.06999848884
> max=322.080084447704
> 
> 
> I guess it is a bug (something that got away in latest updates of
> i.landsat.toar towards the newer metadata file).  Will try to check
> further... not today though, deadlines approaching.
> 
> Best, Nikos
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-dev] r58200 (attempt to fix failure when user name contains non-ascii characters)

[Vaclav Petras]

On Fri, Nov 15, 2013 at 10:21 AM, Glynn Clements
wrote:

>
> Glynn Clements wrote:
>
> > > > What problem is it trying to fix?
> > >
> > > it fixes issue on Windows when user name contains non-ascii charecters
> > > (which is quite common on this platform).
> > >
> > > > And how does it do that (if it does actually work)?
> > >
> > > I have created on my Windows machine such user and this patch was
> > > necessary otherwise GRASS start script simply fails.
> >
> > How/why does it fail? And how does this change fix that?
>
> In the absence of any useful information, r58200 has been reverted for
> lib/init/grass.py (the change to lib/python/script/core.py remains).
>
> I cannot test this because I'm not able to create user with non-ascii
chars at my ms win machine, either because of domain issues or locale or
both.

--
> Glynn Clements 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r58200 (attempt to fix failure when user name contains non-ascii characters)

[Glynn Clements]

Glynn Clements wrote:

> > > What problem is it trying to fix?
> > 
> > it fixes issue on Windows when user name contains non-ascii charecters
> > (which is quite common on this platform).
> > 
> > > And how does it do that (if it does actually work)?
> > 
> > I have created on my Windows machine such user and this patch was
> > necessary otherwise GRASS start script simply fails.
> 
> How/why does it fail? And how does this change fix that?

In the absence of any useful information, r58200 has been reverted for
lib/init/grass.py (the change to lib/python/script/core.py remains).

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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Nikos Alexandris]

Moritz Lennert wrote:
..
> I just did a quick test:

> pan in:
> mean: 31.813
> standard deviation: 3.75447
> 
> ms in:
> mean: 15.2307
> standard deviation: 3.55858
> 
> pan out:
> mean: 15.6117
> standard deviation: 3.23408

> So for this example, mean seems to have been adjusted, but stddev not.

Thanks. Looks not to be the exact same here too.

> >  > > ? Would it be desired to get the HPFA algorithm integrated in
> >  > > i.pansharpen?

> >  > Yes. I think that if we have a generic module such as i.pansharpen, it
> >  > would be preferable to have all pansharpening methods in that one
> >  > module.

> > There is one "difference" in that HPFA treats all bands to be sharpened
> > separately. And, in this manner, it can be (mis-)used to sharpen any
> > low-res band. For example, WorldView-2 products have 8 multi-spectral
> > bands. Hence the "not red= green= blue=" design so far from my side.

> i.pansharpen does not imply rgb either (although the description of the
> ms* parameters does suggest that. You can obviously use any ms bands you
> want.

Yes, I know. I just wanted to avoid this r= g= b= logic. Maybe I am wrong and 
perhaps it 
is better, indeed, to follow the common path.

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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Moritz Lennert]

On 15/11/13 10:50, Nikos Alexandris wrote:

Nikos Alexandris wrote:

 > > together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of

 > > concept. At the moment, we have a custom shell script named

 > > `i.fusion.hpf` (an attempt for a proper GRASS add-on), which implements

 > > the High Pass Filter Additive (HPFA) Fusion Technique for
Pan-Sharpening

 > > [*]. Nikos V started already porting to Python. How can we proceed in

 > > sharing it?

 >

 > [...]

 >

 > > Two questions

 > >

 > > ? Can someone confirm that the part of the existing "i.pansharpen" code

 > > that performs histogram matching (code lines 348 - 431), do so as

 > > "linearly stretching an image to match another image's Mean and
StdDev"?

Moritz Lennert:

 > AFAICT, it applies the method described in [1].

Is that a reference also indicated in i.pansharpen's manual?


It's not in the manual, but there's a long list of other references. But 
Michael is the one who knows where the inspiration came from. AFAIK, 
this is the classical, generic method of histogram matching.




 > I don't know (and don't have the time to think about) what this
method does

 > in terms of mean and stddev.

My guess was/is that it is not the same, i.e. it does not match Mean and
StdDev. As a quick test, I tried the identical (me thinks) tool in
WhiteboxGIS "Histogram Matching (Two Images)", does not give identical
Means and StdDevs after the operation -- which is the case with
i.pansharpen too if I am not wrong.



I just did a quick test:

pan in:

mean: 31.813
standard deviation: 3.75447

ms in:

mean: 15.2307
standard deviation: 3.55858

pan out:

mean: 15.6117
standard deviation: 3.23408

So for this example, mean seems to have been adjusted, but stddev not.


 > > ? Would it be desired to get the HPFA algorithm integrated in

 > > i.pansharpen?

 >

 > Yes. I think that if we have a generic module such as i.pansharpen, it

 > would be preferable to have all pansharpening methods in that one module.

There is one "difference" in that HPFA treats all bands to be sharpened
separately. And, in this manner, it can be (mis-)used to sharpen any
low-res band. For example, WorldView-2 products have 8 multi-spectral
bands. Hence the "not red= green= blue=" design so far from my side.


i.pansharpen does not imply rgb either (although the description of the 
ms* parameters does suggest that. You can obviously use any ms bands you 
want.


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

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Nikos Alexandris]

Nikos Alexandris wrote:

> > together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of
> > concept. At the moment, we have a custom shell script named
> > `i.fusion.hpf` (an attempt for a proper GRASS add-on), which implements
> > the High Pass Filter Additive (HPFA) Fusion Technique for Pan-Sharpening
> > [*]. Nikos V started already porting to Python. How can we proceed in
> > sharing it?
> 
> [...]
> 
> > Two questions
> > 
> > ? Can someone confirm that the part of the existing "i.pansharpen" code
> > that performs histogram matching (code lines 348 - 431), do so as
> > "linearly stretching an image to match another image's Mean and StdDev"?

Moritz Lennert:

> AFAICT, it applies the method described in [1].

Is that a reference also indicated in i.pansharpen's manual?

> I don't know (and don't have the time to think about) what this method does
> in terms of mean and stddev.

My guess was/is that it is not the same, i.e. it does not match Mean and 
StdDev. As a quick 
test, I tried the identical (me thinks) tool in WhiteboxGIS "Histogram Matching 
(Two Images)", 
does not give identical Means and StdDevs after the operation -- which is the 
case with 
i.pansharpen too if I am not wrong.

> > ? Would it be desired to get the HPFA algorithm integrated in
> > i.pansharpen?
> 
> Yes. I think that if we have a generic module such as i.pansharpen, it
> would be preferable to have all pansharpening methods in that one module.

There is one "difference" in that HPFA treats all bands to be sharpened 
separately. And, in 
this manner, it can be (mis-)used to sharpen any low-res band. For example, 
WorldView-2 
products have 8 multi-spectral bands. Hence the "not red= green= blue=" design 
so far from 
my side.

@Michael, is this of interest for you?

Thank you Moritz, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Moritz Lennert]

On 14/11/13 02:25, Nikos Alexandris wrote:

Dear GRASS GIS users,

together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of
concept. At the moment, we have a custom shell script named
`i.fusion.hpf` (an attempt for a proper GRASS add-on), which implements
the High Pass Filter Additive (HPFA) Fusion Technique for Pan-Sharpening
[*]. Nikos V started already porting to Python. How can we proceed in
sharing it?



[...]


Two questions

? Can someone confirm that the part of the existing "i.pansharpen" code
that performs histogram matching (code lines 348 - 431), do so as
"linearly stretching an image to match another image's Mean and StdDev"?


AFAICT, it applies the method described in [1]. I don't know (and don't 
have the time to think about) what this method does in terms of mean and 
stddev.





? Would it be desired to get the HPFA algorithm integrated in i.pansharpen?


Yes. I think that if we have a generic module such as i.pansharpen, it 
would be preferable to have all pansharpening methods in that one module.


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

Re: [GRASS-dev] [GRASS GIS] #789: g.region option to expand the computational region of about "some" pixels?

[GRASS GIS]

#789: g.region option to expand the computational region of about "some" pixels?
---+
 Reporter:  nikos  |   Owner:  grass-dev@…  

 Type:  enhancement|  Status:  new  

 Priority:  normal |   Milestone:  7.0.0

Component:  Default| Version:  unspecified  

 Keywords:  g.region, expand computational region  |Platform:  Unspecified  

  Cpu:  Unspecified|  
---+

Comment(by nikosa):

 Replying to [comment:11 hamish]:
 > your initial idea of "g.region -a vect= res=" solves it. Set the
 resolution to 1000 there (or whatever) and the -a flag will ''always''
 grow outwards in all 4 directions. So you run the above, then run g.region
 a second time with your finer resolution. If your second finer-resolution
 fits evenly in the initial coarser one, you now have a grown region with
 bounds rounded to nice whole numbers, a bit bigger than your points map so
 catching them all!

 Maybe it does so. And, maybe I have placed, in the example above, the


 {{{
 # assume that the raster was just about the same size of what the
 (grass-)region is:
 r.mapcalc landcover_cropped = landcover.30m
 }}}


 in the "wrong" place. This was part of my "pareto" implementation using
 MODIS data (low-res, to be assessed) and Landsat (higher-res, as a
 reference). I have to go through this again. If I remember well, I was
 forced to have "this" very step in-between of the grid creation/centroid
 extraction operations.

-- 
Ticket URL: 
GRASS GIS 

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