Hi, OTB performs a double coordinate transform using the geodetic system as a "hub" : source projection -> geodetic -> target projection.
I guess that for projection transformations, which are supposed to be very smooth, the field spacing can be reduced without much risk. But the best thing is to measure the differences in a roundtrip for different spacing values : source prj -> target prj -> source prj. The CompareImages application can be useful for this (but excluding the image boundaries to avoid the influence of lost rows and columns). On the OTB side, it would be interesting to see what can be done to avoid the double projection, but I don't have any idea about that. Jordi Laurențiu Nicola <[email protected]> wrote: > > Hi, > > I need to reproject some rasters from one UTM zone to another on the fly. > Right now I'm using otb::GenericRSResampleImageFilter. It works, but the > performance seems really bad. > > A sampling profiler reports: > > 42.97% libm-2.17.so [.] __sin_avx > 20.33% libossim.so.1.8.19 [.] > ossimUtmProjection::Convert_Transverse_Mercator_To_Geodetic > 6.99% libm-2.17.so [.] __ieee754_pow_sse2 > 6.41% libossim.so.1.8.19 [.] > ossimUtmProjection::Convert_Geodetic_To_Transverse_Mercator > 3.46% libm-2.17.so [.] __exp1 > 2.51% libm-2.17.so [.] __tan_avx > 2.32% libm-2.17.so [.] __cos_avx > 2.24% libm-2.17.so [.] __sincos > 1.54% libc-2.17.so [.] _int_free > 1.33% libossim.so.1.8.19 [.] ossimDatum::operator== > [snip] > 0.34% libgdal.so.1.18.4 [.] GDALCopyWords > > $ time otbcli_OrthoRectification -io.in > L8_TEST_L8C_PDTIMG_L2VALD_186052_20160630_FRE.DBL.TIF -io.out bar.tif > -outputs.ulx 799980 -outputs.uly 1200000 -outputs.spacingx 10 > -outputs.spacingy -10 -map.utm.zone 32 -outputs.sizex > 10980 -outputs.sizey 10980 -opt.gridspacing 10 # for some reason the output > size comes out when sizex and sizey are not specified, even if lrx and lry > are set > > 873.86s user 2.23s system 107% cpu 13:36.21 total > > The equivalent gdalwarp invocation, on the other hand, is much faster, even > when not using threads: > > $ time gdalwarp -t_srs EPSG:32632 -tr 10 10 -te 799980 1090200 909780 1200000 > -r cubic L8_TEST_L8C_PDTIMG_L2VALD_186052_20160630_FRE.DBL.TIF foo.tif > > 35.56% libgdal.so.20.0.1 [.] > GWKResampleNoMasksOrDstDensityOnlyHas4SampleThread<short, (GDALResampleAlg)2> > 27.82% libc-2.17.so [.] __memcpy_ssse3_back > 16.19% libgdal.so.20.0.1 [.] GTiffRasterBand::IReadBlock > 8.48% libgdal.so.20.0.1 [.] GTiffRasterBand::IWriteBlock > > 43.74s user 6.14s system 97% cpu 51.028 total > > So in this case gdalwarp is 16-18x faster than the OTB filter. Increasing the > displacement field spacing by 10x decreases the time to 27 seconds, but I > don't know how much influence it has on the output quality. Does gdalwarp use > a > different approach? > > Using VRT files should be a viable alternative, but I've seen poor > performance when reading them through OTB. > > Regards, > Laurentiu > > -- -- -- 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.
