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

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

 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>