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

GDAL · July 29, 2013, 12:39pm

#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 |
-----------------------------------------------------------------------+----
Getting 11-bit IKONOS bands pan-sharpened by using i.pansharpen works only
if the bands are rescaled to 8-bit, i.e. to range inside [0, 255]. In this
case, color re-balancing (i.e. of Blue, Green and Red fusion-ed with Pan
-IKONOS spectral bands) after the sharpening appears acceptable.

Any other attempts using out of [0, 255] range values, for example using
Top-of-Atmosphere Reflectances (floating point values < 1.0) or the raw
IKONOS bands that range between [0, 2047], are not successful.

Rescaling, however, might lead to some loss of spectral information (?).
Hence, it may not be desired as pan-sharpening should not be limited in
creating nice looking (pseudo-)color composites for viewing tasks (i.e.
image interpretation) or printing. Sharpened/Fusioned images might as well
be used as an input for segmentation/classification etc.

Looking at the i.pansharpen source code ([http://lists.osgeo.org/pipermail
/grass-user/2013-July/068700.html as suggested by Moritz Lennert in the
grass-user mailing list]) ''I see that in all algorithms a function for
histogram matching is called and IIUC, in that function, values seem to be
limited to [0,255]''.

Related code(lines):
[http://trac.osgeo.org/grass/browser/grass/trunk/scripts/i.pansharpen/i.pansharpen.py#L348
def matchhist] and
[http://trac.osgeo.org/grass/browser/grass/trunk/scripts/i.pansharpen/i.pansharpen.py#L379
arrays[i] = np.zeros((256,),dtype=('i4,f4'))]

Not sure if this is a defect or an enhancement request. Many of the High
Resolution images are frequently delivered in >8-bit formats.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 5:48pm

#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 cmbarton):

The question is whether the histogram matching code can handle resolutions
of >8 bit.

And I guess I don't know. Have to make some modifications and see.

That said, the HIS pan sharpening only works with integers, because that
is a limit of i.rgb.his and i.his.rgb. I don't know if they can handle
integer ranges outside 0-255, however. You might give it a try to
transform one of your images with one of these and see what it converts it
to.

Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 6:03pm

#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 mlennert):

Replying to [comment:1 cmbarton]:
> The question is whether the histogram matching code can handle
resolutions of >8 bit.
>
> And I guess I don't know. Have to make some modifications and see.
>

In the long run, it would be interesting to integrate i.histo.match [1]
from addons into trunk. Then you could call that from i.pansharpen.
However, the code of i.histo.match could definitely use some optimisation
for performance.

[1] [https://trac.osgeo.org/grass/browser/grass-
addons/grass7/imagery/i.histo.match]

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 9:33pm

#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):

Replying to [comment:1 cmbarton]:
> The question is whether the histogram matching code can handle
resolutions of >8 bit.
> And I guess I don't know. Have to make some modifications and see.

