Processing Landsat 8 tiles

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Processing Landsat 8 tiles

Durejka, Stefan

Hi there,

 

I have to mosaic together several Landsat 8 tiles that where pansharpened using Grass 7.0 and exported as RGB composites to GeoTiff. ( I also tried the i.histo.match module in Grass but somehow it fails to produce nice outputs.) Ossim 1.8.16 is set up on Windows 7 using the OSGeo4W 64-bit installer.

 

gdalinfo provides the following data  information for two overlapping example tiles

 

LC81740382014220LGN00_brovey_rgb.tif:

 

Band 1 Block=15123x1 Type=Int16, ColorInterp=Gray

  Min=33.000 Max=32767.000

  Minimum=33.000, Maximum=32767.000, Mean=16251.628, StdDev=9705.333

  NoData Value=-5555

 

LC81740392014236LGN00_brovey_rg:

 

Band 1 Block=15143x1 Type=Int16, ColorInterp=Gray

  Min=0.000 Max=32767.000

  Minimum=0.000, Maximum=32767.000, Mean=16227.811, StdDev=9723.930

  NoData Value=-5555

 

A histogramm for each file was created using

 

ossim-create-histo --disable-elev -i LC81740382014220LGN00_brovey_rgb.tif -o LC81740382014220LGN00_brovey_rgb.his

ossim-create-histo --disable-elev -i LC81740392014236LGN00_brovey_rgb.tif -o LC81740392014236LGN00_brovey_rgb.his

 

Afterwards i tried

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch.tif

 

producing HistMatch.png and

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif --combiner-type ossimFeatherMosaic LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch_feather.tif

 

producing MosaicFeather.png.

 

In my opinion I somehow mess up the boundaries of the tiles.

 

In the Histogram Matchin tutorial http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf extract_vertices and cmm are mentioned to define the boundarys of images without rectangular footprint.

 

ossim-extract-vertices LC81740382014220LGN00_brovey_rgb.tif results in a .kwl file like

 

point0.x:  0

point0.y:  0

point1.x:  15122

point1.y:  0

point2.x:  15122

point2.y:  15442

point3.x:  0

point3.y:  15442

 

ossim-extract-vertices LC81740392014236LGN00_brovey_rgb.tif in a file like

 

point0.x:  0

point0.y:  0

point1.x:  15142

point1.y:  0

point2.x:  15142

point2.y:  15482

point3.x:  0

point3.y:  15482

 

Which represents the raster boundaries but not the area where valid values are defined. Ist there a problem with the -5555 no data value? See also in the cmm output

 

ossim-cmm LC81740382014220LGN00_brovey_rgb.tif produces a .omd file

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

ossim-cmm LC81740392014236LGN00_brovey_rgb.tif

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

 

Do i have to define the boundaries and the messed up no data value manually? And were in the histogram matching process do I have to use the updated .omd and .kwl files?

 

Looking forward to your comments,

 

Stefan

 

 

 

 

 


------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

