Re: [GRASS-dev] r58200 (attempt to fix failure when user name contains non-ascii characters)
Hi, 2013/11/15 Vaclav Petras wenzesl...@gmail.com: 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
Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)
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 mlenn...@club.worldonline.be 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)
On Sat, Nov 16, 2013 at 9:27 PM, Michael Barton michael.bar...@asu.edu 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] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery
#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: http://trac.osgeo.org/grass/ticket/2048#comment:18 GRASS GIS http://grass.osgeo.org ___ 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
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] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)
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