Can we alter the manual somehow? To show how it can be done (now) with
>8-bit images? I have already posted some example at
[http://grasswiki.osgeo.org/wiki/IKONOS#Pan_Sharpening].

> That said, the HIS pan sharpening only works with integers, because that
is a limit of i.rgb.his and i.his.rgb. I don't know if they can handle
integer ranges outside 0-255, however. You might give it a try to
transform one of your images with one of these and see what it converts it
to.

I can/will try to check. First look in the manual of `i.rgb.his` does not
mention anything about bit-depth(s).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 10:16pm

#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 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.

Thanks
Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 11:17pm

#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):

Replying to [comment:4 cmbarton]:
> If you have an image set that is more than 8bit, I can use it to test
some things.

Unfortunately I cannot share the data I work with. However, there are
publicly available 11-bit IKONOS images:
[ftp://ftp.glcf.umd.edu/glcf/China_earthquake_May_2008/IKONOS/\]

> i.histo.match is a nice module. But its objective is different from
histogram matching in i.pan.sharpen.

Unfortunately i.histo.match has its own limitation(s): it understands only
integers - no floating points. See [http://lists.osgeo.org/pipermail
/grass-dev/2013-February/062161.html]. Though, not limited to 2^8^.

> 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.

Maybe... It certainly would be a nice quick-"fix" if i.pansharpen can be
released from being restricted to 2^8^? I mean, to expand in the "integer"
planet as a first step?

Will try to check further in the coming days/week. However, I'd like to
kindly ask again if it is possible to alter the documentation? It is not
a nice surprise trying to work with i.pansharpen and getting strange
colors or empty images as a result. See also
[http://gis.stackexchange.com/q/39174/5256\]. At least mention the current
limitation or... other ideas? Then again, it is in G7, the development
version

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 29, 2013, 11:32pm

#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 cmbarton):

Actually, looking at the code again, I'm pretty sure that it works as well
with floating point values and ranges beyond 256 as it does with 8bit
images--for the Brovey and PCA sharpening. The histogram matching routine
accepts floating points numbers. It runs them through r.stats to create a
0-255 histogram. So it converts them to 8bit before outputting them.

But I don't think this is what is causing your color problems. Some images
I ran through this in testing came out great and other did not, using the
same resolution of image (all 8 bit in my tests). I think that the issue
is preprocessing. IIRC, the best results come if you can estimate radiance
(i.e., dealing with atmospheric corrections and shadows due to topography)
at the surface and the worst come from uncorrected images.

You can do some color correction post facto using Markus' landsat color
correction script. But mostly you need to do a significant amount of
preprocessing to get the best results. It would be good if someone with
more image processing experience could weigh in and offer some insight.

The ideal script--or perhaps better the ideal workflow--would combine a
set of preprocessing steps with the pan sharpening. The latter is a set of
processing algorithms that is completely ignorant of color.

Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 30, 2013, 12:41am

#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):

Replying to [comment:6 cmbarton]:
> Actually, looking at the code again, I'm pretty sure that it works as
well with floating point values and ranges beyond 256 as it does with 8bit
images--for the Brovey and PCA sharpening. The histogram matching routine
accepts floating points numbers. It runs them through r.stats to create a
0-255 histogram. So it converts them to 8bit before outputting them.

OK, maybe this is the "crux" then?

> But I don't think this is what is causing your color problems. Some
images I ran through this in testing came out great and other did not,
using the same resolution of image (all 8 bit in my tests).

No problems when using 8-bit images here as well. The point is how to
pan-sharpen 11-bit images, or 16-bit, or else? Any such examples
available?

FWIW, I might not have described well the "request". Apologies --
honestly. In effect, it's not about color-balancing per se. It is about
getting meaningful output from i.pansharpen.

Michael,

I tested various combinations here: "?CELL" types & "sharpen" methods: raw
DNs 11-bit [0, 2047], DNs converted to 8-bit [0, 255], Radiances (random
example of a Blue band ranging in [0, 394.363700815314]), Reflectances in
[0, 1.0]. The ''only'' way to get a meaningful output is to rescale the
material to [0, 255]. In all other cases without exceptions, colors are
at best fancy, at worse "empty"; and I can't get them, no matter what I
try, re-balanced (tried grey, grey255, grey1.0, grey.eq, with or without
"-e", etc.) pre- and post- sharpening.

Among the various attempts, many of the outputs of i.pansharpen when _not_
using 8-bit as an input, range between 0 and 4 or 1!

> I think that the issue is preprocessing. IIRC, the best results come if
you can estimate radiance (i.e., dealing with atmospheric corrections and
shadows due to topography) at the surface and the worst come from
uncorrected images.

I disagree that this has to do with the degree of "fancyness" I am facing
:-). It might, and will, help to get more visually appealing
images/composites. "Precision" is, however, not the problem here.

> You can do some color correction post facto using Markus' landsat color
correction script.

Sure, it works for 8-bit inputs -- and very nice as I can see. Even more,
no need to balance before sharpening actually. Why should one do that
anyway?

> But mostly you need to do a significant amount of preprocessing to get
the best results. It would be good if someone with more image processing
experience could weigh in and offer some insight.

With or without pre-processing, I am not able to get meaningful images
here. I am probably doing something wrong. I am available to test and
share anything (but the images I work with). But we can work with the
publicly available material.

> The ideal script--or perhaps better the ideal workflow--would combine a
set of preprocessing steps with the pan sharpening. The latter is a set of
processing algorithms that is completely ignorant of color.

That would be really great! But this would be something for High(est)
Precision hunting. My problem, as well as the problems described by Haziq
in the respective Q&A is to get at least something that approaches a real-
RGB image after pan-sharpening and using the R, G and B channels to draw
an RGB composite.

Thanks

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 30, 2013, 1:43pm

#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 mlennert):

Replying to [comment:4 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.

I think in both modules the routines can probably be improved in terms of
performance.

Even though it shouldn't be too complicated to integrate source-target
matching in i.histo.match, I don't have the time to look into that, now.
If anyone has a student that needs a project, this would be a nice
exercise

Moritz

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 30, 2013, 4:38pm

#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 cmbarton):

For pan sharpening, the reason for histogram matching is that the higher
resolution pan image needs to replace one of the lower resolution images
as part of the sharpening algorithm. So the pan band needs to be histogram
matched to the one it is replacing. This is why I don't think that
matching it to an average of all bands is a good idea. I could be
mistaken, but it seems incorrect conceptually.

The routine I used is the standard one discussed for this. There may well
be a more accurate one and a better way to deal with floating point and
large integer data. Using numpy arrays makes this one quite fast. It might
benefit from parallelization in some way. I parallelized other parts of
the code but not this one. So, yes, if there is a student out there with
not enough to do...

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:9>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 11:49am

#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 mlennert):

Replying to [comment:9 cmbarton]:
> For pan sharpening, the reason for histogram matching is that the higher
resolution pan image needs to replace one of the lower resolution images
as part of the sharpening algorithm. So the pan band needs to be histogram
matched to the one it is replacing. This is why I don't think that
matching it to an average of all bands is a good idea. I could be
mistaken, but it seems incorrect conceptually.

I agree with you that for i.pansharpen that's the way to go. What I said
is that I think i.histo.match should ideally allow the use to chose
between the different techniques.

>
> The routine I used is the standard one discussed for this. There may
well be a more accurate one and a better way to deal with floating point
and large integer data. Using numpy arrays makes this one quite fast. It
might benefit from parallelization in some way. I parallelized other parts
of the code but not this one. So, yes, if there is a student out there
with not enough to do...

In terms of optimisation I was mostly thinking about the double loop
through arrays[target] within the 'for i in arrays[original]' loop. I
think that there are more efficient search algorithms, but yours
definitely works.

Moritz

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:10>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 3:00pm

#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):

Some (minor) things to improve i.pansharpen:

* make "sharpen=brovey" progress notifications more informative, for
example instead of solely "Histogram matching...", inform the user what is
being histo-matched to what. I.e., "Matching histogram of Input_Map to
histogram of Reference_Map"

* it seems that the module (at least when "sharp=brovey" ?) does not like
dashes in the input images names:

{{{
i.pansharpen sharpen=brovey ms1=M1BS-01_P001.1 ms2=M1BS-01_P001.2 ms3
=M1BS-01_P001.3 pan=P1BS-01_P001 output_prefix=sharpen_brovey_01_P001

Performing pan sharpening with hi res pan image: 1.000000
Using Brovey algorithm

Histogram matching...
100%
100%

Calculating Brovey transformation...
Invalid map <M1BS>
Invalid map <01_P001.1>
Parse error
ERROR: parse error
Invalid map <M1BS>
Invalid map <01_P001.2>
Parse error
ERROR: parse error
Invalid map <M1BS>
Invalid map <01_P001.3>
Parse error
ERROR: parse error

Assigning grey equalized color tables to output images...
ERROR: Raster map <sharpen_brovey_01_P001_red> not found
ERROR: Raster map <sharpen_brovey_01_P001_green> not found
ERROR: Raster map <sharpen_brovey_01_P001_blue> not found

The following pan-sharpened output maps have been generated:
sharpen_brovey_01_P001_red
sharpen_brovey_01_P001_green
sharpen_brovey_01_P001_blue

To visualize output, run: g.region -p rast=sharpen_brovey_01_P001.red
d.rgb r=sharpen_brovey_01_P001_red g=sharpen_brovey_01_P001_green
b=sharpen_brovey_01_P001_blue

If desired, combine channels into a single RGB map with 'r.composite'.
Channel colors can be rebalanced using i.landsat.rgb.
WARNING: Unable to write history for <sharpen_brovey_01_P001_red>. Raster
          map <sharpen_brovey_01_P001_red> not found in current mapset.
WARNING: Unable to write history for <sharpen_brovey_01_P001_green>.
Raster
          map <sharpen_brovey_01_P001_green> not found in current mapset.
WARNING: Unable to write history for <sharpen_brovey_01_P001_blue>. Raster
          map <sharpen_brovey_01_P001_blue> not found in current mapset.
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:11>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 3:53pm

#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):

Attaching two overview screenshots (uploaded in GRASS-Wiki, links below)
with all "sharpen= ihs, brovey, pca" methods in 11-bit IKONOS DNs, and
double precision both Radiance and Reflectance values. (Unfortunately,
it's not possible to draw d.rgb directly in a d.frame.split-ed d.mon, thus
I created composites)

None of them appears ok to me. Even more, NULL cells have been
introduced.

*
[http://grasswiki.osgeo.org/wiki/File:IKONOS_PanSharpening_Three_Inputs_Greyscaled_Three_Methods.png\]

*
[http://grasswiki.osgeo.org/wiki/File:IKONOS_PanSharpening_Three_Inputs_Rebalanced_Three_Methods.png\]

Working with rescaled 8-bit versions, produced, so far for me, nice
outputs.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:12>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 6:11pm

#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 mlennert):

Replying to [comment:5 nikosa]:
> However, I'd like to kindly ask again if it is possible to alter the
documentation? It is not a nice surprise trying to work with i.pansharpen
and getting strange colors or empty images as a result. See also
[http://gis.stackexchange.com/q/39174/5256\]. At least mention the current
limitation or... other ideas? Then again, it is in G7, the development
version

I just (r57332) added a sentence to the NOTES section about the module
currently working only for 8-bit images.

Several remarks to justify that:

- The histogram matching algorithm in the module is limited to 8-bit as it
reclasses only sources values between 0 and 255 to target value between 0
and 255 (it also calls r.stats with the -i flag, and so rounds everything
to integer, IIUC). In other words, any values above 255 silently ignored !
To check, just comment out line where the temporary histogram matched
(reclassed) images are g.removed. As the histogram matching is used in all
three algorithms, they are all limited to 8-bit.

- the i.rgb.his/i.his.rgb modules are also limited to 8-bit, AFAIK. There
is an old ticket with a patch proposed by Hamish on that: #774. See also
[1]

So, in conclusion, to be able to use i.pansharpen with >8-bit images, the
histogram matching algorithm needs to be rewritten. You could try to just
skip the histogram matching part (just comment out the relevant call to
the function and replace the panmatch images by the pan image and see what
happens (I'll have to read up on the theory again to understand why
histogram matching is necessary here).

You can also apply the brovey or pca method yourself using r.mapcalc and
i.pca.

[1] http://lists.osgeo.org/pipermail/grass-
user/2009-September/052573.html

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:13>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 7:30pm

#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 cmbarton):

Does someone have a small sample set of images to test in order to work
out alternatives to 8bit image matching?

A key issue is that it will be necessary to know the potential value range
for the images. I don't see a way around this being a user-entered value.
Maybe there also needs to be a flag for floating point.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:14>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 7:46pm

#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):

Replying to [comment:14 cmbarton]:
> Does someone have a small sample set of images to test in order to work
out alternatives to 8bit image matching?

See, for example, publicly available IKONOS images:
[ftp://ftp.glcf.umd.edu/glcf/China_earthquake_May_2008/IKONOS/\]. I did
all the series of tests (as postes in the mailing list) with the first one
[ftp://ftp.glcf.umd.edu/glcf/China_earthquake_May_2008/IKONOS/po_58204_0000000.20001116
.China-Sichuan/]

I also have a small script to pan-sharpen DNs, Radiance and Reflectancs
(given all of the pre-processing has been done and some naming conventions
are followed):

{{{
for Method_Input in "ihs DNs" "ihs Radiance" "ihs ToAR" \
"brovey DNs" "brovey Radiance" "brovey ToAR" \
"pca DNs" "pca Radiance" "pca ToAR"

do

# parse "${Method_STR}" and set positional parameters
set -- $Method_Input ; echo $1 $2

# some echo
echo "Pan-Sharpening the <${2}> images based on the <${1}> method"

   i.pansharpen \
   sharpen=${1} \
   pan=Pan_${2} \
   ms1=Blue_${2} \
   ms2=Green_${2} \
   ms3=Red_${2} \
   output=sharp_${1}_${2}

done
}}}

> A key issue is that it will be necessary to know the potential value
range for the images.

If it's an 11-bit image, the the input can be fixed to [0,2047]?
Actually, most of the data come in either 8-bit or 16-bit form. The
latter for not loosing the fine detail of >8-bit sensors (me thinks).

> I don't see a way around this being a user-entered value. Maybe there
also needs to be a flag for floating point.

Can't this be automated in Python? Right, RTFM for myself

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:15>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 31, 2013, 8:31pm

#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 cmbarton):

Replying to [comment:15 nikosa]:
> Replying to [comment:14 cmbarton]:
> > Does someone have a small sample set of images to test in order to
work out alternatives to 8bit image matching?
>
>
> See, for example, publicly available IKONOS images:
[ftp://ftp.glcf.umd.edu/glcf/China_earthquake_May_2008/IKONOS/\]. I did
all the series of tests (as postes in the mailing list) with the first one
[ftp://ftp.glcf.umd.edu/glcf/China_earthquake_May_2008/IKONOS/po_58204_0000000.20001116
.China-Sichuan/]
>
> I also have a small script to pan-sharpen DNs, Radiance and Reflectancs
(given all of the pre-processing has been done and some naming conventions
are followed):
>
>
> {{{
> for Method_Input in "ihs DNs" "ihs Radiance" "ihs ToAR" \
> "brovey DNs" "brovey Radiance" "brovey ToAR" \
> "pca DNs" "pca Radiance" "pca ToAR"
>
> do
>
> # parse "${Method_STR}" and set positional parameters
> set -- $Method_Input ; echo $1 $2
>
> # some echo
> echo "Pan-Sharpening the <${2}> images based on the <${1}> method"
>
> i.pansharpen \
> sharpen=${1} \
> pan=Pan_${2} \
> ms1=Blue_${2} \
> ms2=Green_${2} \
> ms3=Red_${2} \
> output=sharp_${1}_${2}
>
> done
> }}}
>
>
>
> > A key issue is that it will be necessary to know the potential value
range for the images.
>
> If it's an 11-bit image, the the input can be fixed to [0,2047]?
Actually, most of the data come in either 8-bit or 16-bit form. The
latter for not loosing the fine detail of >8-bit sensors (me thinks).
>
>
> > I don't see a way around this being a user-entered value. Maybe there
also needs to be a flag for floating point.
>
> Can't this be automated in Python? Right, RTFM for myself

Actually, Python doesn't care if it is floating point or not (although you
can specify). It's the GRASS routines that matter most, especially r.stats
and r.mapcalc (can't can't change this for r.his.rgb/r.rgb.his or i.pca).

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2048#comment:16>
GRASS GIS <http://grass.osgeo.org>

GDAL · August 1, 2013, 12:23am

#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):

Replying to [comment:1 cmbarton]:
> The question is whether the histogram matching code can handle
resolutions of >8 bit.

Michael, for viewing purposes we all agree (don't we?) that 8-bit per
"channel" is more than enough. For analysis, my guess is that it would be
interesting to have the "fine digits" preserved. But, with the histogram
matching on the way, I don't know really if and at what extent the data
are irreparably re-touched.

Anyway,

did you folks notice that this ticket #2048 just hit the upper... 2^11
limit?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2048#comment:17>
GRASS GIS <http://grass.osgeo.org>

GDAL · November 17, 2013, 12:27am

#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>