HistMatch_tinypng.png (447K) Download Attachment
MosaicFeather_tynipng.png (518K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Processing Landsat 8 tiles

David Burken
Hi,

I've not had any LS8 data.  Is -5555 standard null for that data?  I'd fix the null issue first.  Then I don't think you'd need extract vertices.  To fix the null issue do:

// Just in case:
$ rm <file.omd>

$ ossim-cmm --null -5555 <file>

Then I'd recreate histogram and overviews.

$ ossim-img2rr -r --create-histogram <file>

Note the above two command line apps are being rolled into ossim-preproc but your code is too old for that.

Take care,
Dave



On 04/20/2015 02:43 AM, Durejka, Stefan wrote:

Hi there,

 

I have to mosaic together several Landsat 8 tiles that where pansharpened using Grass 7.0 and exported as RGB composites to GeoTiff. ( I also tried the i.histo.match module in Grass but somehow it fails to produce nice outputs.) Ossim 1.8.16 is set up on Windows 7 using the OSGeo4W 64-bit installer.

 

gdalinfo provides the following data  information for two overlapping example tiles

 

LC81740382014220LGN00_brovey_rgb.tif:

 

Band 1 Block=15123x1 Type=Int16, ColorInterp=Gray

  Min=33.000 Max=32767.000

  Minimum=33.000, Maximum=32767.000, Mean=16251.628, StdDev=9705.333

  NoData Value=-5555

 

LC81740392014236LGN00_brovey_rg:

 

Band 1 Block=15143x1 Type=Int16, ColorInterp=Gray

  Min=0.000 Max=32767.000

  Minimum=0.000, Maximum=32767.000, Mean=16227.811, StdDev=9723.930

  NoData Value=-5555

 

A histogramm for each file was created using

 

ossim-create-histo --disable-elev -i LC81740382014220LGN00_brovey_rgb.tif -o LC81740382014220LGN00_brovey_rgb.his

ossim-create-histo --disable-elev -i LC81740392014236LGN00_brovey_rgb.tif -o LC81740392014236LGN00_brovey_rgb.his

 

Afterwards i tried

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch.tif

 

producing HistMatch.png and

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif --combiner-type ossimFeatherMosaic LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch_feather.tif

 

producing MosaicFeather.png.

 

In my opinion I somehow mess up the boundaries of the tiles.

 

In the Histogram Matchin tutorial http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf extract_vertices and cmm are mentioned to define the boundarys of images without rectangular footprint.

 

ossim-extract-vertices LC81740382014220LGN00_brovey_rgb.tif results in a .kwl file like

 

point0.x:  0

point0.y:  0

point1.x:  15122

point1.y:  0

point2.x:  15122

point2.y:  15442

point3.x:  0

point3.y:  15442

 

ossim-extract-vertices LC81740392014236LGN00_brovey_rgb.tif in a file like

 

point0.x:  0

point0.y:  0

point1.x:  15142

point1.y:  0

point2.x:  15142

point2.y:  15482

point3.x:  0

point3.y:  15482

 

Which represents the raster boundaries but not the area where valid values are defined. Ist there a problem with the -5555 no data value? See also in the cmm output

 

ossim-cmm LC81740382014220LGN00_brovey_rgb.tif produces a .omd file

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

ossim-cmm LC81740392014236LGN00_brovey_rgb.tif

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

 

Do i have to define the boundaries and the messed up no data value manually? And were in the histogram matching process do I have to use the updated .omd and .kwl files?

 

Looking forward to your comments,

 

Stefan

 

 

 

 

 



------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Processing Landsat 8 tiles

David Burken
Hi Stefan,

Hey that looks good!  The grass code is out of my jurisdiction. I would think the next release would use 1.8.18.  Not sure about the order.  I don't have the histo match wired into ossim-chipper but you might be interested in the PSM example:

http://trac.osgeo.org/ossim/wiki/ossim-chipper

// This installer just gives you command line apps and ossim-geocell. 
// Doesn't set path so you need to cd to install dir and source the ossim.bat
http://download.osgeo.org/ossim/installers/windows/ossim_x64_1_8_19-20150327-1.exe

Take care,
Dave



From: "Stefan Durejka" <[hidden email]>
To: "David Burken" <[hidden email]>, [hidden email]
Sent: Tuesday, April 21, 2015 9:11:09 AM
Subject: AW: [OSSIM] Processing Landsat 8 tiles

Hi Dave,

 

-5555 is the NoData value I assigned to the GeoTIFFs while exporting them from GRASS.  

I  just started another try not assigning a specific NoData value during the export eh voilà ossim seems to be recognizing the correct NoData value now , see the attached picture.

 

But I was wondering if it would be better practice to mosaic the tiles for each band >red,green,blue> before creating a rgb composite?

 And is it planned to bring ossim-1.8.18 into the OSGeoW4 installer?

 

Cheers,

 

Stefan

 

 

Von: David Burken [mailto:[hidden email]]
Gesendet: Montag, 20. April 2015 15:36
An: Durejka, Stefan; [hidden email]
Betreff: Re: [OSSIM] Processing Landsat 8 tiles

 

Hi,

I've not had any LS8 data.  Is -5555 standard null for that data?  I'd fix the null issue first.  Then I don't think you'd need extract vertices.  To fix the null issue do:

// Just in case:
$ rm <file.omd>

$ ossim-cmm --null -5555 <file>

Then I'd recreate histogram and overviews.

$ ossim-img2rr -r --create-histogram <file>

Note the above two command line apps are being rolled into ossim-preproc but your code is too old for that.

Take care,
Dave


On 04/20/2015 02:43 AM, Durejka, Stefan wrote:

Hi there,

 

I have to mosaic together several Landsat 8 tiles that where pansharpened using Grass 7.0 and exported as RGB composites to GeoTiff. ( I also tried the i.histo.match module in Grass but somehow it fails to produce nice outputs.) Ossim 1.8.16 is set up on Windows 7 using the OSGeo4W 64-bit installer.

 

gdalinfo provides the following data  information for two overlapping example tiles

 

LC81740382014220LGN00_brovey_rgb.tif:

 

Band 1 Block=15123x1 Type=Int16, ColorInterp=Gray

  Min=33.000 Max=32767.000

  Minimum=33.000, Maximum=32767.000, Mean=16251.628, StdDev=9705.333

  NoData Value=-5555

 

LC81740392014236LGN00_brovey_rg:

 

Band 1 Block=15143x1 Type=Int16, ColorInterp=Gray

  Min=0.000 Max=32767.000

  Minimum=0.000, Maximum=32767.000, Mean=16227.811, StdDev=9723.930

  NoData Value=-5555

 

A histogramm for each file was created using

 

ossim-create-histo --disable-elev -i LC81740382014220LGN00_brovey_rgb.tif -o LC81740382014220LGN00_brovey_rgb.his

ossim-create-histo --disable-elev -i LC81740392014236LGN00_brovey_rgb.tif -o LC81740392014236LGN00_brovey_rgb.his

 

Afterwards i tried

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch.tif

 

producing HistMatch.png and

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif --combiner-type ossimFeatherMosaic LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch_feather.tif

 

producing MosaicFeather.png.

 

In my opinion I somehow mess up the boundaries of the tiles.

 

In the Histogram Matchin tutorial http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf extract_vertices and cmm are mentioned to define the boundarys of images without rectangular footprint.

 

ossim-extract-vertices LC81740382014220LGN00_brovey_rgb.tif results in a .kwl file like

 

point0.x:  0

point0.y:  0

point1.x:  15122

point1.y:  0

point2.x:  15122

point2.y:  15442

point3.x:  0

point3.y:  15442

 

ossim-extract-vertices LC81740392014236LGN00_brovey_rgb.tif in a file like

 

point0.x:  0

point0.y:  0

point1.x:  15142

point1.y:  0

point2.x:  15142

point2.y:  15482

point3.x:  0

point3.y:  15482

 

Which represents the raster boundaries but not the area where valid values are defined. Ist there a problem with the -5555 no data value? See also in the cmm output

 

ossim-cmm LC81740382014220LGN00_brovey_rgb.tif produces a .omd file

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

ossim-cmm LC81740392014236LGN00_brovey_rgb.tif

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

 

Do i have to define the boundaries and the messed up no data value manually? And were in the histogram matching process do I have to use the updated .omd and .kwl files?

 

Looking forward to your comments,

 

Stefan

 

 

 

 

 




------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF




_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 



------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Processing Landsat 8 tiles

Durejka, Stefan

Hi there,

 

it seems that I’m still not finished asking questions. I updated my ossim with the installer provided by Dave.

 

ossim-info --version now returns  ossim-info 1.8.19 20150327

 

In the next step I tried to switch to ossim-preproc according to https://trac.osgeo.org/ossim/wiki/ossim-preproc to minimize lines of code and execute the steps along a file directory.

 

gdalinfo -stats -nomd <file> provides

 

Band 1 Block=15123x1 Type=Float64, ColorInterp=Gray

  Minimum=0.000, Maximum=70.538, Mean=6.759, StdDev=4.501

  NoData Value=-9999

 

ossim-info <file> provides, so clearly the NoData value is no recognized

 

image0.band0.max_value:  4.5035996273705e+015

image0.band0.min_value:  -4.5035996273705e+015

image0.band0.null_value:  -4.5035996273705e+015

 

ossim-preproc --ch <file> therefore results in a wrong histogram

 

number_of_res_levels:  1

rr_level0.band0.bins:  ((0,6619731),(32768,16777216))

rr_level0.band0.max_value:  4.5035996e+015

rr_level0.band0.min_value:  -4.5035996e+015

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

but also ossim-preproc --ch --null -9999.0 <file> fails to recognize the NoData value? Is the --null option only available for the --compute-min-max option?

 

number_of_res_levels:  1

rr_level0.band0.bins:  ((0,6619731),(32768,16777216))

rr_level0.band0.max_value:  4.5035996e+015

rr_level0.band0.min_value:  -4.5035996e+015

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

using the single file option ossim-cmm --null -9999.0 <file>  results in an .omd file

 

band1.max_value:  70.5384615384615

band1.min_value:  -9999

band1.null_value:  -9999

number_bands:  1

scalar_type:  ossim_float64

 

and ossim-info <file> afterwards

 

image0.band0.max_value:  70.5384615384615

image0.band0.min_value:  -9999

image0.band0.null_value:  -9999

 

and hence ossim-create-hist -i <file.tif> -o <file.his>

 number_of_res_levels:  1

rr_level0.band0.bins:  ((0,7488040),(65076,56),(65078,4),(65079,13),(65080,303059),(65081,9454410),(65082,5635479),(65083,6571536),(65084,4422237),(65085,1823516),(65086,1180695),(65087,477798),(65088,347347),(65089,756463),(65090,452317),(65091,381775),(65092,455640),(65093,388345),(65094,627680),(65095,729139),(65096,880824),(65097,1425848),(65098,1647136),(65099,1620057),(65100,2184788),(65101,1912496),(65102,2231602),(65103,2087417),(65104,2369622),(65105,3337459),(65106,3254927),(65107,3205260),(65108,2856514),(65109,2785936),(65110,2764231),(65111,2463460),(65112,2686922),(65113,2325728),(65114,2764054),(65115,2521154),(65116,2303262),(65117,2371784),(65118,2295053),(65119,2210324),(65120,2329326),(65121,1937834),(65122,2399813),(65123,1952501),(65124,2101956),(65125,1951118),(65126,2012242),(65127,2117147),(65128,2142095),(65129,2163735),(65130,2681254),(65131,2131314),(65132,1854480),(65133,1529111),(65134,1435653),(65135,1263790),(65136,1402764),(65137,1184314),(65138,1350931),(65139,1154135),(65140,1182495),(65141,1203111),(65142,1022864),(65143,1124230),(65144,1094152),(65145,1087222),(65146,1077075),(65147,1239467),(65148,1228547),(65149,1433843),(65150,1273172),(65151,1259204),(65152,1099386),(65153,937862),(65154,687543),(65155,581828),(65156,539869),(65157,544695),(65158,543768),(65159,763107),(65160,743274),(65161,784712),(65162,828184),(65163,752229),(65164,846329),(65165,722793),(65166,701663),(65167,796990),(65168,650668),(65169,702712),(65170,653248),(65171,615653),(65172,630652),(65173,539673),(65174,522847),(65175,570532),(65176,444229),(65177,514219),(65178,415605),(65179,380176),(65180,420473),(65181,348967),(65182,346323),(65183,328704),(65184,278220),(65185,296046),(65186,241344),(65187,233922),(65188,241287),(65189,212600),(65190,210858),(65191,191940),(65192,178499),(65193,179330),(65194,144707),(65195,144777),(65196,139416),(65197,101469),(65198,74313),(65199,50858),(65200,72256),(65201,84655),(65202,92220),(65203,99943),(65204,88669),(65205,85616),(65206,78993),(65207,67415),(65208,74303),(65209,58630),(65210,55103),(65211,56883),(65212,46748),(65213,49475),(65214,41436),(65215,37959),(65216,40643),(65217,32506),(65218,31785),(65219,30225),(65220,25099),(65221,22224),(65222,13962),(65223,11094),(65224,14827),(65225,16986),(65226,19798),(65227,19115),(65228,16925),(65229,18758),(65230,15753),(65231,15767),(65232,14862),(65233,14233),(65234,14173),(65235,12332),(65236,12170),(65237,11881),(65238,10678),(65239,9412),(65240,8609),(65241,5678),(65242,5362),(65243,5423),(65244,6759),(65245,6775),(65246,7588),(65247,7379),(65248,7469),(65249,6278),(65250,7091),(65251,5700),(65252,6232),(65253,5687),(65254,5296),(65255,5393),(65256,4607),(65257,4603),(65258,3889),(65259,3765),(65260,3311),(65261,3051),(65262,2809),(65263,2542),(65264,1585),(65265,1245),(65266,1751),(65267,2421),(65268,2112),(65269,2403),(65270,2162),(65271,2140),(65272,2124),(65273,2115),(65274,1721),(65275,1948),(65276,1210),(65277,804),(65278,919),(65279,1388),(65280,1540),(65281,1473),(65282,1456),(65283,1389),(65284,1348),(65285,1315),(65286,1173),(65287,1086),(65288,1043),(65289,547),(65290,443),(65291,771),(65292,1037),(65293,1068),(65294,988),(65295,954),(65296,999),(65297,801),(65298,1033),(65299,740),(65300,868),(65301,709),(65302,802),(65303,639),(65304,719),(65305,409),(65306,241),(65307,253),(65308,577),(65309,585),(65310,500),(65311,538),(65312,508),(65313,479),(65314,483),(65315,447),(65316,433),(65317,460),(65318,319),(65319,439),(65320,275),(65321,336),(65322,288),(65323,296),(65324,262),(65325,270),(65326,197),(65327,233),(65328,179),(65329,184),(65330,187),(65331,175),(65332,150),(65333,123),(65334,112),(65335,93),(65336,86),(65337,53),(65338,40),(65339,66),(65340,90),(65341,82),(65342,78),(65343,85),(65344,82),(65345,83),(65346,80),(65347,59),(65348,42),(65349,32),(65350,21),(65351,35),(65352,18),(65353,31),(65354,36),(65355,36),(65356,40),(65357,45),(65358,35),(65359,17),(65360,19),(65361,25),(65362,24),(65363,28),(65364,19),(65365,17),(65366,26),(65367,34),(65368,16),(65369,14),(65370,19),(65371,19),(65372,22),(65373,20),(65374,16),(65375,16),(65376,6),(65377,14),(65378,11),(65379,12),(65380,12),(65381,21),(65382,13),(65383,17),(65384,9),(65385,13),(65386,11),(65387,13),(65388,12),(65389,9),(65390,10),(65391,14),(65392,15),(65393,14),(65394,5),(65395,6),(65396,2),(65397,7),(65398,3),(65399,7),(65400,1),(65401,3),(65402,2),(65403,2),(65405,2),(65406,3),(65407,2),(65408,1),(65409,1),(65410,3),(65411,1),(65412,1),(65413,1),(65414,1),(65415,1),(65417,1),(65418,5),(65421,1),(65422,1),(65423,1),(65424,1),(65425,1),(65426,1),(65427,1),(65429,2),(65439,1),(65447,1),(65448,1),(65451,1),(65461,1),(65462,1),(65465,1),(65468,1),(65470,1),(65475,1),(65481,1),(65482,1))

rr_level0.band0.max_value:  70.53846

rr_level0.band0.min_value:  -9999

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

 

Still, the bins look kind of strange to me? Is it correct that ossim always recognizes the null value as the minimum value?

 

Stefan

 

 

 

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Dienstag, 21. April 2015 16:06
An: Durejka, Stefan
Cc: ossim
Betreff: Re: AW: [OSSIM] Processing Landsat 8 tiles

 

Hi Stefan,

 

Hey that looks good!  The grass code is out of my jurisdiction. I would think the next release would use 1.8.18.  Not sure about the order.  I don't have the histo match wired into ossim-chipper but you might be interested in the PSM example:

 

 

// This installer just gives you command line apps and ossim-geocell. 

// Doesn't set path so you need to cd to install dir and source the ossim.bat

 

Take care,

Dave

 

 


From: "Stefan Durejka" <[hidden email]>
To: "David Burken" <
[hidden email]>, [hidden email]
Sent: Tuesday, April 21, 2015 9:11:09 AM
Subject: AW: [OSSIM] Processing Landsat 8 tiles

 

Hi Dave,

 

-5555 is the NoData value I assigned to the GeoTIFFs while exporting them from GRASS.  

I  just started another try not assigning a specific NoData value during the export eh voilà ossim seems to be recognizing the correct NoData value now , see the attached picture.

 

But I was wondering if it would be better practice to mosaic the tiles for each band >red,green,blue> before creating a rgb composite?

 And is it planned to bring ossim-1.8.18 into the OSGeoW4 installer?

 

Cheers,

 

Stefan

 

 

Von: David Burken [[hidden email]]
Gesendet: Montag, 20.
April 2015 15:36
An: Durejka, Stefan;
[hidden email]
Betreff: Re: [OSSIM] Processing Landsat 8 tiles

 

Hi,

I've not had any LS8 data.  Is -5555 standard null for that data?  I'd fix the null issue first.  Then I don't think you'd need extract vertices.  To fix the null issue do:

// Just in case:
$ rm <file.omd>

$ ossim-cmm --null -5555 <file>

Then I'd recreate histogram and overviews.

$ ossim-img2rr -r --create-histogram <file>

Note the above two command line apps are being rolled into ossim-preproc but your code is too old for that.

Take care,
Dave

On 04/20/2015 02:43 AM, Durejka, Stefan wrote:

Hi there,

 

I have to mosaic together several Landsat 8 tiles that where pansharpened using Grass 7.0 and exported as RGB composites to GeoTiff. ( I also tried the i.histo.match module in Grass but somehow it fails to produce nice outputs.) Ossim 1.8.16 is set up on Windows 7 using the OSGeo4W 64-bit installer.

 

gdalinfo provides the following data  information for two overlapping example tiles

 

LC81740382014220LGN00_brovey_rgb.tif:

 

Band 1 Block=15123x1 Type=Int16, ColorInterp=Gray

  Min=33.000 Max=32767.000

  Minimum=33.000, Maximum=32767.000, Mean=16251.628, StdDev=9705.333

  NoData Value=-5555

 

LC81740392014236LGN00_brovey_rg:

 

Band 1 Block=15143x1 Type=Int16, ColorInterp=Gray

  Min=0.000 Max=32767.000

  Minimum=0.000, Maximum=32767.000, Mean=16227.811, StdDev=9723.930

  NoData Value=-5555

 

A histogramm for each file was created using

 

ossim-create-histo --disable-elev -i LC81740382014220LGN00_brovey_rgb.tif -o LC81740382014220LGN00_brovey_rgb.his

ossim-create-histo --disable-elev -i LC81740392014236LGN00_brovey_rgb.tif -o LC81740392014236LGN00_brovey_rgb.his

 

Afterwards i tried

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch.tif

 

producing HistMatch.png and

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif --combiner-type ossimFeatherMosaic LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch_feather.tif

 

producing MosaicFeather.png.

 

In my opinion I somehow mess up the boundaries of the tiles.

 

In the Histogram Matchin tutorial http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf extract_vertices and cmm are mentioned to define the boundarys of images without rectangular footprint.

 

ossim-extract-vertices LC81740382014220LGN00_brovey_rgb.tif results in a .kwl file like

 

point0.x:  0

point0.y:  0

point1.x:  15122

point1.y:  0

point2.x:  15122

point2.y:  15442

point3.x:  0

point3.y:  15442

 

ossim-extract-vertices LC81740392014236LGN00_brovey_rgb.tif in a file like

 

point0.x:  0

point0.y:  0

point1.x:  15142

point1.y:  0

point2.x:  15142

point2.y:  15482

point3.x:  0

point3.y:  15482

 

Which represents the raster boundaries but not the area where valid values are defined. Ist there a problem with the -5555 no data value? See also in the cmm output

 

ossim-cmm LC81740382014220LGN00_brovey_rgb.tif produces a .omd file

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

ossim-cmm LC81740392014236LGN00_brovey_rgb.tif

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

 

Do i have to define the boundaries and the messed up no data value manually? And were in the histogram matching process do I have to use the updated .omd and .kwl files?

 

Looking forward to your comments,

 

Stefan

 

 

 

 

 





------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF





_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 


------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Processing Landsat 8 tiles

David Burken
Hi,

Float data is always problematic.  Make sure you don't have a phantom <file.omd> file before you start.   You have to tell compute min max code what the null is.  You can always do it manually by creating a file.omd but the code should do it. Example:

ossim-preproc --null -9999 --compute-min-max GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5


$ ossim-preproc --null -9999 --compute-min-max GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5
Processing file: /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5
100%
Finished...
wrote file:  /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.omd
elapsed time in seconds: 0.364

$ cat /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.omd
band1.max_value:  2.78873558272608e-05
band1.min_value:  -1.50000001308825e-09
band1.null_value:  -9999
bytes_per_pixel:  4
number_bands:  1
scalar_type:  ossim_float32

$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
im$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
im$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
image0.band0.null_value:  -9999

Once you get that you should be able to create a good histogram.

Hope that helps,
Dave


On 04/22/2015 03:52 AM, Durejka, Stefan wrote:

Hi there,

 

it seems that I’m still not finished asking questions. I updated my ossim with the installer provided by Dave.

 

ossim-info --version now returns  ossim-info 1.8.19 20150327

 

In the next step I tried to switch to ossim-preproc according to https://trac.osgeo.org/ossim/wiki/ossim-preproc to minimize lines of code and execute the steps along a file directory.

 

gdalinfo -stats -nomd <file> provides

 

Band 1 Block=15123x1 Type=Float64, ColorInterp=Gray

  Minimum=0.000, Maximum=70.538, Mean=6.759, StdDev=4.501

  NoData Value=-9999

 

ossim-info <file> provides, so clearly the NoData value is no recognized

 

image0.band0.max_value:  4.5035996273705e+015

image0.band0.min_value:  -4.5035996273705e+015

image0.band0.null_value:  -4.5035996273705e+015

 

ossim-preproc --ch <file> therefore results in a wrong histogram

 

number_of_res_levels:  1

rr_level0.band0.bins:  ((0,6619731),(32768,16777216))

rr_level0.band0.max_value:  4.5035996e+015

rr_level0.band0.min_value:  -4.5035996e+015

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

but also ossim-preproc --ch --null -9999.0 <file> fails to recognize the NoData value? Is the --null option only available for the --compute-min-max option?

 

number_of_res_levels:  1

rr_level0.band0.bins:  ((0,6619731),(32768,16777216))

rr_level0.band0.max_value:  4.5035996e+015

rr_level0.band0.min_value:  -4.5035996e+015

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

using the single file option ossim-cmm --null -9999.0 <file>  results in an .omd file

 

band1.max_value:  70.5384615384615

band1.min_value:  -9999

band1.null_value:  -9999

number_bands:  1

scalar_type:  ossim_float64

 

and ossim-info <file> afterwards

 

image0.band0.max_value:  70.5384615384615

image0.band0.min_value:  -9999

image0.band0.null_value:  -9999

 

and hence ossim-create-hist -i <file.tif> -o <file.his>

 number_of_res_levels:  1

rr_level0.band0.bins:  ((0,7488040),(65076,56),(65078,4),(65079,13),(65080,303059),(65081,9454410),(65082,5635479),(65083,6571536),(65084,4422237),(65085,1823516),(65086,1180695),(65087,477798),(65088,347347),(65089,756463),(65090,452317),(65091,381775),(65092,455640),(65093,388345),(65094,627680),(65095,729139),(65096,880824),(65097,1425848),(65098,1647136),(65099,1620057),(65100,2184788),(65101,1912496),(65102,2231602),(65103,2087417),(65104,2369622),(65105,3337459),(65106,3254927),(65107,3205260),(65108,2856514),(65109,2785936),(65110,2764231),(65111,2463460),(65112,2686922),(65113,2325728),(65114,2764054),(65115,2521154),(65116,2303262),(65117,2371784),(65118,2295053),(65119,2210324),(65120,2329326),(65121,1937834),(65122,2399813),(65123,1952501),(65124,2101956),(65125,1951118),(65126,2012242),(65127,2117147),(65128,2142095),(65129,2163735),(65130,2681254),(65131,2131314),(65132,1854480),(65133,1529111),(65134,1435653),(65135,1263790),(65136,1402764),(65137,1184314),(65138,1350931),(65139,1154135),(6514 0,1182495),(65141,1203111),(65142,1022864),(65143,1124230),(65144,1094152),(65145,1087222),(65146,1077075),(65147,1239467),(65148,1228547),(65149,1433843),(65150,1273172),(65151,1259204),(65152,1099386),(65153,937862),(65154,687543),(65155,581828),(65156,539869),(65157,544695),(65158,543768),(65159,763107),(65160,743274),(65161,784712),(65162,828184),(65163,752229),(65164,846329),(65165,722793),(65166,701663),(65167,796990),(65168,650668),(65169,702712),(65170,653248),(65171,615653),(65172,630652),(65173,539673),(65174,522847),(65175,570532),(65176,444229),(65177,514219),(65178,415605),(65179,380176),(65180,420473),(65181,348967),(65182,346323),(65183,328704),(65184,278220),(65185,296046),(65186,241344),(65187,233922),(65188,241287),(65189,212600),(65190,210858),(65191,191940),(65192,178499),(65193,179330),(65194,144707),(65195,144777),(65196,139416),(65197,101469),(65198,74313),(65199,50858),(65200,72256),(65201,84655),(65202,92220),(65203,99943),(65204,88669),(65205,85616),(65206,78 993),(65207,67415),(65208,74303),(65209,58630),(65210,55103),(65211,56883),(65212,46748),(65213,49475),(65214,41436),(65215,37959),(65216,40643),(65217,32506),(65218,31785),(65219,30225),(65220,25099),(65221,22224),(65222,13962),(65223,11094),(65224,14827),(65225,16986),(65226,19798),(65227,19115),(65228,16925),(65229,18758),(65230,15753),(65231,15767),(65232,14862),(65233,14233),(65234,14173),(65235,12332),(65236,12170),(65237,11881),(65238,10678),(65239,9412),(65240,8609),(65241,5678),(65242,5362),(65243,5423),(65244,6759),(65245,6775),(65246,7588),(65247,7379),(65248,7469),(65249,6278),(65250,7091),(65251,5700),(65252,6232),(65253,5687),(65254,5296),(65255,5393),(65256,4607),(65257,4603),(65258,3889),(65259,3765),(65260,3311),(65261,3051),(65262,2809),(65263,2542),(65264,1585),(65265,1245),(65266,1751),(65267,2421),(65268,2112),(65269,2403),(65270,2162),(65271,2140),(65272,2124),(65273,2115),(65274,1721),(65275,1948),(65276,1210),(65277,804),(65278,919),(65279,1388),(65280,1540),(6 5281,1473),(65282,1456),(65283,1389),(65284,1348),(65285,1315),(65286,1173),(65287,1086),(65288,1043),(65289,547),(65290,443),(65291,771),(65292,1037),(65293,1068),(65294,988),(65295,954),(65296,999),(65297,801),(65298,1033),(65299,740),(65300,868),(65301,709),(65302,802),(65303,639),(65304,719),(65305,409),(65306,241),(65307,253),(65308,577),(65309,585),(65310,500),(65311,538),(65312,508),(65313,479),(65314,483),(65315,447),(65316,433),(65317,460),(65318,319),(65319,439),(65320,275),(65321,336),(65322,288),(65323,296),(65324,262),(65325,270),(65326,197),(65327,233),(65328,179),(65329,184),(65330,187),(65331,175),(65332,150),(65333,123),(65334,112),(65335,93),(65336,86),(65337,53),(65338,40),(65339,66),(65340,90),(65341,82),(65342,78),(65343,85),(65344,82),(65345,83),(65346,80),(65347,59),(65348,42),(65349,32),(65350,21),(65351,35),(65352,18),(65353,31),(65354,36),(65355,36),(65356,40),(65357,45),(65358,35),(65359,17),(65360,19),(65361,25),(65362,24),(65363,28),(65364,19),(65365,17),( 65366,26),(65367,34),(65368,16),(65369,14),(65370,19),(65371,19),(65372,22),(65373,20),(65374,16),(65375,16),(65376,6),(65377,14),(65378,11),(65379,12),(65380,12),(65381,21),(65382,13),(65383,17),(65384,9),(65385,13),(65386,11),(65387,13),(65388,12),(65389,9),(65390,10),(65391,14),(65392,15),(65393,14),(65394,5),(65395,6),(65396,2),(65397,7),(65398,3),(65399,7),(65400,1),(65401,3),(65402,2),(65403,2),(65405,2),(65406,3),(65407,2),(65408,1),(65409,1),(65410,3),(65411,1),(65412,1),(65413,1),(65414,1),(65415,1),(65417,1),(65418,5),(65421,1),(65422,1),(65423,1),(65424,1),(65425,1),(65426,1),(65427,1),(65429,2),(65439,1),(65447,1),(65448,1),(65451,1),(65461,1),(65462,1),(65465,1),(65468,1),(65470,1),(65475,1),(65481,1),(65482,1))

rr_level0.band0.max_value:  70.53846

rr_level0.band0.min_value:  -9999

rr_level0.band0.number_of_bins:  65536

rr_level0.band0.type:  ossimHistogram

rr_level0.number_of_bands:  1

rr_level0.type:  ossimMultiBandHistogram

type:  ossimMultiResLevelHistogram

 

 

Still, the bins look kind of strange to me? Is it correct that ossim always recognizes the null value as the minimum value?

 

Stefan

 

 

 

 

Von: [hidden email] [[hidden email]]
Gesendet: Dienstag, 21. April 2015 16:06
An: Durejka, Stefan
Cc: ossim
Betreff: Re: AW: [OSSIM] Processing Landsat 8 tiles

 

Hi Stefan,

 

Hey that looks good!  The grass code is out of my jurisdiction. I would think the next release would use 1.8.18.  Not sure about the order.  I don't have the histo match wired into ossim-chipper but you might be interested in the PSM example:

 

 

// This installer just gives you command line apps and ossim-geocell. 

// Doesn't set path so you need to cd to install dir and source the ossim.bat

 

Take care,

Dave

 

 


From: "Stefan Durejka" <[hidden email]>
To: "David Burken" <
[hidden email]>, [hidden email]
Sent: Tuesday, April 21, 2015 9:11:09 AM
Subject: AW: [OSSIM] Processing Landsat 8 tiles

 

Hi Dave,

 

-5555 is the NoData value I assigned to the GeoTIFFs while exporting them from GRASS.  

I  just started another try not assigning a specific NoData value during the export eh voilà ossim seems to be recognizing the correct NoData value now , see the attached picture.

 

But I was wondering if it would be better practice to mosaic the tiles for each band >red,green,blue> before creating a rgb composite?

 And is it planned to bring ossim-1.8.18 into the OSGeoW4 installer?

 

Cheers,

 

Stefan

 

 

Von: David Burken [[hidden email]]
Gesendet: Montag, 20.
April 2015 15:36
An: Durejka, Stefan;
[hidden email]
Betreff: Re: [OSSIM] Processing Landsat 8 tiles

 

Hi,

I've not had any LS8 data.  Is -5555 standard null for that data?  I'd fix the null issue first.  Then I don't think you'd need extract vertices.  To fix the null issue do:

// Just in case:
$ rm <file.omd>

$ ossim-cmm --null -5555 <file>

Then I'd recreate histogram and overviews.

$ ossim-img2rr -r --create-histogram <file>

Note the above two command line apps are being rolled into ossim-preproc but your code is too old for that.

Take care,
Dave

On 04/20/2015 02:43 AM, Durejka, Stefan wrote:

Hi there,

 

I have to mosaic together several Landsat 8 tiles that where pansharpened using Grass 7.0 and exported as RGB composites to GeoTiff. ( I also tried the i.histo.match module in Grass but somehow it fails to produce nice outputs.) Ossim 1.8.16 is set up on Windows 7 using the OSGeo4W 64-bit installer.

 

gdalinfo provides the following data  information for two overlapping example tiles

 

LC81740382014220LGN00_brovey_rgb.tif:

 

Band 1 Block=15123x1 Type=Int16, ColorInterp=Gray

  Min=33.000 Max=32767.000

  Minimum=33.000, Maximum=32767.000, Mean=16251.628, StdDev=9705.333

  NoData Value=-5555

 

LC81740392014236LGN00_brovey_rg:

 

Band 1 Block=15143x1 Type=Int16, ColorInterp=Gray

  Min=0.000 Max=32767.000

  Minimum=0.000, Maximum=32767.000, Mean=16227.811, StdDev=9723.930

  NoData Value=-5555

 

A histogramm for each file was created using

 

ossim-create-histo --disable-elev -i LC81740382014220LGN00_brovey_rgb.tif -o LC81740382014220LGN00_brovey_rgb.his

ossim-create-histo --disable-elev -i LC81740392014236LGN00_brovey_rgb.tif -o LC81740392014236LGN00_brovey_rgb.his

 

Afterwards i tried

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch.tif

 

producing HistMatch.png and

 

ossim-orthoigen --utm --hist-match LC81740392014236LGN00_brovey_rgb.tif --combiner-type ossimFeatherMosaic LC81740382014220LGN00_brovey_rgb.tif LC81740392014236LGN00_brovey_rgb.tif LC81740_histmatch_feather.tif

 

producing MosaicFeather.png.

 

In my opinion I somehow mess up the boundaries of the tiles.

 

In the Histogram Matchin tutorial http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf extract_vertices and cmm are mentioned to define the boundarys of images without rectangular footprint.

 

ossim-extract-vertices LC81740382014220LGN00_brovey_rgb.tif results in a .kwl file like

 

point0.x:  0

point0.y:  0

point1.x:  15122

point1.y:  0

point2.x:  15122

point2.y:  15442

point3.x:  0

point3.y:  15442

 

ossim-extract-vertices LC81740392014236LGN00_brovey_rgb.tif in a file like

 

point0.x:  0

point0.y:  0

point1.x:  15142

point1.y:  0

point2.x:  15142

point2.y:  15482

point3.x:  0

point3.y:  15482

 

Which represents the raster boundaries but not the area where valid values are defined. Ist there a problem with the -5555 no data value? See also in the cmm output

 

ossim-cmm LC81740382014220LGN00_brovey_rgb.tif produces a .omd file

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

ossim-cmm LC81740392014236LGN00_brovey_rgb.tif

 

band1.max_value:  32767

band1.min_value:  -5555

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

 

Do i have to define the boundaries and the messed up no data value manually? And were in the histogram matching process do I have to use the updated .omd and .kwl files?

 

Looking forward to your comments,

 

Stefan

 

 

 

 

 





------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF





_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 



------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Fw: Processing Landsat 8 tiles

Oscar Kramer
Stefan,

I had a similar problem last month. I found the problem and inserted this comment in ossimImageData (line 3639):

            // NOTE (OLK 03/2015): It is a bad idea to ignore pixels with default nulls, as it may
            // be the actual null value being used. By ignoring it, a new null will be latched
            // corresponding to actual, non-null, minimum value. Unfortunately, when tiles are
            // initialized, they are filled with default nulls since (with float-data), the
            // null (if any exists) is not yet known -- effectively creating two null pixel values.
            // The recommendation (if you're looking at this code, then you're probably having the
            // problem that your nulls aren't being recognized), is to turn off the flag in your
            // ossim prefs file with: overview_builder.scan_for_min_max_null_if_float: false
            // (or just delete that line)

You might want to look at that code to see what the problem might be.

Oscar




From: David Burken <[hidden email]>
To: "Durejka, Stefan" <[hidden email]>
Cc: ossim <[hidden email]>
Sent: Wednesday, April 22, 2015 8:22 AM
Subject: Re: [OSSIM] Processing Landsat 8 tiles

Hi,

Float data is always problematic.  Make sure you don't have a phantom <file.omd> file before you start.   You have to tell compute min max code what the null is.  You can always do it manually by creating a file.omd but the code should do it. Example:

ossim-preproc --null -9999 --compute-min-max GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5


$ ossim-preproc --null -9999 --compute-min-max GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5
Processing file: /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5
100%
Finished...
wrote file:  /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.omd
elapsed time in seconds: 0.364

$ cat /data1/hdf5/SVDNB/d20140215_t0124179/GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.omd
band1.max_value:  2.78873558272608e-05
band1.min_value:  -1.50000001308825e-09
band1.null_value:  -9999
bytes_per_pixel:  4
number_bands:  1
scalar_type:  ossim_float32

$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
im$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
im$ ossim-info -i GDNBO-SVDNB_npp_d20140215_t0124179_e0129583_b11927_c20140215162259667633_noaa_ops.h5 | grep null
image0.band0.null_value:  -9999

Once you get that you should be able to create a good histogram.

Hope that helps,
Dave




------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Processing Landsat 8 tiles

David Burken
See below...


On 04/24/2015 03:59 AM, Durejka, Stefan wrote:

Hi There,

 

Oscar: I’m having trouble understanding your note. Does it say that on import ossim fills gaps in the tiles with the value 0 and that leads to problems If the value 0 actually represents a valid entry? This shouldn’t be a problem in my case, where I assigned a null value to my tiles on export from GRASS and therefore no gaps exists?

 

Dave: Wow. Setting the null value and computing the histograms now works like a charm thanks to you. Still one thing troubles me.

 

ossim-preproc --null -9999.0 --compute-min-max --threads 2.4  <directoy>

 

ossim-preproc --create-histogram --threads 2.4 <directory>

 

The 4 files within the directory are in range between 0 and 88 according to the information in the .omd and .his files, and this is the range they should be in.  They are partially overlapping likes this:  File 2 over File 1, File 3 over File 2 and File 4 over File 3.  But after,

 

ossim-orthoigen --utm --hist-match <file1.tif> --combiner-type ossimFeatherMosaic <file1.tif> <file2.tif> <file3.tif> <file4.tif> HistmatchFeather.tif

 

and

 

ossim-preproc --null -9999. –compute-min-max  HistmatchFeather.tif

 

the .omd file looks like

 

band1.max_value:  4.5035996273705e+015

band1.min_value:  -4.44459039905938e+015

band1.null_value:  -9999

bytes_per_pixel:  8

number_bands:  1

scalar_type:  ossim_float64

 

The output actually looks very good, see attached .png but where is the change in min-max range coming from? Shouldn’t it be in the same range as the input files, especially as the file specified for the --hist-match option?

 

I think the data was stretched between the min and max of the scalar type.  That's what I don't understand, i.e. why is your data type a double (8 byte floating point).
Dave

Cheers,

 

Stefan



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Processing Landsat 8 tiles

Durejka, Stefan

Hi Dave,

 

isn’t the double-precision data type a result of the desired precision?

E.g. for tile 1 the data ranges between 0 and 86.6666666666667 and therefore needs 15 significant digits to be displayed correctly. With single-precision floating-point only 6 to 9 significant digits precision is reached. For tile 2 it’s between 0 and 87.5893223819302, and so on. So the double-precision data type is inherited from the GeoTiff?

 

Cheers,

 

Stefan

 

 

Von: David Burken [mailto:[hidden email]]
Gesendet: Freitag, 24. April 2015 13:10
An: Durejka, Stefan; Oscar
Kramer; [hidden email]
Betreff: Re: AW: [OSSIM] Fw: Processing Landsat 8 tiles

 

See below...

On 04/24/2015 03:59 AM, Durejka, Stefan wrote:

Hi There,

 

Oscar: I’m having trouble understanding your note. Does it say that on import ossim fills gaps in the tiles with the value 0 and that leads to problems If the value 0 actually represents a valid entry? This shouldn’t be a problem in my case, where I assigned a null value to my tiles on export from GRASS and therefore no gaps exists?

 

Dave: Wow. Setting the null value and computing the histograms now works like a charm thanks to you. Still one thing troubles me.

 

ossim-preproc --null -9999.0 --compute-min-max --threads 2.4  <directoy>

 

ossim-preproc --create-histogram --threads 2.4 <directory>

 

The 4 files within the directory are in range between 0 and 88 according to the information in the .omd and .his files, and this is the range they should be in.  They are partially overlapping likes this:  File 2 over File 1, File 3 over File 2 and File 4 over File 3.  But after,

 

ossim-orthoigen --utm --hist-match <file1.tif> --combiner-type ossimFeatherMosaic <file1.tif> <file2.tif> <file3.tif> <file4.tif> HistmatchFeather.tif

 

and

 

ossim-preproc --null -9999. –compute-min-max  HistmatchFeather.tif

 

the .omd file looks like

 

band1.max_value:  4.5035996273705e+015

band1.min_value:  -4.44459039905938e+015

band1.null_value:  -9999

bytes_per_pixel:  8

number_bands:  1

scalar_type:  ossim_float64

 

The output actually looks very good, see attached .png but where is the change in min-max range coming from? Shouldn’t it be in the same range as the input files, especially as the file specified for the --hist-match option?

 

I think the data was stretched between the min and max of the scalar type.  That's what I don't understand, i.e. why is your data type a double (8 byte floating point).
Dave


Cheers,

 

Stefan

 


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer