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

2013-11-16 Thread Nikos Alexandris 
Michael Barton wrote:

> > I took a look at the i.pansharpen code. The method matchhist does the
> > histogram matching. It creates cumulative distribution functions (CDF) of
> > the source and target histograms and then finds the closest values to
> > match at each point on the CDF. It is pretty thoroughly documented in the
> > code. There are other methods of histogram matching, but IIRC, this was
> > the most basic and widespread. As some others have commented, it assumes
> > that images have 256 integer grey values. A more sophisticated histogram
> > matching algorithm could utilize floating point values and a wider range
> > of values. Hope this helps

Markus Neteler wrote:

> How does it compare to the one used in the Addon "i.hist.match"?
> (grass-addons/grass7/imagery/i.histo.match/i.histo.match.py)

My rough guess is that it is about the same logic. In the case of pansharpen 
there is one reference cdf. In the case of i.histo.match there are some 
assumptions I guess and some averaged values are used as a reference. See also 
Moritz' comment:

"   Replying to cmbarton:
If you have an image set that is more than 8bit, I can use it to test 
some  
things. i.histo.match is a nice module. But its objective is different 
from 
histogram matching in i.pan.sharpen. So it would need modification to 
be
used in this context. When I was writing i.pan.sharpen, I looked at the 

i.histo.match code but it was easier to use a much simpler algorithm. 
But   
since you know i.histo.match maybe you can see where the code could be  

modified to be used in i.pan.sharpen.

Your histogram matching code matches the histogram of a source image to that 
of a target image, whereas i.histo.match matches the histogram of each given 
image to the cumulative histogram of all images. Both approaches are valid, 
and both should be available in a histogram matching module.   "


> There I don't see a 8bit limitation (I may be wrong). This might solve
> ticket #2048.

Note, the IHS method for example depends on the respective modules which are 
8-bit based too if I am not wrong.

Nikos



___
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

2013-11-16 Thread Nikos Alexandris 
More details, using i.landsat.toar under `g.version -g`:

version=6.4.4svn
revision=58178


The uncorrected method delivers some "Temperatures" ??:

r.info -hr KR_B.Radiance.61

min=7.64787401574803
max=9.12377952755905
Data Source:
   
Data Description:
   generated by i.landsat.toar
Comments:
Radiance of Landsat-7 ETM+ (method uncorrected)
   -
Acquisition date (and time) ... 2002-07-14 (3.1864 h)
Production date ... 2013-10-17
   
Earth-sun distance (d)  1.0165044
Sun elevation (and azimuth) ... 53.54784 (53.92998)
Digital number (DN) range . 1 to 255
Calibration constants (Lmin to Lmax) .. +0.0 to +17.04000
DN to Radiance (gain and bias)  +0.06709 and -0.06709
Temperature (K1 and K2) ... 0.000 and 0.000
   --


but the DOS1 method does not:

r.info -hr KR_B.ToAR.DOS1.61

min=-nan
max=-nan
Data Source:
   
Data Description:
   generated by i.landsat.toar
Comments:
Temperature of Landsat-7 ETM+ (method dos1)
   -
Acquisition date (and time) ... 2002-07-14 (3.1864 h)
Production date ... 2013-10-17
   
Earth-sun distance (d)  1.0165044
Sun elevation (and azimuth) ... 53.54784 (53.92998)
Digital number (DN) range . 1 to 255
Calibration constants (Lmin to Lmax) .. +0.0 to +17.04000
DN to Radiance (gain and bias)  +0.06709 and -0.06709
Temperature (K1 and K2) ... 0.000 and 0.000
   --

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

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

2013-11-16 Thread GRASS GIS 
#2048: i.pansharpen limited to 8-bit imagery
---+
 Reporter:  nikosa |   
Owner:  grass-dev@…  
 Type:  defect |  
Status:  new  
 Priority:  normal |   
Milestone:  7.0.0
Component:  Imagery| 
Version:  svn-trunk
 Keywords:  i.pansharpen, sharpening, fusion, brovey, ihs, pca, 8-bit  |
Platform:  Unspecified  
  Cpu:  All|  
---+

Comment(by nikosa):

 Without the intention to add "noise", besides the many publications out
 there who perform segmentation and image classification on pan-sharpened
 11(16)-bit data (need for fine radiometry), there are also consumer- &
 professional-grade displays that are capable of 11-bit. They are costly.
 Nevertheless, if the main concern is work and eye-health when spending
 countless hours in front of a display, one might consider getting one if
 possible.

 GRASS will become more attractive with such enhancements.

 Thanks, N

-- 
Ticket URL: 
GRASS GIS 

___
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

2013-11-16 Thread Nikos Alexandris 
Dear Jorge,

I understand that your free time is very limited. Anyhow, just wanted to ping 
you about this.

Many thanks, Nikos


On Friday 15 of November 2013 18:37:38 Nikos Alexandris wrote:
> 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] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

2013-11-16 Thread Markus Neteler 
On Sat, Nov 16, 2013 at 9:27 PM, Michael Barton  wrote:
> I took a look at the i.pansharpen code. The method matchhist does the 
> histogram matching. It creates cumulative distribution functions (CDF) of the 
> source and target histograms and then finds the closest values to match at 
> each point on the CDF. It is pretty thoroughly documented in the code. There 
> are other methods of histogram matching, but IIRC, this was the most basic 
> and widespread. As some others have commented, it assumes that images have 
> 256 integer grey values. A more sophisticated histogram matching algorithm 
> could utilize floating point values and a wider range of values. Hope this 
> helps

How does it compare to the one used in the Addon "i.hist.match"?
(grass-addons/grass7/imagery/i.histo.match/i.histo.match.py)

There I don't see a 8bit limitation (I may be wrong). This might solve
ticket #2048.

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)

2013-11-16 Thread Michael Barton 
I took a look at the i.pansharpen code. The method matchhist does the histogram 
matching. It creates cumulative distribution functions (CDF) of the source and 
target histograms and then finds the closest values to match at each point on 
the CDF. It is pretty thoroughly documented in the code. There are other 
methods of histogram matching, but IIRC, this was the most basic and 
widespread. As some others have commented, it assumes that images have 256 
integer grey values. A more sophisticated histogram matching algorithm could 
utilize floating point values and a wider range of values. Hope this helps

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

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












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] r58200 (attempt to fix failure when user name contains non-ascii characters)

2013-11-16 Thread Martin Landa 
Hi,

2013/11/15 Vaclav Petras :
> 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.

I can confirm it, strangely when I was producing the patch I was
forced to do also changes in grass.py which were later reverted. So
the change in `core.py` seems to be enough to fix this bug (non-ascii
characters in user name). Please could anyone else confirm it?

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