Hi Guillaume, You are right! Now the matching works successfully and generate a DEM. otbcli_ExtractROI -in "/image759.TIF?&skipcarto=true" -startx 0 -starty 0 -sizex 2000 -sizey 2000 -out ./Test_pan_759.tif otbcli_ExtractROI -in "/image771.TIF?&skipcarto=true" -startx 0 -starty 0 -sizex 2000 -sizey 2500 -out ./Test_pan_771.tif
otbcli_StereoFramework -input.il ./Test_pan_759.tif ./Test_pan_771.tif -output.out ./Test_Pan_759_771_DSM_new.tif -elev.dem ./DEM_london -elev.geoid egm96 *[-bm.minhoffset 20 bm.maxhoffset 20 -output.res 1 -output.nodata 0 -bm.metric ncc -postproc.bij 0]* Still seems the generated DEM is not accurate: As the generated DEM shown below, the upper layer is the subset, the background is DEM after matching the entire tile. Obviously the background DEM is correct, while the upper one is not. 1) there are tiles in the upper layer (DEM from subset images), why? Is it because "stereorect.invgridssrate and -stereorect.fwdgridstep"? 2) the image has more noise and no visible ground features, this is no the stretch problem, I have attempted different stretch methods. 3) I notice upper layer DEM value is about 60-70m lower than bottom layer <https://lh4.googleusercontent.com/-guN8IjhXXoE/U_I_hGwF5NI/AAAAAAAAApo/mgiJnwyR-XI/s1600/Pleiades_matching_crop_from_0_0.jpg.jpeg> Another question is the coordinate is still not correct, I "ExtractROI" the tile start from "1000,1000", then generate DEM still stay on the upper-left corner, start from "0,0"? otbcli_ExtractROI -in "/image759.TIF?&skipcarto=true" -startx 1000 -starty 1000 -sizex 2000 -sizey 2000 -out ./Test_pan_759.tif <https://lh6.googleusercontent.com/-Mx7c6lIogjE/U_JGjqk1sdI/AAAAAAAAAqI/GpXODuJtxeQ/s1600/Pleiades_matching_crop_from_1000_1000jpeg.jpeg> the DEM should be in around the redbox. Sorrry for all those questions, I try to have OTB works for me here. Chris, On Thursday, August 14, 2014 3:03:32 AM UTC-4, Guillaume Pasero wrote: > > > > <https://lh6.googleusercontent.com/-Mx7c6lIogjE/U_JGjqk1sdI/AAAAAAAAAqI/GpXODuJtxeQ/s1600/Pleiades_matching_crop_from_1000_1000jpeg.jpeg> > Hi Chris, > > A proper sensor product should give something close to : origin = [0,0] > and spacing = [1,1]. > It seems that you have either : > - an ortho-rectified product > - or a so-called "ortho-ready" product > If ReadImageInfo reports an origin and spacing that look like ground > coordinates, your image won't be used as a sensor image, but as an > ortho-rectified image. The projection reference will be used instead of the > RPC to perform localization. > Please check the latest CookBook version, there is a paragraph on how to > deal with "ortho-ready" images : > http://orfeo-toolbox.org/packages/nightly/latest/CookBook/CookBooksu38.html#x59-820004.2.4 > > If the projection reference is contained in a separate file (as with TIF > world files), you can simply hide this file by renaming it instead of using > extended filenames. > > Regards, > Guillaume > > Le 13/08/2014 23:35, Chris a écrit : > > Hi Guillanume, > > I basically understand how RPC works with the normalized coords after > offset ( usually to the image centre) and scale (on X,Y, and H). But as I > said, since I directly crop the image with ExtractROI, I assume the > subset image will still maintain the correct relationship between image and > RPC. Then it might not need for users to manually revise the subset image > origins? If yes, then how? > > According to ReadImageInfo, here is a summary of the entire image (can > successfully match): > > Image general informations: > > Number of bands : 1 > > Start index : [0,0] > > Size : [9648,9792] > > Origin : [-81.2882,43.0185] > > Spacing : [6.49747e-06,-4.61124e-06] > > Estimated ground spacing (in meters): [0,0] > > Image acquisition informations: > > Sensor : PHR 1A > > Image identification number: 619564101-001 > > Acquisition time : 2013-05-07T16:19:00 > > Image footprint coordinates: > > Upper left corner (latitude, longitude) = [43.0187,-81.2875] > > Upper right corner (latitude, longitude) = [43.0196,-81.2247] > > Lower left corner (latitude, longitude) = [42.9735,-81.2874] > > Lower right corner (latitude, longitude) = [42.9745,-81.2248] > > and the subset (fail to match): > > Image general informations: > > Number of bands : 1 > > Start index : [0,0] > > Size : [2000,2000] > > Origin : [-81.2817,43.0139] > > Spacing : [6.49747e-06,-4.61124e-06] > > Estimated ground spacing (in meters): [0,0] > > Image acquisition informations: > > Sensor : PHR 1A > > Image identification number: 619564101-001 > > Acquisition time : 2013-05-07T16:19:00 > > Image footprint coordinates: > > Upper left corner (latitude, longitude) = [43.0187,-81.2875] > > Upper right corner (latitude, longitude) = [43.0196,-81.2247] > > Lower left corner (latitude, longitude) = [42.9735,-81.2874] > > Lower right corner (latitude, longitude) = [42.9745,-81.2248] > > > Chris, > > On Wednesday, August 13, 2014 3:50:08 AM UTC-4, Guillaume Pasero wrote: > > Hi Chris, > > When dealing with sensor images (without ProjRef), the origin and spacing > are used to locate the image in the full product. If you do an extract of a > full product and that its position is stored in the origin, you can apply > the same RPC because the column/row that will be given to the RPC won't > start at (0,0) but at the start of your ROI. > > If it doesn't work, check that the origin is correctly set with respect to > the full product, and also check that the two extracts actually overlap. > > Regards, > Guillaume > > Le 13/08/2014 05:29, Chris a écrit : > > Hi Jonathan, > > Thank you for the reply. > > If extracROI is the right way to crop the image, then why my entire > image can be successfully matched, whereas the subset image extracted by " > extractROI" cannot match? > > If the entire image and its subset share a same RPC file, but with > different origins, then how OTB can recognize that the image has been > changed? At least the *column/row OFFSET* need to be reset in the RPC? > > Can I alternative modify the RPC file and let OTB read the user-defined > RPC file? I fail to do this, when I modify the "*RPC_###.xml*" comes with > the entire image, and use it for the subset image, by: *otbcli_command > "Subset_Image.tif?&RPC_user_defined.XML"* > > Thank you, > > Chris, > > On Tuesday, August 12, 2014 5:38:20 AM UTC-4, Jonathan Guinet wrote: > > Hi Chris, > > using extractROI on your sensor image affects the origin of the image, > thus the RPC model remains valid, (it can be easilly checkerd unsing > gdalinfo) > > Cheers, > > Jonathan > > > > > 2014-08-11 20:02 GMT+02:00 Chris <[email protected]>: > > Hi, > > I have been attempted to use OTB stereo image matching since 2012, not > got a chance to really let it work. And this time I involved in much more > time and it seems on the right track now. > > I have previously post about OTB installation > <https://groups.google.com/forum/#%21searchin/otb-users/stereo$20framework/otb-users/wANoQ9oHhss/e-ZIQwpfnd0J> > and stereo matching > <https://groups.google.com/forum/#%21profile/otb-users/APn2wQcDet7yykx6xh3fe498XOY19WsE1RahsL9BXiAXF1uKl8kubFdNmTygPJ0uJ1yemTMFJvwn/otb-users/kocntH7LjO8/lQfHi2maLQMJ> > problems > I have encountered. and I have checked some related post to my work, such > as here > <https://groups.google.com/forum/#%21searchin/otb-users/stereo$20framework/otb-users/xEoAwafKjCQ/MYq0XcAtyRMJ> > : > > I have a few issues: > 1. > I *can now successfully *match an entire tile of triple-view Pleiades > image in about 2*10e4 seconds. Please see attached Overview for this DSM. > Due to such a long computation time, I attempt to crop the image first > then match a subset image. > The entire Pleiades tile and subset image information, according to > otbcli_ReadImageInfo, is given in the attached > "Image_information_list.md". > #image subsetting > > ./otbcli_ExtractROI -in /path/to/my/Pleiades/Pan/image/759.TIF -startx > 1000 -starty 1000 -sizex 2000 -sizey 2000 -out > ../../SubsetPleaides/Test_pan_759.tif > ./otbcli_ExtractROI -in /path/to/my/Pleiades/Pan/image/771.TIF -startx > 1000 -starty 1333 -sizex 2000 -sizey 2000 -out > ../../SubsetPleaides/Test_pan_771.tif > > > #stereo matching framework > > ./otbcli_StereoFramework -input.il "Test_pan_759.tif" "Test_pan_771.tif" > -output.res 2 -output.out Test_Pan_759_771_DSM.tif -elev.default 272 > -bm.maxhoffset 120 -bm.minhoffset -120 -bm.radius 3 -ram 6000 > > > # report error: > > 2014 Aug 11 13:03:30 : Application.logger (INFO) Minimum disparity : > *-1.36259e+07* > 2014 Aug 11 13:03:30 : Application.logger (INFO) Maximum disparity : > *1.36259e+07* > ...... > Writing Test_Pan_759_771_DSM.tif...: 0% [ > ]otbApplicationLauncherCommandLine: > /usr/include/ITK-4.5/itkImageConstIterator.h:208: void > ...... > Dimension: 2 > Index: [-13625856, 1321] > Size: [2123, 660] > is *outside of buffered region *ImageRegion (0xd6dd20) > > > Considering the entire tile can match successfully, there should be > something wrong happens during the image crop using "otbcli_ExtractROI" > I have included the "*.geom" files (for both original large tile, and the > subset image) generated by OTB attached to this post. > # the ".geom" of the entire tile is export through ReadImageInfo > > ./otbcli_ReadImageInfo -in /path/to/my/Pleiades/Pan/image/759.TIF > -outkwl Entier_Pleiades_Tile_759.geom > > # the ".geom" of the subset image is generated automatically by > > ./otbcli_ExtractROI -in /path/to/my/Pleiades/Pan/image/759.TIF -startx > 1000 -starty 1000 -sizex 2000 -sizey 2000 -out > ../../SubsetPleaides/Subset_Pleiades_759.tif > > > I already compared these two *.geom files, and I notice there are no > significant changes. > What is the correct method to subset an large satellite image for > matching, preserving its RPC file? > > > 2. What is the* supported RPC formats *for OTB in order load geometry > information correctly? > From a previous post it said RPC modules are inherited from OSSIM, and all > popular satellite formats are supported, such as Worldview, GeoEye, etc. > The XML file comes with Pleiades image works well, but user-defined XML > after subsetting the Pleiades does not work any more, even if in the same > file name and location. > What happened underneath? > > -- > -- > Check the OTB FAQ at > http://www.orfeo-toolbox.org/FAQ.html > > You received this message because you are subscribed to the Google > Groups "otb-users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/otb-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "otb-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > -- > Check the OTB FAQ at > http://www.orfeo-toolbox.org/FAQ.html > > You received this message because you are subscribed to the Google > Groups "otb-users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/otb-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "otb-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > > -- > <http://www.c-s.fr> *Guillaume PASERO* > Ingénieur d'études et développement > *Business Unit E-SPACE & Geo Information* > <https://thor.si.c-s.fr/blogs/cs-blogs-business/>* - Département > APPLICATIONS* > > *CS Systèmes d'Information* > Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 > 31506 Toulouse Cedex 05 - FRANCE > +33 561 17 64 21 - [email protected] > > -- > -- > Chec > > ... -- -- Check the OTB FAQ at http://www.orfeo-toolbox.org/FAQ.html You received this message because you are subscribed to the Google Groups "otb-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/otb-users?hl=en --- You received this message because you are subscribed to the Google Groups "otb-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
