Hi, I've just commited a remote module on GitHub wich deals with image mosaics generation (https://github.com/remicres/otb-mosaic.git). Provided are mosaicing filters and one application. All filters support streaming. The application performs the mosaic generation of multiple images, whith some color/radiometric harmonization features, and feathering features (Details are provided above*)
I hope that you will try and enjoy it. Keep me updated about issues ! Feel free to ask questions, if any. Cheers, Rémi * The application: - From a given input images list, a mosaic is produced. The pipeline supports streaming, so there is no restriction on images number or size. - It implements a color harmonization method explained on our paper: Cresson R., Saint-Geours N., "Natural Color Satellite Image Mosaicking Using Quadratic Programming in Decorrelated Color Space"IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing (Volume:PP , Issue: 99) July 2015 <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7154397&filter%3DAND%28p_IS_Number%3A4609444%29>. In brief, it performs the global colorimetric harmonization of overlapping images in natural colors (i.e. input images must have 3 bands, RGB). You can set the application parameter "-harmo.method" to "rgb" to use this feature. However, the global radiometric harmonization can also be performed on each band individually by setting the application parameter "-harmo.method" to "band" (it can be useful if the color space is not truly RGB like raw Spot6/7, or if you want to perform a kind of radiometric equalized mosaic). Various statistical cost functions can be used (e.g. rmse) to find a correction model (which is linear with zero-y intercept: input images are scaled). We have developed a richer harmonization solver, wich can deal with general linear correction models (i.e. scale, and shift scale of images) but the maths tools brought by VNL were not sufficient, and we had to make use of external libraries to make it work (OOQP, QuadProg++). That is why we brought only simple zero-y intercept (i.e. scale) correction model in this current module. In future release, I think we should propose OOQP based (or QuadProg++ based) solver because it is far more robust than VNL routines (Sometimes VNL's routines throw unexpected errors, obviously coming from numerical instabilities). Waiting what will be the OTB framework for third parties... - As the harmonization method rely of local image statistics, those must be exempt from perturbations (e.g. clouds, ice, brutal landcover change between two images, ...). That's why it is possible to input some vector data to mask valid areas (need one vector data for one input image, in the same order as appearing in input). - It is possible to input some vector data for cutline (need one vector data for one input image, in the same order as appearing in input). - Another cool feature is the feathering/blending of input images, which allows to produce seamless mosaics. The current limitation is that we use a distance map image for each input, computed by itk::DanielssonDistanceMapImageFilter wich is not a streamable filter. That's why the current process first generates all distance map images in temporary .tif files, from resampled input images (the decimation factor can be set using the "-alphamasks.spacing"). Then, the filters use these previously computed distance map images to perform the feathering/blending of the input images. At the moment, 2 feathering methods are implemented (slim: blends the last image over earlier ones in areas of overlap, on a given transition distance / large: blends all images on largests possible overlapping areas) We tested the application successfully on big images collections: RapidEye, France coverage from 2011 (~130 images), Spot6/7, France coverage from 2014 (~190 images), both with a reasonable processing time. Processing time is o(n) for both mosaic generation and statistics computation (n=number of input images pixels). Harmonization problem is solved in o(m) with m=number of input images (about some milliseconds for a hundred of input images). The filters: - otbStreamingMosaicFilterBase: is the base class of all mosaicing filters - otbStreamingSimpleMosaicFilter: inherits otbStreamingMosaicFilterBase, performs simple mosaics with a simple compositing technique which copies the last image over earlier ones in areas of overlap - otbStreamingStatisticsMosaicFilter: inherits otbStreamingMosaicFilterBase, computes statistics of the input images in each overlapping areas (e.g. mean of image i in overlap j, for all i and j) - otbStreamingMosaicFilterWithBlendingBase: inherits otbStreamingMosaicFilterBase, is the base class for all mosaicing filters which use a distance map image (feathering filters...) - otbStreamingFeatherMosaicFilter: inherits otbStreamingMosaicFilterWithBlendingBase, generates a mosaic with blends the last image over earlier ones in areas of overlap, on a given transition distance - otbStreamingLargeFeatherMosaicFilter: inherits otbStreamingMosaicFilterWithBlendingBase, blends all images on largests possible overlapping areas - otbStreamingMultibandFeatherMosaicFilter: inherits otbStreamingFeatherMosaicFilter, experimental. Multiband blending of input image using the laplacian (see Burt & Adelson "A multiresolution spline with application to image mosaics"). Could use GPU support for gaussian filtering. One need to fix some issues related to side effects (around no data pixels of images). - otbSummingFilter: utility filter which sums input images. - otbQuadraticallyConstrainedSimpleSolver: is the solver used for images color/radiometric harmonization. Works only with zero-y intercept correction models (as explained before). We try to make sense of this multilevel inheritance, but it might be perfectible ! A possible optimization might be to process every threadedRegion by subdividing it in multiple smaller regions, in order to loop only on relevant images: an actual drawback is where the threadedRegion is large, a lot of input images have to be checked even if they are out of the region. Another one might be to pre-compute areas where interpolators can work, instead of checking every processed pixel if the current point is inside the buffer. On excellent upgrade would be to strengthen the architecture, and implements those optimizations in a general way (currently, we have to do it for each filter... that is why I think this could be better built) -- -- 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.
